Uno de estos requisitos se especifica en la cláusula 4.9.9 con la marca MUST:
Las respuestas OCSP (Protocolo de estado de certificado en línea) DEBEN cumplir con RFC 6960 y / o RFC 5019. Las respuestas OCSP DEBEN:
- Firmado por la CA que emitió los certificados cuyo estado de revocación se está comprobando, o
- Tener una firma OCSP Responder cuyo certificado esté firmado por la CA que emitió los certificados, cuyo estado de revocación se verifica
En el último caso, el certificado de firma OCSP DEBE contener una extensión de tipo id-pkix-ocsp-nocheck como se especifica en RFC 6960.
Esta regla es violada por casi todas las autoridades de certificación (CA), lo que tiene algunas consecuencias.
A continuación, se muestra una captura de pantalla de los requisitos básicos para la emisión y gestión de certificados de confianza pública (última versión 1.7.0, 4 de mayo de 2020, pdf ):
El estándar RFC6960 en la sección 4.2.2.2 define "Respondedor delegado OCSP" por la presencia de id-kp- OCSPSigning.
El desarrollador Ryan Sleevi, cuya compañía se especializa en trabajar con certificados, ha demostrado que las CA violan masivamente la regla 4.9.9.
Después de examinar los datos de crt.sh, Ryan Slavy encontró 293 certificados intermedios sin la extensión pkix-nocheck, de los cuales 180 son actualmente válidos y 113 revocados.
El filtrado en Census.io emite 276 certificadoscoincidir con estas condiciones.
Así, estos certificados violan los requisitos básicos de CA / Browser, además, requisitos obligatorios .
Según Ryan Slavy, las CA deberían analizar más de cerca las reglas de CA / Navegador. Probablemente, algunas CA no están familiarizadas con los requisitos de RFC 6960. La
falta de una extensión correspondiente no es solo una formalidad. Aquí no hay problema en el sentido de que una CA intermedia no puede revocar el certificado de otra CA intermedia de la misma CA raíz.
El problema real es que en ausencia de una extensión, la CA intermedia teóricamente puede cancelar la revocación del certificado.otra CA intermedia o la propia CA raíz. Esto es realmente un problema. De hecho, la autoridad de certificación en tal situación no tiene una opción confiable para la revocación completa e irreversible de certificados. El procedimiento de revocación no funciona como se esperaba, lo que abre la puerta a atacantes que potencialmente podrían realizar un ataque para restaurar el certificado revocado.
Para solucionar este problema, se sugiere que al revocar un certificado, elimine permanentemente todas las copias de las claves para que la revocación también sea irreversible.
Para justificar la CA, podemos decir que incluso sin este inconveniente, el procedimiento de revocación de certificados no funciona como se esperaba ahora. Por ejemplo, los principales navegadores mantienen sus propias copias de las CRL y no siempre comprueban que estén actualizadas. Estas CRL contienen solo la información básica más importante, pero están lejos de ser completas. Por ejemplo, Chrome no se molesta en verificar si cada certificado TLS específico ha sido revocado, mientras que Firefox sí. Es decir, a veces con Chrome puede ir de manera segura a un sitio con un certificado caducado, y Firefox emitirá una advertencia y no lo dejará ir allí.
Curiosamente, de acuerdo con las reglas, los certificados incorrectos deben revocarse en los navegadores dentro de los 7 días, pero se hizo una excepción para esta situación. Ben Wilson de Mozilla dijo que no lo haránrevocar certificados con la extensión id-pkix-ocsp-nocheck faltante. Aunque dichos certificados no cumplen con los requisitos, el navegador Firefox no se ve afectado por esta vulnerabilidad de seguridad específica porque no acepta respuestas OCSP firmadas por CA intermedias.
Las CA deberían reemplazar de alguna manera los certificados incorrectos, pero no hay una fecha límite para ellos.
Para obtener más información sobre las soluciones PKI para empresas , comuníquese con los gerentes de GlobalSign +7 (499) 678 2210, sales-ru@globalsign.com.