How to Verify a Website’s SSL Certificate (Browser, OpenSSL, and Online Checkers)

• 01 July 2026
• by: Tobias Reinhardt
• in: Security
• Tags: openssl check certificate, SSL, ssl checker, verify website ssl certificate
• note: no comments

When you need to know whether a site’s HTTPS is set up correctly, “the padlock is there” is not an answer. The padlock tells you the connection is encrypted, but it says nothing about whether the certificate is valid for that exact domain, whether it expires next week, or whether the issuing authority is one the world actually trusts. Verifying a certificate properly means inspecting its contents and confirming each of those things deliberately.

To verify a website’s SSL certificate, check three things: that it is currently within its validity dates, that its domain name (common name or SAN) matches the site you are visiting, and that it chains up to a trusted certificate authority. You can do this in your browser by clicking the padlock and viewing the certificate, on the command line with openssl s_client, or through an online SSL checker that reports all of it from a neutral machine. Each method has a place, and the most rigorous answer comes from combining them.

Key Takeaways
• Verifying a certificate means confirming three things: valid dates, a matching domain name (CN/SAN), and a complete chain to a trusted CA.
• The browser padlock proves encryption and a valid chain, not legitimacy – a phishing site can have a perfectly valid certificate.
• Use the browser for a quick look, openssl s_client for the raw truth from your server, and an online SSL checker for a neutral third-party verdict.
• The most common real-world problems are expired certificates, name mismatches, self-signed certificates, and missing intermediates.
• Always verify expiry from a neutral source, because your own browser may cache or paper over chain gaps you cannot see.

Here is the distinction almost everyone collapses, and it matters enormously. A valid padlock proves exactly two things: your connection to the server is encrypted, and the server’s certificate chains up to a trusted certificate authority. That is all. It does not prove the site is run by who you think, that it is honest, or that it is safe to hand over your card. A criminal can register paypa1-secure.com, obtain a free, fully valid domain-validated certificate for it in minutes, and serve you a flawless green padlock. The certificate is genuinely valid, because validation here only ever asserted “whoever controls this domain asked for this certificate.” It never asserted “this is the real PayPal.” So when you verify a certificate, you are verifying a chain of cryptographic facts about a domain, not a verdict about trustworthiness. The padlock answers “is this connection encrypted and the cert genuine?” It never answers “should I trust the people on the other end?” Conflating the two is precisely the gap phishing relies on.

What exactly are you verifying in an SSL certificate?

Verifying a certificate is not one check but a set of independent checks, and a certificate can pass several while failing one. Each property answers a different question, and a single failure is enough to make a browser refuse the connection. Knowing what each field means is what separates a real inspection from glancing at a padlock and moving on.

The table below lists what to verify, why each item matters, and how to check it. Treat it as a checklist: a certificate is only fully trustworthy when every row passes.

What to verify	Why it matters	How to check
Validity dates (Not Before / Not After)	An expired or not-yet-valid certificate is rejected by every browser, breaking the site	Browser certificate viewer; openssl x509 -noout -dates; online checker
Common Name / SAN matches the domain	If the name does not cover the domain you visited, the browser shows a mismatch error	Compare the SAN list against the URL host in the certificate viewer
Issuer / CA	The issuer must be a publicly trusted CA, not a self-signed or unknown one	“Issued by” field in browser; Issuer line in OpenSSL output
Chain completeness	A missing intermediate breaks trust even when your cert is valid	openssl s_client “Certificate chain” section; online SSL checker
Revocation status	A revoked certificate should no longer be trusted, even if unexpired	OCSP/CRL status reported by online checkers and openssl s_client
Signature algorithm	Weak or deprecated algorithms (e.g. SHA-1) are distrusted	“Signature algorithm” field in the certificate details

The defining idea is that these are *separate* conditions joined by an implicit AND. Your dates can be perfect, your issuer reputable, and your chain complete, but if the SAN does not list the domain the visitor typed, the browser still refuses. Verification means confirming all of them, not the easiest one.

How do you view a certificate in the browser?

The fastest way to inspect a certificate is the browser you already have open, and it surfaces the dates, issuer, and SAN list in a few clicks. According to its own documentation, Chrome exposes this through the padlock; the path is nearly identical in Firefox and Edge, because they all render the same underlying X.509 fields.

To view a certificate in Chrome or Edge, click the padlock icon (or the “tune”/site-information icon) to the left of the address bar, choose Connection is secure, then Certificate is valid (or “Certificate details”). A panel opens showing the certificate. Look at four things first: Issued to (the common name and the SAN list under “Subject Alternative Name”), Issued by (the CA), and the validity period with its Not Before and Not After dates.

In Firefox, click the padlock, then Connection secure, then More information, then View Certificate. Firefox opens a clean tabbed page (about:certificate) that lists the subject, issuer, validity window, SANs, and the full chain in one view, which makes it the friendliest browser for a careful manual read.

The browser view is excellent for a quick human check, but remember its blind spot: your browser may have cached an intermediate from an earlier visit, so a chain that *looks* complete to you can still be broken for a first-time visitor. For that reason, never treat your own browser as the final word on chain completeness.

[IMAGE: Browser address bar with padlock clicked open showing certificate details panel – search “browser padlock security certificate”]

How do you verify a certificate with OpenSSL?

OpenSSL is the most precise way to see what a server actually sends, because it makes no assumptions and caches nothing. It connects, completes the TLS handshake, and prints the raw certificate chain exactly as the server presents it. This is the tool engineers reach for when a browser and an online checker disagree.

The core command opens a connection and dumps the certificates. The -servername flag is not optional on shared or modern infrastructure: it sends the SNI hostname so the server knows which certificate to return. Omit it and you may receive the wrong certificate entirely.

openssl s_client -connect example.com:443 -servername example.com

In the output, read the Certificate chain section near the top. A healthy result shows your leaf certificate followed by each intermediate, in order. Look further down for Verify return code: 0 (ok), which is OpenSSL confirming the chain validated against its trust store. Any other code points to a specific failure worth investigating.

To check just the validity dates without wading through the full output, pipe the connection into x509. This prints the Not Before and Not After dates and nothing else, which is ideal for confirming expiry quickly:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

If you already have the certificate saved as a file, you can inspect it directly without a network connection. The -text flag expands every field, including the issuer, subject, SAN list, and signature algorithm, so you can verify a downloaded or pre-deployment certificate offline:

openssl x509 -in certificate.pem -noout -text

[PERSONAL EXPERIENCE] In practice, I keep the -dates one-liner in my shell history and run it on production endpoints whenever an expiry alert fires. It answers the only question that matters in that moment, “is this thing about to lapse?”, in under a second, with no browser cache to mislead me and no GUI to click through.

How do you use an online SSL checker?

An online SSL checker is the right tool when you want a neutral verdict, because it connects from a third-party machine that has never cached any of your intermediates. According to Qualys, the SSL Labs Server Test grades a server’s full configuration and reports the exact chain it observes, which makes it the standard reference for confirming what the wider internet actually sees.

Using one is simple: enter your domain, wait for the scan, and read the report. A good checker tells you the certificate’s validity dates, the issuer, whether the common name and SANs match, and, critically, whether the chain is complete. Because the checker holds no cached intermediates, a “chain incomplete” warning from it is far more reliable than your own green padlock.

[UNIQUE INSIGHT] The reason online checkers matter is not convenience, it is *neutrality*. Your laptop is the worst possible place to test chain completeness, because it has accumulated cached intermediates from months of browsing and will silently fill gaps that a fresh visitor’s device cannot. The online checker is valuable precisely because it is ignorant: it knows nothing about your site and starts from zero, which is exactly the position your real visitors are in.

[CHART: Comparison bar chart of verification methods (browser, OpenSSL, online checker) scored on neutrality, depth, and speed – source: author analysis]

For deployment work, run the checker *after* every certificate install and renewal, not just when something breaks. A clean report ending at a trusted root is your confirmation that the chain is whole for everyone, not only for you.

How do you spot a problem certificate?

Most certificate problems fall into four recognizable categories, and learning their signatures lets you diagnose a warning in seconds. Each one produces a distinct browser error, and each has a different cause and fix. The good news is that none of them are mysterious once you know what you are looking at.

Expired (or not-yet-valid) certificates are the most common failure. The Not After date has passed, and every browser hard-rejects the connection with a date error. Check the dates with openssl x509 -noout -dates; if expiry is the cause, the fix is renewal, and the deeper fix is automated renewal so it never recurs.

Name mismatches happen when the certificate’s SAN list does not include the domain you visited – for example, a certificate for example.com served on www.example.com with no matching SAN. The browser reports the certificate is not valid for this name. The fix is reissuing the certificate with the correct SANs.

Self-signed certificates are signed by themselves rather than by a trusted CA, so they chain to no recognized root. Browsers flag them as untrusted because no public authority vouches for them. They are fine for internal testing, but never for a public site. In OpenSSL output, the giveaway is a self signed certificate verify error and an issuer identical to the subject.

Missing intermediates are the sneakiest, because the certificate itself is valid but the server fails to send the intermediate that links it to the root. It often works in one browser and fails in another. Confirm it with an online checker, then install the full CA bundle.

How DarazHost keeps certificates verified and never lets them lapse

DarazHost removes the most common verification failures before they can happen, because the platform issues and maintains certificates automatically through AutoSSL. AutoSSL provisions a free certificate with the complete chain – leaf plus intermediates – installed correctly, so the missing-intermediate and self-signed problems that plague manual setups simply do not occur. It then auto-renews every certificate well before the Not After date, which means expiry, the single most common reason a site suddenly throws security warnings, is handled silently in the background. You still get the full certificate to verify yourself with any of the methods above, but you are verifying a certificate that was built and renewed correctly from the start. If anything ever looks off, 24/7 support can confirm the chain and dates with you directly.

For the bigger picture of how certificates, encryption, and browser trust fit together, see our pillar guide: SSL Certificates: The Complete Guide to How HTTPS, Encryption, and Trust Work.

Frequently asked questions

How do I check if a website’s SSL certificate is valid? Click the padlock in your browser and open the certificate details, then confirm three things: the validity dates have not passed, the domain you visited appears in the Subject Alternative Name list, and the issuer is a recognized certificate authority. For a neutral, cache-free confirmation, also run the domain through an online SSL checker.

How do I check an SSL certificate’s expiry date? The quickest command-line method is echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates, which prints the Not Before and Not After dates. In a browser, open the certificate via the padlock and read the validity period. Online SSL checkers report expiry too, often with a countdown.

Does the padlock mean a website is safe? No. The padlock means the connection is encrypted and the certificate chains to a trusted CA – nothing more. A phishing site can obtain a perfectly valid certificate for its own deceptive domain. Always read the actual domain name in the address bar; the padlock verifies encryption and certificate validity, not the honesty of whoever runs the site.

Why does OpenSSL say “self signed certificate” or give a verify error? A self signed certificate verify error means the certificate is signed by itself, not by a trusted authority, so it chains to no recognized root. Other verify codes usually indicate a missing intermediate or an expired certificate. Read the Verify return code line in the openssl s_client output; 0 (ok) is the only fully passing result.

Can a certificate be valid but still trigger a browser warning? Yes. A certificate can have perfect dates and a reputable issuer yet still fail if the domain name does not match its SANs, or if the server omits a required intermediate so the chain cannot reach a trusted root. Validity and trustability are separate; verification means confirming the dates, the name match, and the complete chain together.