SSL certificate viewer (PEM/CRT)

O SSL foi desenvolvido pela Netscape em 1994 para resolver um problema que ameaçava inviabilizar o comércio eletrônico antes mesmo de ele começar: como transmitir números de cartão de crédito pela internet sem que qualquer roteador no caminho pudesse interceptar e ler os dados. O SSL 2.0 estreou com o Netscape Navigator 1.1 em 1995, com o SSL 3.0 chegando em 1996. O protocolo TLS, que substituiu o SSL com melhorias criptográficas fundamentais, foi padronizado no RFC 2246 em 1999. Hoje usamos TLS 1.3 (RFC 8446, 2018) — tecnicamente nunca mais SSL, mas o nome popular persistiu. O formato X.509 do certificado é ainda mais antigo: foi definido pela ITU-T em 1988 como parte do padrão X.500 para diretórios de rede. A infraestrutura de confiança que usamos hoje — autoridades certificadoras (CAs) como DigiCert, Sectigo e Let's Encrypt — é basicamente o mesmo modelo hierárquico proposto em 1988.

Um certificado X.509 é um documento assinado digitalmente que associa uma chave pública a uma identidade. Os campos mais relevantes: Subject (CN = Common Name, o domínio principal), SANs (Subject Alternative Names — lista de domínios e IPs cobertos pelo certificado, que substituiu o CN como campo autoritativo), Issuer (a CA que assinou o certificado), validade (NotBefore e NotAfter), e a assinatura digital da CA que prova a autenticidade. Os certificados formam uma cadeia: folha — intermediária — raiz. O certificado raiz fica pré-instalado no sistema operacional e no navegador; os intermediários são entregues pelo servidor junto com o certificado folha. A verificação do navegador percorre a cadeia da folha até a raiz, checando assinatura e validade em cada nível. Em 2020, os navegadores reduziram a validade máxima de certificados para 398 dias — forçando renovações frequentes. O Let's Encrypt, lançado em 2015 pela ISRG, automatizou esse processo com o protocolo ACME e transformou o HTTPS num padrão universal ao oferecer certificados gratuitos.

Esta ferramenta decodifica certificados no formato PEM (base64 entre `-----BEGIN CERTIFICATE-----` e `-----END CERTIFICATE-----`) e exibe os campos de forma legível — útil para os casos clássicos de troubleshooting: verificar se um certificado está prestes a expirar antes que o monitor de uptime avise, confirmar quais domínios estão cobertos pelos SANs antes de fazer deploy, identificar a cadeia de CAs intermediárias quando um servidor retorna erro SSL em alguns clientes mas não em outros, ou simplesmente entender o que está dentro de um certificado sem precisar do `openssl x509 -text` no terminal. Uma dica prática: certificados emitidos pelo Let's Encrypt têm validade de 90 dias por design — o argumento é que rotação frequente limita a janela de exposição de chaves comprometidas, e a automação via certbot ou Caddy elimina o trabalho manual de renovação.

SSL was developed by Netscape in 1994 to solve a problem that threatened to make e-commerce impossible before it even started: how to transmit credit card numbers over the internet without any router along the path being able to intercept and read the data. SSL 2.0 debuted with Netscape Navigator 1.1 in 1995, with SSL 3.0 arriving in 1996. The TLS protocol, which replaced SSL with fundamental cryptographic improvements, was standardized in RFC 2246 in 1999. Today we use TLS 1.3 (RFC 8446, 2018) — technically never SSL anymore, but the popular name persisted. The X.509 certificate format is even older: it was defined by the ITU-T in 1988 as part of the X.500 standard for network directories. The trust infrastructure we use today — certificate authorities (CAs) like DigiCert, Sectigo, and Let's Encrypt — is essentially the same hierarchical model proposed in 1988.

An X.509 certificate is a digitally signed document that associates a public key with an identity. The most relevant fields: Subject (CN = Common Name, the primary domain), SANs (Subject Alternative Names — the list of domains and IPs covered by the certificate, which replaced CN as the authoritative field), Issuer (the CA that signed the certificate), validity period (NotBefore and NotAfter), and the CA's digital signature that proves authenticity. Certificates form a chain: leaf — intermediate — root. The root certificate is pre-installed in the operating system and browser; intermediate certificates are delivered by the server alongside the leaf certificate. The browser's verification traverses the chain from leaf to root, checking the signature and validity at each level. In 2020, browsers reduced the maximum certificate validity to 398 days — forcing frequent renewals. Let's Encrypt, launched in 2015 by the ISRG, automated this process with the ACME protocol and made HTTPS a universal standard by offering free certificates.

This tool decodes certificates in PEM format (base64 between `-----BEGIN CERTIFICATE-----` and `-----END CERTIFICATE-----`) and displays the fields in a readable way — useful for the classic troubleshooting scenarios: verifying whether a certificate is about to expire before the uptime monitor fires an alert, confirming which domains are covered by the SANs before deploying, identifying the intermediate CA chain when a server returns SSL errors in some clients but not others, or simply understanding what is inside a certificate without needing `openssl x509 -text` in the terminal. A practical note: Let's Encrypt certificates have a 90-day validity by design — the argument is that frequent rotation limits the exposure window for compromised keys, and automation via certbot or Caddy eliminates the manual renewal work.

El SSL fue desarrollado por Netscape en 1994 para resolver un problema que amenazaba con hacer inviable el comercio electrónico antes incluso de que comenzara: cómo transmitir números de tarjeta de crédito por internet sin que ningún router en el camino pudiera interceptar y leer los datos. SSL 2.0 debutó con Netscape Navigator 1.1 en 1995, y SSL 3.0 llegó en 1996. El protocolo TLS, que sustituyó al SSL con mejoras criptográficas fundamentales, fue estandarizado en el RFC 2246 en 1999. Hoy usamos TLS 1.3 (RFC 8446, 2018) — técnicamente nunca más SSL, pero el nombre popular persistió. El formato X.509 del certificado es aún más antiguo: fue definido por la ITU-T en 1988 como parte del estándar X.500 para directorios de red. La infraestructura de confianza que usamos hoy — autoridades de certificación (CAs) como DigiCert, Sectigo y Let's Encrypt — es básicamente el mismo modelo jerárquico propuesto en 1988.

Un certificado X.509 es un documento firmado digitalmente que asocia una clave pública con una identidad. Los campos más relevantes: Subject (CN = Common Name, el dominio principal), SANs (Subject Alternative Names — lista de dominios e IPs cubiertos por el certificado, que sustituyó al CN como campo autoritativo), Issuer (la CA que firmó el certificado), período de validez (NotBefore y NotAfter), y la firma digital de la CA que prueba la autenticidad. Los certificados forman una cadena: hoja — intermedia — raíz. El certificado raíz está preinstalado en el sistema operativo y el navegador; los intermedios los entrega el servidor junto con el certificado hoja. La verificación del navegador recorre la cadena desde la hoja hasta la raíz, comprobando la firma y la validez en cada nivel. En 2020, los navegadores redujeron la validez máxima de los certificados a 398 días — forzando renovaciones frecuentes. Let's Encrypt, lanzado en 2015 por la ISRG, automatizó este proceso con el protocolo ACME y convirtió HTTPS en un estándar universal al ofrecer certificados gratuitos.

Esta herramienta decodifica certificados en formato PEM (base64 entre `-----BEGIN CERTIFICATE-----` y `-----END CERTIFICATE-----`) y muestra los campos de forma legible — útil para los escenarios clásicos de troubleshooting: verificar si un certificado está a punto de caducar antes de que el monitor de disponibilidad lance una alerta, confirmar qué dominios están cubiertos por los SANs antes de hacer un despliegue, identificar la cadena de CAs intermedias cuando un servidor devuelve errores SSL en algunos clientes pero no en otros, o simplemente entender qué hay dentro de un certificado sin necesidad de usar `openssl x509 -text` en la terminal. Un apunte práctico: los certificados emitidos por Let's Encrypt tienen una validez de 90 días por diseño — el argumento es que la rotación frecuente limita la ventana de exposición de claves comprometidas, y la automatización con certbot o Caddy elimina el trabajo manual de renovación.