Certificate Decoder

What is an X.509 certificate?

An X.509 certificate is a signed document that binds a public key to an identity, such as a domain name. In HTTPS, validating it helps the client authenticate the server. It contains the issuer, validity period, subject alternative names and public key, among other fields.

Structure of an X.509 certificate

An X.509 v3 certificate (RFC 5280) binds a public key to an identity, under a CA’s signature. It has three parts: the tbsCertificate, which holds the signed fields, the signature algorithm and the signature itself. The signed fields are the serial number, the issuer and subject (distinguished names: CN, O, OU, C…), the validity period (notBefore, notAfter), the public key and the extensions.

The extensions carry most of the meaning. basicConstraints says whether the certificate is a CA, keyUsage and extendedKeyUsage restrict its uses (serverAuth for a TLS server), subjectAltName lists the names covered, authorityInfoAccess gives the OCSP responder and the intermediate’s address, cRLDistributionPoints the revocation list. The CN no longer matters for host names: RFC 2818 already required the SAN to be used when present in 2000, and Chrome has ignored the CN since version 58 (2017).

On disk, a certificate is either DER, the binary ASN.1 encoding, or PEM, the same DER in base64 between -----BEGIN CERTIFICATE----- lines (RFC 7468). The .crt and .cer extensions are used for both. A PKCS#7 file (.p7b, RFC 2315) carries a list of certificates without a key; a PKCS#12 file (.pfx, .p12, RFC 7292) usually holds the private key, protected by a password. Conversions: openssl x509 -inform DER -in a.cer -out a.pem, openssl pkcs7 -print_certs -in a.p7b, openssl pkcs12 -in a.pfx -nokeys.

Certificates as a recon source

The SAN of a production certificate often lists far more than the target site: APIs, staging, VPNs, admin consoles. The certificate served on a bare IP address gives the virtual host name to put in the Host header to reach the right application, and a wildcard hints at a naming scheme to complete with DNS enumeration. Internal names (.local, .corp, .internal, RFC 1918 ranges) reveal the private network, and the LDAP URLs in an AD CS CRL distribution point give away the Active Directory domain and the CA server.

Certificate Transparency (RFC 6962, 2013) requires public CAs to record every certificate in public, append-only logs; Chrome has required it for certificates issued after 30 April 2018. Those logs make a complete, historical inventory of each domain’s names, which crt.sh (run by Sectigo) lets you search: %.example.com returns every certificate issued for the domain and its subdomains, hosts retired since included. It is fully passive recon, with no packet sent to the target.

The chain of trust

A client accepts a server certificate if it leads, signature by signature, to a root in its trust store. The server must send its leaf then the intermediates; the root is pointless since the client already holds it. TLS 1.2 (RFC 5246) required the leaf first, then each certificate signed by the next one; TLS 1.3 (RFC 8446) asks clients to tolerate any order, which older, Java or embedded libraries still handle poorly.

A missing intermediate goes unnoticed in Chrome on Windows, which downloads it from the caIssuers URL in the AIA extension, but breaks curl, OpenSSL, mobile apps and most API clients. The tool checks each link (issuer name, AKI and SKI key identifiers, signature) with Web Crypto. It consults neither a trust store nor revocation status: for that, use openssl verify -CAfile or test the live connection.

Common weaknesses and CA/B Forum rules

The CA/B Forum Baseline Requirements bind every CA trusted by browsers. They have banned SHA-1 certificates since 1 January 2016 and internal names or reserved addresses since 1 November 2015, and they require RSA keys of at least 2048 bits. MD5 signatures were ruled out much earlier: an MD5 collision was used to forge a CA certificate in 2008.

The maximum validity of a public certificate depends on its issuance date: 39 months from 1 April 2015, 825 days from 1 March 2018 (ballot 193), then 398 days from 1 September 2020, a rule Apple imposed and the Baseline Requirements adopted through ballot SC31 in July 2020. Ballot SC-081v3, adopted on 11 April 2025, lowers it to 200 days for certificates issued from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. The tool applies the cap in force on the notBefore date, and only to certificates that carry a CA/B Forum policy or SCTs.

Outside those rules, the typical flaws of an internal PKI or an appliance are self-signed certificates, which users learn to accept, server certificates flagged CA:TRUE (the default of openssl req -x509 with the stock configuration), wildcards shared across many servers, and lifetimes of ten years or more.

Defence

• Keep an inventory of certificates from the CT logs: crt.sh, Cert Spotter or a dedicated monitor report any issuance for your domains, including by a third party.
• Automate renewal with ACME (RFC 8555): the short lifetimes coming by 2029 make manual renewal untenable, and a stolen key soon stops being useful.
• Keep internal names out of public certificates: reserve them for an internal PKI and avoid putting staging and production in the same SAN.
• Publish a CAA record (RFC 8659) to restrict which CAs may issue for your domains.
• Prefer one certificate per service to shared wildcards, and ECDSA P-256 or RSA 2048-bit and larger keys, signed with SHA-256.