X.509 Certificate Viewer

The X.509 Certificate Viewer parses PEM-encoded SSL/TLS certificates and displays subject, issuer, validity, key details, extensions, and fingerprints in a human-readable format -- all processed locally in your browser without uploading certificates to external servers. Paste a value like -----BEGIN CERTIFICATE-----...-----END CERTIFICATE----- and instantly see every field decoded.

Understanding X.509 Certificates

If you work with web servers, load balancers, or any service that speaks HTTPS, you deal with X.509 certificates constantly. An X.509 certificate is essentially a digitally signed document that binds a public key to an identity -- usually a domain name or an organization. When a browser connects to your server over TLS, it receives the certificate, checks that a trusted Certificate Authority signed it, and verifies that the domain in the address bar matches the names listed in the certificate. If anything is off -- wrong domain, expired date, untrusted signer -- the connection fails and users see a scary warning page.

The trouble is that certificates are encoded in ASN.1 DER, a binary format that is completely unreadable without tools. Even the PEM wrapper, which base64-encodes the binary data and adds header/footer lines, gives you nothing but a wall of characters. You cannot tell by looking at a PEM blob whether the certificate covers your domain, when it expires, or whether it uses a strong enough key. That is where a certificate viewer comes in: it decodes the binary structure and presents every field in plain text so you can verify things are correct before deploying to production.

This viewer is especially useful for certificates you cannot or should not upload to third-party inspection services. Internal CA certificates, client authentication certificates, and certificates containing proprietary organization details all deserve inspection in a tool that processes everything locally. Paste the PEM text, review the decoded output, and confirm that subject names, validity dates, key strength, and extensions all match your expectations.

How to View an X.509 Certificate

1. Open the X.509 Certificate Viewer tool
2. Paste your PEM-encoded certificate (starting with -----BEGIN CERTIFICATE-----)
3. The viewer instantly parses and displays all certificate fields
4. Review the decoded subject, issuer, validity period, key information, and extensions
5. Copy fingerprints or specific fields as needed

X.509 Certificate Fields Explained

Subject and Issuer

The Subject identifies who the certificate was issued to. The Issuer identifies the Certificate Authority (CA) that signed it. Both use Distinguished Name (DN) format:

Key Information

The viewer displays the public key algorithm and strength:

• RSA 2048-bit -- minimum acceptable for production certificates
• RSA 4096-bit -- higher security, slightly slower handshakes
• ECDSA P-256 -- equivalent to RSA 3072-bit with better performance
• ECDSA P-384 -- required by some compliance frameworks

Certificate Extensions

Modern certificates rely on extensions for critical functionality:

• Subject Alternative Names (SANs) -- all hostnames and IPs the certificate covers
• Key Usage -- permitted operations (digitalSignature, keyEncipherment)
• Extended Key Usage -- specific purposes (serverAuth, clientAuth)
• Basic Constraints -- whether the certificate can sign other certificates (CA:TRUE/FALSE)
• Authority Information Access -- OCSP responder and CA issuer URLs

Example Certificate Output

Pasting a typical Let's Encrypt certificate produces:

Subject:    CN=www.example.com
Issuer:     CN=R3, O=Let's Encrypt, C=US
Not Before: 2025-01-15 00:00:00 UTC
Not After:  2025-04-15 23:59:59 UTC
Serial:     04:A3:2B:9C:...
Algorithm:  RSA 2048-bit
SHA-256:    A1:B2:C3:D4:E5:F6:...
SHA-1:      1A:2B:3C:4D:5E:...

SANs:
  DNS: www.example.com
  DNS: example.com

When to Use This Tool

• Pre-deployment verification -- confirm certificate contents match your domain and intended configuration before installing on a server
• Troubleshooting TLS errors -- inspect certificates to find mismatched CNs, missing SANs, or expired validity periods
• Security audits -- review key strength, signature algorithm, and extension configuration across your certificate inventory
• Certificate chain inspection -- examine each certificate in a chain to identify the end-entity, intermediate, and root CAs
• Private certificate handling -- inspect internal or private CA certificates without uploading them to third-party services
• Incident response -- quickly decode a suspicious certificate from a packet capture or log file to assess its legitimacy

How X.509 Certificates Work

X.509 is the ITU-T standard defining the format of public key certificates. Every HTTPS connection relies on X.509 certificates to establish trust. The certificate binds a public key to an identity (domain name, organization) and is cryptographically signed by a trusted Certificate Authority.

Certificate Structure

An X.509v3 certificate contains these top-level fields:

Certificate:
  Version:            v3 (0x2)
  Serial Number:      unique identifier assigned by the CA
  Signature Algorithm: e.g., sha256WithRSAEncryption
  Issuer:             DN of the signing CA
  Validity:
    Not Before:       start of validity window
    Not After:        end of validity window
  Subject:            DN of the certificate holder
  Subject Public Key Info:
    Algorithm:        RSA, ECDSA, or Ed25519
    Public Key:       the actual key data
  Extensions:         SANs, Key Usage, AIA, etc.
  Signature:          CA's digital signature over all fields

Encoding Formats

Certificates are encoded using ASN.1 DER (binary) format, then typically wrapped in PEM (base64 with header/footer lines) for human handling. The -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- markers delimit the base64-encoded DER data. You can retrieve a server's certificate in PEM format using OpenSSL:

openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null

Certificate Inspection in Practice

The most important habit when working with certificates is to inspect them before deployment. It takes thirty seconds to paste a certificate into a viewer and confirm that the subject matches your domain, the SANs cover all the hostnames you need, the validity dates are reasonable, and the key algorithm meets your security requirements. Skipping this step is how teams end up deploying a certificate for the wrong domain or missing a SAN entry for an API subdomain that only gets noticed when monitoring alerts fire at 2 AM.

When troubleshooting TLS errors, start by getting the certificate the server is actually presenting. Run openssl s_client -connect yourserver.com:443 -servername yourserver.com and paste the PEM output into this viewer. Compare the decoded fields against what you expect: is the CN or SAN correct? Is the certificate expired? Is the issuer the CA you intended? Many TLS problems that look mysterious from an error message become obvious when you see the actual certificate fields side by side with your expectations.

For organizations managing dozens or hundreds of certificates, building a regular inspection routine is valuable. Export certificates from your servers, paste them into the viewer, and check for upcoming expirations, weak key sizes (RSA 1024 should have been retired years ago), or deprecated signature algorithms. This kind of proactive audit catches problems before they become outages.

Frequently Asked Questions

What is the difference between CN and SAN in a certificate? The Common Name (CN) is a legacy field in the Subject that historically held the domain name. Modern browsers now use Subject Alternative Names (SANs) exclusively for hostname validation. A certificate with CN=example.com but no matching SAN entry will fail validation in Chrome and Firefox. Always ensure your domains appear in the SAN extension.

How do I get the PEM text for a certificate I want to inspect? Use OpenSSL on the command line: openssl s_client -connect example.com:443 -showcerts outputs PEM certificates. You can also export from browser developer tools (Security tab), or find PEM files in server configurations -- they typically have .pem, .crt, or .cer extensions.

Can this viewer handle certificate chains? Yes. If you paste multiple PEM certificates (a full chain), the viewer parses each one individually. For splitting chains into separate certificates, use the PEM Bundle Splitter.

What does "CA:TRUE" mean in the Basic Constraints extension? A certificate with CA:TRUE in its Basic Constraints is authorized to sign other certificates -- it is a Certificate Authority certificate, not a leaf certificate. Leaf certificates used by web servers should always show CA:FALSE. If you see CA:TRUE on a certificate you expected to be a server certificate, something is wrong with your configuration.

Why does my certificate show a different issuer than the CA I purchased from? Certificate Authorities often use intermediate certificates to sign leaf certificates rather than signing directly with their root. The Issuer field shows the intermediate CA's name, not the root. This is normal and expected. You can trace the full chain by examining each certificate's Subject and Issuer fields from leaf to root.

How can I tell if a certificate uses a strong enough key? Check the Key Information section. For RSA, 2048 bits is the current minimum; 4096 bits provides extra margin. For ECDSA, P-256 (256 bits) provides security equivalent to RSA 3072-bit. Any RSA key below 2048 bits should be replaced immediately, as CAs will not issue certificates for smaller keys and browsers may reject them.

Related Tools

• Certificate Fingerprint Generator - Calculate SHA-256 and SHA-1 hashes for certificate pinning
• Certificate Expiry Checker - Check validity dates and days remaining until expiration
• SAN Extractor - Pull all Subject Alternative Names from a certificate
• CSR Viewer - Parse and inspect Certificate Signing Requests before submission
• PEM Bundle Splitter - Separate a certificate chain into individual PEM files
• Convert DER to PEM - Convert binary DER certificates to PEM format for inspection