Abstract
The word “certificate” means too many different things.
When someone says “the certificate for example.com,” they might mean the public key the CA signed. They might mean the key-pair sitting on the filesystem. They might mean the signature that expires in 47 days. Or they might mean all the things together, that you’ve been renewing for the last 10 years.
That last one doesn’t have a name in any PKI standard. And it should.
What “certificate” means in the spec
An X.509 certificate is a point-in-time object. It carries a serial number, an expiration date, a public key, a set of Subject Alternative Names, and a CA signature. When you renew, the CA issues a brand-new certificate (new serial, usually a fresh key pair) with no cryptographic link to what came before. The renewal relationship doesn’t exist at the protocol level.
The closest the protocol has come to acknowledging this is RFC 9773, the ACME Renewal Information extension (ARI). It added a replaces field to the ACME newOrder request, so when your client renews, it can tell the CA which predecessor it’s replacing. The CA uses this to waive rate limits and coordinate mass revocations. As we wrote when ARI shipped, it’s a meaningful change in how the protocol handles renewal events.
But replaces is a single hop. One cert pointing at its immediate predecessor. Walk those pointers backward and you can reconstruct a history, but the protocol has no name for the set you just reconstructed. It can express “this cert replaced that cert.” It cannot express “these ten certs are all versions of the same thing.”
The vocabulary gap Certbot quietly filled
Certbot named it. In their documentation, a lineage is a collection of all the versions of a certificate plus configuration information maintained for that certificate from renewal to renewal. The term never made it into X.509, the CA/Browser Forum Baseline Requirements, or the ACME spec. It was an internal naming decision by one tool.
It’s a good word for it.
The concept that needed naming is distinct from the piece of vocabulary that sounds adjacent: the chain of trust. These are completely different ideas that get conflated often enough to be worth separating clearly.
The chain of trust is vertical. It’s the hierarchy a client walks when it validates a certificate, from your leaf cert up through an intermediate CA to a root CA the browser trusts. It answers the question: can I trust this certificate right now? Every certificate has a chain. The chain lives in the protocol.
┌─────────────── Lineage: example.com ────────────────┐
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Root CA │ │ Root CA │ │ Root CA │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ ↓ ↓ ↓ │
│ ┌──────┴──────┐ ┌──────┴──────┐ ┌──────┴──────┐ │
│ │Intermediate │ │Intermediate │ │Intermediate │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ ↓ ↓ ↓ │
│ ┌──────┴──────┐ ┌──────┴──────┐ ┌──────┴──────┐ │
│ │ example.com │─►│ example.com │─►│ example.com │ │
│ │Expires Jun 1│ │Expires Jul 1│ │Expires Aug 1│ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
└─────────────────────────────────────────────────────┘
Lineage is horizontal, over time. It’s the series of certificates issued and renewed for the same SAN set, each replacing the last. The June 1 cert and the July 1 cert for example.com are different certificates with different chains of trust, but the same lineage.
Why this is starting to matter
At 398-day certificate lifetimes, the lineage of example.com has roughly one entry per year. That’s easy to track. Each renewal is an event: a reminder fires, you spend an afternoon on it, done.
At 47 days (where certificate lifecycle management is heading), that same lineage has eight entries per year, per certificate. The renewal stops being an event. It’s the background workload. You’re interacting with the example.com lineage every few weeks: verifying the latest renewal succeeded, confirming deployment, investigating why a host is still serving the June 1 cert when July 1 has been out for four days.
At that cadence, the ambiguity in the word “certificate” stops being a minor annoyance and starts causing real confusion. When a monitoring alert fires for example.com, which certificate does it mean? When you pull an audit log, which issuance are you looking at? When someone asks whether example.com is up to date, are they asking about the lineage or about one specific cert in it?
The lineage is the thing you’re managing. The individual certificates are the mechanism.
What CertKit means when it says “certificate”
In the CertKit UI a “certificate” is really a lineage of certificates.
When you connect example.com to CertKit, we manage that as an ongoing certificate configuration. CertKit issues the first certificate, deploys it, and then keeps issuing and deploying replacements on the same schedule with the same configuration, indefinitely. That persistent record is what the interface calls a “certificate.”
When we price per certificate, we mean per lineage. When we show you a certificate’s expiry date, we mean the current certificate in that lineage. Every cert we’ve issued for it is in the audit log, but the top-level record is the lineage.
We made the same naming trade-off Certbot made. “Lineage” is the precise term. “Certificate” is what people already call the thing they’re managing. We went with what you’ll recognize.
The word “certificate” will keep meaning too many things. Lineage is the one worth being precise about.
CertKit handles the full certificate lifecycle so renewals, at whatever cadence, are not your problem.
Comments