SSL Certificate Decoder: A Real ASN.1/X.509 Parser, Verified Against OpenSSL
An X.509 certificate is a binary ASN.1-encoded structure — readable text like "Issuer: CN=..." only appears after a parser walks that structure. This tool implements that parser from scratch: a generic ASN.1 DER decoder plus the fixed field layout RFC 5280 defines for certificates, checked during development against real OpenSSL-generated certificates to confirm every field — subject, issuer, serial, validity, public key, SANs — matches openssl x509 -text exactly.
Field order within tbsCertificate is fixed by RFC 5280, not self-describing — the parser has to know the schema.
PEM Is Just Base64-Wrapped DER
The -----BEGIN CERTIFICATE----- text format is nothing more than the certificate's raw binary DER (Distinguished Encoding Rules) bytes, base64-encoded and line-wrapped for safe copy-pasting. Stripping the markers and base64-decoding gets you back to the actual ASN.1 structure a certificate parser needs to walk.
ASN.1 DER: Tag, Length, Value, Recursively
Every element in a DER-encoded structure follows the same pattern: a tag byte (identifying the type — INTEGER, SEQUENCE, OCTET STRING, etc.), a length (in short or long form), and the value bytes. For constructed types like SEQUENCE, the 'value' is itself a series of nested tag-length-value elements — which is why a generic recursive parser can walk any DER structure without knowing its schema in advance.
Where X.509-Specific Knowledge Comes In
The generic ASN.1 parser alone just produces an untyped tree — turning that into 'Subject: CN=example.com' requires knowing RFC 5280's fixed field order (version, serial, signature algorithm, issuer, validity, subject, public key, extensions) and a table mapping object identifiers (OIDs) like 2.5.4.3 to human-readable names like CN.
Practical Examples
Inspecting a Server's Certificate
Decoding what a browser sees.
- 1.openssl s_client -connect example.com:443 -showcerts
- 2.Copy the leaf certificate's PEM block
- 3.Paste here to see subject, SANs, and validity
Checking a Certificate's SANs
Confirming which hostnames are covered.
- 1.Paste the certificate
- 2.Review the Subject Alternative Names list
- 3.Confirm the exact hostname you need is listed
Fields This Tool Decodes
- Subject and Issuer distinguished names
- Serial number and signature algorithm
- Validity period (Not Before / Not After)
- Public key algorithm and size
- Subject Alternative Names (DNS, IP, email)
- Key Usage and CA status
Good Use Cases
- Inspecting a certificate without installing openssl
- Debugging a hostname/SAN mismatch error
- Checking a certificate's expiry date at a glance
- Learning what's actually inside an X.509 certificate
Frequently Asked Questions
How does this decode a certificate without a crypto library?
It implements a generic ASN.1 DER parser (the binary encoding X.509 certificates use) from scratch, then walks the resulting tree using the fixed field order defined in RFC 5280. This was verified during development against real certificates generated with OpenSSL, matching openssl x509 -text field-for-field.
Where do I get a certificate's PEM text to paste here?
Run openssl s_client -connect example.com:443 -showcerts and copy the first -----BEGIN CERTIFICATE----- block, or export a certificate as PEM/Base-64 from your browser's certificate viewer, or read a .pem/.crt file directly.
What are Subject Alternative Names (SANs)?
The list of additional hostnames (and sometimes IP addresses or email addresses) a certificate is valid for, beyond the CN in the subject. Modern browsers require the hostname being visited to appear in the SAN list — the subject CN alone is no longer sufficient for validation.
What does 'Certificate Authority (CA): Yes' mean?
It means the certificate's basicConstraints extension marks it as allowed to sign other certificates — this is what makes a certificate a root or intermediate CA rather than an end-entity (leaf/server) certificate.
Does this verify the certificate's signature or trust chain?
No — this tool only decodes and displays the certificate's fields. It doesn't verify the signature against the issuer's public key or check the certificate against a trust store; use the SSL Certificate Validator for expiry/weakness checks, or your browser/openssl verify for full chain validation.
Is my certificate sent anywhere?
No, parsing happens entirely in your browser via a local ASN.1 parser — no upload. Certificates are public information by design (unlike private keys), but this still runs fully offline.