Decodificador de OCSP (respuesta y petición)

Cómo usar

1. Suelta el archivo .der o pega la respuesta en base64, PEM o como volcado hexadecimal de una captura. Todo se analiza en la página.
2. Mira primero el estado de la respuesta. Cualquier valor distinto de successful es una respuesta completa y sin firma que no informa de ningún certificado.
3. Revisa la tabla de estado: good, revoked o unknown, con thisUpdate y nextUpdate al lado, y la fecha y el motivo de revocación cuando los hay.
4. Fíjate en la línea de vigencia y en el instante de referencia junto a ella. Una respuesta pasada de nextUpdate es la que un cliente conforme rechazaría.
5. Pega en el último cuadro la petición que enviaste para confirmar el eco del nonce, y revisa los certificados para ver si el respondedor delegado lleva id-kp-OCSPSigning.

Preguntas frecuentes

Mi respuesta ocupa solo seis bytes. ¿Está truncada?

Casi con seguridad no. Una OCSPResponse es una SEQUENCE cuyo primer campo es el estado, y los bytes de respuesta que vienen después solo existen cuando ese estado es successful. Por eso malformedRequest, internalError, tryLater, sigRequired y unauthorized son respuestas completas de cinco o seis bytes: sin firma, sin producedAt y sin mencionar certificado alguno. tryLater en particular es lo que devuelve un respondedor saturado, y el cliente debe reintentar en vez de darlo por fallo. Si guardas respuestas para el grapado, guardar una de estas es el error: nadie aguas abajo puede aprender nada de ella.

¿Por qué el CertID sigue usando SHA-1? ¿Es una debilidad?

Porque identifica, no autentica. Un CertID es el hash del nombre del emisor, el hash de su clave pública y el número de serie del certificado: una clave de búsqueda para que el respondedor encuentre la entrada correcta. Lo que protege la respuesta es la firma sobre el conjunto, no ese hash. Un ataque de colisión exigiría dos emisores con el mismo hash de nombre, el mismo hash de clave y el mismo serie, y no le daría al atacante nada que no consiga más fácilmente por otra vía. Por eso RFC 6960 mantiene SHA-1 aquí. En cambio, una firma SHA-1 sobre la respuesta sí es un problema, y este decodificador lo señala aparte.

La respuesta no tiene nextUpdate. ¿Cuándo caduca?

Formalmente, nunca. RFC 6960 dice que cuando falta nextUpdate hay información más reciente disponible en todo momento y la respuesta puede usarse hasta ser sustituida. En la práctica cada cliente aplica su propio techo, pero muchos la aceptan mientras se pueda analizar, que es justo la ventana que busca un ataque de repetición. Ese es el interés del nonce: con él, una respuesta capturada no sirve para una pregunta posterior, porque la respuesta queda atada a un valor que eligió el cliente.

El respondedor descartó mi nonce. ¿La respuesta no vale?

Sí vale, y esta es la sorpresa más común al depurar. Las grandes CA públicas precalculan respuestas en lotes y las sirven desde un CDN, lo que es incompatible con devolver un nonce distinto por petición, así que simplemente lo omiten; RFC 8954 incluso permite que un respondedor ignore la extensión. La respuesta sigue siendo válida: lo que pierdes es la prueba de que se hizo para tu petición, y la vigencia queda en manos de thisUpdate y nextUpdate. Pega tu petición en esta herramienta y te dirá si el nonce volvió, se descartó o volvió distinto, que es el caso que de verdad significa que estás mirando la respuesta a la pregunta de otro.

¿En qué se diferencia unknown de una respuesta que no dice nada?

unknown es una respuesta de verdad: este respondedor no tiene registro de ese número de serie, casi siempre porque el certificado lo emitió una CA distinta de la que nombra el CertID o porque nunca existió. No equivale a good y un cliente no debe tratarlo así. Tampoco equivale a unauthorized, que dice que el respondedor no va a contestar por ese certificado. Y si la respuesta lleva la extensión extended-revoke el significado se estrecha: un respondedor así contesta revoked, con fecha a principios de 1970, para certificados que nunca emitió, de modo que su unknown se parece más a «fuera de mi ámbito».

¿Puede decirme de qué certificado habla la respuesta, o verificar la firma?

Lo primero no, y lo segundo no lo pretende. El CertID es un conjunto de hashes más un número de serie, y los hashes no se recorren hacia atrás, así que la única forma de emparejar una respuesta con un certificado es calcular el hash del nombre y de la clave de su emisor y comparar, lo que exige tener ya el certificado. Verificar la firma requiere la clave pública del emisor, que esta página no tiene ni descarga, de modo que lo mostrado es una lectura fiel de los bytes y no una decisión de confianza. Lo que sí puede resolverse solo con los bytes es quién firmó: comparar el hash de la clave de cada certificado incluido con el issuerKeyHash del CertID distingue a la CA emisora de un respondedor delegado.

Herramientas relacionadas