Do You Know Every Certificate?
Certificate outages are almost always caused by the certificate nobody wrote down. Chronolith finds them by looking, tracks what is expiring, and — the part most tools skip — proves a replacement actually took effect.
In short
- Discovery is by observation, not inventory. The appliance probes what is actually listening, so undocumented certificates appear.
- Read-only and key-free. Chronolith never holds a private key and never needs one to do this.
- A certificate is identified by its fingerprint, so the same one installed in three places is one thing in three places — which is how the half-finished renewal gets caught.
- Deployment is verified, not assumed. An installer's success message means the command ran, not that the site is serving the new certificate.
- Five checks after every deployment, and only one of them rolls back.
- It also looks from the outside. Public certificate logs show what a certificate authority has issued for your domains, including certificates installed somewhere the appliance cannot reach — which no internal check can see.
The outage is never the certificate you were tracking
Every firm has a spreadsheet, or a calendar reminder, or somebody who remembers. Those cover the certificates that were documented when they were installed.
The outage comes from the other ones: a certificate on a load balancer nobody owns, an internal service someone stood up three years ago, a device with a management interface that was never part of anyone's list. They are invisible until the morning they stop working.
Chronolith probes the endpoints in your estate and records what is actually being served. A certificate appears in the inventory because it exists, not because somebody remembered to add it.
What it finds, and what it never touches
- Expiry — what has expired, and what is close.
- Chain problems — self-signed, incomplete chains, untrusted issuers, and certificates whose name does not match the host serving them.
- Where each certificate lives — every place the same certificate is being served.
- Certificates issued for your domains that you are not serving — read from the public logs every authority is required to publish to.
Probing finds what is installed on hosts the appliance can talk to. A certificate issued for your domain and installed on somebody else’s server is invisible to that by construction — there is no host of yours to probe. It is visible in the public certificate logs, because since 2018 every publicly trusted authority must publish what it issues or browsers reject the certificate.
In practice this usually finds a supplier: a marketing agency running a site under your name on their own hosting, or a service somebody stood up and forgot. Rarely, it finds a certificate nobody in the firm asked for at all, which is the only external warning a firm this size is ever likely to get.
It needs outbound internet and there is no on-premises equivalent — the logs are public internet infrastructure and there is nothing local to consult. An appliance that cannot reach them says so rather than reporting a clean result it did not obtain. Only public names are ever looked up, so an estate using only internal names sends no queries at all.
Discovery reads what a server presents publicly during a normal connection. There is no key custody, no agent required, and nothing to compromise — the appliance has no more access to your certificates than any client connecting to them.
“Deployed successfully” does not mean it is serving
A deployment tool's exit code says the command ran. It does not say the site is serving the new certificate. The binding did not update; the service was never restarted; the private key is not readable by the service account; the certificate went to one of the three places it lives.
Each of those reports success and leaves the estate exactly as it was.
So a deployment is not finished when the installer returns. It is finished when a fresh probe of the endpoint comes back with the new certificate.
- Is it reachable?Does TLS answer at all. Failing this means the deployment caused an outage.
- Is it serving this certificate?Not “a valid one”. A site still serving the old certificate looks perfectly healthy to anything that only checks validity — which is why validity is not the check.
- Did the chain go with it?A certificate installed without its intermediates validates on the machine that installed it and fails for everyone else. That is the version that reaches a customer before it reaches you.
- Do the names still cover what they covered?A renewal that quietly dropped a name breaks one hostname out of six, and nobody notices until that hostname is used.
- What about everywhere else?Renewing the web server and leaving the load balancer on the old certificate is invisible from the machine you just fixed.
Failing reachable is an outage, and the old certificate was working — so going back is strictly better than staying. Failing any of the other four is a deployment that did not take: bad, but not worse than what preceded it, and rolling back would destroy the evidence of what actually happened.
And if the probe itself cannot run — no network path, a firewall in the way — that is recorded as unknown, not as failure. Rolling back a good deployment because nobody could look would be the worst outcome of the three.
Common questions
Does it renew certificates for us?
Requesting and deploying certificates are registered actions that a person authorises — Chronolith does not renew anything on its own schedule. Discovery, expiry tracking and post-deployment verification ship today; end-to-end automated renewal is a roadmap item and is not claimed as shipped.
Will it rotate our internal certificate authority?
No, and it never will. The decision to rotate a root of trust is permanently barred from automatic execution — it is irreversible and estate-wide, which is exactly the shape the architecture refuses to automate.
How does it find certificates on things it does not know about?
Two ways. Inside, by probing the endpoints in the ranges and hosts it has been given, and by reading the internal certificate authority where one exists. A device on a network segment the appliance cannot reach will not be found that way — and coverage is reported so that gap is visible rather than assumed away.
Outside, by reading the public certificate logs for the domains you own. That covers the certificates no probe can reach, including ones installed on hosting you do not control. It reports what it found rather than what exists: the public search for names we do not already know about is not guaranteed to be complete, and where a content delivery network holds several certificates for one name and serves one of them, an extra one cannot be told from a routine rotation.
Does this need an agent on each server?
No. Discovery is a network probe from the appliance, which is why it works on appliances, load balancers and devices that could never run an agent.