Decodificador de certificados SSL

Qué te enseña un decodificador de certificados

Un certificado SSL es una estructura X.509 codificada en DER, normalmente envuelta en la armadura base64 que forma un archivo PEM. Dentro están el nombre del sujeto y el del emisor, un número de serie, las dos fechas entre las que el certificado es válido, una clave pública y una lista de extensiones, de las cuales la que importa para una web es el nombre alternativo del sujeto, porque los navegadores dejaron de aceptar el nombre común como nombre de host hace años.

Decodificar todo eso no necesita servidor. Es un análisis a nivel de bytes de un perfil muy concreto de una codificación, y por eso esta página lo hace en la pestaña que ya tienes abierta en vez de pedirte que subas nada. Con un certificado público de servidor importa menos que con una clave privada, pero la costumbre de pegar material criptográfico en el formulario de otro no es una costumbre que convenga tener, y este sitio mantiene la misma postura en el decodificador de JWT.

Lo que casi ningún decodificador te dice es si el certificado cumple realmente las reglas. El RFC 5280 es bastante concreto en varias cosas que son fáciles de comprobar y fáciles de incumplir, y hay certificados reales en tu propio almacén de confianza que las incumplen.

Cómo se usa

1. Pega el certificado. Un bloque PEM completo, solo el base64 de dentro, o hex en bruto. Los tres valen, y los espacios se ignoran.
2. Lee los campos. Nombres, serie, validez, clave y extensiones. Las dos fechas indican además con qué tipo de tiempo ASN.1 están codificadas, que es justo la parte que acaba importando.
3. Mira la lista de conformidad. Se detalla, con su motivo, todo lo que el certificado hace y el RFC 5280 prohíbe o desaconseja. Si el certificado es conforme, también lo dice.

La regla que casi nadie comprueba, y las raíces que la incumplen

El apartado 4.1.2.5 del RFC 5280 es peculiar. No se limita a permitir dos formas de escribir una fecha: impone cuál según el año. Las fechas hasta 2049 tienen que ser UTCTime, y las de 2050 en adelante tienen que ser GeneralizedTime. El motivo es que UTCTime lleva un año de dos dígitos, donde 00 a 49 se lee como 20xx y 50 a 99 como 19xx, así que la codificación sencillamente no puede expresar 2050.

Eso le da a la regla una forma rara. Una mitad la impone la codificación y no se puede incumplir: ningún certificado puede meter 2050 en un UTCTime porque no hay dónde meterlo. La otra mitad no la impone nada, y se incumple. De los 150 certificados raíz de un almacén de confianza estándar, 149 codifican sus fechas como UTCTime y uno usa GeneralizedTime caducando en 2046, cuatro años antes de que el cambio esté permitido. Certum Trusted Network CA 2 está en el almacén de confianza por defecto de prácticamente todos los navegadores y sistemas operativos, y puedes cargarlo en el cuadro de arriba y ver el aviso.

El mismo almacén saca a la luz una segunda infracción con más frecuencia. El apartado 4.1.2.2 dice que el número de serie de un certificado tiene que ser un entero positivo. Ocho de las 150 raíces tienen número de serie cero, entre ellas dos raíces de Go Daddy y dos de la autoridad Hellenic Academic and Research Institutions. El cero no es positivo, y OpenSSL imprimirá serial=00 para todas ellas si prefieres comprobarlo con algo que no sea esta página.

Ninguna de las dos cosas hace peligroso un certificado. Son de esas que permitía lo que fabricó el certificado hace una década o más y que se han ido heredando sin ruido. Merece la pena enseñarlas porque un decodificador que solo informa de los campos te está diciendo lo que el certificado dice, no si está bien formado.

Límites honestos y cómo se ha comprobado

Esto lee un certificado; no lo verifica. No hay comprobación de firma, ni construcción de cadena, ni consulta de revocación, ni decisión de confianza, porque todo eso necesita el certificado del emisor y una fuente de revocación al día, y una página no puede fingir honestamente que tiene ninguna de las dos. Si la herramienta dice que un certificado está autofirmado, es una afirmación sobre dos nombres iguales, no sobre si la firma es válida.

También decodifica solo las extensiones que merece la pena resumir, y el resto las muestra como su identificador de objeto y sus bytes en bruto. Las políticas de certificado y las marcas de tiempo de transparencia son estructuras por derecho propio, y decodificarlas a medias sería peor que enseñarlas tal cual.

El analizador se contrasta con OpenSSL sobre los 150 certificados raíz de un almacén real: coinciden todos los números de serie, todas las versiones, los dos instantes de validez y todos los atributos del sujeto, con 326 comprobaciones y 15 controles negativos. Durante ese trabajo salieron tres discrepancias y las tres eran errores de la comparación, no del analizador, incluida una que solo apareció porque OpenSSL escapa el texto no ASCII en su salida mientras que el analizador lo decodifica. Los casos que un almacén de confianza no puede aportar —una serie de más de veinte octetos, un certificado que no esté autofirmado, un nombre en BMPString— se construyen desde cero en las pruebas, porque una regla que nada del corpus incumple no se está comprobando de verdad.

¿Por qué es gratis?

Aquí no interviene ningún servidor. Analizar DER es aritmética sobre bytes, se ejecuta en tu navegador y no hay nada que cobrar ni a lo que registrarse.

Nada de lo que pegues se sube, se guarda ni se registra. Un certificado público no es un secreto, pero el cuadro de arriba aceptará encantado cosas que sí lo son, y el único diseño seguro es aquel en el que eso no puede importar.