The old name SSL is still the one people search for, although current certificates use the TLS protocol. This post uses both terms the way site owners do, and it points to the Security and SSL Check for an automated run. It explains what the padlock does and does not prove, what an ssl certificate checker actually examines, how to read the result, and the usual fix for each common ssl certificate error. It also covers HSTS and the main security headers, and ends with a way to stop expiry from catching you off guard.
What an SSL/TLS certificate does and what the padlock proves
A certificate does two jobs. It lets the browser and your server set up an encrypted connection, so anyone watching the network between them sees scrambled data. It also ties a public key to your domain name, signed by a certificate authority that the browser already trusts. When the signature, the dates and the name all check out, the browser shows its secure indicator.
The padlock proves less than people assume. It says the connection is encrypted and that the certificate matches the host name in the address bar. It says nothing about who runs the site, whether the business is honest or whether the server behind it is patched. Phishing sites routinely carry valid certificates, because certificate authorities issue them to anyone who can show control of a domain.
That is why a certificate check is a hygiene test. A valid certificate removes a reason for visitors to leave, and an invalid one adds a very visible reason. It does not tell you the site is safe, and a good checker will avoid saying so.
What an SSL checker examines
A checker connects to your host name the way a browser does and inspects what comes back. Four things matter most. The first is validity dates: the start and end of the certificate's life, and how many days remain. The second is name match: whether the host name you typed appears in the certificate's list of covered names.
The third is the issuer and the chain. A server certificate is signed by an intermediate certificate, which is signed by a root that browsers ship with. Your server is expected to send its own certificate plus the intermediate. The fourth is the protocol version. TLS 1.2 and TLS 1.3 are the current versions. SSL 2.0, SSL 3.0, TLS 1.0 and TLS 1.1 are retired, and modern browsers refuse them.
Some checkers go further and grade cipher suites or key sizes. Those details matter to server administrators, and for most small sites the four items above explain nearly every real-world failure.
How to read the results
Start with the expiry date. Anything under 30 days deserves action this week, and anything already past is the reason visitors are seeing warnings now. Next, compare the covered names with the address people use. If your site answers at both example.com and www.example.com, both should be listed.
Then look at the issuer. A name you recognize, such as a public certificate authority, is normal. If the issuer and the subject are the same, the certificate is self-signed. After that, check whether the checker reports a complete chain. A warning about a missing intermediate is one of the most useful findings, because it often passes unnoticed in your own browser.
Finally, note the protocol. If your server still offers TLS 1.0 or 1.1, ask your host to turn them off. Treat the result as a snapshot of one moment and one URL, since a different subdomain can have a different certificate.
Fixing the most common ssl certificate error messages
Expired certificate. The date passed and the certificate was not renewed or the renewed one was never installed. Renew it with your provider or host, then confirm the new certificate is the one the server actually serves. Renewing and deploying are two separate steps, and the second is the one people forget.
Name mismatch. The browser reports that the certificate belongs to a different name. Usually the certificate covers example.com but not www, or the reverse. A wildcard such as *.example.com covers one level, so it matches www.example.com but not a.b.example.com, and it does not cover the bare domain unless that name is listed separately. Reissue the certificate with every name you serve.
Incomplete chain. The server sends only its own certificate and leaves out the intermediate. Desktop browsers sometimes fill the gap from cache, so the site looks fine to you while phones, API clients and other tools fail. Install the certificate bundle your authority provides, which includes the intermediate, and rerun the check.
Self-signed certificate. The site vouches for itself, and no browser trusts that. It is fine for a private test server and wrong for anything public. Replace it with one issued by a public authority. Many hosts offer free certificates with automatic renewal.
Redirects and mixed content after you install a certificate
A working certificate does not help if visitors can still land on the plain http version. Type your address without https and see where you end up. The http address should send people to the https address in one step with a permanent redirect. Without it, two copies of your site exist, and search engines may index both. The Technical SEO angle is covered in the technical SEO audit checklist.
Redirect loops are the usual side effect of fixing this. They tend to appear when two layers both try to force https, for example a hosting setting and a plugin, or a CDN that talks to your server over http while the server insists on https. The browser shows a too many redirects error. Turn off one of the layers, or set the CDN to connect to your server over https, then retest in a private window.
Mixed content is the other leftover. A page loads over https but pulls an image, script or stylesheet from an http address. Browsers block most scripts loaded this way and may warn about images, so the padlock disappears or a feature breaks. Search your templates and database for http:// links to your own domain and change them to https. A Content-Security-Policy directive called upgrade-insecure-requests can paper over stragglers while you clean up, though fixing the source addresses is the real repair.
HSTS and the main security headers explained simply
Security headers are lines your server adds to its responses. They tell the browser how strict to be, which is why a security headers check is quick and gives useful results. The first one, HSTS, tells browsers to use https for your domain only, even if someone types http. A typical line looks like Strict-Transport-Security: max-age=31536000, which means one year. Start with a short max-age while testing, and add includeSubDomains only after every subdomain works over https.
Content-Security-Policy lists the places a page may load scripts, images and frames from. It limits what an injected script could do. It is also the header most likely to break a site when set carelessly, because analytics, fonts and embeds all need to be listed. Browsers support a report-only version, so you can watch what would be blocked before enforcing anything.
X-Frame-Options controls whether other sites may place your pages inside a frame, with values DENY or SAMEORIGIN. It guards against clickjacking, and the frame-ancestors directive in a Content-Security-Policy does the same job in a more flexible way. X-Content-Type-Options: nosniff stops browsers from guessing a file's type. Referrer-Policy sets how much of your address is shared when a visitor clicks a link out. Permissions-Policy switches off browser features such as camera, microphone and location for your pages when you do not use them.
A header present in the response is a good sign, and it only reflects intent. Whether the values suit your site is a judgment you or your developer make.
Run a first check with the Security and SSL Check
You can do all of this by hand with your browser's certificate viewer and the Network tab of the developer tools. If you would rather have one readable report, the Security and SSL Check covers the certificate and its expiry, the http to https redirect, HSTS, the five headers above, cookie flags, version details your server reveals and mixed content. Paste the URL and read the result. The free 7-day trial includes 1 credit, enough for a first run.
Know what it is. It looks at your public site from the outside, one URL at a time. It is not a penetration test or a vulnerability scanner, and it cannot see your server, code or database. The report marks each item as present or missing and does not declare a site secure or hacked. If you suspect a compromise, talk to your host or a security professional.
Security setup also touches speed, since extra redirects and slow certificate handshakes add delay. Read the speed test guide and run a Page Speed Report after you tidy the redirect chain.
Why certificates expire unnoticed and how to catch it early
Certificates rarely fail on a convenient day. Automatic renewal works for months, then stops after a hosting move, a DNS change or a server rebuild, and nobody is watching. Manually bought certificates are worse. The reminder email goes to someone who left the company, and the date passes on a weekend. Free certificates from public authorities are commonly valid for roughly 90 days, so a broken renewal job shows up fast.
Three habits cover most of the risk. Turn on auto-renew where your host or authority offers it, and confirm it by checking that the expiry date moves forward after the first renewal. Keep a calendar reminder 30 days before each expiry, owned by a named person and a shared mailbox. Keep a list of every host name that has its own certificate, including shop, booking and landing page subdomains, because each can lapse separately.
A weekly look helps as well. Website Monitoring re-runs the Marketing Audit on up to 5 websites every 7 days and alerts you by email and in your dashboard when something gets worse, including when the site cannot be reached. It does not track certificate dates on its own, so pair it with the reminders above and run the Security and SSL Check again after any hosting change. The broader routine is laid out in the guide to what to check when monitoring a website, and a full pass is in the website audit checklist.
Your next step: open your homepage's certificate details today, write down the expiry date and the covered names, and set a calendar reminder for 30 days before that date.
Frequently asked questions
How do I check if my SSL certificate is valid?
Run your domain through an SSL checker, or click the padlock in your browser and open the certificate details. Confirm the expiry date is in the future, your host name appears in the covered names, and the chain is complete. Check both the www and non-www versions, since they can differ.
What causes an SSL certificate error in the browser?
The usual causes are an expired certificate, a certificate that does not cover the host name you typed, a missing intermediate certificate, a self-signed certificate, or a device clock that is wrong. The error text usually names which one. Start with the expiry date and the covered names.
Does a padlock mean a website is safe?
No. It means the connection is encrypted and the certificate matches the host name. It does not show who runs the site or whether the server is protected. Scam sites can have valid certificates, so treat the padlock as one signal among several.
What is HSTS and do I need it?
HSTS is a response header that tells browsers to load your domain over https only. It is worth adding once https works on every page and subdomain, because it closes the gap when someone types http. Begin with a short max-age and raise it after testing.
Can a security checker tell me if my site was hacked?
No. An outside check of the certificate and headers shows your public setup. It cannot scan files or the server for malware or tampering. If you suspect a break-in, contact your host or a security professional and use the check only for the configuration side.