Propòsit de certificat no suportat: per què falla la CA intermèdia

El propòsit del certificat del servidor sembla correcte, la clau coincideix, les dates són correctes, i la connexió continua fallant amb unsupported certificate purpose. El detall que ho resol sol ser a la mateixa línia que l'error: un valor de profunditat i un subjecte que anomenen un certificat més amunt de la cadena. S'executen dues proves diferents, i només una tracta del certificat final. Comparar-les explica per què substituir el certificat del servidor no canvia res.

Quin certificat va rebutjar realment el verificador

Una cadena no és un objecte repetit tres vegades. El certificat final porta el nom i la clau del servidor, les intermèdies l'enllacen amb una arrel, i cadascun té el seu període de validesa, restriccions i usos. Quan l'error anomena una profunditat, aquest número identifica una posició en la cadena que ha construït el verificador, que pot no ser la posició que espereu si el servidor envia una cadena inesperada.

Llegiu els camps del certificat en aquella profunditat i no el certificat que heu suposat que era el culpable. Demaneu les dues extensions que restringeixen l'emissió en lloc d'abocar tots els camps, perquè la resposta gairebé sempre és en una d'elles. La sortida de les extensions es pot compartir; les claus privades, mai.

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

Si el certificat anomenat és una intermèdia l'ús estès de clau de la qual esmenta alguna cosa no relacionada amb l'autenticació del servidor TLS, la resta de la fallada se segueix mecànicament. La cadena no es pot fer servir per al propòsit que OpenVPN ha demanat.

El propòsit del certificat final i la política de la cadena són dues proves

La prova del certificat final fa una pregunta estreta: aquest certificat d'entitat final permet l'autenticació del servidor per a aquest nom? La prova de la cadena en fa una de més àmplia: pot cada certificat del camí servir aquest propòsit? Una autoritat de certificació que només pot emetre certificats de client passarà les seves pròpies comprovacions de signatura i tot i així fallarà la segona prova, perquè el camí que autoritza no inclou el propòsit que necessita l'aplicació. Les dues proves fallen amb les mateixes paraules i tenen reparacions completament diferents.

Per això un certificat final acabat d'emetre, correcte en tots els camps visibles, pot fallar immediatament. També per això la correcció sol pertànyer al perfil de l'autoritat emissora i no a la configuració de la VPN.

Un EKU absent no és un EKU restrictiu

La RFC 5280 fa opcional l'extensió d'ús estès de clau i, quan hi és, restrictiva. Un certificat de CA sense l'extensió, doncs, no ha dit «no» a l'autenticació del servidor, mentre que un que només llista un propòsit no relacionat ha dit una cosa molt concreta. Tractar aquests dos estats com a equivalents produeix un diagnòstic equivocat i, pitjor, una reparació equivocada. La distinció també explica per què dues autoritats que semblen iguals en una consola es comporten de manera ben diferent en una cadena.

El comportament de les biblioteques aquí tampoc no és uniforme. document d'OpenSSL sobre les opcions de verificació descriu el seu propi tractament de les comprovacions de propòsit en certificats de CA, i aquest tractament és una política d'implementació, no una regla que totes les piles TLS segueixin de manera idèntica. Descriu què fa el vostre verificador i després confirmeu-ho amb la versió que realment executeu.

Reproduïu la fallada fora de línia abans de reemetre

Una verificació fora de línia treu l'aplicació de la qüestió. Si la cadena falla de la mateixa manera amb el mateix propòsit, el problema és el certificat i cap configuració del servidor no ho amagarà. Si la cadena passa fora de línia mentre el servei encara refusa, l'aplicació demana un propòsit diferent o utilitza una cadena diferent de la que heu provat.

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

-show_chain importa perquè imprimeix el camí que ha construït l'eina, que sovint no és l'ordre de fitxers que heu proporcionat. Aquesta sortida és la manera més ràpida de descobrir que s'està estirant una segona intermèdia d'un magatzem de confiança, que el servidor envia una variant signada creuadament que no volíeu, o que el senyal de propòsit que heu copiat d'un tutorial pertany a un rol diferent del que se serveix.

Corregiu la política d'emissió, no la crida de verificació

La reparació duradora és una intermèdia emesa sota una política que permet els propòsits que ha de servir, amb la restricció escrita i revisada. Afegir tots els propòsits a totes les autoritats no és una política; elimina la restricció que feia significativa l'extensió i normalment sobreviu a l'incident que la va provocar. Una nota breu al perfil que descrigui quins rols pot certificar l'autoritat evita que la propera reemissió repeteixi la mateixa discussió.

Desactivar la verificació és l'altra drecera temptadora, i converteix un problema de certificat en un problema de confiança. Manteniu la comprovació de propòsit, corregiu la cadena i torneu a executar la mateixa verificació fora de línia per confirmar que el camí ara serveix el rol previst abans de tocar el servei de nou.