LiveChat 
Support 
Certificate Decoder: How to Read and Inspect an SSL Certificate
Open an SSL certificate file in a text editor and you are met with a wall of seemingly random characters wedged between two header lines. It looks like a secret. It is not. A certificate decoder is a tool that reads that encoded block and shows you the human-readable details it has contained all along: the domain it covers, who issued it, when it expires, and which hostnames it protects.
If you have ever stared at a browser warning that says “this certificate does not match the site” and felt like the problem was a mystery, the certificate decoder is the thing that makes the mystery disappear. The certificate openly states everything you need to know. You just cannot read it in its raw form. Decoding it takes about thirty seconds and turns guesswork into a fact.
This guide explains what a certificate decoder does, what lives inside a certificate, and exactly how to decode one — both with an online tool and on the command line with `openssl`.
Key Takeaways
• A certificate decoder translates the encoded contents of an SSL/TLS certificate (or a CSR) into readable details — it does not “crack” or unlock anything.
• A certificate stores plain facts: the subject (domain), the SAN list (every valid hostname), the issuer (the CA), validity dates, the public key, and a serial number.
• You decode a cert to verify it covers the right domain(s), check it has not expired, confirm a trusted CA issued it, and validate a CSR before submitting it.
• The fastest method is `openssl x509 -in cert.pem -text -noout`; for a CSR use `openssl req -in csr.pem -text -noout`.
• Almost every SSL error is diagnosable by decoding the cert and reading three things: the SAN list, the validity dates, and the issuer.
What Is a Certificate Decoder?
A certificate decoder is a tool — either an online form or a command-line program — that takes the encoded text of an SSL/TLS certificate and renders it as readable fields. You paste in (or point it at) the certificate, and it returns a structured breakdown: which domain the certificate is for, the full list of hostnames it is valid for, the certificate authority that signed it, the exact dates it is valid between, the public key and the algorithm used, and a few identifiers like the serial number and signature.
The word “decoder” matters here. The certificate is encoded, not encrypted. Encoding is a format, like translating a document into Morse code: anyone with the key to the format can read it, and there is no secret involved. The decoder simply reverses the encoding so the contents become legible. Nothing is being unlocked, broken, or revealed that was hidden — it was all sitting in the file, just in a machine-friendly packaging.
This is the single most useful tool for diagnosing certificate problems, because a certificate is fundamentally a public statement. It declares, in writing, which domains it protects and when it is valid. The decoder lets you read that statement.
Why Would You Decode an SSL Certificate?
You decode a certificate when you need to confirm a fact about it rather than trust that it is configured correctly. The common reasons:
- Verify it contains the right domain(s). Before or after installation, confirm the certificate actually lists the domain people type into their browser — including the `www` and non-`www` variants.
- Check expiry and validity. Read the “not before” and “not after” dates to confirm the certificate is currently valid and see when it needs renewing.
- Confirm the issuer. Make sure a recognised, trusted certificate authority signed it — not a self-signed certificate that browsers will reject.
- Inspect the SAN list. The Subject Alternative Name field is where modern certificates list every hostname they cover. Mismatches here cause most “name does not match” errors.
- Validate a CSR before submitting. When you generate a Certificate Signing Request, decode it first to make sure the domain and organisation details are correct — a mistake here means a wrong certificate.
- Troubleshoot a mismatch. When something is broken, decoding both the certificate the server is serving and the one you expected tells you exactly where they differ.
What Is Inside an SSL Certificate?
A certificate is a structured record. Decoding it exposes a fixed set of fields. Here is what each one means and why you would look at it.
| Field | What it contains | Why it matters |
|---|---|---|
| Subject (CN) | The primary domain the certificate identifies, e.g. `example.com` | Tells you the main name the certificate was issued for |
| Subject Alternative Name (SAN) | The full list of hostnames the cert is valid for, e.g. `example.com`, `www.example.com` | This is the authoritative list browsers check — the most common source of mismatch errors |
| Issuer | The certificate authority that signed it | Confirms a trusted CA issued it rather than a self-signed source |
| Validity (Not Before / Not After) | The start and end dates of the certificate’s validity | Tells you if it is expired, not yet valid, or active |
| Public Key + Algorithm | The public key and its type/size, e.g. RSA 2048 or ECDSA P-256 | Confirms the key strength and type |
| Serial Number | A unique identifier assigned by the CA | Used to reference or revoke the specific certificate |
| Signature | The CA’s cryptographic signature over the certificate | Proves the certificate was not altered after signing |
The most operationally important fields are the SAN list, the validity dates, and the issuer. If you only ever read three things from a decoded certificate, read those.
What Does a CSR Contain?
A Certificate Signing Request (CSR) is the file you generate and send to a CA when you want a certificate. It is also encoded, and you decode it the same way. A CSR contains the subject details you are requesting — the domain (Common Name), and often organisation, location, and country — along with the public key the certificate will be bound to. It does not contain validity dates or an issuer, because those are assigned by the CA when the certificate is actually issued. Decoding a CSR before you submit it is the cheapest way to catch a typo’d domain before it becomes a wrong certificate.
An SSL certificate looks like meaningless gibberish — a wall of Base64 between `BEGIN CERTIFICATE` and `END CERTIFICATE` lines — precisely because it is encoded, not encrypted or secret. People treat the appearance as proof that the contents are hidden and mysterious. They are not. A certificate decoder simply translates that encoding back into the plain facts it always contained. This reframes SSL troubleshooting entirely. Nearly every real SSL problem is diagnosable by decoding the cert and reading exactly three things: the SAN list (does it actually include the precise hostname people visit, including `www` versus non-`www`?), the validity dates (is it expired or not yet valid?), and the issuer (is it from a trusted CA, or self-signed?). The certificate openly states whether it covers your domain, when it is valid, and who issued it. So the decoder turns “why is my SSL broken?” from a mystery into a thirty-second lookup: decode the cert, read the SAN, the dates, and the issuer, and the cause of almost any certificate error reveals itself. The information was never hidden — it was just encoded.
How Do You Decode a Certificate?
There are two practical methods. Pick whichever fits where you are working.
Using an Online Certificate Decoder
An online decoder is a web form. You copy the certificate’s text — the entire block including the `—–BEGIN CERTIFICATE—–` and `—–END CERTIFICATE—–` lines — paste it into the box, and submit. The tool parses the encoding and displays the subject, SAN, issuer, validity dates, key details, and serial number in a readable layout.
This is the fastest option when you already have the PEM text in front of you and just want to eyeball the fields. One caution: a certificate is public information, so pasting one into a decoder is low-risk — but never paste a private key into any online tool. The certificate and the private key are different files; only the certificate (and the CSR, which is also safe) belong in a decoder.
Using the Command Line with openssl
If you have shell access — for example on a VPS or dedicated server with root — `openssl` is the canonical certificate decoder and it runs locally, so nothing leaves your machine.
To decode a certificate file:
“`bash openssl x509 -in cert.pem -text -noout “`
Reading that command: `x509` is the certificate-handling subcommand, `-in cert.pem` points at your certificate file, `-text` says “print the human-readable details,” and `-noout` suppresses re-printing the encoded block (which you do not need). The output lists the Issuer, Validity (Not Before / Not After), Subject, Public Key, and — under “X509v3 extensions” — the Subject Alternative Name list.
To decode a CSR instead, use the `req` subcommand:
“`bash openssl req -in csr.pem -text -noout “`
This prints the subject you requested and the public key, so you can confirm the domain and organisation details are correct before sending the CSR to a CA.
You can also decode a certificate directly from a live server without having the file, which is handy for confirming what a server is actually serving:
“`bash openssl s_client -connect example.com:443 -servername example.com /dev/null | openssl x509 -text -noout “`
Reading the Output
The `-text` output is organised into labelled sections. Scan for these:
- Issuer: the CA. If this says something like “CN = example.com” matching your own domain, it is self-signed — browsers will reject it.
- Validity: the `Not Before` and `Not After` dates. Compare `Not After` to today to check for expiry.
- Subject: the primary domain (CN).
- X509v3 Subject Alternative Name: the full SAN list. This is where you confirm both `www` and non-`www` are present.
What Is the PEM Format?
When you decode a certificate you are almost always working with PEM format. PEM is a text encoding: the binary certificate is Base64-encoded and wrapped between header and footer lines like:
“`
—–BEGIN CERTIFICATE—– MIIDdTCCAl2gAwIBAgILBAAAAAABFUtaw5QwDQYJKoZIhvcNAQEFBQAwVzELMAkG … (many lines of Base64) …
—–END CERTIFICATE—– “`
Those `BEGIN`/`END` lines tell tools what kind of object the block is. A certificate says `CERTIFICATE`, a CSR says `CERTIFICATE REQUEST`, and a private key says something like `PRIVATE KEY`. When you paste into a decoder or run `openssl`, include those wrapper lines — they are part of the format, not decoration. The Base64 in between is the encoded data the decoder translates back into fields.
What Are the Most Common Checks When Decoding?
When you decode a certificate to troubleshoot, run through this short checklist. It catches the overwhelming majority of certificate errors.
| Check | What to look for | What a failure means |
|---|---|---|
| SAN coverage | Does the SAN list include the exact hostname visitors use — both `www.example.com` and `example.com`? | A “name does not match” error; visitors hitting the missing variant get a warning |
| Expiry | Is today between `Not Before` and `Not After`? | Expired or not-yet-valid certificates trigger a hard browser block |
| Issuer | Is the issuer a recognised CA, not your own domain? | A self-signed certificate is untrusted and rejected by browsers |
| Chain | Are intermediate certificates present alongside the leaf? | A missing intermediate causes “incomplete chain” errors on some clients |
The first three — SAN, expiry, issuer — are readable directly from a single decoded certificate. The chain check usually means decoding the additional certificates the server sends and confirming they link your certificate up to a trusted root.
Decoding certificates is far easier when they were issued correctly in the first place. DarazHost’s free AutoSSL issues and installs correctly-scoped certificates — with the right SAN entries (including `www` and non-`www`) and the full chain — and then auto-renews them before they expire. The practical result is that you rarely need to decode a certificate to hunt for a problem, because there usually is not one. And if you are running a with root access, you have `openssl` and full control to decode, inspect, and manage certificates yourself whenever you want — with 24/7 support on hand if a check turns up something unexpected.
How Does Decoding Fit Into the Bigger SSL Picture?
Decoding is the inspection step in a certificate’s lifecycle. You generate a and decode it to confirm the request is right. The CA issues a certificate, and you decode it to confirm coverage and validity. You and decode the live server’s response to confirm what is actually being served. When a browser complains, decoding the certificate and its tells you precisely what is wrong.
If you want the full background on how certificates establish trust and encryption in the first place, see our pillar guide on SSL certificates and how HTTPS encryption and trust work. Understanding what a is makes every decoded field self-explanatory.
Frequently Asked Questions
Is decoding a certificate the same as decrypting it? No. Decoding reverses an encoding format (Base64/DER) to make the certificate’s fields readable. Decryption reverses encryption to recover hidden data. A certificate is encoded but not encrypted — its contents are public and meant to be read, so a decoder simply translates the format.
Is it safe to paste my certificate into an online decoder? Yes, for the certificate itself — certificates are public information sent to every visitor’s browser anyway. Never paste your private key into any online tool, though. The private key is a separate file and must stay secret; only the certificate and the CSR are safe to decode online.
How do I check which domains a certificate covers? Decode it and read the Subject Alternative Name (SAN) field. With `openssl`, run `openssl x509 -in cert.pem -text -noout` and look under “X509v3 Subject Alternative Name.” Every hostname the certificate is valid for is listed there, including `www` and non-`www` variants.
Why does my certificate work for example.com but not www.example.com? Almost certainly the SAN list includes one but not the other. Decode the certificate and check whether both `example.com` and `www.example.com` appear in the SAN field. If one is missing, visitors to that variant get a name-mismatch warning, and the certificate needs reissuing to cover both.
How can I tell if a certificate is self-signed? Decode it and compare the Issuer and Subject fields. If the Issuer is the same as the Subject (your own domain) rather than a recognised certificate authority, the certificate is self-signed and browsers will not trust it.
