Leer un certificado SSL
Pega el PEM o carga el archivo y lee en claro cuándo caduca, qué nombres cubre, qué clave usa y si la cadena está en el orden correcto. Sirve también para las solicitudes de certificado (CSR) y los .p7b, y el certificado no sale de tu navegador.
Cuándo hace falta leer un certificado
El caso más común es también el más banal: cuándo caduca. El proveedor te ha enviado el archivo del certificado nuevo, o tienes que renovar el viejo, y el panel del hosting no te lo dice. Aquí el primer número que ves son los días que faltan, y si el certificado ya ha caducado o todavía no es válido lo ves antes que todo lo demás, en rojo o en amarillo.
Los otros casos reales son tres. El navegador dice «certificado no válido» y quieres saber si es un problema de nombres (el certificado no cubre ese subdominio) o de cadena (en el servidor falta una pieza). Tienes que enviar una solicitud de certificado (CSR) a la autoridad y quieres comprobar que dentro están los nombres correctos antes de pagar. O te llega por correo un archivo .cer o .p7b y quieres saber qué es antes de instalarlo.
La página acepta el PEM pegado (también varios certificados seguidos), los archivos .crt, .cer, .pem y .der, las CSR y los .p7b, y reconoce el tipo por lo que hay dentro, no por la extensión.
Los nombres cubiertos: el nombre común ya no cuenta
Los nombres para los que vale un certificado están en los nombres alternativos (SAN), y son lo único que miran los navegadores de hoy: Chrome dejó de leer el nombre común, el CN, en 2017, y Safari en 2019. Un certificado con el nombre correcto solo en el CN hoy da error.
El comodín vale para un solo nivel. Un certificado para *.ejemplo.es cubre www.ejemplo.es y tienda.ejemplo.es, pero no ejemplo.es a secas (hace falta un nombre más) ni tampoco a.b.ejemplo.es (haría falta *.b.ejemplo.es). Escribe el nombre en el campo «Nombre que comprobar» y la respuesta es sí o no, con el nombre del certificado que lo cubre.
Entre los nombres puede haber también direcciones IP, algo típico del NAS o del router de casa: ahí el certificado vale solo para esa dirección exacta, y un nombre de dominio que apunte a la misma dirección no basta. Para razonar sobre direcciones y redes está Calculadora de subredes.
La cadena, y por qué el orden importa
Un sitio no envía un solo certificado: envía el suyo, emitido por un intermedio, que a su vez ha sido emitido por una raíz que el navegador ya conoce. El vínculo se lee dentro de los certificados: el emisor de cada uno debe ser el sujeto del siguiente. Si pegas toda la cadena, la página comprueba los vínculos uno a uno.
Cuando el orden está mal tienes la cadena ya reordenada, lista para copiar en el archivo que envía el servidor (el que muchos paneles llaman fullchain). Pero el fallo más común es otro: el intermedio que falta. Algunos navegadores lo van a buscar por su cuenta y el sitio parece funcionar, mientras que curl, muchas apps del móvil y muchos programas dan error. Si pegas lo que envía el servidor y después del certificado del sitio no hay nada, el problema es ese. Y si has hecho el archivo uniendo dos archivos con cat, comprueba que entre una línea END y la BEGIN siguiente haya un salto de línea: pegadas, OpenSSL no encuentra ningún certificado, y la página lo señala.
Hay también un caso más sutil: un intermedio con el nombre correcto y la clave equivocada. Pasa cuando una autoridad renueva su clave y en el servidor se queda el archivo viejo. Los nombres coinciden, pero los identificadores de la clave no, y la página lo señala. En los archivos .p7b en cambio el orden no existe, porque los certificados están en un conjunto: la página los muestra ya puestos en fila del sitio a la raíz.
Las fechas: zona horaria, días y duración máxima
Las fechas dentro de un certificado están siempre en tiempo universal (UTC), y así las encuentras escritas aquí. En la España peninsular es una hora más en invierno y dos en verano, así que un certificado que caduca a las 23:30 UTC del día 3 en Madrid ya ha caducado el día 4. Los días que faltan son días enteros de 24 horas, contados desde el momento en que lees.
Luego está la duración. Desde septiembre de 2020 un certificado público de sitio no puede durar más de 398 días, y las reglas del CA/Browser Forum la están acortando: 200 días para los emitidos desde el 15 de marzo de 2026, 100 desde el 15 de marzo de 2027, 47 desde el 15 de marzo de 2029. Si un certificado de sitio dura más de lo que estaba permitido el día en que se emitió, la página lo señala: si viene de una autoridad pública el navegador lo rechaza, si viene de una autoridad interna de una empresa la regla no vale.
Un detalle que hace fallar a los lectores caseros: hasta 2049 el año se escribe con solo dos cifras, y «50» quiere decir 1950, no 2050, como dice la norma (RFC 5280).
Clave, firma y huellas
La clave dice lo robusto que es el certificado. Una clave RSA de 2048 bits es el mínimo aceptado, 3072 o 4096 son más lentas y más robustas; las claves de curva elíptica P-256 y P-384 son más cortas con la misma seguridad. Ed25519 existe en los certificados, pero los navegadores todavía no lo aceptan para los sitios. Por debajo de 2048 bits y con las firmas SHA-1 o MD5 la página pone un aviso, porque son justo los casos en que un navegador rechaza.
Las huellas SHA-256 y SHA-1 son el resumen del certificado entero, calculado aquí con las funciones criptográficas del navegador: sirven para comparar dos certificados sin leerlos, por ejemplo por teléfono con quien gestiona el servidor, y son el mismo número que muestran Windows, macOS y OpenSSL. La SHA-1 aquí es solo una etiqueta y no una firma, y es la que Windows llama «huella digital». Para la huella de un archivo cualquiera, no de un certificado, está Checksum de un archivo.
El número de serie es el que la autoridad te pide para revocar un certificado. Las líneas OCSP y CRL dicen dónde pregunta el navegador si ha sido revocado: la página las muestra, pero no se conecta a ellas.
Nombres con acentos, escritos de cuatro maneras
Dentro de un certificado el texto puede estar codificado de maneras distintas, y un lector apresurado las trata todas como UTF-8. Aquí cada una se lee por lo que es: UTF8String como UTF-8, BMPString como UTF-16, el viejo UniversalString como UTF-32. El caso difícil es el T61String, que en los certificados reales contiene unas veces UTF-8 y otras Latin-1: la página prueba el primero y, si los bytes no lo son, usa el segundo, que es lo que hace OpenSSL. Así «Società» sigue siendo «Società» en lugar de convertirse en una fila de símbolos, y cuando ha hecho falta el Latin-1 la página lo escribe.
Lo que no hace, dicho claro
No verifica la firma y no dice si el certificado es de fiar: muestra lo que está escrito. Para saber si un sitio está bien configurado hace falta una comprobación que se conecte al servidor, y desde una página web no se puede, porque los navegadores no le dan el certificado de otro sitio al código de una página. Para conseguirlo, pulsa en el candado junto a la dirección y exporta el certificado, o usa openssl s_client -connect ejemplo.es:443 -showcerts y pega aquí lo que sale.
No abre los .pfx ni los .p12: contienen la clave privada y están cifrados con una contraseña. Y si junto al certificado pegas una clave privada, la página no la lee y te avisa, porque una clave privada no se pega en ningún sitio. Para leer un token de acceso, que es otra cosa aunque se le parezca, está Decodificar JWT.