| Field | Value | Copy |
|---|---|---|
| {{ k }} | {{ v }} | |
| No details available. | ||
| # | DNS / IP | Copy |
|---|---|---|
| {{ i + 1 }} | {{ n }} | |
| No SAN entries | ||
X.509 certificates are identity records that bind names to public keys for a limited validity window. They are useful only when their details can be inspected clearly, because a hostname mismatch, expired date, or unexpected issuer can break a deployment long before anyone starts debugging the cryptography itself. This decoder turns certificate blobs into readable fields so those checks happen quickly.
The package accepts pasted certificate text and uploaded certificate files, detects whether the input is a single certificate or part of a chain, and then chooses a likely leaf certificate for display. From there it surfaces subject and issuer names, serial number, validity dates, signature algorithm, public-key summary, SHA-256 and SHA-1 fingerprints, Subject Alternative Name entries, key-usage data, and a JSON payload for handoff or ticket notes.
That makes it practical for routine troubleshooting as well as inventory work. A support engineer can confirm whether the expected DNS name appears in SAN before a cutover. A PKI administrator can compare fingerprints or SPKI pins across environments. A security reviewer can check whether a certificate is marked as a CA, what path-length limit is encoded, and whether the usage flags match the intended role.
The page also handles container differences that often confuse quick inspections. The decode logic can pull certificates from PEM text, binary DER, base64-encoded DER, and PKCS#7 content, then keep basic metadata about how the chain was detected and which entry was selected as the likely leaf. That is useful when the file you received is not a single clean PEM block.
The limit is important: decoding a certificate is not the same as trusting it. This package does not build a trust chain, verify hostname matching, consult revocation sources, or tell you whether a browser or mail server will accept the result. It is a field decoder and comparison aid, not a path validator.
Start by deciding what you are trying to confirm. If the question is identity, compare the expected hostname with the SAN list and, secondarily, the subject common name. If the question is expiry, the validity window is the first thing to read. If the question is whether two artifacts are the same certificate or key, the fingerprints and SPKI pin give faster answers than visually comparing the subject text alone.
The input path matters less than the resulting fields, but it still affects workflow. Pasting PEM is the cleanest route when you already have the certificate in text form. Dropping a file is better when the content might be binary DER or PKCS#7. The package keeps track of whether it detected a PEM chain, DER, or PKCS#7 source so you can see what kind of container the certificate came from without manually re-encoding it first.
The overview tab is for the first pass. It collects the core facts into one table and supports CSV or DOCX export. The SAN tab is for host and service-name checks, especially when the certificate covers several DNS names or IP addresses. The JSON tab is for structured handoff, because it carries both the chosen certificate and the surrounding chain metadata.
Use the CA and usage fields carefully. A certificate with CA: Yes is not automatically wrong, but it means the certificate is allowed to issue other certificates and should usually not be deployed as a normal leaf in application traffic. Key Usage and Extended Key Usage are similar: they do not prove the certificate is trusted, but they often explain why a seemingly correct certificate still fails in a specific role.
The local-date display is convenient for fast review, but it is not authoritative for policy decisions. Time zone and locale formatting can change how the same not-before and not-after values appear. When timing matters, compare the ISO timestamps in the JSON output against the system or policy you actually care about.
The decoder resets its state, then chooses one of two entry paths. If text exists in the textarea, it tries text decoding first. If no text exists but a file buffer is present, it tries binary decoding. The text path can parse PEM certificates, PEM-encoded PKCS#7 content, and long base64 strings that decode into DER. The binary path tries DER first and then falls back to PKCS#7 DER decoding if a single-certificate parse fails.
When a chain is detected, the package builds a model for every certificate and then picks a likely leaf by preferring a non-CA entry. That matters because the first element in a file is not always the certificate a user actually wants to inspect. The chain metadata in the JSON output records how the source was detected, how many certificates were found, and which index was selected for the visible summary.
The certificate model combines raw and interpreted fields. Subject and issuer attributes are mapped into short-name keys such as CN, O, and OU. Validity is exposed both as ISO strings and localized strings. Signature algorithms are shown as friendly names when the object identifier is known. The model also extracts SAN values, SHA-256 and SHA-1 fingerprints, a public-key summary, an SPKI pin derived from the public-key structure, key-usage lists, extended-key-usage lists, and basic-constraints values such as CA state and path length.
The visible export surfaces are thin wrappers around those same decoded objects. The overview table can be copied or downloaded as CSV and exported as DOCX. The SAN list has the same CSV and DOCX paths. The JSON tab bundles the selected certificate, the chain array, and the chain-detection metadata so the result can be handed to another person without forcing them to repeat the decode.
The package is deliberately silent on trust. It does not validate signatures against a trust store, check OCSP or CRL status, or match SAN names against a target hostname. Those jobs require context outside the certificate blob itself. What this decoder does well is reveal the certificate's own encoded claims and let you compare them reliably.
| Input form | Package behavior | Why it matters |
|---|---|---|
| PEM certificate text | Decodes one certificate or an entire PEM chain | Useful for pasted server or CA material |
| PEM PKCS#7 text | Extracts every embedded certificate into the chain list | Supports bundle-style certificate containers without manual conversion |
| Base64 DER text | Attempts DER decoding when the text is long and base64-like | Recovers certificates from raw pasted DER encodings |
| Binary DER file | Parses the file directly as a single certificate | Avoids having to re-wrap the file into PEM first |
| PKCS#7 DER file | Falls back to PKCS#7 extraction when single-certificate decode fails | Lets the package surface the embedded chain instead of erroring immediately |
| Field group | Examples shown by the package | Interpretation value |
|---|---|---|
| Identity | Subject CN, O, OU, issuer CN and issuer O | Quick check of who the certificate claims to represent and who issued it |
| Lifecycle | Version, serial, valid-from, valid-to | Shows issuance window and certificate instance details |
| Crypto summary | Signature algorithm, public-key summary, SHA-256, SHA-1, SPKI pin | Supports fingerprint comparison and key continuity checks |
| Extensions | SAN, Key Usage, Extended Key Usage, CA flag, path length | Explains what identities and roles the certificate was encoded for |
The overview should be read as a certificate fact sheet. A matching subject or SAN name is useful, but it is only one part of the trust story. If the validity window is wrong, the issuer is unexpected, or the usage flags do not fit the intended role, the certificate can still be unsuitable even when the hostname appears to match.
Fingerprints and SPKI pins are most useful for comparison rather than judgment. They let you confirm whether two sources really carry the same certificate or key material. A different fingerprint does not automatically mean the new certificate is bad; it means the artifact changed and deserves conscious review.
The chain metadata is operational context, not a full path analysis. If the package selected one certificate from a chain, that selection is only a likely leaf choice based on CA properties. It is a helpful default for inspection, but not proof that the remaining chain is valid or complete.
A team is preparing to move traffic to api.example.com. They decode the presented certificate, open the SAN tab, and confirm that the expected DNS name is listed. If the SAN list contains only a parent name or an unrelated service name, the issue is obvious before any client begins failing hostname checks.
Two PEM files show the same subject and issuer text, but the team needs to know whether they are actually the same certificate. The SHA-256 fingerprint and serial number make that check immediate. If both values differ, the files are not the same issuance, even if the visible names look alike.
An uploaded file turns out to contain a small PKCS#7 bundle rather than a single PEM certificate. The package detects the container, extracts the certificates, and chooses a likely leaf for display. That keeps the first inspection useful without requiring the operator to split the bundle by hand.
No. It reads and summarizes the certificate fields, but it does not perform trust-store, hostname, OCSP, or CRL validation.
The package prefers a non-CA entry as the likely leaf so the overview starts with the certificate most people want to inspect first.
It is a digest of the subject public-key structure, which makes it useful for comparing key continuity even when other certificate fields change.
Use it for convenience, but rely on the ISO timestamps when exact time-zone handling matters.