Secure Sockets Layer (SSL) Certificate Decoder
Decode SSL certificates from PEM, DER, or PKCS#7 in your browser, with SAN coverage, validity, fingerprints, usage, and chain checks.{{ summaryHeading }}
| Field | Value | Copy |
|---|---|---|
| {{ row.field }} | {{ row.value }} |
| # | Type | Name | Copy |
|---|---|---|---|
| {{ row.index }} | {{ row.type }} | {{ row.value }} | |
|
No SAN entries parsed
The certificate did not expose subject alternative names in the parsed extension set.
|
|||
| Extension | OID | Critical | Value | Copy |
|---|---|---|---|---|
| {{ row.name }} | {{ row.oid }} | {{ row.critical }} | {{ row.value }} | |
|
No certificate extensions parsed
Paste a certificate that includes extension data to populate this ledger.
|
||||
| # | Subject | Issuer | Validity | Role | Copy |
|---|---|---|---|---|---|
| {{ row.index }} | {{ row.subject }} | {{ row.issuer }} | {{ row.validity }} | {{ row.role }} |
People often still say SSL certificate, even though modern encrypted web traffic uses Transport Layer Security. The practical object is the same one administrators handle during renewals and outages: an X.509 certificate that presents a public key, a set of names, an issuer, a serial number, a validity window, and extensions that describe how the certificate is meant to be used.
A certificate is not just a name badge for a website. It is part of a public key infrastructure where a leaf certificate is signed by an intermediate certificate, the intermediate traces back toward a trusted root, and a client decides whether the presented certificate is acceptable for the service it is trying to reach. Inspection matters when a browser reports a name mismatch, a load balancer serves an old certificate, a monitoring check warns about expiry, or a private PKI file contains several certificates and nobody is sure which one is the end-entity certificate.
The name fields are the easiest place to make a wrong assumption. A Common Name may look familiar, but modern service identity checks rely on Subject Alternative Name entries for DNS names and IP addresses. Wildcards also have limits: *.example.com can cover api.example.com, but not deep.api.example.com. A certificate can therefore be time-valid and signed by a recognizable issuer while still being wrong for the hostname a client requested.
Dates and fingerprints answer different questions. The validity window says when the certificate is allowed to be used by time, while a SHA-256 fingerprint identifies the exact certificate bytes and an SPKI pin identifies the public key inside the certificate. Those comparison values are useful during rotations because a new certificate can keep the same key, change the key, or accidentally leave an old certificate on one server behind a load balancer.
Decoding a certificate reveals claims and warning signs; it does not prove trust. Real acceptance still depends on path building, trusted roots, revocation handling, hostname policy, application purpose, and the certificate actually presented by the live service.
How to Use This Tool:
Use the decoder when you have certificate text, a certificate file, or a PKCS#7 container and need a readable inventory before comparing it with a live service or deployment record.
- Paste PEM certificate text, base64 DER text, or PKCS#7 text into Certificate or bundle, or use Browse certificate for PEM, CRT, CER, DER, P7B, P7C, or TXT files.
- Select Decode certificate. The summary should show whether a leaf or CA certificate was decoded, the common name, date status, key summary, and decoded certificate count.
- Open Advanced when the input has more than one certificate. Certificate selection can auto-pick the first non-CA certificate, use the first certificate, or use the last certificate in the bundle.
- Enter a DNS name in Hostname to match when name coverage matters. URLs are reduced to their host, and the Name Coverage results show whether a parsed DNS Subject Alternative Name matches exactly or through a one-label wildcard.
- Use Show UTC dates when comparing the output with OpenSSL, monitoring systems, CI logs, or expiry alerts that report ISO UTC timestamps.
- Review Certificate Fields for subject, issuer, serial, validity, fingerprints, public key, SPKI pin, usage fields, and local warning rows. Then use Certificate Extensions and Chain Inventory for role and chain context.
- Use JSON when the selected certificate and decoded chain need to move into a ticket, audit note, or scripted comparison.
If the page reports No certificate found in input, confirm that the pasted text includes certificate boundaries or a long base64 DER body. For file errors, try the original DER, P7B, P7C, PEM, CRT, or CER file rather than text copied through a rich-text editor.
Interpreting Results:
Treat the output as a field inspection, not a complete TLS verdict. The most useful first checks are the selected certificate role, the Validity window, the Identity coverage note, and any review rows added to Certificate Fields.
| Output group | Useful for | Do not overread it as |
|---|---|---|
| Subject and issuer | Identifying who the certificate names and who signed it. | Proof that the issuer is trusted by the client you care about. |
| Subject Alternative Name | Checking DNS, IP, URI, and email identities parsed from the certificate. | Proof that every application service type or client policy will accept the identity. |
| Validity window | Finding expired, not-yet-valid, or under-30-day renewal cases. | Proof that revocation, chain trust, deployment, and hostname checks will pass. |
| Fingerprints and SPKI pin | Comparing exact certificate bytes or public-key continuity across renewals. | Proof that the matching private key is currently deployed or controlled. |
| Usage and CA fields | Spotting server-auth, client-auth, signing, CA, and path-length signals. | Proof that every relying party will accept the certificate for that role. |
A green date status can still fail in production if the server presents a different certificate, the intermediate chain is missing, the hostname is absent from DNS SAN entries, or the client rejects the issuer or signature policy. When a live endpoint is in question, compare the SHA-256 Fingerprint or SPKI pin (sha256/base64) from this decode with a certificate captured from that endpoint.
The local hostname check covers decoded DNS SAN entries, exact names, and one-label wildcards. It does not replace full service-identity validation for IP SAN entries, URI-based identities, mail or messaging service identifiers, revocation, certificate transparency, or trust-store policy.
Technical Details:
X.509 version 3 certificates use a signed structure that combines a subject name, issuer name, serial number, validity period, public key, signature algorithm, and optional extensions. The extensions carry much of the practical TLS meaning: Subject Alternative Name lists service identities, Key Usage and Extended Key Usage restrict acceptable purposes, and Basic Constraints distinguishes CA certificates from ordinary end-entity certificates.
Certificate decoding is a transformation from an encoded container into field groups. PEM wraps binary DER data in text boundaries. DER is the binary ASN.1 encoding. PKCS#7 can carry several certificates together, commonly as a chain or bundle. Once the certificate objects are decoded, the same field-reading rules apply regardless of which container delivered them.
Transformation Core:
| Stage | Rule | Shown output |
|---|---|---|
| Input recognition | Text input is checked for PEM certificates, PEM PKCS#7 content, and long base64 DER. Binary file input is checked first as DER and then as PKCS#7 DER. | Detected source type and decoded certificate count. |
| Certificate selection | Auto-pick leaf chooses the first decoded certificate that is not marked as a CA. First and last modes use the corresponding certificate position. | The selected certificate drives the summary, Certificate Fields, Name Coverage, Certificate Extensions, and JSON certificate object. |
| Field extraction | Subject, issuer, serial, validity dates, signature algorithm, public key details, fingerprints, SPKI pin, SAN entries, usage fields, Basic Constraints, and extension records are read from the selected certificate. | Certificate fact tables and copyable rows. |
| Chain inventory | Every decoded certificate remains available even when only one certificate is selected for the main view. | Subject, issuer, validity range, and leaf or CA role for each decoded certificate. |
| Hostname comparison | A supplied hostname is normalized from a host or URL and compared only with parsed DNS SAN values. | Host matched, host mismatch, or a prompt to enter a hostname. |
Rule Core:
| Signal | Local rule | Practical meaning |
|---|---|---|
| Date status | Not yet valid when the browser clock is before notBefore; expired when it is after notAfter; renew soon when fewer than 30 whole days remain; otherwise date-valid. |
The certificate may still fail for chain, revocation, hostname, or policy reasons. |
| Missing SAN | No parsed Subject Alternative Name entries add a name-coverage warning. | Modern TLS hostname checks expect SAN identities for normal server certificates. |
| Hostname match | Exact DNS SAN matches pass. Wildcard DNS SAN entries match one label below the wildcard suffix only. | *.example.com can match api.example.com, but not deep.api.example.com. |
| Signature algorithm | Signature names containing SHA-1 or MD5 receive a legacy warning. | Older signatures can parse correctly while failing modern client or CA policy. |
| RSA key size | RSA public keys below 2048 bits receive a short-key warning. | Short RSA keys are usually unsuitable for modern public TLS use. |
| CA signaling | A certificate marked as a CA without parsed keyCertSign usage receives a usage warning. |
CA role and signing usage should agree before a certificate is treated as an issuer. |
Formula Core:
Date and pin fields are deterministic comparisons and digests derived from decoded certificate values. Day counts are rounded down to whole days using the current browser clock.
For example, a certificate with 11 whole days between the browser clock and notAfter is labeled Renew soon, while a certificate whose notAfter has already passed is labeled Expired. A certificate reissued with the same public key can have a new SHA-256 Fingerprint while keeping the same SPKI pin (sha256/base64).
Publicly trusted TLS server certificates also follow CA/Browser Forum profile rules beyond basic X.509 parsing. Those rules include Subject Alternative Name requirements and scheduled maximum-validity limits for subscriber certificates. They explain why validity length and SAN entries deserve attention, but full public-trust compliance still requires checks beyond field decoding.
Privacy Notes:
The decode action runs in the browser after the page loads. Certificate text and selected files are not uploaded by the decoding step, but certificate contents can still expose internal hostnames, email identities, organization names, issuer names, or private PKI structure.
Be careful with shared tickets, screenshots, and copied JSON. A certificate is often public on an internet-facing service, but private PKI certificates and unreleased hostnames can be sensitive inventory data.
Worked Examples:
Renewal near expiry. A PEM server certificate decodes as Leaf Certificate Decoded with Days Remaining set to 11 and the validity badge showing Renew soon. The certificate is still inside its date window, but the short remaining time belongs in the renewal plan before checking chain deployment.
Hostname mismatch. A certificate has Common Name set to www.example.com, but Name Coverage lists only DNS: api.example.com. A probe for www.example.com returns Host mismatch, so the common name should not be used as proof that the hostname is covered.
Reissue with the same key. Two decoded certificates have different Serial and SHA-256 Fingerprint values, but the same SPKI pin (sha256/base64). That points to a reissue around the same public key, which can matter for pinning, inventory comparison, or staged key rotation.
Container troubleshooting. A P7B file reports several certificates in Chain Inventory, but the main view selected an intermediate because every decoded certificate is marked as a CA. Changing Certificate selection to first or last lets you inspect each certificate, but it also confirms that the container may not include a normal server leaf.
FAQ:
Does this verify whether a certificate is trusted?
No. It decodes fields, compares DNS SAN entries when you enter a hostname, and shows local warnings. It does not build a trusted path, query revocation, apply a browser trust store, or confirm what a live service is presenting.
Why does the common name not match the hostname result?
The hostname check uses parsed DNS Subject Alternative Name entries. A familiar Common Name can still fail if the hostname is absent from SAN or is only covered by a wildcard that does not reach that label depth.
What certificate formats can I paste or upload?
You can paste PEM certificate text, long base64 DER text, or PEM PKCS#7 content, and you can upload PEM, CRT, CER, DER, P7B, P7C, or TXT files. Corrupted binary files and text without certificate data produce an error.
Why does a bundle show only one certificate in the summary?
The summary and main tables focus on the selected certificate. Use Certificate selection to choose leaf, first, or last, and use Chain Inventory or JSON to review every decoded certificate in the bundle.
What should I compare during a renewal?
Compare Common Name, Name Coverage, Valid To, SHA-256 Fingerprint, and SPKI pin. A new certificate should usually change the fingerprint, may or may not change the SPKI pin, and must still cover the intended hostname.
Glossary:
- X.509 certificate
- A structured certificate format that binds a subject identity and public key to issuer-signed data.
- Leaf certificate
- The end-entity certificate normally presented by a server for its own identity.
- Subject Alternative Name
- The extension that carries DNS names, IP addresses, URIs, email identities, and related service identifiers.
- Basic Constraints
- The extension that indicates whether a certificate can act as a certificate authority and, when present, its path-length limit.
- SPKI pin
- A Base64-encoded SHA-256 digest of the SubjectPublicKeyInfo structure, used to compare public keys across certificate issuances.
- PKCS#7
- A container format that can carry one or more certificates together.
References:
- RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile, RFC Editor, May 2008.
- RFC 8446: The Transport Layer Security Protocol Version 1.3, RFC Editor, August 2018.
- RFC 9525: Service Identity in TLS, RFC Editor, November 2023.
- Baseline Requirements for Publicly-Trusted TLS Server Certificates, CA/Browser Forum.