Esta respuesta dependerá de qué software PKI esté utilizando y cómo esté configurada para manejar la información de revocación. Los errores de certificado tienen una prioridad; primero quieres comprobar lo más grave.
El procedimiento general para validar un certificado es:
Verifique que el Root Cert esté en su almacén de confianza (o que cree una ruta complicada para una gran CA corporativa, consulte [**]).
-
Comenzando en la raíz, camine por la cadena de certificación comprobando cada uno :
-
¿Se revoca? : el certificado contendrá información sobre dónde y cómo comprobar que sigue siendo válido, generalmente por CRL o OCSP. Siga este enlace para asegurarse de que no haya sido revocado.
-
¿Se puede verificar la firma en ella utilizando el certificado anterior en la cadena? , es decir, el que está justo encima de ella y que acaba de verificar.
-
¿Ha caducado? : compruebe la vida útil (también conocida como período de validez) del certificado.
* Elegí ordenar los cheques de esta manera porque trabajo con grandes PKI corporativas, y nuestras CA realizan el seguimiento del vencimiento y la revocación por separado, ya que no tiene sentido bloquear a los usuarios para que no vean un documento corporativo solo porque es antiguo (piense 10 + email años). [Vea el hilo de comentarios a continuación con @SteffenUllrich para más información sobre eso].
En el mundo web / ssl debe verificar la revocación y el vencimiento al mismo tiempo y tratar los certificados caducados como si hubieran sido revocados . La razón es que la mayoría de las CAs públicas (¿todas?) Ssl detienen el seguimiento de la revocación cuando el certificado expira. Por ejemplo, imagine un certificado que fue revocado debido a un compromiso clave, luego, cuando caduca, pasa de ser "Revocado" a simplemente "Expirado" y se pierde el hecho de que fue revocado.
[**] Generalizaré mi respuesta un poco para incluir otros casos de PKI en los que tiene que aceptar certificados de entidades emisoras de certificados raíz que no están en su almacén de confianza. Para las PKI corporativas, a menudo el certificado raíz no está integrado en el certificado final, por lo que tiene que ir en una expedición de construcción de caminos. Esto empeora aún más cuando su CA raíz está certificada de forma cruzada con otras CA, por ejemplo, los servidores de correo corporativo y los sistemas de identificación cuando dos empresas se fusionan, o si cada departamento mantiene su propia CA raíz (que es común en el gobierno). Si tiene que admitir PKI de este tipo, deberá diseñar un esquema de creación de rutas de certificados en línea (probablemente complicado).
En respuesta al comentario de Steffen Ullrich , acabo de verificar el software de CA que utilizamos para nuestra PKI corporativa, el administrador de seguridad de Entrust Authority, y ciertamente lo respalda:
yconestoactivado,tambiénpuederevocarcertificadosinclusodespuésdequehayancaducado.Desafortunadamenteparausted,losdocumentosqueestoyviendonosonpúblicos,porloquenopuedovincularlos.Creoquela"CRL particionada" es un formato de CRL propiedad de Entrust, por lo que no tengo idea si los clientes de otros proveedores lo admiten o si otro software de CA tiene características similares.
Dicho esto, a menos que sepa (1) qué software de CA emitió los certificados que está verificando, y (2) que está configurado para mantener certificados caducados en la CRL, es más seguro tratarlos como caducados y revocados mismo nivel de gravedad (o incluso el mismo error).