The Real Cost of Rolling Your Own Service-to-Service TLS

A workable in house setup needs a certificate authority you control, an issuance process for every service that needs one, and a rotation schedule that runs well before expiry, not the week of. Each of those is a small piece of ongoing infrastructure with its own failure modes: a forgotten rotation, a certificate issued with the wrong hostname, a revocation that doesn't propagate to every service checking it. None of these are hard individually. Maintaining all of them correctly, indefinitely, without dedicated ownership, is where teams actually struggle. Write down, explicitly, who owns each of these steps and what happens if that person is unavailable when a rotation is due. A process that only works because one specific engineer remembers to run it isn't a process, it's a single point of failure wearing a runbook's clothing, and it fails the same way any single point of failure does: quietly, until the person is out and the date arrives anyway.

A certificate quietly approaching expiry produces no symptoms at all, right up until the moment it expires and every connection depending on it starts failing simultaneously, often across multiple services at once if they were issued in a batch. This is a uniquely bad failure mode: it's completely silent beforehand and then total and immediate. Alert on certificate expiry well ahead of the deadline, thirty and seven days out at minimum, not just at the moment of failure.

A service mesh or managed certificate platform that handles issuance and rotation automatically removes the specific failure mode above entirely: certificates rotate on a schedule before they're ever close to expiry, without a human remembering to trigger it. The tradeoff is a new dependency, and a new thing to understand when something goes wrong with certificate issuance itself. For teams running more than a handful of services, that tradeoff usually favors automation, since the manual alternative scales linearly with headcount.

How much buffer to build into a rotation schedule depends on how expensive an outage from a missed rotation would be. A 99.95% uptime target allows roughly 4.38 hours of downtime a year across every incident combined¹, which is a useful anchor: a rotation process with any chance of a multi-hour gap between expiry and renewal is putting a meaningful share of that annual budget at risk over a single preventable event.

Say a batch of internal service certificates was issued together and nobody flagged the shared expiry date. When it hits, every one of those services loses the ability to authenticate to each other at once, not gradually. If that takes two hours to fully diagnose and fix across a dozen affected services, that single incident alone can consume a large share of a tight annual downtime budget, all from one date that a thirty day expiry alert would have caught with time to spare.

Track certificate inventory and expiry dates somewhere visible, a tool like ClickUp works fine for the calendar and ownership, regardless of whether issuance itself is manual or automated. Automate rotation once you're running more than a handful of services, since the manual alternative doesn't scale with headcount. Compliance platforms such as Vanta can often collect encryption-in-transit evidence from your setup when a SOC 2 auditor asks how service-to-service traffic is protected; confirm what it supports for your stack in the vendor's current documentation.

Put certificate management into practice this way:

• Track certificate inventory and expiry dates somewhere visible, with named owners, whether issuance is manual or automated.
• Automate rotation once you run more than a handful of services, since manual rotation doesn't scale with headcount.
• Rotate well before expiry, not the week of, so a missed step never becomes a shared outage.
• Avoid issuing a batch of certificates that all share one expiry date that nobody has flagged.