Decodificador de certificados y PEM

Qué hace esta herramienta

Un certificado llega como un bloque de Base64 entre dos líneas de guiones, y no hay forma de saber nada de él mirándolo. Esto lo decodifica: a quién se emitió y quién lo emitió, cuándo caduca, qué nombres de host cubre, qué clave contiene y todas las extensiones que lleva. Pegue una cadena completa y cada certificado se comprueba contra el siguiente.

Todo se ejecuta en su navegador. Aquí importa más que en la mayoría de las herramientas: la alternativa suele ser pegar un certificado de producción en el servidor de otra persona, o acordarse de la invocación de openssl, cosa que casi nadie hace.

PEM es solo el envoltorio

Los guiones y el Base64 son embalaje. Dentro hay DER, una codificación binaria de una estructura llamada ASN.1, y la etiqueta entre los guiones dice qué estructura esperar:

CERTIFICATE           un certificado X.509 emitido
CERTIFICATE REQUEST   una CSR: lo que pidió a una CA
PUBLIC KEY            una clave suelta, sin identidad
PRIVATE KEY           la mitad secreta, rechazada aquí

El mismo certificado puede llegar también como DER en crudo en un archivo .cer o .crt, sin guiones y sin Base64. Si un archivo se abre como ruido binario en vez de texto, eso es lo que es; pásalo antes a Base64, o expórtalo como PEM.

Qué hay realmente en un certificado

Los campos básicos son los mismos en todos los certificados emitidos:

• Sujeto: de quién trata el certificado. Para un sitio web hoy suele ser solo un nombre común, y a menudo nada más.
• Emisor: la autoridad de certificación que lo firmó. Su nombre de sujeto aparece literalmente como emisor de todo lo que firma, y eso es lo que hace posible comprobar la cadena.
• Validez: dos instantes absolutos, siempre en UTC. Esta herramienta muestra ambos y calcula cuánto queda en su navegador, porque la máquina que generó esta página no tiene ni idea de cuándo la está leyendo usted.
• Número de serie: único por emisor, y el identificador que se usa cuando se revoca un certificado.
• Algoritmo de firma: con qué firmó el emisor, por ejemplo SHA-256 con ECDSA.
• Clave pública: el tipo y el tamaño. En RSA es la longitud en bits del módulo; en EC es una propiedad de la curva nombrada, así que P-256 son siempre 256 bits.

Un campo que la gente espera y ya no encuentra: el nombre común del sujeto no es lo que comprueban los navegadores. Hace años que se ignora para emparejar el nombre de host. Lo que cuenta es la extensión de nombres alternativos, más abajo.

Las extensiones que deciden si funciona

Un certificado puede llevar cualquier número de extensiones. Cinco determinan si de verdad será aceptado, y esta herramienta las decodifica por completo:

• Nombres alternativos del sujeto: los nombres de host, direcciones IP o de correo para los que el certificado es válido. Es el campo que comprueban los navegadores, y un certificado cuyos nombres alternativos no incluyan el que usted escribió será rechazado por correcto que sea todo lo demás.
• Restricciones básicas: si es una autoridad de certificación y cuántos intermedios pueden situarse por debajo. Un certificado final marcado como CA, o al revés, rompe la cadena.
• Uso de clave: para qué puede emplearse la clave en absoluto: firmar, cifrar claves, firmar certificados. Casi siempre marcada como crítica, lo que obliga al software a rechazar el certificado en lugar de ignorar un uso que no entiende.
• Uso extendido de clave: el propósito: servidor TLS, cliente TLS, firma de código, correo. Un certificado sin autenticación de servidor TLS no servirá un sitio web, y esa es una sorpresa frecuente en certificados emitidos para otra cosa.
• Identificadores de clave del sujeto y de la autoridad: hashes cortos que permiten al software emparejar rápidamente un certificado con su emisor cuando varios comparten nombre.

Cualquier otra extensión aparece con su nombre cuando se conoce, su OID y si está marcada como crítica. Nada se descarta en silencio: una extensión que esta herramienta no decodifica sigue apareciendo, para que se vea que está ahí.

Cadenas, y qué significa aquí «continua»

Un servidor casi nunca envía un solo certificado. Envía el suyo más los intermedios necesarios para llegar a una raíz en la que el cliente ya confía. El orden importa y el archivo suele llamarse fullchain.pem:

bloque 1   final          subject: example.com     issuer: Example CA R3
bloque 2   intermedio     subject: Example CA R3   issuer: Example Root
bloque 3   raíz           a menudo se omite: el cliente ya la tiene

Cada certificado nombra a su emisor, y el certificado siguiente debería tener exactamente ese nombre como sujeto. Esta herramienta compara esos dos nombres byte a byte y dice si coinciden. Es la única relación comprobable sin conexión, y detecta los dos fallos que explican la mayoría de los problemas de cadena: un intermedio omitido y bloques pegados en el orden equivocado.

Esos fallos tienen un síntoma característico. Los navegadores de escritorio a menudo tapan un intermedio ausente descargándolo ellos mismos, así que el sitio se ve bien en su portátil y falla en un teléfono, en una app móvil o desde curl. Si eso describe lo que está depurando, pegue aquí primero la cadena completa.

Lo que esta herramienta no le dice

No verifica firmas, y no puede. Comprobar que un certificado fue realmente firmado por su emisor necesita la clave pública del emisor; decidir si hay que creer a ese emisor necesita un almacén de confianza. Un archivo pegado no aporta ninguno de los dos. Tampoco puede comprobar la revocación, que exige una petición de red a la CA.

Así que «la cadena es continua» aquí significa que los nombres encajan, no que la cadena sea válida. Una cadena de certificados falsificados encajaría a la perfección. Para lo que sirve la comprobación es para encontrar errores estructurales en su propia configuración, que es justo lo que la gente está mirando cuando pega una cadena en un decodificador.

Huellas y claves privadas

La huella SHA-256 es un hash del certificado entero, y es lo que se compara con un valor que alguien le dio o con un pin. Fíjese en qué identifica: el certificado, no la clave que contiene. Renovar un certificado con la misma clave produce una huella distinta, y esa es la razón habitual de que un pin se rompa al renovar. La huella SHA-1 también se muestra porque las herramientas y consolas antiguas la siguen imprimiendo, solo para identificar; SHA-1 no tiene nada que hacer firmando nada.

Las claves privadas se reconocen y se rechazan. Nada de lo que se pega aquí sale de su navegador, así que el rechazo no va de esta página: va de que pegar una clave privada en un formulario web es una costumbre que conviene no adquirir, y el próximo sitio que se lo pida puede no ejecutarse en local. Si necesita comprobar que una clave y un certificado van juntos, compare la clave pública del certificado con la derivada de la clave, en local.