The renewal worked. Nothing reloaded.

You probably got here from my own free checker. It was right.

So this page opens where that report ends, rather than explaining your certificate back to you.

The SSL certificate checker on this site is free, ungated and uncapped. It reads your certificate, tells you what is wrong, shows the evidence that proves it and explains the fix. Ten of the eleven faults on this page are already on that report, in full. Nothing is held back and nothing here unlocks it.

So the honest part first. If you run one web server, on port 443, with certbot, this page is probably not for you. Get a certificate and test the renewal, free, for as long as you like:

# get and install a certificate
sudo certbot --apache

# test that renewal will succeed
sudo certbot renew --dry-run

That is Let’s Encrypt and the EFF’s client doing the whole job for nothing, and there is no version of this page where you should pay me instead of running it. Then check the configuration with SSL Labs and generate a hardened protocol and cipher policy with the TLSRef configurator — free, and it covers twenty-four server types rather than web servers alone. Mozilla’s own SSL Configuration Generator now says it has moved there.

Every free tool reads the certificate you are serving right now.

That is the whole category, mine included. None of them can watch a renewal, because at the moment you ask, the renewal has not happened yet.

My own SSL certificate checker

ten of the eleven faults below, with the evidence, free and uncapped

Qualys SSL Labs

“a deep analysis of the configuration of any SSL web server on the public Internet” — deeper than mine

testssl.sh

free, GPLv2, and it checks any port — so mail and appliances too

internet.nl

website and mail transport tests, from an initiative of the Internet community and the Dutch government

crt.sh

a search of the public certificate transparency logs, so you can see certificates issued for your name that you did not ask for

The TLSRef configurator

hardened configuration generated for twenty-four server types, Apache, nginx, HAProxy, Postfix and Exim among them. Mozilla’s own generator now says it has moved here

Every one of them answers the same question: what is on the wire at the instant you ask. They are good at it, and several are better at it than I am.

The fault behind almost every certificate outage is not on the wire at the instant you ask. It is this — the renewal succeeded, a new file landed on disk, and the process serving it never picked it up. Or a different process, on a port nobody checks, is still handing out last year’s copy to anyone who connects.

My own tool says exactly this, and can do nothing about it

Not my summary of it. This is the finding text it prints, which you can go and read for yourself in a couple of minutes:

• cert.expired the renewal itself is rarely the thing that broke, it is the reload step afterwards.
• cert.expiring_soon Certificates almost never expire because nobody knew the date — they expire because renewal failed quietly and nothing raised a flag.
• chain.self_signed It is also what a server falls back to when a real certificate fails to load, so it can appear on a site that used to work.
• cert.caa_mismatch Renewal is where it bites, because a compliant CA is required to refuse, and automated renewal fails with an authorisation error that never mentions CAA.

Four findings naming the reload step, from a tool that cannot reach it. It reads your server from the outside, once. That is not a limitation anyone is hiding — it is what an external scanner is.

And certbot documents the same boundary

This is not an argument against certbot, which is excellent and which I recommend above. It is certbot’s own manual, from its user guide:

• --dry-run performs a test run against the staging server, obtaining test certificates “but not saving them to disk”
• “You can test whether future renewals will succeed with --dry-run.”
• “--pre-hook and --post-hook commands run by default. --deploy-hook commands do not run, unless enabled by --run-deploy-hooks.”

Exactly as narrow as that sounds, and no wider. The documented way to test a renewal never writes a certificate. It proves the certificate authority would issue you one — properly, and that is the half certbot can test. It cannot prove the new certificate reaches your services, because there is no new certificate. --run-deploy-hooks does make the hook run, against unchanged files, which proves your reload command exits zero.

Worth adding that the market prices it the same way. DigiCert sells Trust Lifecycle Manager to “scan networks, clouds, and endpoints for unmanaged certificates”, and it is sold by quote — two of its three tiers are contact-sales, and none of the three publishes a price. AWS issues certificates at no cost for use inside its own services, but bills per domain — at issuance, and again at every renewal — for the ones you can export. Even AWS treats a renewal as an event worth billing for.

One renewal, forced, with the serial read off every port before and after.

This is the artefact rather than a description of one. Filled in, so you can see the shape of what lands in your inbox.

Read the two mail rows again, because that is the finding. The renewal worked perfectly. Postfix and Dovecot carried on handing out the previous certificate — and they will keep handing it out until it expires, at which point every mail client on the domain starts refusing to connect, on a morning nobody scheduled. Nothing monitors it. The web checker says the site is fine, because the site is fine.

The panel row is a second one: an appliance certificate that has never renewed, because nothing was ever set up to renew it. And the CDN row is a third mechanism entirely, renewing on a different clock from a different authority — so a change made on the origin never reaches what visitors actually see. That is three renewal mechanisms on one small estate, and the client believed there was one.

The inventory it is read against

This exists first, because a drill with nothing to check against proves nothing. It is deliberately not the headline: testssl.sh checks any port, crt.sh lists every certificate ever publicly issued for your name, and a competent engineer could assemble most of this for free. It is the drill’s input. What makes it worth doing is that almost nobody has one — and the certificate that breaks is never the main site’s, because that one gets noticed.

Eleven distinct faults route here. Four of them you should not pay anyone for.

Split openly, because most of this you can check yourself in about ten minutes.

Four that free tools find and fix

Run SSL Labs, generate the configuration with TLSRef, reload. These stay free after any engagement here ends, and they appear in my packages as labour rather than as discoveries.

The transport is obsolete

TLS 1.0 or 1.1 still accepted, or a genuinely broken cipher negotiated on the live connection rather than merely offered. Both are a configuration line in one file, and the free generators write that line for you.

The certificate’s own crypto is obsolete

A SHA-1 signature, or a key too small to be worth having. Almost always a certificate that has been reissued from the same old request for years, because reissuing is easier than starting again.

Plain HTTP still works

Or it redirects, but the chain drops back to HTTP partway before landing on HTTPS. The padlock at the end of that journey says nothing about the middle of it.

No HSTS

So the first request of every visit is still available to be intercepted, even though every request after it is not. It is one header, and it is the one header people skip because turning it on badly is genuinely awkward to undo.

Six the drill is about

These are the ones where reading the wire gives you the symptom and says nothing about the cause.

Renewal has failed quietly

Expired, not yet valid, or inside thirty days. The date was never the problem. Something renewed and nothing reloaded, or the renewal stopped running months ago and the only notification went to an address that bounces.

The certificate is not one a browser accepts

Self-signed, or a chain ending somewhere no trust store has heard of. Worth knowing that this is also what a server falls back to when the real certificate fails to load — so it turns up on sites that used to work, which makes it a renewal fault wearing a different hat.

It does not cover the name people type

Hostname mismatch, no SAN at all, or www works and the apex does not. Frequently a renewal that quietly dropped a name: somebody removed a subdomain from the request two years ago and nothing has needed it since.

The full chain is not being sent

Or an intermediate expires before the leaf does. Browsers often paper over this by fetching what is missing; API clients, older devices and payment gateways do not, which is why it usually surfaces as “the website is fine but the integration broke”.

CAA authorises nobody, or not the CA you use

Or the record is malformed. The DNS checker finds it and it costs you nothing today — the certificate you are serving stays valid. It bites at renewal, because a compliant CA is required to refuse, and the failure arrives as an authorisation error that never mentions CAA.

The same incident keeps coming back

Certificate, redirect or DNS, two or three times a year, and nobody can say why. That is not bad luck. It is a renewal mechanism nobody owns, failing the same way each time and being fixed by hand each time.

And one that is not a review at all

There is no usable HTTPS on the host at all

Nothing listening on 443, or a handshake that completes and hands back no readable certificate. There is nothing to renew yet. If that is a site which never had HTTPS, it is setup work and I will say so rather than selling you a drill. If it went down an hour ago, see the last section — that is a phone call, not a booking form.

One more thing that is not a fault. The uptime trial here reports TLS failing on a host that otherwise answers. That is not a twelfth problem — it is the same faults above, seen over time instead of once, and it is the closest free thing to what this page sells. Start there. The combined website health check carries the same TLS module alongside DNS, redirects and headers if you would rather see everything at once.

Four ways in

Everyone starts with the drill, because until a renewal has actually been forced nobody knows how many mechanisms are in play — including me.

Renewal Watch is not uptime monitoring, and it is not expiry alerting. Expiry alerting is free in several places, including the uptime trial on this site, which watches a certificate for nothing during its trial. If what you want is dashboards, alerting and somebody watching the whole stack, that is hosted monitoring and it is a different service. This watches one thing: that the serial changes, on time, everywhere.

There are no figures on this page, and that is deliberate rather than coy. A fixed number would be too high for one web server and too low for an estate with five renewal mechanisms, and I would rather quote against what you actually have. Tell me the shape of it in the form — what presents a certificate, and how each one renews, or that nobody knows — and you get a figure back before anything is committed to.

What you have to supply

The first item is settled in writing before the engagement starts rather than discovered during it, and I will not proceed without it.

What I will not promise you

Three things this is not, and one of them is urgent

Worth reading before the form, because in all three cases the right response looks nothing like the rest of this page.

And a fourth, smaller one: if an appliance or a CA relationship cannot support automated renewal at all, that is a procurement change rather than a configuration change. I will say so plainly and quote it separately, rather than building a manual process and calling it fixed.

How payment works

Plainly, so nothing about it is a surprise later. There is no account to create, no portal to log into and no card stored anywhere.

1. You apply through the form

   No payment at this point, and no commitment. Tell me what presents a certificate, how each one renews, and what prompted this.

2. I review it and confirm the scope

   If it is not worth doing, I say so here and it costs you nothing. If it is, you get the scope, the endpoint list and the window in writing before any invoice exists.

3. An invoice arrives, payable within 48 hours

   It carries an invoice number and a due date. Unpaid past 48 hours, the application lapses and the slot is released to somebody else.

4. Work begins once payment is received

   Not before. For one-off work there is nothing to suspend after delivery, so payment comes first — that is the standard arrangement and it runs both ways.

5. Renewal Watch, if you take it, is monthly in advance

   Non-payment simply stops the work. Nothing is billed silently in the background and you can stop whenever you like.

If you are still building

Everything above assumes an estate that grew over years. Before launch the same work is a fraction of it, and on this page that gap is genuinely large rather than merely real.

Mention that you are pre-launch in the form and I will quote it as its own piece of work. It is cheaper, and it is the version of this engagement I would rather sell.

Questions