SSL Certificate Decoder & TLS Health Checker — Free

SSL/TLS Certificate Decoder

Decode PEM/x509 certificates offline or inspect live SSL/TLS certificate chains with expiration countdowns and health checks.

Free SSL/TLS certificate decoder and health checker. Decode raw PEM/X.509 certificates in your browser air-gapped with zero network transmission, or test any live domain for TLS protocol version, cipher suite, full certificate chain (Leaf → Intermediate → Root), SANs, expiration countdown, and DNS CAA records. Includes security health scoring and interactive wildcard hostname matching.

Keywords: ssl certificate decoder, ssl checker online, x509 decoder, cert decoder, ssl decoder online, tls checker, view pem cert, check ssl expiration, ssl certificate chain viewer, subject alternative name checker, caa record check, ssl security health audit

Tags: ssl, tls, certificate, x509, pem, https, security, crypto, san, caa

Browse all 4 Security & Crypto tools →

SSL/TLS Certificate Decoder is also known as: X.509 Certificate Decoder, SSL Checker Online, TLS Certificate Inspector, PEM Certificate Viewer, SSL Expiration Checker.

How to SSL/TLS Certificate Decoder Online

  1. Select your operational mode: choose "Live Domain Check" to query an active HTTPS endpoint, or "Decode PEM" to parse raw certificate files offline.

  2. For live domains, enter any fully qualified domain name (e.g., example.com, api.domain.org) and optional port (defaults to 443), then click "Check SSL Certificate".

  3. For offline decoding, paste your PEM-formatted certificate block (beginning with -----BEGIN CERTIFICATE-----) or click "Upload .CRT / .PEM" to load a file directly from your machine.

  4. Review the Expiration Status & Timeline bar to inspect the certificate start date, expiration date, total lifetime in days, and real-time days remaining.

  5. Examine the Subject and Issuer cards to verify the Common Name (CN), Organization (O), Organizational Unit (OU), Country (C), State/Province (ST), Locality (L), and Serial Number.

  6. Switch to the "Chain" tab to audit the full Certificate Chain of Trust (Leaf Server Certificate → Intermediate CA → Root CA) and verify cryptographic signature paths.

  7. Check the "Health" tab for an automated security health rating (0–100 with A+ to F grades) evaluating key size, signature algorithm, expiration status, and DNS CAA records.

  8. Use the interactive "Hostname Coverage Checker" to test whether specific subdomains, multi-level domains, or wildcards (*.example.com) are validly secured.

  9. Click "Copy Report" or "Copy PEM / JSON" to export the structured audit results into tickets, configuration files, or compliance reports.

SSL/TLS Certificate Decoder Features

  • Dual-mode operation: 100% client-side air-gapped PEM decoder + high-performance server-side live domain TLS inspector.

  • Comprehensive ASN.1 DER parser: decodes standard X.509 v1, v2, and v3 certificates, multi-certificate bundles, and raw DER base64 streams.

  • Live expiration countdown & lifetime progress bar: visual timeline showing percentage elapsed, days remaining, start date, and expiry date.

  • Multi-algorithm cryptographic support: decodes RSA (1024, 2048, 3072, 4096-bit), Elliptic Curve (ECDSA P-256, P-384, P-521), Ed25519, and Ed448.

  • Subject Alternative Name (SAN) inspection: full extraction of DNS names, IPv4/IPv6 addresses, RFC822 email addresses, and URIs with search and one-click copy.

  • Visual certificate chain hierarchy: renders interactive Leaf (Server), Intermediate CA, and Root CA trees with trust authorization validation.

  • Automated security health score & grading: assigns 0–100 scores and A+ to F grades checking for weak hashes (MD5, SHA-1), undersized keys, and upcoming expiration.

  • RFC 6125 wildcard hostname matching: interactive tester verifies if subdomains and microservices match certificate SANs or wildcard patterns (*.domain.com).

  • DNS CAA record resolution: queries and analyzes Certification Authority Authorization records (RFC 6844) to verify permitted certificate issuers.

  • Multi-format cryptographic fingerprints: generates SHA-256, SHA-1, and MD5 fingerprints in both colon-separated hex and raw formats.

  • Full X.509 extension parsing: Basic Constraints (CA flag, Path Length), Key Usage flags, Extended Key Usage (Server Auth, Client Auth, Code Signing), SKI, and AKI.

  • Revocation & Authority endpoint discovery: extracts Authority Information Access (AIA) OCSP responder URLs, CA Issuers URLs, and CRL Distribution Points.

  • TLS protocol & cipher suite detection: identifies negotiated TLS version (TLS 1.2, TLS 1.3) and cipher suite parameters on live connections.

  • Recent check history: local storage history allows one-click re-runs of recent domain checks without transmitting search logs to external databases.

  • Zero-knowledge air-gapped privacy: pasted certificates and sensitive internal cryptographic blocks remain strictly on your local browser in PEM mode.

  • One-click multi-format export: export parsed certificate metadata as structured JSON, cleaned PEM, or formatted text audit reports.

Supported SQL Dialects

The SSL/TLS Certificate Decoder supports 5 SQL dialects. Select the right dialect for accurate formatting and keyword recognition.

PEM (Privacy-Enhanced Mail)
The most common text-based container format for certificates (.pem, .crt, .cer). Consists of base64-encoded DER data enclosed between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" headers.
DER (Distinguished Encoding Rules)
The raw binary ASN.1 encoding of an X.509 certificate (.der, .cer). Used natively by Java keystores, Windows certificate stores, and low-level cryptographic hardware.
PKCS#7 / P7B
A cryptographic message syntax standard (.p7b, .p7c) designed to store full certificate chains and CRLs without including private keys. Commonly used in Windows Server and Microsoft IIS.
PKCS#12 / PFX
An encrypted binary archive format (.pfx, .p12) capable of bundling leaf certificates, intermediate CA chains, and password-protected private keys together for server imports.
CSR (Certificate Signing Request)
A PKCS#10 formatted request sent to a Certificate Authority containing your public key and organization identity, used by the CA to sign and generate your final X.509 SSL certificate.

Frequently Asked Questions

What is an X.509 SSL/TLS certificate and how does it work?
An X.509 certificate is a digital document standard (RFC 5280) that cryptographically binds a public key to an identity (such as a domain name or organization). When a client establishes an HTTPS connection, the server presents its X.509 certificate. The client verifies the digital signature of the certificate against a trusted Certificate Authority (CA) root store to establish an encrypted, tamper-proof TLS session.
What is the difference between offline PEM decoding and a live domain check?
Offline PEM decoding parses the raw base64-encoded ASN.1 DER data directly inside your browser using JavaScript and Web Crypto. It requires no network requests and is completely air-gapped, making it ideal for checking certificates before deployment. A live domain check connects over TCP port 443 to perform a TLS handshake with a live server, inspecting the served certificate chain, cipher suite, negotiated TLS protocol, and DNS CAA records.
Is it safe to paste certificates into this tool?
Yes. In "Decode PEM" mode, all parsing and cryptographic hash calculations occur 100% locally in your browser sandbox without sending any data to our servers. Furthermore, public X.509 certificates contain only public keys and metadata, which are designed to be publicly accessible. You should never paste private keys (starting with -----BEGIN PRIVATE KEY-----), and this tool specifically processes only public certificate blocks.
What are Subject Alternative Names (SANs) and why are they mandatory?
Subject Alternative Names (SANs) are an X.509 extension (RFC 5280 / RFC 2818) that lists all domain names, subdomains, and IP addresses secured by a single certificate. Modern web browsers (including Google Chrome, Mozilla Firefox, Apple Safari, and Microsoft Edge) mandate the presence of SANs and completely ignore the legacy Common Name (CN) field during hostname verification.
How do wildcard SSL certificates work (*.example.com) and what are their limitations?
A wildcard certificate includes an asterisk in the leftmost label of a SAN (e.g., *.example.com). Under RFC 6125 standards, it secures all immediate single-level subdomains (such as api.example.com or blog.example.com). However, a wildcard does not secure the apex domain (example.com) unless explicitly listed as a separate SAN entry, nor does it secure multi-level subdomains like dev.api.example.com.
What causes an "Incomplete Certificate Chain" or "Missing Intermediate CA" error?
When a browser connects to an HTTPS server, it expects the server to send its leaf certificate along with any intermediate CA certificates required to build a path to a trusted Root CA. If a web server (like Nginx, Apache, or Caddy) is configured with only the leaf certificate instead of the full bundle (fullchain.pem), desktop browsers may attempt to fetch the intermediate via AIA chasing, but mobile browsers and API clients (cURL, Python, Node.js) will fail with SSL_ERROR_UNTRUSTED_ISSUER.
What are DNS CAA records and why are they important for SSL health?
Certification Authority Authorization (CAA) is a DNS resource record (RFC 6844) that allows domain owners to specify which Certificate Authorities (e.g., Let’s Encrypt, DigiCert, Sectigo) are permitted to issue certificates for their domain. Before issuing a certificate, all public CAs are required by the CA/Browser Forum to check CAA records, protecting your domain from unauthorized certificate issuance.
What is the difference between RSA and ECDSA SSL certificates?
RSA is the traditional asymmetric algorithm using prime factorization, typically requiring 2048-bit or 4096-bit keys. ECDSA (Elliptic Curve Digital Signature Algorithm) uses elliptic curves (like P-256 or P-384) to achieve equivalent or superior cryptographic security with much smaller key sizes (256-bit ECDSA equals roughly 3072-bit RSA). ECDSA certificates result in smaller TLS handshake sizes and faster cryptographic computations.
How do certificate expiration countdowns and renewal thresholds work?
Public SSL/TLS certificates have a maximum validity period of 398 days (approx. 13 months). Industry best practices recommend renewing certificates when 30 days remain (and treating ≤7 days as critical). Automated tools like Certbot or ACME clients typically renew certificates automatically when 30 days of validity remain to prevent unexpected outages.
What is the difference between SHA-256, SHA-1, and MD5 fingerprints?
A certificate fingerprint (or thumbprint) is a cryptographic hash computed over the entire raw DER-encoded certificate. It acts as a unique digital identifier. Modern systems rely exclusively on SHA-256 fingerprints for certificate pinning and identification. SHA-1 and MD5 fingerprints are provided for legacy diagnostic verification only, as their collision resistance is mathematically broken.
What is Key Usage and Extended Key Usage (EKU)?
Key Usage defines the core cryptographic operations permitted with the certificate’s public key (such as Digital Signature, Key Encipherment, or Certificate Signing). Extended Key Usage (EKU) specifies the higher-level application purposes for which the certificate may be used, such as Server Authentication (TLS Web Server), Client Authentication (mTLS), Code Signing, or Secure Email (S/MIME).
How do OCSP and CRL endpoints handle certificate revocation?
When a certificate is compromised or revoked before its expiration date, CAs publish revocation status via Certificate Revocation Lists (CRLs) or real-time Online Certificate Status Protocol (OCSP) responders. The Authority Information Access (AIA) and CRL Distribution Points extensions embedded in the certificate tell clients where to verify live revocation status.
What causes "Self-Signed Certificate in Certificate Chain" errors?
A certificate is self-signed when its Subject and Issuer fields are identical and it is signed with its own private key. Because self-signed certificates do not trace back to a pre-installed public trust root, web browsers and automated clients reject them by default with warning screens unless the root is manually installed into the client trust store.
What is Server Name Indication (SNI) and why is it necessary for TLS checks?
Server Name Indication (SNI) is an extension to the TLS protocol (RFC 6066) where the client indicates which hostname it is attempting to connect to at the start of the TLS handshake. This allows a single web server or IP address to host multiple secure websites with distinct SSL certificates on the same port 443.
How do I convert between CRT, CER, DER, and PEM formats?
A PEM certificate is simply base64-encoded DER binary data wrapped in text headers (-----BEGIN CERTIFICATE-----). You can convert binary DER (.crt/.der) to PEM using OpenSSL with the command: `openssl x509 -inform DER -in cert.der -out cert.pem`. Conversely, you can convert PEM to binary DER using: `openssl x509 -outform DER -in cert.pem -out cert.der`.
How is the 0–100 security health score calculated?
The security health score evaluates four primary dimensions: (1) Expiration timeline — full score for active validity, deductions for expiration or near-expiry (<30d, <7d); (2) Signature algorithm strength — full score for SHA-256/SHA-384, severe deductions for MD5/SHA-1; (3) Key length & curve security — full score for RSA ≥ 2048-bit or ECC ≥ 256-bit; (4) Authority trust & DNS CAA setup — verified CA chains and configured CAA records.

Developer Reference & Learning Hubs