SSL Certificate Checker

Our SSL checker connects to your website the same way a browser does and tells you, within a few seconds, whether the certificate it is given is trusted, which authority issued it and how many days remain before it expires. It is built for UK small businesses, marketers and agencies who need a quick, reliable answer when a client reports a padlock warning, after a hosting move or rebuild, or as a routine check before renewal dates catch anyone out.

How to use the SSL checker

1. 1 Enter the exact hostnameType the hostname you want to test, such as www.example.co.uk. A full URL or an email address also works, because we reduce it to the host before connecting.
2. 2 Test each hostname separatelyThe bare domain and the www version can be served by different certificates, so run the check on both, plus any shop, booking or portal subdomains.
3. 3 Run the checkSign in to your free account and start the test. We open a verified TLS connection to port 443 and read the certificate the server presents.
4. 4 Read the status and detailsStart with the headline result (pass, warning or fail), then look at the Issued to, Issued by, Valid from and Expires on rows underneath.
5. 5 Fix, wait, then re-testResults are cached for ten minutes per hostname, so after installing or renewing a certificate give it a few minutes before checking again.

What an SSL certificate checker actually tests

An SSL certificate, more accurately called a TLS certificate today, is a small signed file that proves a server is allowed to use a particular hostname. When a visitor opens your site, their browser receives that certificate during the TLS handshake and checks three things before showing the padlock: that the certificate was signed by an authority it trusts, that it is in date, and that it was issued for the name in the address bar.

Trust works as a chain. Your server certificate (the leaf) is signed by an intermediate certificate, which in turn is signed by a root certificate held in the browser or operating system trust store. If any link is missing, expired or untrusted, the whole chain fails. A good SSL certificate checker therefore needs to behave like a strict client rather than simply reading dates from the certificate file.

Problems rarely announce themselves. A certificate can be fine on the www address and broken on the bare domain, renewed on disk but not loaded by the server, or valid at your CDN while your origin certificate quietly lapses. Checking from outside your own network, with a client that refuses to cut corners, is the quickest way to see what a first-time visitor, a payment provider or an API integration will actually encounter.

How our SSL check works behind the scenes

When you run the tool, our server opens a direct TLS connection to the hostname on port 443. It sends the hostname using Server Name Indication (SNI), so shared hosting and CDNs return the certificate meant for that site rather than a default one. Peer verification and hostname verification are both switched on, which means the connection only succeeds if the chain builds to a trusted root and the certificate covers the exact name you entered.

If the handshake succeeds, we parse the certificate and report the subject common name, the issuing organisation, the start and end dates and the number of whole days left. If it fails, we show the error the TLS library returned, such as a verification failure or a refused connection, rather than guessing at a cause.

The check is deliberately focused. It does not grade protocol versions or cipher suites, test other ports such as mail on 465 or 993, or follow HTTP-to-HTTPS redirects. For HSTS and other response headers, use our security headers checker alongside it.

Reading your SSL test results

Each result has a status, and the score at the top is weighted by those statuses. Information rows are shown for context and never change the score.

• Valid SSL certificate (pass): the chain verified, the name matched and there are 14 or more days left.
• Certificate expires soon (warning): the certificate is valid today but has fewer than 14 days remaining. Renew it now and confirm automatic renewal is running.
• SSL certificate (fail): the connection could not be verified. The value shows the reason, for example an expired certificate, a name mismatch, a missing intermediate or nothing listening on port 443.
• Issued to: the common name on the certificate. Modern certificates list every covered name in the Subject Alternative Name field, so a common name of example.co.uk can still cover www.example.co.uk.
• Issued by, Valid from and Expires on: the certificate authority and validity window, useful for spotting an old certificate still being served after a renewal.

How to fix SSL certificate errors step by step

Expired certificate: on cPanel, open SSL/TLS Status and run AutoSSL for the affected domains. On a server using Certbot, run certbot renew --dry-run to see why renewal is failing, fix the cause (often a blocked port 80 or a changed web root), then renew and reload the web server.

Name mismatch: reissue the certificate with every hostname you serve, typically both example.co.uk and www.example.co.uk. In Certbot that means passing each name with its own -d flag; in cPanel, make sure the www alias exists so AutoSSL includes it.

Incomplete chain: browsers sometimes hide this problem by fetching missing intermediates themselves, but strict clients and our checker do not. On Nginx, point ssl_certificate at fullchain.pem, not cert.pem. On Apache 2.4.8 or later, put the full chain in the file named by SSLCertificateFile.

Behind Cloudflare: when the record is proxied, we see the certificate on Cloudflare's edge, not your origin server. Use the Full (strict) encryption mode and a valid origin certificate, and avoid Flexible mode, which leaves the connection to your server unencrypted.

WordPress: once the certificate passes, change WordPress Address and Site Address to https in Settings, General, then fix any hard-coded http links so pages do not trigger mixed-content warnings.

Building an SSL renewal routine that does not rely on memory

With certificate lifetimes shortening each year, manual renewal is no longer realistic for most businesses. Automate issuance through ACME, which cPanel AutoSSL, Certbot, most managed hosts and CDNs already use, and treat this SSL checker as a monitor that confirms automation is working rather than as the renewal process itself.

Do not count on reminder emails. Let's Encrypt stopped sending expiry notifications in 2025, and paid authorities email whoever placed the original order, who may have left the business. Agencies should keep a simple register of every client hostname, who renews it and how, and check it monthly. Remember that renewal is only half the job: a new certificate sitting on disk does nothing until the web server has been reloaded.

A practical rhythm is to run the checker on every important hostname at the start of each month and straight after any change to hosting, DNS or CDN settings. Anything showing fewer than 30 days left deserves a look even before the tool raises its 14-day warning, because a renewal that has silently failed once will usually keep failing.

SSL best practice for UK business websites

A free domain-validated certificate gives exactly the same encryption as a paid one, and browsers no longer display a special indicator for extended validation, so paying more rarely improves trust with visitors.

• Cover every hostname you use, including www, and any subdomain linked from emails or adverts.
• Redirect all HTTP traffic to HTTPS with a single 301, then add HSTS once you are confident everything works over HTTPS.
• Allow TLS 1.2 and 1.3 only; older versions are disabled in current browsers.
• Publish a CAA record naming the certificate authorities you actually use.
• Re-run this SSL checker after any hosting move, CDN change or DNS migration, when certificates are most often missed.

Examples you can copy

server {
    listen 443 ssl;
    http2 on;
    server_name example.co.uk www.example.co.uk;

    ssl_certificate     /etc/letsencrypt/live/example.co.uk/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.co.uk/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
}

<VirtualHost *:443>
    ServerName example.co.uk
    ServerAlias www.example.co.uk
    SSLEngine on
    SSLCertificateFile    /etc/letsencrypt/live/example.co.uk/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.co.uk/privkey.pem
    SSLProtocol -all +TLSv1.2 +TLSv1.3
</VirtualHost>

sudo certbot certonly --webroot -w /var/www/example -d example.co.uk -d www.example.co.uk
sudo certbot renew --dry-run
sudo certbot renew --deploy-hook "systemctl reload nginx"

example.co.uk.  3600  IN  CAA  0 issue "letsencrypt.org"
example.co.uk.  3600  IN  CAA  0 iodef "mailto:security@example.co.uk"

Common mistakes to avoid

Frequently asked questions