An SSL certificate check reads back four things that decide whether browsers trust your site: who issued the certificate, the chain of certificates that links it to a trusted root, the validity dates that say when it expires, and the Subject Alternative Name (SAN) list that controls which hostnames it actually covers. If any one of those is wrong, visitors see a security warning even when the rest of your setup is perfect. This guide walks through each field, explains what valid, expired, self-signed, and incomplete-chain results mean, and clears up a myth: unlike DNS, an SSL certificate does not propagate.
What an SSL certificate check actually shows you
When you run a hostname through an SSL checker, the tool opens a TLS connection to the server on port 443, asks for the certificate the server presents, and then reads the structured fields inside it. You are not looking at a file on your computer. You are looking at exactly what the server hands to every browser during the TLS handshake, which is why a live check beats trusting your control panel. The important fields are the issuer, the certificate chain, the validity window, and the SAN list. A good check also reports the signature algorithm and the key size, but those rarely cause the warnings people come looking to fix.
Issuer and the certificate authority
The issuer field names the certificate authority (CA) that signed your certificate. For a certificate to be trusted automatically, that CA has to chain up to a root that ships in the browser and operating system trust stores. Public CAs such as Let's Encrypt, DigiCert, Google Trust Services, and Sectigo meet that bar. If the issuer is your own company name or the same name as the subject, you are looking at a self-signed certificate, and no public browser will trust it without a manual exception.
The issuer also matters for policy. If you publish a CAA record, only the CAs you list are allowed to issue certificates for your domain. A mismatch there does not break an existing certificate, but it will block renewals, so it is worth confirming your issuer matches your intent. Our guide on CAA records and which CAs can issue your certificates covers that control in detail.
Reading the chain from leaf to root
A browser does not trust your certificate directly. It trusts a root, and your certificate has to form an unbroken chain up to that root. The chain has three tiers. The leaf (or end-entity) certificate is the one for your hostname. One or more intermediate certificates sit between the leaf and the root. The root certificate lives in the trust store and is never sent over the wire.
The single most common chain problem is a missing intermediate. Your server sends the leaf but forgets to send the intermediate that links it upward. Desktop Chrome often papers over this by fetching the missing piece, which fools you into thinking everything works, while mobile apps, older clients, and many API libraries fail the handshake outright. If a check reports the chain as incomplete, fix the server bundle rather than ignoring it. Our walkthrough on an incomplete SSL certificate chain shows how to add the right intermediate.
Validity dates and expiry
Every certificate carries a Not Before and a Not After date. The certificate is valid only inside that window. Past the Not After date it is expired, and browsers block the page with a hard error no matter how correct everything else is. As of November 2026, publicly trusted TLS certificates are capped at a maximum lifetime well under one year, and the industry is moving toward even shorter lifetimes, which makes automated renewal essential rather than optional. Treat any certificate with fewer than two weeks left as something to renew now, and confirm the renewal actually deployed by checking the live expiry date rather than assuming the renewal job succeeded.
The SAN list decides which hostnames are covered
Modern browsers ignore the old Common Name field and read only the Subject Alternative Name list to decide which hostnames a certificate covers. If you request a certificate for example.com but visitors reach the site at www.example.com, and www is not in the SAN list, they get a name mismatch error. A wildcard entry such as *.example.com covers one level of subdomain but not the bare apex and not a deeper label like a.b.example.com. When a certificate check throws a name mismatch, the SAN list is the first place to look.
SSL does not propagate: result states compared
People often ask how long an SSL certificate takes to propagate. It does not. A certificate is installed on a server and is live for every new connection the instant the server starts presenting it. The reason a fix sometimes seems slow is caching or load balancers still serving an old certificate, not propagation. The table below summarizes the result states an SSL checker reports.
| Result | What it means | Visitor impact | Typical fix |
|---|---|---|---|
| Valid | Trusted issuer, complete chain, in date, hostname in SAN | Padlock, no warning | None |
| Expired | Past the Not After date | Hard block | Renew and redeploy |
| Self-signed | Issuer equals subject, no public CA | Untrusted warning | Get a CA-issued certificate |
| Incomplete chain | Intermediate missing from server bundle | Fails on mobile and API clients | Add the intermediate |
| Name mismatch | Hostname not in SAN list | Name error warning | Reissue with the hostname added |
A field-by-field checklist
- Confirm the issuer is a public CA your clients trust, and that it matches any CAA policy you publish.
- Verify the chain is complete from leaf to root, with every intermediate present in the server bundle.
- Read the Not After date and renew well before it, then recheck the live date after deploying.
- Check that the exact hostname your visitors use appears in the SAN list, including www and any apex.
- Test from an independent client, not just your own browser, so a browser that silently repairs the chain does not hide a problem.
- Recheck after any server, CDN, or load balancer change, since each endpoint presents its own certificate.
You can run every one of these checks at once with the Valla DNS SSL checker, which reads the live certificate the server presents and reports the issuer, full chain, expiry, and SAN list in one view.
Frequently asked questions
How long does an SSL certificate take to propagate?
It does not propagate. A certificate is live for new connections the moment the server starts presenting it. If an update seems slow, suspect a cached certificate on a CDN or load balancer rather than propagation, and check each endpoint separately.
Why does my site work in Chrome but fail on my phone or in an API client?
This is the classic missing-intermediate symptom. Desktop Chrome can fetch a missing intermediate on its own, while mobile apps and many libraries cannot. Add the intermediate to your server bundle so the full chain is sent to every client.
What is the difference between a self-signed and a CA-issued certificate?
A self-signed certificate is signed by its own subject and chains to no public root, so browsers do not trust it without a manual exception. A CA-issued certificate chains to a root in the browser trust store and is trusted automatically.
Does a wildcard certificate cover my apex domain?
No. A wildcard such as *.example.com covers one level of subdomain but not the bare apex example.com and not deeper labels. Add the apex explicitly to the SAN list if you need it covered.
My certificate is in date but the browser still warns. Why?
Check the SAN list for a name mismatch and the chain for a missing intermediate. A certificate can be perfectly in date yet still fail because the hostname is not listed or the chain to the root is broken.
Reading a certificate field by field turns a vague security warning into a specific, fixable cause. Start with a live check on the SSL checker to see exactly what your server is presenting today.
SSL Certificate Checker: Run a Free Online Check
If you came here searching for an SSL certificate checker or an SSL validator, here is the short version: paste a hostname into an online checker and it opens a live TLS connection and reads back the exact certificate your server presents right now. That beats trusting a control panel, because the checker sees what every visitor sees. Our SSL checker reports the issuer, the full chain to the root, the validity window, and the SAN list in a single pass, with nothing to install and nothing to configure.
Check your SSL now: run any public hostname through the Valla DNS SSL checker and read the result against the field-by-field checklist above.
What counts as a valid SSL certificate?
A certificate counts as valid only when four things are true at the same time: it was issued by a certificate authority in the browser and operating-system trust stores, the chain from your leaf certificate up to that root is complete, the current date falls inside the Not Before and Not After window, and the exact hostname a visitor types appears in the Subject Alternative Name list. Miss any one and the browser shows a warning, even when the other three are perfect. As of November 2026, publicly trusted certificates are also capped at a short maximum lifetime, so "valid" now includes "not yet expired under the current limit."
Is an online SSL checker safe to use?
Yes. A reputable checker only makes an outbound TLS connection to the public hostname you enter and reads the certificate the server already hands to anyone, the same way a browser does. It never needs your private key, your server login, or any credential, because the certificate and its chain are public information sent during every handshake.