Decode any X.509 certificate free. Paste PEM, upload .crt/.cer/.der, or fetch by domain to view subject, SANs, issuer, expiry and fingerprints.
This X.509 certificate decoder turns an opaque block of Base64 into a readable breakdown of every field an SSL/TLS certificate carries: subject, issuer, validity window, Subject Alternative Names, public key algorithm and size, extensions, and SHA-256, SHA-1 and MD5 fingerprints. Paste a PEM block, upload a .pem, .crt, .cer or .der file, or type a domain name and let the tool fetch the live certificate straight from the server. Decoding happens in your browser using the Web Crypto API and a JavaScript ASN.1 parser, so a pasted or uploaded certificate never leaves your machine.
Administrators reach for a decoder at exactly the moments where guessing is expensive: confirming that a newly issued certificate actually covers www as well as the apex domain, checking whether the file a vendor emailed is the leaf or the intermediate, working out why a browser reports a name mismatch, or pinning down the precise expiry timestamp before a change window. Instead of remembering openssl x509 -in cert.pem -noout -text and its dozen flags, you get the same information laid out with the security-relevant parts highlighted.
-----BEGIN CERTIFICATE-----; it also accepts raw DER supplied as hexadecimal. The Upload File tab accepts .pem, .crt, .cer and .der files by click or drag-and-drop. The URL tab takes a hostname such as example.com and retrieves the certificate the server is currently presenting, along with the chain it sends.An X.509 certificate is an ASN.1 structure defined by RFC 5280. Version 3 — the only version in practical use on the public web — wraps a core set of fields plus an open-ended list of extensions. Here is what each decoded field means and why it matters.
| Field | What it contains | Why it matters |
|---|---|---|
| Version | 1, 2 or 3 (shown as the integer) | Only v3 supports extensions such as SAN; v1 certificates cannot name multiple hosts. |
| Serial Number | A large integer unique to the issuing CA | The identifier used in CRL and OCSP revocation lookups. |
| Subject | CN, O, OU, C, ST, L | Identifies the entity. Modern browsers ignore CN for hostname matching — SAN governs. |
| Issuer | The DN of the signing CA | If Issuer equals Subject, the certificate is self-signed and the tool flags it. |
| Not Before / Not After | UTC timestamps | The validity window. Public TLS certificates are now capped at roughly 13 months. |
| Public Key | Algorithm, key size, modulus or curve | RSA below 2048 bits and any use of a deprecated curve are security findings. |
| Signature Algorithm | e.g. sha256WithRSAEncryption, ecdsa-with-SHA256 | SHA-1 signatures are rejected by every current browser. |
| Extensions | SAN, Key Usage, Extended Key Usage, Basic Constraints, AKI/SKI, CRL and AIA URIs | Each is shown with its OID and its critical flag, because a critical extension a client cannot process must cause rejection. |
| Fingerprints | SHA-256, SHA-1, MD5 of the DER encoding | The value you compare against what a vendor, a pinning config or a monitoring system expects. |
Suppose a hosting provider sends you a bundle and TLS still fails after installation. Decode the first certificate in the file. If Basic Constraints reads CA:TRUE and the Subject CN looks like “R11” or “DigiCert Global G2” rather than your hostname, you have been handed the intermediate, not the leaf, and the files are in the wrong order in the bundle. If instead the Subject CN is your hostname but the SAN list contains only example.com while users browse to www.example.com, the certificate is valid but does not cover the name being requested — the classic ERR_CERT_COMMON_NAME_INVALID. And if the Issuer DN of your leaf does not match the Subject DN of the next certificate up, the chain is broken regardless of how many files are concatenated together.
Each of those three failures produces an identical-looking browser warning, and each is settled in seconds by reading the decoded fields.
The formats people argue about are mostly one structure in two encodings. DER is the binary ASN.1 encoding of the certificate. PEM is that same DER, Base64-encoded and wrapped in -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- header lines. The .crt and .cer extensions carry no format guarantee at all: both are used for PEM on Linux and for DER on Windows, which is why a file that opens fine in one tool is rejected by another. A quick test — open it in a text editor; if you can read the BEGIN line, it is PEM.
This decoder accepts PEM directly, accepts DER files by upload, and accepts DER as pasted hex. If you need to convert between encodings, or to produce a PKCS#12 bundle or a new signing request, the certificate and CSR generator handles conversion and generation and can be pre-filled from a decoded certificate’s subject fields.
Decoding tells you what a certificate claims; it is not the same as validating trust. Full validation means building a path to a trusted root, checking each signature, honouring name constraints, and confirming the certificate has not been revoked. What this tool does check, and surfaces in the Security Analysis panel, is the set of properties that break deployments in practice: expiry and days remaining, self-signed status, weak public keys, weak signature algorithms, missing or mismatched SANs, wildcard scope, and the SPKI pin values you would need for HPKP-style pinning or for a mobile app’s pin set. When a certificate is fetched by domain, the served chain is displayed too, so a missing intermediate is visible immediately.
Yes. There is no charge, no registration, and no usage limit.
No. Pasted and uploaded certificates are parsed entirely in your browser. The only case where a network request occurs is the URL tab, where a hostname is sent so the live certificate can be retrieved — and certificates served publicly over TLS are public information by definition.
No, and you should not paste one into any web tool. This decoder handles certificates only. A private key belongs on the server it was generated on.
PEM text, DER supplied as hexadecimal, and uploaded .pem, .crt, .cer and .der files. You can also fetch the certificate from a live hostname.
Decode it and read the Validity Period block: Not Before and Not After are shown as full UTC timestamps, and the Security Analysis panel converts Not After into days remaining, flagging certificates that have already expired.
Almost always a missing intermediate. Browsers often repair an incomplete chain using cached intermediates or AIA fetching; command-line clients and Java trust stores do not. Fetch the certificate by domain and check whether the server actually sends the intermediate alongside the leaf.
Common Name is a legacy field inside the Subject DN. Since 2017 every major browser matches hostnames exclusively against the Subject Alternative Name extension and ignores CN entirely. If a hostname is missing from SAN, the certificate does not cover it, no matter what CN says.
The Issuer DN is identical to the Subject DN, meaning the certificate signed itself rather than being signed by a CA. That is normal for a root CA or an internal lab certificate, and a failure for anything a browser must trust automatically.
Decode the leaf to see its own fields; when you fetch by domain, the chain the server presents is displayed alongside it so you can confirm each Issuer matches the next Subject.
SHA-256. SHA-1 fingerprints are still shown because older systems and some vendor documentation reference them, and MD5 for legacy device compatibility, but neither is collision-resistant and neither should be used as a security control.
An X.509 certificate decoder parses and displays the contents of digital certificates used in TLS/SSL, code signing, email encryption (S/MIME), and other PKI (Public Key Infrastructure) applications. X.509 is the ITU-T standard that defines the format of public key certificates, and decoding them reveals critical information about identity, validity, key usage, and the trust chain.
Every HTTPS connection relies on X.509 certificates to establish trust between a client and server. When your browser connects to a website, it receives the server's X.509 certificate, verifies the signature chain back to a trusted root Certificate Authority (CA), and checks that the certificate is valid for the requested domain. Understanding certificate contents is essential for security professionals, system administrators, and developers working with encrypted communications.
An X.509 v3 certificate contains these key fields:
| Field | Description | Example |
|---|---|---|
| Version | Certificate format version | v3 (most common) |
| Serial Number | Unique identifier from the CA | 03:A1:B2:... |
| Signature Algorithm | Algorithm used to sign | SHA256withRSA, ECDSA |
| Issuer | CA that issued the certificate | CN=Let's Encrypt R3 |
| Validity | Not Before / Not After dates | 2024-01-01 to 2025-01-01 |
| Subject | Entity the cert identifies | CN=example.com |
| Public Key | Subject's public key | RSA 2048-bit, EC P-256 |
| Extensions | Additional constraints and usage | SAN, Key Usage, CRL |
Subject Alternative Names (SANs) are a critical extension that lists all domain names and IP addresses the certificate is valid for. Modern certificates rely on SANs rather than the Common Name (CN) field for domain matching. A single certificate might cover example.com, www.example.com, and api.example.com.
Key Usage and Extended Key Usage extensions restrict what the certificate can be used for—server authentication, client authentication, code signing, or email protection. A TLS server certificate should have the "serverAuth" extended key usage.
X.509 is the standard format for public key certificates used in TLS/SSL and other cryptographic protocols. An X.509 certificate contains: (1) Public Key - The certificate holder's public key, (2) Identity Information - Domain name, organization, location, (3) Digital Signature - Signed by a Certificate Authority (CA) to prove authenticity, (4) Validity Period - Start and expiration dates, (5) Extensions - Subject Alternative Names (SANs), key usage, policies. X.509 certificates enable: HTTPS websites (SSL/TLS), Code signing, Email encryption (S/MIME), VPN authentication, and Document signing. When you visit an HTTPS website, your browser verifies the site's X.509 certificate to ensure you're connecting to the legitimate site and that the connection is encrypted. The certificate chain links back to a trusted root CA.
X.509 certificates come in multiple encoding formats: PEM (Privacy Enhanced Mail) - Base64-encoded, text format, enclosed in -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- markers, most common format, .pem or .crt extension. DER (Distinguished Encoding Rules) - Binary format, more compact than PEM, .der or .cer extension, commonly used in Java. PKCS#7/P7B - Container format that can include certificate chain, Base64-encoded with .p7b extension, used by Windows and Java. PKCS#12/PFX - Binary format containing certificate AND private key, password protected, .p12 or .pfx extension, used for importing/exporting. CRT/CER - Generic extensions that can be either PEM or DER format, need to check file contents to determine actual format. To convert formats: PEM to DER: openssl x509 -in cert.pem -outform DER -out cert.der, DER to PEM: openssl x509 -in cert.der -inform DER -out cert.pem.
A certificate chain (or chain of trust) is a sequence of certificates linking an end-entity certificate (your website) to a trusted root CA. Typical chain: End-Entity Certificate (leaf) → Your website's certificate, contains your domain. Intermediate Certificate(s) → Issued by CA, signs your certificate. Root Certificate → Self-signed, pre-installed in browsers/OS, ultimate trust anchor. Why chains matter: (1) Security - Root CA private keys are kept offline for security. Intermediates handle day-to-day signing. (2) Trust - Browsers/OS trust root CAs. Your certificate inherits that trust through the chain. (3) Revocation - If an intermediate is compromised, only that intermediate needs replacement, not the root. Common issues: Missing intermediate certificates (browser shows "incomplete chain"), Wrong order (chain must go leaf→intermediate→root), Expired intermediate, Self-signed certificates (no chain, browser warnings). Always include the full chain when configuring SSL/TLS servers.
SSL/TLS certificates come in three validation levels with increasing identity verification: DV (Domain Validation) - Verifies domain ownership only (email or DNS validation), issued in minutes, cheapest option ($0-50/year), shows padlock in browser, suitable for blogs, personal sites. No organization validation. OV (Organization Validation) - Verifies domain ownership AND organization identity, CA validates organization exists and operates at claimed address, takes 1-3 days, moderate cost ($50-200/year), shows organization name in certificate details, suitable for businesses, e-commerce. EV (Extended Validation) - Most rigorous validation, extensive verification of organization's legal, physical, and operational existence, takes 1-2 weeks, expensive (~$150-1000/year), historically showed company name in browser address bar (deprecated in 2019 due to phishing concerns), suitable for financial institutions, high-security needs. Modern recommendation: DV is sufficient for most websites with proper HTTPS. EV provides minimal additional security benefit after browsers removed the EV indicator.
Subject Alternative Names (SANs) are X.509 v3 extensions that allow a single certificate to secure multiple domains/subdomains. Before SANs: One certificate = one domain, required separate certificates or expensive wildcard certificates. With SANs: One certificate can include: Multiple domains (example.com, example.org), Multiple subdomains (www.example.com, api.example.com, mail.example.com), Wildcard and specific domains together (*.example.com, example.com), IP addresses (192.168.1.1), Email addresses (for S/MIME). Example SAN certificate: CN: example.com, SAN: example.com, www.example.com, blog.example.com, shop.example.com. Benefits: Cost-effective (one certificate for multiple domains), Easier management (single renewal/installation), Flexible (add/remove domains as needed). Limitations: Most CAs limit SANs to 100-250 domains, All domains visible in certificate (privacy concern), All domains share same validation level. Modern best practice: Use SAN certificates instead of buying separate certificates for each domain.
A decoded X.509 certificate reveals extensive information: Subject Information - Common Name (CN): domain name, Organization (O), Organizational Unit (OU), Locality (L), State/Province (ST), Country (C). Issuer Information - Certificate Authority that issued the certificate, Issuer's signature algorithm. Validity - Not Before date (certificate start), Not After date (expiration), Days remaining until expiration. Public Key - Algorithm (RSA, ECDSA, EdDSA), Key size (2048-bit, 3072-bit, 4096-bit), Public key value. Extensions - Subject Alternative Names (SAN), Key Usage (encryption, signing), Extended Key Usage, Basic Constraints (CA certificate?), Authority Key Identifier, Subject Key Identifier, CRL Distribution Points, Authority Information Access (OCSP). Signature - Signature algorithm (SHA256withRSA), Signature value, Thumbprint/fingerprint (SHA-1, SHA-256). Certificate Policies - OIDs indicating certificate purpose, EV status indicators. This information helps verify certificate authenticity, check expiration, validate domain coverage, and audit security properties.
Certificate expiration checking is critical for maintaining secure connections: Check Methods: (1) Browser - Visit HTTPS site, click padlock, view certificate, check "Valid until" date. (2) OpenSSL - openssl x509 -in cert.pem -noout -dates shows validity period. (3) Online Tools - This decoder tool, SSL Labs SSL Test. (4) Monitoring - Automated tools that alert before expiration. Expiration Timeline: Modern certificates: 398 days maximum (13 months), Old certificates: Previously 825 days (2-3 years), Let's Encrypt: 90 days (encourages automation). Best Practices: Monitor 30 days before expiration, Automate renewal (Let's Encrypt certbot, ACME protocol), Set up alerts (email, Slack, PagerDuty), Test renewal process quarterly, Keep contact information updated. Consequences of Expiration: Browser warnings ("Your connection is not private"), Users can't access site (especially mobile), SEO ranking impacts, Lost revenue and trust, API integrations fail. Set up automated renewal to avoid manual tracking. Certificate transparency logs can help discover forgotten certificates.
RSA and ECDSA are two different public-key cryptography algorithms used in X.509 certificates: RSA (Rivest-Shamir-Adleman) - Older algorithm (1977), Widely supported everywhere, Larger keys (2048-bit minimum, 4096-bit recommended), Larger certificates (~1-2KB), Slower signing and encryption, Battle-tested and trusted. ECDSA (Elliptic Curve Digital Signature Algorithm) - Modern algorithm, Smaller keys (256-bit = 3072-bit RSA security), Much smaller certificates (~500 bytes), Faster operations (3x faster signing), Lower CPU and bandwidth usage, Growing support (all modern browsers, some older clients incompatible). Key Size Equivalence: RSA 2048-bit ≈ ECDSA 224-bit, RSA 3072-bit ≈ ECDSA 256-bit, RSA 7680-bit ≈ ECDSA 384-bit. Modern Recommendation: Use ECDSA for new deployments (P-256 curve), Provides dual RSA+ECDSA certificates for compatibility, Benefits: Faster TLS handshakes, Lower server CPU usage, Smaller certificate chains. If supporting legacy clients (Windows XP, old Android), stick with RSA 2048-bit or provide dual certificates.