propósito de certificado non admitido: por que falla a CA intermedia

O propósito do certificado do servidor parece correcto, a chave coincide, as datas están ben, e a conexión segue fallando con unsupported certificate purpose. O detalle que o resolve adoita estar na mesma liña que o erro: un valor de profundidade e un subject que nomean un certificado máis arriba na cadea. Execútanse dúas probas distintas, e só unha delas trata do certificado final. Comparalas explica por que substituír o certificado do servidor non cambia nada.

Que certificado rexeitou realmente o verificador

Unha cadea non é un obxecto repetido tres veces. O certificado final leva o nome e a chave do servidor, os intermedios enlázano cunha raíz, e cada un ten o seu propio período de validez, restricións e usos. Cando o erro nomea unha profundidade, ese número identifica unha posición na cadea que construíu o verificador, e pode que non sexa a posición que espera se o servidor envía unha cadea inesperada.

Lea os campos do certificado nesa profundidade en lugar do certificado que supuxo culpable. Pida as dúas extensións que restrinxen a emisión en vez de volcar todos os campos, porque a resposta case sempre está nunha delas. A saída das extensións pódese compartir; as chaves privadas nunca.

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

Se o certificado nomeado é un intermedio cuxo uso estendido de chave menciona algo alleo á autenticación de servidor TLS, o resto do fallo séguise mecanicamente. A cadea non se pode usar para o propósito que solicitou OpenVPN.

O propósito do certificado final e a política da cadea son dúas probas

A proba do certificado final fai unha pregunta estreita: permite este certificado de entidade final a autenticación de servidor para este nome? A proba da cadea fai unha máis ampla: pode cada certificado da ruta servir ese propósito? Unha autoridade de certificación autorizada a emitir só certificados de cliente pasará as súas propias comprobacións de sinatura e aínda así fallará a segunda proba, porque a ruta que autoriza non inclúe o propósito que necesita a aplicación. As dúas probas fallan coas mesmas palabras e teñen reparacións completamente distintas.

Por iso un certificado final recentemente emitido, correcto en todos os campos visibles, pode fallar de inmediato. Tamén por iso a corrección adoita pertencer ao perfil da autoridade emisora e non á configuración da VPN.

Un EKU ausente non é un EKU restritivo

A RFC 5280 fai opcional a extensión de uso estendido de chave e, cando está presente, restritiva. Un certificado de CA sen a extensión, por tanto, non dixo «non» á autenticación de servidor, mentres que un que só enumera un propósito alleo dixo algo moi concreto. Tratar eses dous estados como equivalentes produce o diagnóstico equivocado e, peor, a reparación equivocada. A distinción tamén explica por que dúas autoridades que parecen iguais nunha consola se comportan de forma totalmente distinta nunha cadea.

O comportamento das bibliotecas tampouco é uniforme aquí. documento de OpenSSL sobre as opcións de verificación describe o seu propio tratamento das comprobacións de propósito en certificados de CA, e ese tratamento é unha política de implementación, non unha regra que todas as pilas TLS sigan de xeito idéntico. Describa o que fai o seu verificador e despois confírmeo coa versión que executa realmente.

Reproduza o fallo sen conexión antes de reemitir

Unha verificación sen conexión saca a aplicación da ecuación. Se a cadea falla igual co mesmo propósito, o problema é o certificado e ningunha configuración do servidor o ocultará. Se a cadea pasa sen conexión mentres o servizo segue negándose, a aplicación solicita outro propósito ou usa unha cadea distinta da que probou.

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

-show_chain importa porque imprime a ruta que construíu a ferramenta, que a miúdo non é a orde de ficheiros que forneceu. Esa é a forma máis rápida de descubrir que se está a extraer un segundo intermedio dun almacén de confianza, que o servidor envía unha variante asinada de forma cruzada que non pretendía, ou que a marca de propósito que copiou dun titorial pertence a un rol distinto do que se serve.

Corrixa a política de emisión, non a chamada de verificación

A reparación duradeira é un intermedio emitido baixo unha política que permite os propósitos que debe servir, coa restrición escrita e revisada. Engadir todos os propósitos a todas as autoridades non é unha política; elimina a restrición que daba sentido á extensión e adoita sobrevivir ao incidente que a motivou. Unha nota breve no perfil que describa que roles pode certificar a autoridade evita que a seguinte reemisión repita a mesma discusión.

Desactivar a verificación é o outro atallo tentador, e converte un problema de certificado nun problema de confianza. Manteña a comprobación de propósito, corrixa a cadea e volva executar a mesma verificación sen conexión para confirmar que a ruta xa serve o rol previsto antes de tocar o servizo de novo.