Free tool
What is inside this certificate?
A .crt, .pem or .cer file is unreadable by eye, and it is often the only thing you have to go on when a site refuses to load. Paste it and you get the names it covers, how long it is good for, who issued it, its key size and its extensions, field by field.
Whatever you paste is decoded by your own browser. It is never sent to a server, not even ours: not the certificate, not the request, not the domain name.
What this tool reads, and what it does not
It reads the certificate you paste and nothing else. It never contacts the site, so it cannot tell you whether the intermediate chain is actually being served, whether the certificate has been revoked, or whether it is still installed anywhere. Those are three different questions, and all three are answered online by the SSL certificate check in this same toolbox.
The date is written inside, and nobody ever reads it back
An expired certificate is the easiest outage to avoid and still one of the most common. The date has been known to the second since the day it was issued; what is missing is someone looking at it on the right day. DomainVigil reads every certificate on the domains it is given and writes ahead of the deadline, thirty days then seven, to you and not to your client.
How it works
The padlock only shows one side
A visitor sees a padlock and a domain name. The browser reads a ten-line record, and reads it again on every visit. Flip the card to see that record, then push the clock forward three months and watch which line starts lying on its own.
There is nothing more to see on the visitor's side, and that is the problem. The day the certificate runs out, this face changes all at once and warns nobody.
A sample record, on a domain reserved for demonstrations. To read your own, paste your certificate in the field at the top of the page.
What the file says
It is all written inside.
The names it covers, the two dates, the extensions, the CA that signed it. A certificate is not something you guess at — you read it, and it fits in a text field.
- 2dates: one start, one end
- 14extensions named instead of shown raw
- 2048bits: the minimum for an RSA key
Reading the result
The banner gives the main name, the verdict and the time left. Below it, the panels follow the order you actually ask things in: good until when, for which names, issued by whom, with which key.
- Fine
- The certificate is inside its validity period, it covers at least one name, and its key and signature are current. None of that means it is installed correctly: a sound certificate served without its intermediate chain still throws an error for part of your visitors.
- Problem
- Expired, not yet valid, signed with SHA-1, key too short, or carrying no alternative name at all. In every one of those cases an up-to-date browser stops the visit before the page ever shows, and no server setting makes up for it.
- Worth checking
- The certificate works, but something is off: under thirty days to go, a self-signed certificate, a common name that is not repeated in the alternative names. Each of those hits only part of your visitors, which is exactly what makes them so hard to reproduce.
- Good to know
- A trait, not a flaw: a wildcard, several names covered, a CA certificate. It is flagged because it changes what the certificate really covers, and with it what you have to check after a renewal.
- Names covered
- The exact list of names this certificate authenticates, with the type of each entry. A browser checks the name in the address bar against this list and against nothing else. If the requested name is missing, the error talks about a name mismatch even though the certificate is perfectly valid.
- Fingerprints
- The SHA-256 fingerprint of the whole certificate. It tells you whether the file in your hand is the one installed on the server, or the one the CA issued: identical files share a fingerprint, different files never do. Your browser computes them.
- Extensions
- The extensions decide what the certificate allows: for which names, for which uses, how far down a chain. Each one is shown with its identifier and, when it is readable, its contents — and marked “critical” when RFC 5280 requires a client to reject it rather than ignore it.
Five failures you can read straight off a certificate
Every one of them can be diagnosed from what this page shows, without touching the server.
The browser says the name does not match, and the certificate is valid
What causes it: The requested name is not in the alternative name list. The usual case: the certificate covers www.example.com and the visitor lands on example.com, or the other way around.
What fixes it: Compare the names-covered panel against the exact address typed. If the name is missing, the certificate has to be reissued with it added — no server setting adds a name to a certificate that is already signed.
The site loads for you and not for your client
What causes it: The server is not sending the intermediate certificate. Your browser has it cached from an earlier visit and rebuilds the chain on its own; your client's browser does not.
What fixes it: Install the chain file the CA gives you, not just the site certificate. The authority information access panel holds the address where the issuing certificate is published.
The file refuses to open: “unable to load certificate”
What causes it: It is not PEM. A .cer or .der is a binary file, so what you pasted is not base64. Sometimes it is simply a private key, or a request that got named .crt.
What fixes it: Convert it: openssl x509 -in certificate.der -inform DER -out certificate.pem. If that fails too, the file is not a certificate.
The certificate was renewed and the site still serves the old one
What causes it: A web server holds the certificate in memory from startup. Replacing the file is not enough, and on multi-machine hosting you have to replace it everywhere.
What fixes it: Reload the server configuration, then check what is actually served: openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates.
The expiration date here is not the one the browser shows
What causes it: Certificate dates are written in universal time, and most tools print them exactly as encoded. A gap of several hours between two tools usually comes from that.
What fixes it: This page shows the dates in your own time zone, the way a browser does. For the raw value, openssl x509 -noout -dates gives it in UTC, exactly as encoded.
The X.509 extensions you meet, and what each one allows
A certificate is more than a name and two dates — the extensions decide what it permits. Here are the ones you run into, with the identifier each is encoded under and the RFC 5280 section that defines it.
| Extension | What it holds | What it allows |
|---|---|---|
| 2.5.29.17 — subjectAltName | The list of names: DNS names, IP addresses, email addresses (§ 4.2.1.6). | It defines the certificate's identity. A browser trusts the names in this list and no others. |
| 2.5.29.15 — keyUsage | Usage bits: signature, key encipherment, certificate signing (§ 4.2.1.3). | It limits what the key is allowed to do. A TLS server needs digitalSignature, plus keyEncipherment for RSA key exchange. |
| 2.5.29.37 — extendedKeyUsage | Usage identifiers: serverAuth, clientAuth, codeSigning (§ 4.2.1.12). | It limits where the certificate can be used. Without serverAuth it authenticates no website, even with the right name on it. |
| 2.5.29.19 — basicConstraints | CA:TRUE or CA:FALSE, and a path length (§ 4.2.1.9). | It says whether the certificate can sign others. A site certificate carries CA:FALSE, a CA certificate carries CA:TRUE. |
| 1.3.6.1.5.5.7.1.1 — authorityInfoAccess | The addresses of the OCSP responder and of the issuing certificate (§ 4.2.2.1). | It lets a client check revocation and go fetch a missing intermediate. |
| 2.5.29.31 — cRLDistributionPoints | The addresses where the revocation list is published (§ 4.2.1.13). | It lets a client find out that the certificate was revoked before its end date. |
| 2.5.29.14 — subjectKeyIdentifier | A fingerprint of the subject's public key (§ 4.2.1.2). | It ties a certificate to the ones it signed, for the case where several keys share a name. |
| 2.5.29.35 — authorityKeyIdentifier | The identifier of the issuer's key (§ 4.2.1.1). | It names which issuing certificate signed this one, and that is how a chain gets rebuilt. |
| 2.5.29.32 — certificatePolicies | The authority's policy identifiers (§ 4.2.1.4). | It records the rules the certificate was issued under: domain validation or organization validation. |
| 2.5.29.30 — nameConstraints | Permitted or excluded name spaces (§ 4.2.1.10). | CA certificates only: it restricts the names that CA is allowed to certify. |
| 1.3.6.1.4.1.11129.2.4.2 — SCT | Proofs of publication in transparency logs (RFC 6962 § 3.3). | It proves the certificate was made public when it was issued, which browsers require. |
An extension marked critical has to be understood by the client, or the certificate must be rejected (RFC 5280 § 4.2). That is why the tool shows it: an unknown critical extension explains a rejection that nothing else explains.
The commands that go with it
Every one of them was run while writing this page, on OpenSSL 3.6.
| Command | What it does |
|---|---|
| openssl x509 -in certificate.crt -noout -text | Prints the whole certificate, extensions and all. |
| openssl x509 -in certificate.crt -noout -subject -issuer -dates | The three lines you look at first: for whom, by whom, good until when. |
| openssl x509 -in certificate.crt -noout -ext subjectAltName | The one list that decides which names are covered. |
| openssl x509 -in certificate.crt -noout -fingerprint -sha256 | The SHA-256 fingerprint, to line up against the one shown on this page. |
| openssl x509 -in certificate.der -inform DER -out certificate.pem | Turns a binary certificate (.der, .cer) into PEM you can read and paste. |
| openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -text | Pulls the certificate a site is actually serving and prints it. |
| openssl verify -CAfile chain.pem certificate.crt | Checks that the certificate really chains up to the file you provide. |
Frequently asked questions
What is the difference between .crt, .pem, .cer and .der?
Two formats and four file extensions. DER is the certificate in binary; PEM is that same binary encoded as base64 between BEGIN and END lines. The names .crt and .cer tell you nothing about the contents — either one can hold either format. If a file opens in a text editor and shows base64, it is PEM and this page will read it. If it does not, convert it with the command in the table above.
How do I know whether a certificate covers www and the bare domain?
Read the names-covered panel: both names have to be in there. A certificate issued for www.example.com does not cover example.com, and a *.example.com wildcard does not cover it either — a wildcard applies to one level of subdomains, never to the name it sits on. This is the number one cause of a name error on a site that just went live.
Why is my certificate rejected when it has not expired?
Three possible causes, and this page catches two of them. The requested name is not in the alternative name list. The certificate is self-signed, or signed by a CA the machine does not know. Or the server is not sending the intermediate chain — the only one of the three that means querying the site rather than reading the file.
What does “self-signed” mean?
That issuer and subject are the same entity: the certificate signed itself, with no authority above it. This page catches it by comparing the two distinguished names. It is perfectly usable inside a network where the certificate is installed on every machine, and useless on a public site — no browser accepts a signature whose chain it cannot follow.
What is the SHA-256 fingerprint for?
Comparing two files without reading either one. It identifies a certificate uniquely: if the fingerprint shown here matches the one the server returns, it is the same certificate down to the byte. That is the fastest way to confirm a renewal actually got deployed, or that a file someone emailed you is the one the CA issued.
How long does a certificate stay valid?
The exact period is written inside the certificate, and that is the only thing that counts — this page shows it in days, start and end included. Public authorities have cut the maximum lifetimes in steps over the years, so the general answer keeps moving. The one that matters for your site is the date your own file carries.
The vocabulary
The words you meet around a certificate
The ones that turn up in an error message, a CA's documentation or a support thread, and never get defined there.
PEM- The certificate in base64, between a BEGIN line and an END line. That is the form this page reads.
DER- The same certificate in binary. A .cer or .der file will not open in a text editor — convert it first.
SAN- The subject alternative name list. A browser checks the address typed against that list and against nothing else.
CN- The subject's common name. It no longer identifies the site — a name that is not repeated in the list is covered by nothing.
CA:TRUE- The mark of a CA certificate, carried by the basic constraints. It signs other certificates instead of identifying a site.
serverAuth- The extended usage without which a certificate authenticates no website at all, even when it covers the right name.
SHA-256- The fingerprint of the whole file. Two identical files share one, two different files never do.
*.example.com- A wildcard. It covers subdomains one level down, never the name it sits on.
Before the outage
Thirty days out, this page already tells you
30days
Under that, the certificate turns “worth checking” even while it still works.
That is the threshold this page applies, and it is also the first of the two reminders DomainVigil sends on the domains it is given: thirty days, then seven. The date itself has been sitting in the file since the day it was issued.
Twenty checks, no sign-up
- What is my certificate request actually asking for?
- What does this domain name look like in Punycode?
- Has my DNS change propagated yet?
- Build your SPF record
- Is this domain blacklisted?
- What security headers does this site send?
- A domain's full health report
- When does this domain expire?
- Is this SSL certificate valid, and when does it expire?
- Are your SPF, DKIM and DMARC set up right?
- Is this domain or its mail server blacklisted?
- Which servers receive mail for this domain?
- Which nameservers answer for this domain?
- What do this domain's TXT records do?
- Where does this CNAME end up?