finalidade de certificado não suportada: por que a CA intermediária falha

A finalidade do certificado do servidor parece correta, a chave corresponde, as datas estão certas, e a conexão ainda falha com unsupported certificate purpose. O detalhe que resolve isso geralmente está na mesma linha do erro: um valor de profundidade e um subject que nomeiam um certificado mais acima na cadeia. Dois testes diferentes são executados, e apenas um deles trata do certificado final. Compará-los explica por que substituir o certificado do servidor não muda nada.

Qual certificado o verificador realmente rejeitou

Uma cadeia não é um objeto repetido três vezes. O certificado final carrega o nome e a chave do servidor, os intermediários ligam-no a uma raiz, e cada um tem seu próprio período de validade, restrições e usos. Quando o erro nomeia uma profundidade, esse número identifica uma posição na cadeia que o verificador construiu, e pode não ser a posição que você espera se o servidor enviar uma cadeia inesperada.

Leia os campos do certificado nessa profundidade em vez do certificado que você presumiu culpado. Peça as duas extensões que restringem a emissão em vez de despejar todos os campos, porque a resposta quase sempre está em uma delas. A saída das extensões pode ser compartilhada; as chaves privadas nunca.

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

Se o certificado nomeado for um intermediário cujo uso estendido de chave mencione algo alheio à autenticação de servidor TLS, o restante da falha segue mecanicamente. A cadeia não pode ser usada para a finalidade que OpenVPN solicitou.

A finalidade do certificado final e a política da cadeia são dois testes

O teste do certificado final faz uma pergunta estreita: este certificado de entidade final permite a autenticação de servidor para este nome? O teste da cadeia faz uma mais ampla: cada certificado do caminho pode servir a essa finalidade? Uma autoridade de certificação autorizada a emitir apenas certificados de cliente passará nas suas próprias verificações de assinatura e ainda assim falhará no segundo teste, porque o caminho que autoriza não inclui a finalidade de que a aplicação precisa. Os dois testes falham com as mesmas palavras e têm reparos completamente diferentes.

Por isso um certificado final recém-emitido, correto em todos os campos visíveis, pode falhar imediatamente. Também por isso a correção costuma pertencer ao perfil da autoridade emissora e não à configuração da VPN.

Uma EKU ausente não é uma EKU restritiva

A RFC 5280 torna a extensão de uso estendido de chave opcional e, quando presente, restritiva. Um certificado de CA sem a extensão, portanto, não disse «não» à autenticação de servidor, enquanto um que lista apenas uma finalidade alheia disse algo muito específico. Tratar esses dois estados como equivalentes produz o diagnóstico errado e, pior, o reparo errado. A distinção também explica por que duas autoridades que parecem iguais em um console se comportam de forma totalmente diferente numa cadeia.

O comportamento das bibliotecas também não é uniforme aqui. documento do OpenSSL sobre as opções de verificação descreve o próprio tratamento das verificações de finalidade em certificados de CA, e esse tratamento é uma política de implementação, não uma regra que toda pilha TLS segue de forma idêntica. Descreva o que o seu verificador faz e depois confirme com a versão que você realmente executa.

Reproduza a falha offline antes de reemitir

Uma verificação offline tira a aplicação da equação. Se a cadeia falhar da mesma forma com a mesma finalidade, o problema é o certificado e nenhuma configuração de servidor o esconderá. Se a cadeia passar offline enquanto o serviço continua recusando, a aplicação está pedindo outra finalidade ou usando uma cadeia diferente da testada.

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

-show_chain importa porque imprime o caminho que a ferramenta construiu, e esse caminho muitas vezes não é a ordem de arquivos que você forneceu. Essa saída é a forma mais rápida de descobrir que um segundo intermediário está sendo puxado de um armazenamento de confiança, que o servidor envia uma variante assinada de forma cruzada que você não pretendia, ou que o sinalizador de finalidade copiado de um tutorial pertence a um papel diferente do que está sendo servido.

Corrija a política de emissão, não a chamada de verificação

O reparo duradouro é um intermediário emitido sob uma política que permite as finalidades que ele deve servir, com a restrição escrita e revisada. Adicionar todas as finalidades a todas as autoridades não é uma política; isso remove a restrição que dava sentido à extensão e costuma sobreviver ao incidente que a motivou. Uma nota curta no perfil descrevendo quais papéis a autoridade pode certificar evita que a próxima reemissão repita a mesma discussão.

Desativar a verificação é o outro atalho tentador, e converte um problema de certificado em um problema de confiança. Mantenha a verificação de finalidade, corrija a cadeia e execute novamente a mesma verificação offline para confirmar que o caminho agora serve ao papel pretendido antes de tocar no serviço de novo.