Secure Sockets Layer (SSL) Certificate Decoder
Decode SSL certificates online to inspect issuer, SAN entries, validity dates, fingerprints, and usage flags for faster X.509 troubleshooting or audits.{{ 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 |
|---|---|---|---|---|
| {{ row.index }} | {{ row.subject }} | {{ row.issuer }} | {{ row.validity }} | {{ row.role }} |
Introduction
X.509 certificates are signed records that tie an identity to a public key for a stated validity window. When a site, API, gateway, mail system, or internal service starts failing certificate checks, the first job is usually much simpler than full trust validation: read the certificate clearly, confirm the names and dates, and make sure the file in front of you is actually the one you think it is.
This decoder turns pasted certificate text or loaded certificate material into a readable certificate summary, a Subject Alternative Name list, and a structured JSON record. It surfaces subject and issuer details, serial number, validity dates, signature algorithm, public-key summary, SHA-256 and SHA-1 fingerprints, an SPKI pin, key-usage fields, extended key-usage fields, CA state, and path-length information.
The decoder is especially useful when the input is messy. It can recognize ordinary PEM certificate text, base64 DER text, binary DER data, and PKCS#7 bundles that contain more than one certificate. If a chain is present, the tool keeps the whole decoded chain in the JSON output and shows one likely leaf certificate in the main summary so you can start reading without splitting the bundle by hand.
The privacy boundary is clear. The decoding work happens in your browser, and the exports are generated from that in-browser result. That makes the tool suitable for many routine inspection tasks where you want a quick read without sending certificate contents to a server-side checker.
The same boundary also defines what the result does not mean. Reading certificate fields is not the same as proving trust. This decoder does not build or verify a certification path, test revocation, confirm hostname matching against a live target, or tell you whether a browser or client library will accept the certificate in context. It shows the claims encoded in the certificate and lets you inspect them cleanly.
Technical Details
The certificate fields shown here follow the normal X.509 structure. RFC 5280 defines the validity period as the time from notBefore through notAfter, inclusive, and it defines how extensions such as Subject Alternative Name, Key Usage, Extended Key Usage, and Basic Constraints are meant to be interpreted. That is why the overview groups together identity, dates, cryptographic summary, and extension-derived limits instead of treating the certificate as plain text.
For name coverage, the most important split is between the subject common name and the Subject Alternative Name extension, usually shortened to SAN. Modern service-identity rules rely on SAN when it is present, with common-name matching reduced to a last-resort fallback when no supported SAN identity exists. This decoder does not perform a live hostname check, but it gives you the exact SAN entries it can read as DNS names, IP addresses, URIs, and email addresses so you can make that comparison yourself.
Usage fields matter for a different reason. Basic Constraints tells you whether a certificate is marked as a certificate authority. Key Usage and Extended Key Usage say what the certified key is meant to do. RFC 5280 treats those extensions as independent constraints, so a certificate needs a purpose that is consistent with both when both are present. That is why a certificate can look fine at a glance and still be wrong for the role you had in mind.
SHA-256 fingerprint = SHA-256(DER certificate bytes)SPKI pin = Base64(SHA-256(DER SubjectPublicKeyInfo))Leaf selection = first decoded certificate where CA = No, otherwise the first decoded certificateThose derived values solve different comparison problems. A certificate fingerprint changes when the certificate itself changes. An SPKI pin stays focused on the public key, so it is useful when you want to know whether two different certificate issuances still carry the same key material. Serial number, issuer, and validity dates add context, but the fingerprints and SPKI pin are the fastest way to compare artifacts without relying on visual similarity.
The decoder also keeps track of how the input was recognized. Text input is checked for PEM certificates, PEM PKCS#7, and long base64 DER strings. Binary input is checked as DER first and then as PKCS#7/CMS-style content. That distinction matters because certificate bundles are common in operations work, and RFC 7468 notes that textual PKCS#7 is still seen even though CMS is the newer successor format. The JSON export preserves the detected container type, the total number of decoded certificates, the selected certificate index, the chosen certificate, and the full chain array.
What the decoder can read from each source
| Source form | What the decoder does | Why that matters |
|---|---|---|
| PEM certificate text | Reads one certificate or several consecutive PEM certificates | Useful for pasted server certificates, copied bundles, and certificate chains from documentation or terminals |
| PEM PKCS#7 text | Extracts the embedded certificates into a decoded chain | Lets you inspect bundle-style content without converting it first |
| Base64 DER text | Attempts to decode the text directly as DER certificate data | Helps when the copied material is raw base64 rather than PEM-wrapped text |
| Binary DER data | Parses the binary content as a single certificate | Useful for exported certificate files that were never wrapped in PEM markers |
| Binary PKCS#7 data | Falls back to bundle extraction if a single-certificate DER parse does not fit | Prevents a common certificate-bundle format from looking like a broken file |
How to read the main fields
| Field group | What you learn | Typical use |
|---|---|---|
| Subject and SAN | The names or identifiers the certificate claims to cover | Checking expected DNS names, IP entries, service URIs, or email identities |
| Issuer, serial, validity | Who issued it, which issuance it is, and when it starts and stops being valid | Renewal checks, audit notes, and side-by-side comparison between old and new certificates |
| Signature algorithm and key summary | How the certificate was signed and a short description of the public key | Spotting older signatures, confirming key-family expectations, or documenting inventory |
| Fingerprints and SPKI pin | Stable comparison values derived from the certificate and the public key | Proving whether two files are the same certificate or whether they reuse the same key |
| Key Usage, Extended Key Usage, CA, path length | Operational limits on what the key and certificate can be used for | Explaining why a certificate belongs in a CA chain, a server role, or a different use entirely |
Everyday Use & Decision Guide
Start with the question you actually need answered. If you need to know whether a service name belongs on the certificate, go straight to SAN and compare the expected host there before you spend time on fingerprints or issuer details. If you need to know whether a certificate is the exact artifact you deployed, read serial number and fingerprints first. If the concern is role or chain position, read the CA flag and usage fields before treating a certificate as a normal leaf.
The overview tab is the fastest first pass because it gathers the main facts into one table and gives you copy, CSV, and DOCX exports. The SAN tab is better when the identity question is the whole job, especially with multi-name certificates. The JSON tab matters when you need a structured handoff, because it keeps the chosen certificate together with the full decoded chain and the detection metadata.
Read common name carefully. It is still useful for quick orientation, but it is not the whole identity story when SAN exists. For web and many other networked services, SAN is the field that should settle the question. That is why a certificate can have a familiar common name and still be the wrong certificate for the deployment you are checking.
Read dates with the same care. The tool shows local date strings because they are convenient for a quick human check, but the JSON output also keeps machine-readable timestamps. When expiry timing affects cutovers, change windows, or a disputed outage minute, use the structured timestamps for the final comparison rather than relying only on locale formatting.
| If you need to know | Check this first | Why |
|---|---|---|
| Does this certificate cover the host or service I expect? | SAN | It lists the concrete DNS, IP, URI, or email identities the decoder could read from the extension. |
| Is this the same certificate as another file or endpoint? | Serial number and SHA-256 fingerprint | Those values change when the certificate issuance changes, even when names look similar. |
| Did the certificate change but keep the same public key? | SPKI pin | It tracks the public key rather than the whole certificate object. |
| Am I looking at a CA certificate or a likely leaf certificate? | CA and Path Len | Those fields describe whether the certificate is allowed to sign other certificates and how far that authority can extend. |
| Is the certificate intended for the role I want? | Key Usage and Extended Key Usage | They show purpose restrictions such as certificate signing, server authentication, or client authentication. |
Step-by-Step Guide
- Paste certificate text into the input area, or load or drop the certificate material you want to inspect.
- Run the decoder and check whether the input was interpreted as PEM, DER, or PKCS#7-style bundle content.
- Read
Certificate Overviewfirst for subject, issuer, serial, validity dates, signature algorithm, fingerprints, usage flags, CA state, and path length. - Open
SANwhen the main question is name coverage or service identity. - Open
JSONwhen you need the chain metadata, extension dump, or a structured handoff for another person or system. - Export CSV, DOCX, or JSON only after you have confirmed that the selected certificate is the one you intended to inspect.
Interpreting Results
The safest way to read the result is as a certificate fact sheet, not as a pass or fail verdict. A familiar issuer does not prove the certificate belongs on the current service. A matching DNS name does not prove the certificate is trusted. A valid date window does not prove the whole chain is usable. Each field answers a narrower question, and the strength of the decoder is that it keeps those questions separate.
If the tool selects one certificate from a chain, treat that as a practical starting point rather than a formal path decision. The default leaf choice comes from the CA flag, which is a reasonable shortcut for inspection but not a substitute for full chain building. The JSON output keeps the rest of the decoded chain precisely because the surrounding certificates may still matter during troubleshooting.
Fingerprints and SPKI pin are comparison values, not quality scores. A changed SHA-256 fingerprint usually means you are looking at a different certificate issuance. A changed SPKI pin means the public key changed too. If the certificate renewed but the SPKI pin stayed the same, the organization may have reissued around the same key pair rather than generating a new one.
Usage fields often explain puzzling failures. A certificate marked as a CA certificate is normally wrong for a standard server leaf even if the subject name looks plausible. A missing or unexpected extended key usage can matter even when the basic key usage looks close enough. RFC 5280 explicitly says key usage and extended key usage must both be consistent with the intended purpose when both extensions are present.
Shorter validity windows are also normal in public Web PKI now. According to the CA/Browser Forum Baseline Requirements, subscriber certificates issued on or after March 15, 2026 and before March 15, 2027 must not exceed 200 days. If you decode a newly issued public TLS certificate in April 2026 and it is valid for far less than a year, that is usually expected rather than suspicious.
Worked Examples
Checking whether a replacement certificate kept the same key
An operations team receives a replacement certificate before a maintenance window. The subject and issuer text look familiar, but that alone does not prove key continuity. They decode the old and new files, compare the SPKI pin, and see that the pin is unchanged while the serial number and certificate fingerprint differ. That tells them the certificate was reissued around the same public key rather than rebuilt from a new key pair.
Finding the leaf certificate inside a bundle
A support ticket includes a PKCS#7 bundle instead of a single PEM certificate. The decoder extracts the certificates, marks the source as bundle content, and shows a likely non-CA leaf in the main summary. The engineer still has the full chain in JSON, but the first screen is immediately useful for reading names, dates, and issuer details without splitting the file manually.
Explaining why a certificate is wrong for the intended role
A certificate appears to come from the right private PKI and has a familiar common name, yet a deployment keeps failing. After decoding it, the team sees CA: Yes and usage bits that fit certificate signing rather than a normal leaf role. The decoder does not need to perform trust validation to make that mistake visible. The field set itself explains why the wrong certificate landed on the server.
FAQ:
Does this decoder send my certificate to a server?
The decode and export work is done in your browser. That makes it useful for many routine inspection tasks where you want local handling of certificate contents.
Does it verify trust, hostname matching, or revocation?
No. It reads the certificate claims and exports them cleanly, but it does not perform trust-store validation, live hostname verification, OCSP checks, or CRL checks.
Why does the decoder show one certificate when the file contains several?
When several certificates are decoded, the main summary chooses a likely leaf by preferring the first certificate that is not marked as a CA. The full chain still remains available in the JSON output.
Why is SAN more important than common name for host checks?
Modern service-identity rules prefer SAN when it is present. Common name is mainly a fallback for older situations where no supported SAN identity is available.
Why does a new public TLS certificate sometimes last only a few months?
Public certificate lifetimes are getting shorter. For subscriber certificates issued from March 15, 2026 through March 14, 2027, the CA/Browser Forum caps the maximum validity period at 200 days.
Glossary:
- X.509 certificate
- A structured digital certificate format that binds identities or names to a public key.
- SAN
- Subject Alternative Name, the extension that can carry DNS names, IP addresses, URIs, email addresses, and other identifier types.
- Extended Key Usage
- An extension that narrows the intended purposes of the certificate, such as server authentication or client authentication.
- SPKI pin
- A Base64-encoded SHA-256 digest of the SubjectPublicKeyInfo structure, useful for comparing public keys across certificate issuances.
- PKCS#7 / CMS bundle
- A container that can hold one or more certificates together instead of presenting just a single leaf certificate.
References:
- RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC Editor.
- RFC 6125: Representation and Verification of Domain-Based Application Service Identity within PKIX Certificates in the Context of TLS, RFC Editor.
- RFC 7468: Textual Encodings of PKIX, PKCS, and CMS Structures, RFC Editor.
- RFC 5652: Cryptographic Message Syntax (CMS), RFC Editor.
- Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, CA/Browser Forum.