SSL Certificate Check: Online, in the Browser and with OpenSSL
An SSL certificate check tells you whether browsers trust your HTTPS: whether the certificate has expired, whether the name matches the domain, whether the chain is complete, and who issued it. The fastest way to check SSL online is to enter the domain in the SSL certificate checker — the result takes a few seconds. Without a working certificate, browsers flag the site as not secure and some visitors leave before the page loads.
How to check an SSL certificate online, step by step
- Open the SSL certificate checker and enter a domain:
example.com. A full URL works too — the tool extracts the hostname. A non-standard port goes after a colon:example.com:8443. - The tool connects as strictly as a browser does, verifying the chain of trust and the hostname. If strict verification fails, it connects a second time without it, so it can still show you the certificate and explain what is wrong.
- Look at the banner at the top: how many days are left. Under 30 days you get a yellow warning; a red banner means browsers do not trust the certificate, with the reasons listed below it — expired, issued for another name, self-signed, or a chain that does not verify. The OpenSSL message from the strict attempt is shown under the list.
- Go through the detail cards: Common Name, issuer, "valid from" and "valid to" dates, key type and size (RSA under 2048 bits is flagged as weak), signature algorithm, and the Subject Alternative Names (SAN) — every hostname you serve, including www, must be on that list.
- Repeat the check for
www.example.comand your subdomains. Each name can have its own certificate, and the broken one is usually the host nobody visits.
To be clear about the limits: this is a one-off check of a single hostname. It does not enumerate the TLS versions and ciphers your server accepts, does not look for mixed content on pages, and does not watch the expiry date for you. Protocol versions can be tested with the openssl commands below or with the Shield scanner.
How to view a certificate in your browser
- Chrome, Edge and other Chromium browsers: click the icon to the left of the address, then "Connection is secure" → "Certificate is valid". The viewer shows who the certificate was issued to, who issued it, the validity period, and the chain.
- Firefox: padlock → "Connection secure" → "More information" → "View Certificate".
- Safari: padlock in the address bar → "Show Certificate".
The browser is handy for a quick look at the expiry date and issuer, but it is not a final verdict: browsers cache intermediate certificates and can "complete" a broken chain that a crawler or a mobile app will reject.
How to check SSL from the command line (openssl)
openssl ships with macOS and Linux; on Windows you get it with Git for Windows, for example. The basic command connects to the server and prints the chain and the verification result:
openssl s_client -connect example.com:443 -servername example.com </dev/null-servername sends the hostname (SNI). Without it, a server that hosts several sites may return another domain's certificate, and you end up chasing an error that does not exist. In the output, find Verify return code: 0 (ok) means the chain is fine; 21 (unable to verify the first certificate) usually means the server does not send the intermediate; 10 (certificate has expired) — expired; 18 (self-signed certificate) — self-signed.
To pull out the dates, subject and issuer in one line:
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -checkend 1209600notBefore and notAfter are the start and end of validity, -ext subjectAltName lists the names (OpenSSL 1.1.1 and later), and -checkend 1209600 tells you whether the certificate expires within the next 14 days (1,209,600 seconds) — a convenient line for a monitoring cron job.
To see whether the server still accepts an old protocol, try connecting with only that version: openssl s_client -connect example.com:443 -servername example.com -tls1_1 </dev/null. If the handshake succeeds, TLS 1.1 is enabled on the server. One caveat: recent OpenSSL builds may refuse old versions on the client side, in which case a failure tells you nothing about the server. Use -tls1_2 and -tls1_3 for the current versions.
What to Look for in the Report
| Parameter | What Should Be |
|---|---|
| Validity | More than two weeks in advance; free certificates last about three months and renew automatically |
| Name in the Certificate | Matches the domain, including the www variant |
| Chain of Trust | Complete: without the intermediate certificate, some clients will show an error |
| Protocols | TLS 1.2 and 1.3; outdated versions are better disabled |
| Issuer | Well-known certification authority, not a self-signed certificate |
What to Do in Case of Errors
- Expired. Renew the certificate and check that auto-renewal is indeed working.
- Name Mismatch. Add the necessary domains to the certificate or set up a separate one.
- Incomplete Chain. Upload the intermediate certificate to the server.
- Mixed Content. Replace links to images, styles, and scripts from http to https, otherwise the browser will complain even with a valid certificate.
SSL errors: what they look like and how to fix them
| Problem | What you see | Fix |
|---|---|---|
| Expired certificate | Chrome: NET::ERR_CERT_DATE_INVALID; openssl: certificate has expired | Reissue it and check that auto-renewal works. A common case: the new file is already on disk, but the web server was never reloaded and keeps serving the old one. |
| Name mismatch | NET::ERR_CERT_COMMON_NAME_INVALID | Issue a certificate with every hostname in the SAN — for example, example.com and www.example.com. A wildcard *.example.com covers one level of subdomains, but not example.com itself and not a.b.example.com. |
| Incomplete chain | Works in some browsers, NET::ERR_CERT_AUTHORITY_INVALID in others; openssl: unable to verify the first certificate | Install the full chain: the site certificate plus intermediates. With Let's Encrypt on nginx, point to fullchain.pem, not cert.pem. |
| Self-signed certificate | NET::ERR_CERT_AUTHORITY_INVALID; openssl: self-signed certificate | Replace it with a certificate from a trusted CA. Free options: Let's Encrypt or the certificate your host or CDN issues. |
| Only outdated TLS | Usually ERR_SSL_VERSION_OR_CIPHER_MISMATCH | Enable TLS 1.2 and 1.3, disable SSL 3.0, TLS 1.0 and 1.1, update the web server and OpenSSL. |
| Wrong clock | A date error on a certificate that is actually valid | Check the clock on the visitor's device or on the server: validity is compared with the current date. |
How long SSL certificates are valid
The maximum lifetime of publicly trusted TLS certificates is set by the CA/Browser Forum, the body of certificate authorities and browser makers. For years the cap was 398 days. In April 2025 the forum adopted ballot SC-081, which shortens it in stages, and the first stage is already in force:
| Certificate issued | Maximum validity |
|---|---|
| on or after 15 March 2026 | 200 days |
| on or after 15 March 2027 | 100 days |
| on or after 15 March 2029 | 47 days |
The cap applies by issue date: a certificate issued earlier runs to its original end date. Details are in ballot SC-081 on the CA/Browser Forum site. Free Let's Encrypt certificates are short already: according to the Let's Encrypt FAQ they last 90 days (6-day certificates are opt-in), and 90-day ones should be renewed every 60 days. The takeaway: renewing by hand once a year is over — renewal has to be automated.
Let's Encrypt auto-renewal: how to confirm it works
sudo certbot certificates
sudo certbot renew --dry-run
systemctl list-timers | grep certbotcertbot certificateslists every certificate on the server with its expiry date.certbot renew --dry-runrehearses renewal against the Let's Encrypt staging server without touching live certificates. If the rehearsal fails, the real renewal will fail too.- Renewal is triggered by a systemd timer or a cron job; with the snap package the timer is
snap.certbot.renew.timer. If there is neither, there is no auto-renewal. - To make the web server pick up the new certificate, reload it after renewal:
--deploy-hook "systemctl reload nginx". - Typical reasons renewal fails:
/.well-known/acme-challenge/is blocked by a redirect, a password or a firewall rule; or the domain has moved to another server or CDN while certbot still runs on the old one.
If your host or CDN issues the certificate, renewal is usually on their side — but only while the domain points to them. After any DNS change, check the certificate again.
Certificate monitoring
- Alerts in advance. External monitoring or a cron script with
openssl x509 -checkend: get the alert at least two weeks before expiry. - Re-check after renewal. Run the domain through the SSL checker: new dates, full chain, every name in the SAN.
- Certificate Transparency logs. Every public certificate is recorded in open logs; searching your domain (for example on crt.sh) shows which certificates were issued for it — forgotten subdomains and unexpected issuances included.
- Regular audits. Shield is a paid security check (one-off from your balance or a monitoring subscription); its "TLS and certificate" group covers certificate validity and expiry, outdated TLS 1.0/1.1, the HTTP-to-HTTPS redirect, and HSTS.
Free or Paid Certificate
For the purpose of checking validity, there is no difference: both the browser and the bot check validity, not price. Free certificates are issued automatically and renew themselves — this is sufficient for the overwhelming majority of sites. Paid certificates make sense where extended organization verification, insurance, or support for rare scenarios is needed. The main thing is that auto-renewal actually works: an expired expensive certificate is worse than a timely renewed free one.
How This Relates to Promotion
Https is a basic requirement: a site without it loses trust and visitors. Additionally, a certificate error hinders our checks: the page may become inaccessible for crawling. A complete picture of security is provided by Shield, and security headers are discussed in the article on security headers.