The Cert Renewal Game of Telephone: When Ownership Falls Through the Cracks
When you played telephone as a kid, the rules were simple. Someone whispers a sentence into the first person's ear. That person whispers what they heard to the next person. By the time the message reaches the last person in the line, the sentence is unrecognisable - and usually funny. "The blue bird sat on the fence" becomes "the bus driver bought a tent."
Cert renewal ownership in organisations works the same way, except without the funny part at the end. The whispered message is "you own this certificate." The chain of whispers stretches across reorgs, team changes, contractor handoffs, and the occasional acquisition. By the time anyone tries to renew the cert at year four or five, the chain has gone quiet. Nobody knows whose certificate this is. The renewal alert is sent into a void.
This is the cert ownership problem. It is the most common single cause of cert outages in mature organisations. It's not a tooling problem. It's a structural problem in how teams hand off responsibility, and the fix has nothing to do with which certificate manager you use.
Here's how cert ownership degrades, the three specific patterns of orphaning we see most, and the structural fix.
How ownership normally degrades
Most certs start with a clear owner. An engineer needs a cert. They issue it. Their email is on file. Their calendar has the renewal reminder. They get the email when the cert is about to expire. They renew it. Everyone is happy.
Then time passes.
Year one: the engineer renews the cert without thinking. The system works.
Year two: the engineer changes teams. Maybe they still see the renewal email; maybe they don't. They might renew it themselves, or might forward the alert to "whoever owns this now."
Year three: the engineer has left the company. Their email forwards somewhere - maybe their old manager, maybe a deactivated alias. The renewal email arrives somewhere nobody reads.
Year four: the cert is about to expire. There is no human alert. The cron job that was set up to monitor it has been silently failing for six months because the credentials it used were tied to the original engineer's account. The cert expires. Somebody notices when customers start seeing browser warnings.
This story isn't unusual. It's the median path for any cert older than three years in an organisation with any meaningful turnover.
Three patterns of cert orphaning
The general pattern has three specific shapes worth recognising.
Pattern 1: The personal email problem. A cert was originally registered with engineer@company.com. That email is now deactivated. The renewal notice from the CA goes to a bouncing address. The engineer's calendar reminder lives in a Google account nobody can access. The cert dies quietly because the only person who would have known is unreachable.
Pattern 2: The reorg orphan. The team that owned this cert was reorganised. The new team thinks "platform" owns it. Platform thinks "infrastructure" owns it. Infrastructure thinks "the original team" owns it. Nobody owns it. The renewal email gets archived by whoever happens to be on the rotation that week.
Pattern 3: The acquisition orphan. You bought a company. Their certs came with the deal. Their renewal calendar was in their internal wiki, which got migrated to your wiki but the renewal page didn't make the cut. Their staging environment cert is still being renewed by an automation running on a server you don't know exists.
Each pattern produces the same outcome: a cert with no clear human owner, an alert going to a place nobody reads, and an outage waiting to happen.
The fix: ownership at the team level
The root cause of all three patterns is the same: certs were owned by people, not by teams.
People leave. Teams move. Companies merge. The names on the calendar invite go stale. The only ownership that survives organisational change is ownership tied to a structural entity - a team, a service, a function - that persists even as the humans rotate through.
What this looks like in practice:
Renewal notices go to a shared inbox or channel, not a person. certs@team.com, #certs-platform, a PagerDuty service. Anything that doesn't have one person's name on it. The notice still gets read because someone on the team will read it; it doesn't die when one person leaves.
Ownership is recorded against a service, not an engineer. "The auth-service cert is owned by the Auth team" survives reorgs better than "Bob owns this cert." When Bob moves teams, the cert ownership stays with Auth.
Ownership is reviewed on a schedule. Quarterly is reasonable. Walk through every cert in your inventory, ask "is the owner correct?" Update what's wrong. The first time you do this, you'll fix a lot of things you didn't know were broken.
Onboarding includes cert ownership. New team leads learn what certs their team owns. Departing team leads hand off explicitly.
Most of this isn't tooling work. It's process work - and the kind of process work that nobody puts on a roadmap because it has no visible payoff until it prevents an outage.
What good ownership looks like
A team with good cert ownership can answer three questions in under a minute, without checking with anyone:
- "Which certs does our team own?" (Without "let me check the wiki.") "When does each one renew?" (Without "let me ask Bob.") "What happens if the renewal fails?" (Without "I'll figure it out at the time.")
A team without good cert ownership cannot answer any of these. Their certs are renewed by accident, monitored by accident, and they have outages because of it.
This is the cert problem we keep coming back to. It is solvable. It is mostly not solved.
One small ask
The telephone game ends with a punchline. The cert version ends with an outage and a post-mortem. The fix isn't more sophisticated tooling - it's making cert ownership structural instead of personal. TLS Radar lets you assign ownership at the team level, route alerts to shared channels, and track ownership over time as people move. Free tier covers three domains, which is enough to surface where your current ownership has already gone quiet.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.