Certificate Analyzer

X.509 Certificate Structure

X.509 is the standard format for public key certificates used in SSL/TLS, code signing, email encryption, and many other security protocols. An X.509 certificate is a structured data object encoded according to ASN.1 (Abstract Syntax Notation One) that binds a public key to an identity (a subject) and is signed by a trusted Certificate Authority (CA). Every HTTPS website uses an X.509 certificate to prove its identity to browsers.

The core fields of an X.509 certificate include the Subject (the entity the certificate belongs to, identified by its Distinguished Name), the Issuer (the CA that signed it), the Validity period (Not Before and Not After dates), the Public Key and its algorithm, and the CA's digital Signature over all the other fields. Extensions added in X.509 v3 carry additional information like Subject Alternative Names, Key Usage constraints, and CRL distribution points.

PEM vs. DER Certificate Formats

X.509 certificates can be encoded in two primary formats, and knowing the difference matters when working with TLS configurations and certificate management tools:

• DER (Distinguished Encoding Rules) is the binary format for encoding ASN.1 data. DER files contain raw binary data and cannot be opened in a text editor. They use the .der or .cer extension and are commonly used in Java environments and Windows certificate stores.
• PEM (Privacy-Enhanced Mail) is a Base64-encoded version of the DER format, wrapped with header and footer lines (-----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----). PEM is the most common format for web servers (Apache, Nginx) and is used by Let's Encrypt. The .pem, .crt, and .keyextensions all typically contain PEM-encoded data.

Our Certificate Analyzer accepts PEM format (paste the text starting with-----BEGIN CERTIFICATE-----) or any binary certificate file. All parsing happens in your browser using the Web Crypto API — your certificate bytes never leave your device, which is critical when analyzing certificates for production systems that may contain sensitive organizational information.

Certificate Extensions and Security Implications

X.509 v3 extensions significantly expand what a certificate can express. The Subject Alternative Name (SAN) extension is the most important for HTTPS: modern browsers require all domain names covered by a certificate to be listed as SANs. The legacy Common Name (CN) field is no longer sufficient and is ignored by Chrome and Firefox for hostname validation.

Key Usage and Extended Key Usage extensions constrain what a certificate can be used for. A certificate with Key Usage of "Digital Signature" and Extended Key Usage of "Server Authentication" (OID 1.3.6.1.5.5.7.3.1) is appropriate for HTTPS servers. If these constraints are absent or misconfigured, a certificate might technically be valid but functionally incorrect — causing connection failures in strict TLS clients.

The Basic Constraints extension identifies whether a certificate is a CA certificate (capable of signing other certificates) or an end-entity (leaf) certificate. A leaf certificate with the CA flag set to true is a major security misconfiguration — it would allow the certificate holder to issue fraudulent certificates. Certificate Transparency logs exist precisely to detect and expose such misissuances.