You can see your website's certificate in three clicks: open the website information beside the address and show the certificate. Labels vary by browser and version, but the route is the same. There you find the four entries that matter: which names the certificate covers, who issued it, and the dates it is valid between. Free online checkers show more. The SSL Server Test from Qualys SSL Labs grades the whole configuration from A+ to F and has two special cases, T for a certificate nobody trusts and M for a name that does not match. On the command line, openssl s_client diagnoses one selected connection and shows the certificate data for any service, including a mail server; it is not a replacement for the full SSL Labs matrix. The browser error messages are far more precise than they look, and some of them are not about your server at all but about the visitor's device or route. The point where almost everyone eventually gets stuck, though, is none of these: it is auto-renewal, which works for six months and then stops without anyone telling you.
At my place this kind of check is not an annual ritual. It is one fixed part of a staged security test run by an AI employee, and the certificate is only the first item on a long list. Why I hand this work to an AI employee at all, and what that changes for a small business, is in AI for small businesses. If you are starting out and want to check the whole site rather than just the certificate, Check your website security online is the broader entry point. This article goes deep on exactly one of its four steps.
See what is in the certificate, in three clicks
In Chrome and Edge, click the security icon to the left of the address, then "Connection is secure", then "Certificate is valid". In Firefox the path runs from the padlock through "Connection secure" to the details; in Safari it is the padlock and then "Show certificate". The labels change between versions, the structure does not.
Then read these four fields, in this order:
- Issued to. One name appears here. What actually counts is the full list further down in the details, under subject alternative name (SAN). Only names in that list are covered.
your-domain.example and www.your-domain.example are two separate entries, and a certificate that carries only one of them produces a full-page warning on the other.
- Issued by. The name of the certificate authority. If it shows your own domain name, or something that sounds like your router, your antivirus product or your company network, this is not a publicly trusted certificate.
- Valid from and valid until. The expiry date is the one that matters day to day. Work out how many days are left and remember the number.
- The chain. Under the certification path tab you can see which intermediates connect your certificate to a root. Something missing here is the most common finding that the browser does not show you but other software very much does.
This takes a minute and fully answers the question of validity and remaining lifetime. Everything beyond that is something tools see better than you do.
What the checking tools show on top
The SSL Server Test from Qualys SSL Labs is the most thorough free service. It describes itself as a free online service that performs a deep analysis of the configuration of any SSL web server on the public internet, and it states that it does not use the domain names or test results. I still tick "Do not show the results on the boards" every time, otherwise your result lands on the public list of recently tested sites.
On T and M the Rating Guide makes a point that matters more than the grade table: when there is no certificate trust, the actual security grade is meaningless, because an active network attacker can undermine the connection anyway. Strong encryption on a certificate nobody believes is not half a success. It is none.
Certificate Transparency answers a question no browser asks: which certificates have been issued for your domain at all, including ones you never put into service. Using the search at crt.sh, run by Sectigo, you enter your domain name and get the entries from the public logs. An entry proves issuance, not that the hostname still resolves, a service is reachable or that the certificate was ever deployed. It gives you candidates for a DNS and reachability check; an unexpected certificate is a reason to investigate, not proof of an active or compromised environment.
For a mail server a website test is not enough, because mail encryption runs over different ports and is usually switched on only after the connection has been opened. The ImmuniWeb SSL Security Test explicitly offers mail server testing, free of charge and with an option to hide the test from the public overview.
On the command line openssl s_client is the targeted counterpart, and you do not have to hand your address to anyone. The tool describes itself as a diagnostic tool for SSL servers: it inspects a selected handshake, certificate data, SNI and protocol-specific STARTTLS. It does not test the full protocol and cipher matrix or award a grade. SSL Labs remains responsible for that broader check. Three invocations cover everyday practice:
openssl s_client -connect your-domain.example:443 -servername your-domain.example -showcerts
The first shows you the chain exactly as your server actually serves it. -servername is not a nicety but a necessity, because several certificates can live on one address and without it the server may hand you the wrong one. According to the documentation, -showcerts displays the server certificate list as sent by the server, in the order the server sent it, and explicitly not a verified chain. That is precisely why it reveals a missing intermediate.
openssl s_client -connect your-domain.example:443 -servername your-domain.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
The second gives you the four fields from above as text: subject, issuer, validity period and the complete name list. This is the version you can drop into a script or a monthly reminder.
openssl s_client -starttls smtp -connect mail.your-domain.example:587
The third checks the mail server. Per the documentation, -starttls sends the protocol-specific messages to switch to TLS, and it supports pop3, imap, ftp and ldap alongside smtp. For an inbox you would use -starttls imap on port 143.
Error messages: which ones count and which do not
The codes look alarming but are cleanly defined. The reading below comes from the Chromium project's error list, that is, from the source that produces these messages in Chrome and Edge. The last column gives you a first diagnostic direction, not proof of who is responsible.
Firefox names the same facts differently, SEC_ERROR_EXPIRED_CERTIFICATE for expiry and SEC_ERROR_UNKNOWN_ISSUER for an untrusted issuer. The distinction that saves the most time in practice is a different one: does the error hit every visitor, or one? If everyone sees it, the cause is almost always on your side. If only some do, check their clock, network and security software, but also a single CDN edge, IPv6 target or regional route to your site. An independent check from another network separates those cases better than an assumption.
Why a valid certificate says nothing about security
The padlock in the browser says the connection is encrypted. It says nothing about who is sitting at the other end, or whether they work carefully.
A certificate proves exactly two things: that traffic between browser and server is encrypted, and that someone demonstrated control over this domain name to a certificate authority. That is valuable and far from nothing. But it is a statement about the route, not about the destination. A fraudster gets a free, flawless certificate for a freshly registered domain in minutes, and with it the same padlock your bank has. A site with A+ in the SSL test can at the same time run a plugin that has not been updated in a year, expose an admin interface to the open internet, or show one logged-in user another user's data. The certificate notices none of it, because it cannot.
In practice: checking the certificate is the first step of an audit, not its result. What comes after it I wrote up in Check your website security online, from security headers through outdated software to the areas sitting open on the internet that should not be.
Auto-renewal, and what happens when it fails silently
This is where most people get stuck, and not during setup but six months later. The sequence is always the same: setup worked, the first automatic renewal worked, then something changed and nobody noticed. The next morning a full-page warning sits in front of your website, and practically nobody clicks past a certificate warning.
Four things make this failure so quiet:
- The reminder email is gone. Let's Encrypt ended its expiration notification service on 4 June 2025, for three understandable reasons: automation is now widespread, the service required retaining millions of email addresses, and it cost tens of thousands of dollars a year. Anyone who had grown used to it has had no advance warning since.
- Renewal runs, the server does not notice. Certbot renews a certificate when less than one third of its lifetime remains. The new file is then on disk, but the web server keeps serving the old one until it is reloaded. That is what
--deploy-hook is for: per the documentation it runs only after a successful renewal, precisely so you can restart a service or distribute the renewed certificates to where they are used.
- The trigger is gone. The scheduled job was not carried over during a server move, the service did not come back up after a reboot, or validation has been failing since a redirect change. Certbot has
--dry-run for this, a test run against the staging server, and the documentation says you can test whether future renewals will succeed with it. That test run belongs after every change to the web server, the redirects or the domain.
- The certificate is not on the web server at all. Mail servers, payment interfaces, a router, an app reusing your certificate: these get forgotten at renewal time, and expiry there only shows up when an order confirmation stops going out.
On top of that comes a development that moves this question from annoying to unavoidable. On 11 April 2025 the CA/Browser Forum adopted ballot SC-081v3, which reduces the maximum lifetime of publicly trusted TLS certificates in stages from 398 days to 47 days, starting in March 2026 and concluding in March 2029. In parallel, the period for which a completed domain validation may be reused drops from 398 days to 10 days. What that looks like in practice is visible at DigiCert: since 24 February 2026 the authority has issued public TLS certificates with a maximum lifetime of 199 days, from early 2027 a maximum of 99 days and from early 2029 a maximum of 46, each one day shorter than permitted so as not to overrun the limit by accident.
Only one practical conclusion follows. An annual calendar reminder will soon not fit the arithmetic, and renewing by hand stops being an option. Let's Encrypt already lives in that world with a default lifetime of 90 days and renewal recommended after roughly 60, and it even offers six-day certificates on request, renewed roughly every three days. What you need instead is two things: automation that also reloads the service after renewal, and monitoring that warns you before your visitors do. For monitoring, Let's Encrypt points to third parties and names Red Sift Certificates Lite, which watches up to 250 certificates for free, while explicitly not guaranteeing that or any of the other listed services. The rule underneath is simple: whatever alerts you has to look at your certificate from the outside, not at your script from the inside. A script that is not running does not complain.
Where the deeper audit starts
Certificate and encryption are the first layer, and the only one anyone can see from outside. That is exactly why it gets mistaken for the whole. What lies beneath it no online test can see: not the server side, whose hardening is a job of its own, not the area behind the login, not the question of whether one logged-in user can reach another user's data.
Those layers are checked at my place by Falk, my AI employee for security. He works in stages rather than in one pass: first from outside with no access at all, then as an unauthenticated visitor, and where I explicitly approve it, with credentials or source code access. Every finding comes with evidence, a rating against the CVSS standard and a concrete fix, not just an entry on a list. The automated part deliberately runs throttled, at most 20 requests per minute, so that a test does not disturb live operations.
What separates this work from a one-click checker is the frame around it. Every engagement gets its own scope and its own written approval for exactly the target system in question, and before that approval exists, not a single request goes out. He does not test third-party systems without a written scope, does not perform destructive actions, and does not extract real personal data. That is also why Falk does not exist as a finished package: an off-the-shelf security test presupposes an off-the-shelf system, and there is no such thing.
Frequently asked questions
What is the fastest way to check an SSL certificate's validity?
In the browser: click the icon to the left of the address, then "Connection is secure", then "Certificate is valid". The expiry date is right there. If you need it as text or want to check several addresses, openssl s_client -connect your-domain.example:443 -servername your-domain.example piped into openssl x509 -noout -dates gives you the same thing in one line.
How do I check how much lifetime a certificate has left?
The "valid until" field in the browser gives the date; you work out the difference yourself. That is no good as ongoing monitoring, because you have to remember to look. Better is a service that checks from outside and warns you in advance. Let's Encrypt points among others to Red Sift Certificates Lite, free for up to 250 certificates, with no guarantee for the service.
How do I check a mail server's SSL certificate?
Not with a website test, because mail servers encrypt over different ports and usually switch on TLS only after the connection is open. On the command line, openssl s_client -starttls smtp -connect mail.your-domain.example:587 works, and -starttls imap on port 143 for an inbox. If you prefer a browser: the ImmuniWeb SSL Security Test explicitly offers mail server testing.
My certificate is valid but the browser still warns. Why?
Usually one of three things: the address variant being called is missing from the certificate's name list, an intermediate certificate is missing from the served chain, or the clock on the visitor's device is wrong. The first two show up in the SSL Server Test; you recognise the third by the fact that only individual visitors are affected.
Does the padlock mean the website is secure?
No. It means the connection is encrypted and somebody proved control over the domain name. It says nothing about the software behind it, about exposed admin areas, or about the operator. Any freshly registered domain gets a free certificate in minutes, including a fraudster's.
How often will I have to deal with renewal in future?
More often. In April 2025 the CA/Browser Forum decided to cut the maximum lifetime of public TLS certificates from 398 to 47 days between March 2026 and March 2029. DigiCert has issued a maximum of 199 days since 24 February 2026. Renewing by hand drops out as a method; what remains is automation plus monitoring from the outside.
How to carry on
Take ten minutes and do three things, in this order. First, call your site once with and once without www and look at the certificate in both cases. Second, run the SSL Server Test with "Do not show the results on the boards" ticked, and write down the grade, the expiry date and any note about an incomplete chain. Third, and this is the step that actually changes something: set up monitoring that looks at the expiry date from outside and warns you weeks ahead, instead of relying on a script that may quietly not be running. If your site is due for work anyway, these points belong in the plan from the start, and the essentials are in Having a website built and, for an existing site, Modernising a website. And if you want to know how to build yourself an AI employee that runs checks like these in stages and evidences every finding, the path is in my community Claude Practitioners.
