Certificat full vàlid, cadena caducada: llegeix la profunditat

Comproves el certificat del servidor, veus mesos restants al rellotge i el client encara rebutja la connexió amb un missatge de caducitat. La data que llegeixes pertany al full, i la queixa pot ser sobre alguna cosa més profunda al camí. La verificació recorre una cadena, i qualsevol certificat que aquest recorregut triï pot fallar en la seva pròpia finestra de validesa. Llegeix quin ha fallat abans de renovar res.

La profunditat nomena el certificat que ha fallat

A la diagnosi d'OpenSSL, la profunditat 0 és el certificat objectiu i la profunditat 1 és l'emissor que el va signar, amb nombres més alts que continuen cap a l'àncora de confiança. Una caducitat informada a la profunditat 1 no queda contradita per un notAfter vigent al full, així que tornar a comprovar el certificat visible mai no explicarà l'error.

Anota l'empremta del certificat fallit juntament amb el seu subjecte, perquè certificats diferents poden portar el mateix nom de CA. La signatura creuada produeix exactament aquesta situació: la mateixa autoritat apareix més d'una vegada, amb dates de validesa diferents, i el verificador va triar la que no esperaves. Una etiqueta familiar no és un identificador, i una empremta és el que distingeix dos objectes que comparteixen nom.

Vigila també els productes amb més d'un rol de certificat. A OpenVPN Access Server, els certificats que protegeixen les interfícies web són separats dels que s'utilitzen per a les connexions VPN, així que un navegador que obre la pàgina d'administració no demostra res sobre el camí del túnel.

Les entrades de confiança no són el mateix que els candidats de cadena

Dona al verificador les dues entrades per separat i explícitament. El fitxer de confiança conté les àncores que acceptes; el paquet no fiable conté certificats intermedis oferts per construir el camí. Barrejar-los és com la gent promou per accident un intermediari a arrel i després es pregunta per què el mateix error els segueix entre màquines.

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

Desactivar el camí i el magatzem per defecte amb -no-CApath -no-CAstore manté la prova honesta: el resultat aleshores depèn dels fitxers que has anomenat, no del que l'estació de treball confia per casualitat. La referència de verificació d'OpenSSL documenta aquestes opcions i la diagnosi que produeixen.

-show_chain imprimeix la cadena construïda quan la verificació té èxit, cosa útil per confirmar que el camí és el que pretenies. Quan falla, conserva la profunditat i el subjecte informats; aquests dos camps diuen al següent lector quin certificat cal inspeccionar.

El que no fa és reproduir la política de cada client. Un pin, una restricció de propòsit o una comprovació d'identitat específica del client viu al client, no en aquesta ordre. Aquests són els paràmetres a inspeccionar quan la verificació passa al servidor i la connexió encara falla. Mantén les dues diagnosis separades, o renovaràs un certificat sa perseguint un error de pinning.

Què demostra la comprovació i què deixa fora

Aquesta és una comprovació de camí i propòsit contra un fitxer de confiança que has subministrat. Per a una comprovació de nom HTTPS, afegeix el nom d'amfitrió esperat amb l'opció adequada; per a una connexió VPN, mantén les comprovacions d'identitat configurades del client i utilitza el material de confiança que aquest client llegeix realment.

El que un servidor envia és un conjunt de candidats, no el camí que el teu client acabarà construint. La confiança local i les regles de construcció de la biblioteca formen totes dues el resultat, i per això la mateixa resposta pot verificar-se en una màquina i fallar en una altra. Compara el magatzem de confiança mantingut i la implementació TLS del client que falla amb els d'un client que funciona abans de suposar una avaluació idèntica. Una diferència aquí explica molts informes de «només falla aquest portàtil».

Per veure la finestra de cada certificat en lloc d'un a la vegada, imprimeix-los com a conjunt:

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

Aquesta segona ordre llista subjectes i emissors sense descodificar cada fitxer a mà, i així detectes un intermediari la data del qual ha passat mentre el full encara sembla bé.

Repara el camí sense debilitar la verificació

Quan se subministra un intermediari caducat o un certificat creuat obsolet, obtén la cadena actualment suportada de l'emissor i desplega-la pel flux de certificats documentat del servei. Quan al client li falta l'àncora mantinguda prevista, actualitza la seva configuració de confiança gestionada o el programari del client. Resist-te a la drecera de marcar cada certificat del paquet com a arrel només per silenciar el missatge.

El tractament de l'arrel mereix una nota, perquè els resums sovint l'exageren. RFC 5280 tracta l'àncora com una entrada que queda fora del camí prospectiu, mentre que OpenSSL documenta comprovacions de validesa que inclouen el seu certificat CA arrel. Totes dues afirmacions són certes per als seus propis sistemes; generalitzar el comportament de caducitat de l'arrel d'una biblioteca a tots els clients produeix respostes errònies amb seguretat.

Després del canvi, força una autenticació nova al client afectat i confirma que el missatge de caducitat específic ha desaparegut. Renova el full només si el full mateix no és adequat. Desactivar les comprovacions de temps o restaurar un certificat creuat històric no produeix un camí actual vàlid; només ajorna la propera fallada.