Secure Sockets Layer (SSL) Certificate Decoder

Decoding the certificate locally...

Certificate or bundle:

Paste PEM, base64 DER, or PKCS#7, or drop PEM, CRT, CER, DER, P7B, P7C, or TXT.

Drop PEM, CRT, CER, DER, P7B, P7C, or TXT onto the textarea.

Certificate selection:

Auto-pick leaf works for normal chains; choose first or last for bundle audits.

Hostname to match:

Use a DNS name such as www.example.com; URLs are normalized to their host.

Show UTC dates:

Show ISO UTC when matching OpenSSL, CI, or expiry-monitor timestamps.

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 }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Administrators still say SSL certificate in everyday work, but modern HTTPS uses Transport Layer Security. The object being inspected is an X.509 certificate: a signed record that binds a public key to names, dates, issuer information, serial numbers, and extensions that tell clients how the certificate is meant to be used.

A certificate sits inside a wider trust decision. A web server usually presents a leaf certificate for the requested hostname, one or more intermediates help connect that leaf to a root, and the client applies hostname, validity, usage, revocation, and trust-store policy. Decoding the fields is therefore useful during renewal, incident response, and bundle cleanup, but it is not the same as proving that a live endpoint will be trusted.

Certificate inspection questions and limits
Question	Fields that help	Limit to remember
Is this the certificate I expected?	Subject, issuer, serial, SHA-256 fingerprint, and SPKI pin.	A file can differ from what a load balancer or CDN is serving.
Will the hostname be covered?	Subject Alternative Name DNS entries and wildcard patterns.	Common Name text is not enough for modern server identity checks.
Is renewal urgent?	notBefore, notAfter, days remaining, and the validity status.	A date-valid certificate can still fail chain, trust, hostname, or revocation checks.
What role does the certificate claim?	Basic Constraints, Key Usage, and Extended Key Usage.	Role fields must be interpreted with issuer policy and client policy.

Name coverage is one of the easiest certificate details to misread. A familiar Common Name can still be ignored by modern TLS clients when the Subject Alternative Name extension is present or required. Wildcards are also narrow: *.example.com can cover api.example.com, but not deep.api.example.com or the bare example.com.

Fingerprints and dates answer different operational questions. A SHA-256 fingerprint identifies the exact certificate bytes, while an SPKI pin identifies the public key inside the certificate. During a renewal, the fingerprint normally changes; the SPKI pin may stay the same if the certificate is reissued around the same key. The validity dates then tell you whether the file is inside its allowed time window, not whether every client will accept it.

Certificate decoding is strongest when it is paired with a live capture from the service that users actually reach. Files in a ticket, a deployment directory, or a PKCS#7 bundle can be correct on their own and still fail to match the certificate presented by a reverse proxy, CDN, mail gateway, or older backend node.

How to Use This Tool:

Use the decoder when you have certificate text, a certificate file, or a certificate bundle and need a readable field inventory before comparing it with a service, deployment record, or renewal plan.

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 identify a leaf or CA certificate, show the common name, date status, key summary, issuer clue, and decoded certificate count.
Open Advanced when the input contains 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 service identity matters. URLs are reduced to their host, and the name result compares that host with parsed DNS Subject Alternative Name entries.
Use Show UTC dates when comparing output with OpenSSL, CI logs, expiry monitors, or server-side timestamps that use ISO UTC.
Review Certificate Fields for subject, issuer, serial, validity, fingerprints, public key, SPKI pin, usage fields, and warnings. Use Name Coverage, Certificate Extensions, and Chain Inventory to audit names, roles, and bundle contents.
Copy or download CSV, DOCX, or JSON only after the summary, warnings, and selected certificate match the audit question you are answering.

If the page reports No certificate found in input, check for certificate boundaries or a long base64 DER body. For file errors, try the original PEM, CRT, CER, DER, P7B, P7C, or TXT file rather than text copied through a formatted document.

Interpreting Results:

Treat the result as local certificate field inspection. The first checks are the selected certificate role, the Validity window, the Identity coverage note, and any review rows added to Certificate Fields. Those rows can explain why a certificate deserves attention before a full endpoint or trust-store test.

Certificate output groups and interpretation cautions
Output group	Useful for	Do not treat it as
Subject and issuer	Identifying who the certificate names and who signed it.	Proof that the issuer is trusted by the client or operating system.
Subject Alternative Name	Checking parsed DNS, IP, URI, and email identities in the certificate.	Proof that every application-specific identity policy will pass.
Validity window	Finding expired, not-yet-valid, and under-30-day renewal cases.	Proof that revocation, chain trust, hostname checks, or deployment all pass.
Fingerprints and SPKI pin	Comparing exact certificate bytes and public-key continuity across renewals.	Proof that the private key is controlled or that the file is currently served.
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 date-valid result can still fail in production when 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, signature algorithm, or policy. When a live endpoint is the real subject, compare the SHA-256 Fingerprint or SPKI pin (sha256/base64) from the decoded file with a certificate captured from that endpoint.

The hostname comparison covers parsed DNS SAN entries, exact names, and one-label wildcard patterns. It does not replace full service-identity validation for IP SAN entries, URI names, email identities, revocation status, certificate transparency, or trust-store policy.

Technical Details:

X.509 version 3 certificates combine a subject name, issuer name, serial number, validity period, public key, signature algorithm, and optional extensions inside a signed structure. The extensions carry most of the practical TLS meaning: Subject Alternative Name lists service identities, Key Usage and Extended Key Usage restrict acceptable purposes, and Basic Constraints marks CA certificates and path-length constraints.

Container format and certificate meaning are separate concerns. PEM is base64 DER wrapped in text boundaries. DER is the binary ASN.1 encoding of a certificate. PKCS#7 can carry several certificates together, often as a chain or certificate bundle. After the certificates are decoded, the same field-reading rules apply no matter which container supplied them.

Transformation Core:

Certificate decoding stages and shown outputs
Stage	Rule	Shown output
Input recognition	Text is checked for PEM certificates, PEM PKCS#7 content, and long base64 DER. Binary files are checked as DER certificates and then as PKCS#7 DER.	Detected source type and decoded certificate count.
Certificate selection	Auto-pick leaf chooses the first decoded certificate not marked as a CA. First and last modes use the corresponding bundle position.	The selected certificate drives the summary, fields, name coverage, extensions, and JSON certificate object.
Field extraction	Subject, issuer, serial, validity dates, signature algorithm, public key, fingerprints, SPKI pin, SAN entries, usage fields, Basic Constraints, and extension rows are read from the selected certificate.	Certificate field tables, review rows, and copyable values.
Chain inventory	Every decoded certificate remains listed even when 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 host or URL is normalized to a DNS host and compared only with parsed DNS SAN values.	Host matched, host mismatch, or a prompt to enter a hostname.

Rule Core:

Local certificate warning and status rules
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 can still fail chain, revocation, hostname, issuer, or policy checks.
Missing SAN	No parsed Subject Alternative Name entries add a name-coverage warning.	Modern TLS clients 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 generally 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 counts and pin values are deterministic comparisons or digests derived from decoded certificate values. Whole-day counts are rounded down using the current browser clock.

\begin{array}{lcl} Days Remaining & = & floor (\frac{notAfter - now}{86,400,000 milliseconds}) \\ Lifetime Days & = & floor (\frac{notAfter - notBefore}{86,400,000 milliseconds}) \\ SPKI Pin & = & Base64(SHA-256(DER SubjectPublicKeyInfo)) \end{array}

A certificate with 11 whole days between the browser clock and notAfter is labeled Renew soon. A certificate whose notAfter is already in the past is labeled Expired. A reissued certificate can have a new SHA-256 Fingerprint while keeping the same SPKI pin (sha256/base64) if the public key did not change.

Publicly trusted TLS server certificates also follow CA/Browser Forum baseline requirements beyond basic X.509 parsing. Those requirements explain why SAN entries, key size, validity length, and signing profile deserve attention, but full public-trust compliance 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 certificates can still reveal internal hostnames, email identities, organization names, issuer names, serials, or private PKI structure.

Be careful with shared tickets, screenshots, exported DOCX files, and copied JSON. A public website certificate is often visible to anyone who connects to the 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 file 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 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.

Bundle troubleshooting. A P7B file reports several certificates in Chain Inventory, but auto-pick selects an intermediate because every decoded certificate is marked as a CA. Changing Certificate selection to first or last lets you inspect each entry and confirms that the bundle may not include a normal server leaf.

FAQ:

Does this prove 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 can the Common Name differ from the hostname result?

The hostname check uses parsed DNS Subject Alternative Name entries. A familiar Common Name can still fail if the hostname is missing 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 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 renewal?

Compare Common Name, Name Coverage, Valid To, SHA-256 Fingerprint, and SPKI pin. A new certificate usually changes 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.
How to check SSL certificate expiration with cURL, Simplified Guide.
How to configure Let's Encrypt SSL in Nginx, Simplified Guide.
How to configure self-signed SSL/TLS certificates in Apache, Simplified Guide.