How to Decode SSL Certificates: Read PEM, X.509, CSR Online
Paste an SSL certificate (PEM format) or CSR and inspect subject, issuer, expiry, SANs, and SHA-256 fingerprint instantly.
Try the free online tool mentioned in this guide:Certificate / PEM Decoder
Why decode SSL certificates?
SSL/TLS certificates authenticate servers and encrypt traffic. A certificate contains metadata: the domain it covers (Common Name and Subject Alternative Names), who issued it, and when it expires.
Decoding a certificate helps when:
- Debugging HTTPS connection errors.
- Verifying a certificate matches a domain before deployment.
- Checking expiration dates to prevent outages.
- Inspecting Certificate Signing Requests (CSRs) before signing.
- Auditing a server's certificate chain.
SSL certificate structure (X.509)
An X.509 certificate contains:
Subject — The domain owner (Common Name and Organization).
Subject Alternative Names (SANs) — Additional domains covered by the certificate (example.com, *.example.com, www.example.com).
Issuer — The Certificate Authority (CA) that signed it.
Valid From / Valid To — Expiration dates. HTTPS warnings occur when the current date is outside this range.
Public Key — Used to establish the encrypted connection.
Signature — Cryptographic proof that the CA issued the certificate.
Serial Number — Unique identifier for the certificate.
SHA-256 Fingerprint — Hash of the entire certificate, useful for pinning.
# PEM format (begins and ends with header/footer)
-----BEGIN CERTIFICATE-----
MIIDrzCCAlegAwIBAgIQCDvgVpBCRrGfEwnt50uqWzANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
...
-----END CERTIFICATE-----Reading certificate output
MyDevTools Certificate Decoder parses the PEM format and displays:
- Subject CN — The primary domain (example.com).
- SANs — Wildcard and additional domains covered.
- Valid From/To — Expiration dates and remaining validity.
- Issuer — Which CA signed it (Let's Encrypt, DigiCert, etc.).
- Key Type — RSA, ECDSA, etc.
- SHA-256 Fingerprint — For certificate pinning.
Look for warnings: expired certificates, mismatched domains, or untrusted issuers.
Certificate Signing Requests (CSRs)
A CSR is a request to a CA to sign a certificate. It contains the public key and subject information but is not yet signed. Decode CSRs to verify the domain and key before sending to a CA.
Common certificate issues
Expired certificate — Renew before the "Valid To" date. Many hosting providers auto-renew (Let's Encrypt, managed SSL).
Domain mismatch — The certificate CN or SANs do not match the domain being accessed. Re-issue or add the domain as a SAN.
Untrusted issuer — The CA is not in the browser's trust store. Ensure the full certificate chain is served.
Self-signed certificate — Valid for encryption but causes browser warnings. Use for internal testing only.
Frequently asked questions
What is a SHA-256 fingerprint and why use it?
A fingerprint is a hash of the certificate. Use it for certificate pinning in apps: instead of trusting all CAs, pin specific certificates and reject others.
Can I decode a certificate without the private key?
Yes. The public certificate (PEM) contains all the metadata. The private key is separate and never included in the certificate.
How long is a typical SSL certificate valid?
Usually 1 year (Let's Encrypt, modern CA standard). Some CAs issue multi-year certificates, but renewal before expiry is best practice.
Can a certificate cover multiple domains?
Yes, via Subject Alternative Names (SANs). A single certificate can cover example.com, *.example.com, www.example.com, and other specified domains.