Anteriormente, os DCs usavam um certificado auto-assinado comum formatado, comum (em todos os DCs) para permitir que os LDAPS para os APCs no datacenter fossem autenticados. O Cisco UCS não aceitaria o certificado autoassinado para criar 'Trust Points'. Para habilitar a mesma funcionalidade para o UCS, determinou-se que o certificado usado deve ser encadeado. O teste indicou que não importa se o certificado raiz ao qual o certificado de host está encadeado é uma autoridade de certificação válida ou se era uma autoridade de certificação autoassinada. Dessa forma, decidimos criar uma nova CA autoassinada e depois assinar o certificado LDAP da DC. Isso é bastante padrão, com exceção do requisito especial de SANs (nomes alternativos de assunto) necessário para que o LDAPS funcione em vários controladores de domínio acessados pelo nome de domínio.
Foram feitos os melhores esforços para gerar o certificado necessário por meio das ferramentas do Windows, mas, se possível, é tão mal documentado que determinamos que seria rápido gerá-los em uma máquina Linux e copiá-los para o domínio posteriormente. O método abaixo permite gerar os certificados sem configurar uma estrutura CA completa usando a funcionalidade "mini CA" de "openssl x509" ( link ).
Gere a chave privada para o certificado de autoridade de certificação e o próprio certificado de autoridade de certificação por procedimento padrão:
openssl genrsa -des3 -out ldapCA.key 4096 openssl req -x509 -new -nodes -key ldapCA.key -days 3650 -out ldapCA.pem
Crie um arquivo de configuração de certificado para o certificado LDAP do host que contém a seção v3_req necessária para suportar SANs:
[req] distinguished_name = req_distinguished_name req_extensions = v3_req prompt = no [req_distinguished_name] C = US ST = NC L = XXX O = YYY OU = ZZZ CN = [v3_req] basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment extendedKeyUsage = serverAuth subjectAltName = @alt_names [alt_names] DNS.1 = DNS.2 = DNS.3 = DNS.4 = DNS.5 =
Após falhas repetidas para gerar o certificado correto usando a configuração de solicitação acima, descobrimos que a opção x509 para o openssl não copia as extensões do CSR ( link )
OpenSSL has two ways to create a cert from a CSR: 'ca' # the original most complete way 'x509 -req' # a simplified way without the 'database' etc. Only 'ca' fully uses the config file settings and in particular copy_extensions. 'x509 -req' can use the config file for extensions but nothing else. Use 'ca' if you want to copy extensions from the CSR. You *can* use 'x509 -req' and put extensions including SAN in the config file at 'x509 -req' time (not 'req -new' time), and that's good for CA-related extensions like crldp, but you usually want SAN to vary for each cert.
Para corrigir isso, precisamos criar um segundo arquivo apenas com as extensões: <
basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment extendedKeyUsage = serverAuth subjectAltName = DNS:, DNS:, DNS:,DNS:,DNS:
Não ficou claro se os mesmos dados precisavam para estar no CSR e no arquivo de extensões, mas funcionam em ambos. Nesse ponto, podemos gerar o certificado de host usando a CA, a chave CA, o arquivo de solicitação de certificado e o arquivo de extensão e, em seguida, verificar o certificado resultante:
openssl x509 -days 1460 -req -CA ldapCA.pem -CAkey ldapCA.key -CAcreateserial -in ldapSAN.csr -out ldapSAN.pem -extfile ext.txt openssl x509 -text -noout -in ldapSAN.pem
A saída da verificação deve mostrar que é um certificado v3, é assinada pela autoridade de certificação e deve mostrar a seção SAN preenchida com o FQDN de cada controlador de domínio:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: ()
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=, ST=, L=, O=, OU=, CN=/emailAddress=
Validity
Not Before: Mar 5 16:36:10 2015 GMT
Not After : Mar 4 16:36:10 2019 GMT
Subject: C=, ST=, L=, O=, OU=, CN=
Subject Public Key Info:
[...]
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Subject Alternative Name:
DNS:, DNS:, DNS:, DNS:, DNS:
Signature Algorithm: sha1WithRSAEncryption
[...]
Para importar os certificados e usá-los nos DCs, temos que exportar o certificado do host com a chave privada no formato pkcs12 (pfx):
openssl pkcs12 -export -out ldapSAN.pfx -inkey ldapSAN.key -in ldapSAN.pem -certfile ldapCA.pem
Por fim, instalamos a versão pública do certificado de CA, neste caso ldapCA.pem , no armazenamento Autoridades de certificação raiz confiáveis da conta de computador de cada controlador de domínio. Isso pode ser feito com ferramentas de administração remota, localmente em cada servidor ou por meio do GPO. Em seguida, instalamos o certificado do host e a chave privada em cada servidor. Esse deve ser feito localmente, pois a importação de pfx com informações de chave privada não é possível remotamente:
CERTUTIL -f -p <password> -importpfx ldapSAN.pfx
Neste momento, os DCs podem apenas pegar o certificado automaticamente ( link ):
Finally, if a Windows Server 2008 or a later version domain controller finds multiple certificates in its store, it automatically selects the certificate whose expiration date is furthest in the future. Then, if your current certificate is approaching its expiration date, you can drop the replacement certificate in the store, and AD DS automatically switches to use it.
Em nosso caso, como os certificados anteriores tinham uma data de expiração após os novos, tivemos que excluir os certificados antigos antes que cada controlador de domínio usasse o novo. Você pode verificar o certificado em uso pelo serviço LDAP com o seguinte (o NAGIOS também verifica isso):
openssl s_client -connect <FQDN of DC>:636 -showcerts
A saída conterá informações semelhantes à verificação de certificado que fizemos acima.
Neste ponto, você pode fornecer os certificados públicos a qualquer cliente que precise deles. Alguns podem exigir apenas a AC, alguns podem exigir apenas o certificado de host e alguns podem exigir um único arquivo com toda a cadeia.
Tanto o UCS quanto o APC foram reconfigurados pelo SR para se conectar aos novos certificados.
w00t