Criação e Gerenciamento de Cadeias de Certificados

Uma CA raiz é um certificado autoassinado que serve como âncora de confiança máxima. A chave privada da CA raiz deve ser mantida desconectada (em um sistema isolado de redes ou HSM), pois seu comprometimento abala toda a PKI. "openssl req -x509 -new -nodes -key root_key.pem -sha256 -days 3650 -out root_cert.pem" gera um certificado raiz autoassinado válido por 10 anos.

As CA intermediárias são assinadas pela CA raiz e usadas para a emissão cotidiana de certificados. Primeiro, gere a chave e a CSR da CA intermediária: "openssl req -new -key intermediate_key.pem -out intermediate.csr". Em seguida, a CA raiz a assina: "openssl x509 -req -in intermediate.csr -CA root_cert.pem -CAkey root_key.pem -CAcreateserial -days 1825 -out intermediate_cert.pem".

Os certificados de entidade final (certificados folha) são assinados pela CA intermediária para servidores ou clientes específicos. Gere a chave e a CSR do servidor com nomes alternativos do assunto (SAN) e, em seguida, assine com a CA intermediária: "openssl x509 -req -in server.csr -CA intermediate_cert.pem -CAkey intermediate_key.pem -CAcreateserial -extensions v3_req -days 365 -out server_cert.pem".

A chave privada da CA raiz é mantida desconectada e usada somente para assinar um pequeno número de certificados de CA intermediárias. A emissão cotidiana de certificados é realizada por CA intermediárias conectadas à rede. Se uma CA intermediária for comprometida, ela poderá ser revogada e substituída sem comprometer a raiz. A chave raiz permanece segura porque nunca foi exposta na internet.

O comando "openssl ca" oferece um fluxo de trabalho de CA mais completo do que "openssl x509 -req". Ele mantém um banco de dados de certificados (index.txt), atribui números de série a partir de um arquivo de números de série e lida com a geração de CRL. Ele exige um arquivo de configuração openssl.cnf adequado, com seções específicas da CA que definem a política de certificados e as restrições de comprimento do caminho de certificação.

Um arquivo completo da cadeia de certificados para um servidor da web contém o certificado de entidade final seguido pelos certificados de CA intermediárias na ordem, terminando imediatamente antes da raiz. Os certificados raiz não são incluídos porque os navegadores já têm repositórios raiz instalados. Ordem de concatenação: "cat server_cert.pem intermediate_cert.pem > chain.pem". A ordem incorreta causa falhas na negociação do TLS.

"openssl verify -CAfile root_cert.pem -untrusted intermediate_cert.pem server_cert.pem" verifica a cadeia completa. A opção "-untrusted" fornece certificados intermediários que fazem parte da cadeia, mas ainda não são confiáveis. Se a verificação for bem-sucedida, a saída será "server_cert.pem: OK". Erros comuns indicam certificados intermediários ausentes ou certificados expirados.

Entre os problemas frequentes nas cadeias de certificados estão: certificados intermediários ausentes (o servidor envia somente o certificado folha), ordem de concatenação incorreta (o certificado folha deve vir primeiro), certificado intermediário expirado (facilmente ignorado, pois a expiração do certificado folha é monitorada), certificados autoassinados que não estão no repositório de confiança e incompatibilidade de nome (o SAN do certificado não corresponde ao nome do host). Todos podem ser diagnosticados com "openssl s_client -showcerts".

PKCS#12 (.pfx ou .p12) é um formato de contêiner que reúne a chave privada, o certificado de entidade final e os certificados intermediários em um único arquivo criptografado. Crie-o com: "openssl pkcs12 -export -out bundle.pfx -inkey server_key.pem -in server_cert.pem -certfile intermediate_cert.pem". É exigido pelo IIS, pelo .NET, pelos armazenamentos de chaves do Java e por muitos aplicativos empresariais.

PEM é ASCII codificado em base64, legível por seres humanos, aceita vários objetos em um arquivo e é usado pelo Apache, pelo nginx e pelas ferramentas do OpenSSL. DER é binário, contém um objeto por arquivo e é usado pelo Java (para importações em JKS), pelo Android e por algumas ferramentas empresariais. PKCS#12/PFX é um contêiner binário criptografado para vários objetos, usado pelo Windows e pelo IIS. Antes de implantar, verifique qual formato o sistema de destino espera.

As CA modernas são obrigadas a registrar todos os certificados emitidos em registros de Transparência de certificados (CT) antes da entrega. Ao criar uma CA privada para uso interno, o registro no CT não é obrigatório. No entanto, certificados voltados ao público devem conter SCT incorporados para serem confiáveis pelo Chrome. As CA privadas podem adotar suas próprias políticas sem requisitos de CT.

Ao montar um arquivo de cadeia de certificados TLS para um servidor nginx, qual é a ordem correta de concatenação?

As CA raiz são autoassinadas, mantidas desconectadas e assinam somente certificados intermediários. As CA intermediárias cuidam da emissão cotidiana. Os arquivos de cadeia contêm o certificado folha e depois os intermediários (a raiz é omitida). Verifique com "openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem". Os pacotes PKCS#12 reúnem chave e certificados para Windows/Java. A ordem incorreta da cadeia é um modo comum de falha na implantação, diagnosticável com s_client -showcerts.