Certificado folla válido, cadea caducada: le a profundidade

Comprobas o certificado do servidor, ves meses restantes no reloxo e o cliente segue rexeitando a conexión cunha mensaxe de caducidade. A data que les pertence á folla, e a queixa pode ser sobre algo máis profundo na ruta. A verificación percorre unha cadea, e calquera certificado que este percorrido seleccione pode fallar na súa propia xanela de validez. Le cal fallou antes de renovar nada.

A profundidade nomea o certificado que fallou

No diagnóstico de OpenSSL, a profundidade 0 é o certificado obxectivo e a profundidade 1 é o emisor que o asinou, con números superiores que continúan cara á áncora de confianza. Unha caducidade informada na profundidade 1 non queda contradita por un notAfter vixente na folla, así que volver comprobar o certificado visible nunca explicará o erro.

Anota a pegada do certificado fallido xunto co seu suxeito, porque certificados distintos poden levar o mesmo nome de CA. A sinatura cruzada produce exactamente esa situación: a mesma autoridade aparece máis dunha vez, con datas de validez diferentes, e o verificador escolleu a que non esperabas. Unha etiqueta familiar non é un identificador, e unha pegada é o que distingue dous obxectos que comparten nome.

Fíxate tamén nos produtos con máis dun rol de certificado. En OpenVPN Access Server, os certificados que protexen as interfaces web son distintos dos que se usan para as conexións VPN, así que un navegador que abre a páxina de administración non demostra nada sobre a ruta do túnel.

As entradas de confianza non son o mesmo que os candidatos de cadea

Entrega ao verificador as dúas entradas por separado e de forma explícita. O ficheiro de confianza contén as áncoras que aceptas; o paquete non confiable contén certificados intermedios ofrecidos para construír a ruta. Mesturalos é como a xente promove por accidente un intermedio a raíz e despois se pregunta por que o mesmo erro os segue entre máquinas.

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

Desactivar a ruta e o almacén predeterminados con -no-CApath -no-CAstore mantén honesta a proba: o resultado depende entón dos ficheiros que nomeaches, non do que a estación de traballo confía por casualidade. A referencia de verificación de OpenSSL documenta estas opcións e o diagnóstico que producen.

-show_chain imprime a cadea construída cando a verificación ten éxito, o que resulta útil para confirmar que a ruta é a que pretendías. Cando falla, conserva a profundidade e o suxeito informados; eses dous campos din ao seguinte lector que certificado inspeccionar.

O que isto non fai é reproducir a política de cada cliente. Un pin, unha restrición de propósito ou unha comprobación de identidade específica do cliente vive no cliente, non neste comando. Eses son os axustes que hai que inspeccionar cando a verificación pasa no servidor e a conexión segue fallando. Mantén os dous diagnósticos separados, ou renovarás un certificado san perseguindo un erro de pinning.

Que demostra a comprobación e que deixa fóra

Esta é unha comprobación de ruta e propósito contra un ficheiro de confianza que ti aportaches. Para unha comprobación de nome HTTPS, engade o nome de host esperado mediante a opción axeitada; para unha conexión VPN, conserva as comprobacións de identidade configuradas do cliente e usa o material de confianza que ese cliente le realmente.

O que un servidor envía é un conxunto de candidatos, non a ruta que o teu cliente acabará construíndo. A confianza local e as regras de construción da biblioteca dan forma ambas ao resultado, e por iso a mesma resposta pode verificar nunha máquina e fallar noutra. Compara o almacén de confianza mantido e a implementación TLS do cliente que falla cos dun cliente que funciona antes de supoñer unha avaliación idéntica. Unha diferenza aí explica moitos informes de «só falla este portátil».

Para ver a xanela de cada certificado en lugar dun a unha, imprímeos como conxunto:

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

Ese segundo comando lista suxeitos e emisores sen descodificar cada ficheiro a man, e así é como detectas un intermedio cuxa data pasou mentres a folla aínda parece ben.

Repara a ruta sen debilitar a verificación

Cando se subministra un intermedio caducado ou un certificado cruzado obsoleto, obtén a cadea actualmente soportada do emisor e desprégaa mediante o fluxo de certificados documentado do servizo. Cando ao cliente lle falta a áncora mantida prevista, actualiza a súa configuración de confianza xestionada ou o software do cliente. Resiste o atallo de marcar cada certificado do paquete como raíz só para silenciar a mensaxe.

O tratamento da raíz merece unha nota, porque os resumos a miúdo exaxérano. RFC 5280 trata a áncora como unha entrada que queda fóra da ruta prospectiva, mentres que OpenSSL documenta comprobacións de validez que inclúen o seu certificado CA raíz. Ambas afirmacións son certas para os seus propios sistemas; xeneralizar o comportamento de caducidade da raíz dunha biblioteca a todos os clientes produce respostas erróneas con seguridade.

Tras o cambio, forza unha autenticación nova no cliente afectado e confirma que a mensaxe de caducidade concreta desapareceu. Renova a folla só se a folla mesma é inadecuada. Desactivar as comprobacións de tempo ou restaurar un certificado cruzado histórico non produce unha ruta actual válida; só retrasa o seguinte fallo.