pulsa ⌘K para cambiar de herramienta
SECURITY

Visor de Certificados SSL y CSR

Lee un certificado SSL o CSR en tu navegador. No se sube nada.

local
cert-viewer

🖥 Reads an X.509 certificate or a PKCS#10 CSR entirely in your browser. Nothing is uploaded. A private key is refused rather than displayed.

§01 ACERCA DE ESTA HERRAMIENTA

Resumen

Un certificado es un conjunto firmado de afirmaciones en DER, una codificación binaria, envuelto en Base64 para el transporte. Todo lo que sale mal con los certificados en la práctica es visible en esas afirmaciones: un nombre que falta en la lista SAN, una ventana de validez que termina antes de lo previsto, un intermedio pegado donde va una hoja, un uso de clave que prohíbe el uso para el que se compró.

Este visor decodifica el PEM, analiza el DER y expone el contenido — tanto para certificados X.509 como para solicitudes de certificado PKCS#10. Lo hace en su navegador, y rechaza de plano las claves privadas.

Cómo se usa

  1. Pegue un bloque PEM que empiece por -----BEGIN CERTIFICATE----- o -----BEGIN CERTIFICATE REQUEST-----.
  2. Lea el resumen: tipo, sujeto, emisor, validez, días restantes.
  3. Contraste la lista SAN con los nombres de host que espera servir.

Para obtener un certificado en vivo de un servidor: openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509

Los nombres alternativos son los únicos que cuentan

El Common Name del sujeto parece el nombre del certificado, y para la validación del nombre de host no se usa. Chrome lo ignoró desde la versión 58 y los demás navegadores siguieron. Solo se consulta la extensión subjectAltName.

Las consecuencias prácticas:

  • Un certificado cuyo nombre de host aparece solo en el CN falla la validación en todos los navegadores actuales, y a la vez parece completamente correcto en cualquier herramienta que muestre el sujeto de forma destacada.
  • Un comodín *.example.com coincide con una sola etiqueta. Cubre www.example.com y no a.b.example.com, y no cubre el example.com desnudo — ese nombre necesita su propia entrada SAN, por lo que los certificados listan habitualmente ambos.
  • Los SAN tienen tipo. Se muestran las entradas dNSName, iPAddress, rfc822Name y URI, y un nombre de host colocado en el tipo equivocado no coincide.

Cómo leer la clave y su uso

El algoritmo y el tamaño de clave se leen de la estructura de clave pública. Para RSA, la longitud del módulo da directamente el tamaño en bits. Para EC se indica la curva nombrada cuando se usa una, y cuando el certificado lleva parámetros explícitos en lugar de un nombre de curva se señala como tal — los parámetros explícitos los rechazan la mayoría de las pilas TLS modernas, así que merece la pena verlo. Si no hay nombre de curva, el tamaño se deduce de la longitud del punto público, y por eso una clave P-521 informa 521 y no los 528 que daría un recuento ingenuo de bytes.

keyUsage y extendedKeyUsage describen lo que la clave tiene permitido hacer, y ambos se aplican. Un certificado sin serverAuth en su EKU no funcionará para TLS ni aunque todo lo demás sea correcto — resultado frecuente cuando se instala por error un certificado de cliente en un servidor.

basicConstraints dice si el certificado es una AC. Si pegó lo que creía su certificado hoja y se informa como AC, ha pegado el intermedio — la causa habitual de una cadena que valida en local y falla en otros lugares.

La lista de extensiones muestra cada extensión presente con su marca de crítica. Una extensión crítica que el cliente no entienda debe provocar el rechazo, según la RFC 5280, así que una extensión crítica desconocida merece investigarse.

Ejemplos

  • Un nombre que no valida — revise la lista SAN, no el sujeto. Si el nombre de host solo está en el CN, hay que reemitir el certificado.
  • Leer una CSR antes de enviarla — la CSR fija el sujeto y la clave pública. Confirmar los nombres antes del envío evita un ciclo de reemisión, sobre todo cuando la AC lo cobra.
  • Confirmar qué certificado tiene — hoja, intermedio y raíz se parecen como texto. basicConstraints y la relación entre sujeto y emisor los identifican al instante: una raíz tiene sujeto y emisor idénticos.
  • Planificar renovaciones — los días restantes se muestran directamente. Con el sector avanzando hacia vidas máximas mucho más cortas, un proceso de renovación manual que funcionaba con certificados anuales no sobrevive a ese cambio.
  • Auditar un paquete — pegue cada bloque por turno. Un paquete en el orden equivocado, o con un certificado no relacionado incluido, es una causa frecuente de error de cadena que solo aparece en algunos clientes.

Notas

Solo se aceptan bloques PEM CERTIFICATE y CERTIFICATE REQUEST. Cualquier otro tipo de bloque, incluidos todos los formatos de clave privada, se rechaza con un error que nombra lo encontrado. De un bloque rechazado no se analiza ni se muestra nada.

El analizador DER rechaza lo que DER prohíbe: codificaciones de longitud indefinida, longitudes que se pasan del final del búfer y anidamiento más allá de 32 niveles. Un pegado truncado produce un mensaje concreto como ASN.1 length exceeds buffer en lugar de un informe parcialmente rellenado, porque un certificado analizado a medias invita a la lectura errónea. Cuando el análisis falla, cualquier resultado anterior se borra por la misma razón.

Las fechas se muestran tal como están codificadas en el certificado. GeneralizedTime lleva un año de cuatro dígitos; UTCTime lleva dos, y la RFC 5280 fija la interpretación en 50–99 para 19xx y 00–49 para 20xx. Los días restantes se calculan contra el reloj de su dispositivo, así que una hora de sistema errónea da una cifra errónea.

Esta herramienta lee un certificado de forma aislada. La construcción de la cadena, la revocación y la confianza no se evalúan. Para ver qué envía realmente un servidor y cómo responde, use encabezados HTTP y el comprobador de encabezados de seguridad. Todo lo de aquí ocurre en su navegador — véase la política de privacidad.

FAQ
¿Se sube el certificado a algún sitio?
No. El PEM se decodifica en Base64 y la estructura DER se analiza en su navegador. No se envía nada, y una vez cargada la página funciona sin conexión. Esto importa más de lo que parece — el mismo portapapeles que contiene un certificado contenía normalmente su clave privada un momento antes.
¿Qué ocurre si pego una clave privada por error?
Se rechaza con un error que nombra el tipo de bloque, y no se analiza ni se muestra nada de ella. La herramienta solo acepta bloques CERTIFICATE y CERTIFICATE REQUEST. Quien maneja certificados tiene la clave correspondiente a mano: rechazar es el único valor por defecto seguro.
¿Por qué el certificado indica un dominio tanto en el sujeto como en la lista SAN?
Porque solo cuenta la lista SAN. Los navegadores dejaron de usar el CN del sujeto para la coincidencia de nombre de host hace años — Chrome desde la versión 58 — así que un certificado cuyo nombre solo aparece en el CN falla la validación por correcto que parezca. El CN se conserva para la visualización y las herramientas antiguas.
¿Puede decirme si el certificado es de confianza?
No. La confianza depende de la cadena hasta una raíz en la que su cliente confíe, del estado de revocación y de la hora actual en el cliente. Aquí se lee lo que un certificado afirma sobre sí mismo. Un certificado autofirmado y uno de una AC pública parecen igual de válidos aquí, y es el campo del emisor donde se ve la diferencia.
¿Por qué mi CSR no muestra fechas de validez?
Una CSR no las tiene. Es una solicitud que contiene un sujeto, una clave pública y las extensiones solicitadas, firmada con la clave privada correspondiente. La validez la elige la AC emisora, así que notBefore y notAfter solo existen una vez emitido el certificado.
¿Qué significa un número de días negativo?
El certificado ya ha caducado, y la cifra indica hace cuánto. Las fechas se leen exactamente como están codificadas — los años UTCTime se interpretan según la RFC 5280, donde 50 a 99 significa 19xx y 00 a 49 significa 20xx — y se comparan con el reloj de su dispositivo.