Conceito e mecanismo
Um certificado associa uma chave pública a identidades e restrições, com assinatura de um emissor. A chave privada continua separada e deve permanecer protegida; partilhar o certificado não exige entregar esse segredo. A validação precisa de construir um caminho até uma âncora que o cliente já confia segundo a política aplicável. Certificados intermédios ajudam a construir esse caminho, mas não ganham confiança só porque o servidor os envia. Formato PEM, nome do ficheiro e presença de uma assinatura não provam, por si, que o cliente deve confiar no emissor. Mantém separados os papéis de material apresentado e confiança aprovada.
Aplicação guiada
Num caso fictício, um browser funciona porque já dispõe de material intermédio, enquanto um cliente novo falha com o mesmo leaf. Se a raiz é aprovada e falta o intermédio, corrige a cadeia apresentada e valida sem depender de cache. Não transformes o leaf numa raiz improvisada para ocultar a falha. Depois de uma rotação de chave, compara as componentes públicas do certificado e da chave privada para confirmar o par, sem divulgar o segredo. Verifica também o propósito: um certificado limitado a clientAuth não se torna automaticamente adequado a serverAuth por ter cadeia e nome corretos. Identidade, confiança, validade e uso permitido são dimensões complementares.
Raiz aprovada e leaf válido não bastam se o cliente não consegue construir o caminho intermédio.
Armadilhas comuns
Chave privada como material de diagnóstico partilhável; cadeia recebida como confiança; PEM como correspondência; propósito ignorado.
Tópicos relacionados: Identidade, nome e tempo · Negociação, mTLS e aplicação · Renovação e certificado servido
Valida o caminho, o par e o uso sem expor a chave privada.
Referência: X.509 certificates and path validation · DR TLS/certificates 2026-09; selected TLS 1.2/1.3, RFC 9525 identity and OpenSSL 3.5 diagnostics