Certificado folha válido, cadeia expirada: leia a profundidade

Você verifica o certificado do servidor, vê meses restantes no relógio, e o cliente ainda recusa a conexão com uma mensagem de expiração. A data que você lê pertence à folha, e a queixa pode ser sobre algo mais profundo no caminho. A verificação percorre uma cadeia, e qualquer certificado que esse percurso selecione pode falhar na sua própria janela de validade. Leia qual falhou antes de renovar qualquer coisa.

A profundidade nomeia o certificado que falhou

No diagnóstico do OpenSSL, a profundidade 0 é o certificado alvo e a profundidade 1 é o emissor que o assinou, com números maiores seguindo em direção à âncora de confiança. Uma expiração reportada na profundidade 1 não é contraditada por um notAfter atual na folha, então verificar novamente o certificado visível nunca explicará o erro.

Anote a impressão digital do certificado que falhou junto com seu subject, porque certificados diferentes podem carregar o mesmo nome de CA. A assinatura cruzada produz exatamente essa situação: a mesma autoridade aparece mais de uma vez, com datas de validade diferentes, e o verificador escolheu a que você não esperava. Um rótulo familiar não é um identificador, e uma impressão digital é o que distingue dois objetos que compartilham um nome.

Observe também produtos com mais de um papel de certificado. No OpenVPN Access Server, os certificados que protegem as interfaces web são separados dos usados para conexões VPN, então um navegador que abre a página de administração não prova nada sobre o caminho do túnel.

As entradas de confiança não são o mesmo que os candidatos da cadeia

Entregue ao verificador as duas entradas separadamente e de forma explícita. O arquivo de confiança contém as âncoras que você aceita; o pacote não confiável contém certificados intermediários oferecidos para construir o caminho. Misturá-los é como as pessoas acidentalmente promovem um intermediário a raiz e depois se perguntam por que o mesmo erro as segue entre máquinas.

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

Desativar o caminho e o armazenamento padrão com -no-CApath -no-CAstore mantém o teste honesto: o resultado depende então dos arquivos que você nomeou, não do que a estação de trabalho confia por acaso. A referência de verificação do OpenSSL documenta essas opções e o diagnóstico que elas produzem.

-show_chain imprime a cadeia construída quando a verificação tem sucesso, o que é útil para confirmar que o caminho é o que você pretendia. Quando falha, mantenha a profundidade e o subject reportados; esses dois campos dizem ao próximo leitor qual certificado inspecionar.

O que isto não faz é reproduzir a política de cada cliente. Um pin, uma restrição de propósito ou uma verificação de identidade específica do cliente vive no cliente, não neste comando. Essas são as configurações a inspecionar quando a verificação passa no servidor e a conexão ainda falha. Mantenha os dois diagnósticos separados, ou você renovará um certificado saudável perseguindo um erro de pinning.

O que a verificação prova e o que deixa de fora

Esta é uma verificação de caminho e propósito contra um arquivo de confiança que você forneceu. Para uma verificação de nome HTTPS, adicione o nome de host esperado pela opção apropriada; para uma conexão VPN, mantenha as verificações de identidade configuradas do cliente e use o material de confiança que esse cliente realmente lê.

O que um servidor envia é um conjunto de candidatos, não o caminho que seu cliente acabará construindo. A confiança local e as regras de construção da biblioteca moldam ambas o resultado, e é por isso que a mesma resposta pode verificar em uma máquina e falhar em outra. Compare o armazenamento de confiança mantido e a implementação TLS do cliente que falha com os de um cliente que funciona antes de supor uma avaliação idêntica. Uma diferença aí explica muitos relatos de «só este portátil falha».

Para ver a janela de cada certificado em vez de um de cada vez, imprima-os como um conjunto:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

Esse segundo comando lista subjects e emissores sem decodificar cada arquivo à mão, e é assim que você percebe um intermediário cuja data já passou enquanto a folha ainda parece bem.

Repare o caminho sem enfraquecer a verificação

Quando um intermediário expirado ou um certificado assinado cruzado obsoleto é fornecido, obtenha a cadeia atualmente suportada do emissor e implante-a pelo fluxo de trabalho de certificados documentado do serviço. Quando o cliente não tem a âncora mantida pretendida, atualize a sua configuração de confiança gerenciada ou o software do cliente. Resista ao atalho de marcar cada certificado do pacote como raiz apenas para silenciar a mensagem.

O tratamento da raiz merece uma nota, porque os resumos muitas vezes o exageram. O RFC 5280 trata a âncora como uma entrada que fica fora do caminho prospectivo, enquanto o OpenSSL documenta verificações de validade que incluem o seu certificado CA raiz. Ambas as afirmações são verdadeiras para os seus próprios sistemas; generalizar o comportamento de expiração da raiz de uma biblioteca para todos os clientes produz respostas erradas com confiança.

Após a mudança, force uma nova autenticação no cliente afetado e confirme que a mensagem de expiração específica desapareceu. Renove a folha apenas se a própria folha for inadequada. Desativar as verificações de tempo ou restaurar um certificado cruzado histórico não produz um caminho atual válido; apenas atrasa a próxima falha.