The Expiry Date Hiding in Your Managed Database

Yesterday I wrote about being first to adopt a new SKU. Today is the opposite corner of the managed-service bargain: the thing you never adopted at all, and which still goes wrong. I want to talk about a failure mode so rare and so boring that almost nobody keeps it on a runbook, and which nonetheless took down verified database connections across the industry in August 2024.

Here is the setup. You spin up a managed database: Amazon RDS, Aurora, or something similar from another provider. The provider handles provisioning, backups, patching, failover, storage scaling. You feel like an operator with nothing left to operate. That feeling is accurate, with one exception.

Your database talks TLS. The server presents a certificate chain signed by the provider’s certificate authority, and your application is configured to verify it, which is the right way to do it. That chain is a piece of calendar arithmetic, and it expires. The provider will not surprise you with a new root CA: a new root has to land in your client’s trust store first, which only you can do. So the provider publishes new CAs years in advance and asks you to adopt them, and most teams, most of the time, don’t get to it.

In August 2024, Amazon’s rds-ca-2019 certificate authority expired. AWS’s own knowledge center describes what happened: “Connections to Amazon RDS databases might fail because the SSL/TLS certificates are expired. This issue affects every type of Amazon RDS DB instance.”¹ The error text that arrives is wonderfully misleading. PostgreSQL clients log sslv3 alert certificate expired or a certificate verification failure that mentions certificates you have never heard of. MySQL clients log MySQL Error 2026 (HY000): SSL connection error: certificate verify failed.² None of those strings says “check the calendar.” They say “something is wrong with your encryption,” which reads like an incident, or a compromise, or a misconfigured proxy. The first hour of triage goes to all the wrong places.

What makes this a genuinely operational problem, rather than a trivia question, is the shape of the failure. It has nothing to do with load, nothing to do with capacity, and nothing to do with anything your dashboards watch. Your database CPU graphs look fine, because there is almost no CPU usage happening. No top-ten error table on any dashboard lights up in a way that hints at TLS. The failure arrives on a date, hits every verified connection at once, and persists until a human notices that the root CA named in the error is the one that turned five this month. This is the failure class the book calls the “when you are the one escalated on” problem, in chapter 3: the person on call inherits everything the dashboards were not built to watch, and no dashboard is built to watch a date.

The really sneaky part is that part of the rotation genuinely is automatic. AWS rotates the server certificate by itself. Their docs say: “RDS attempts to rotate your DB server certificate in your preferred maintenance window at the DB server certificate half life,” and the new server certificate is valid for twelve months on engines that support rotation without a restart.³ So from the database side, everything hums along for years. The component that does not rotate itself is the trust store inside your application. That part is your job, forever, on a hosted database. The provider cannot push a new root CA into your code. Every time they prepare a rotation, the order of operations is the same: update your clients first, then change the database. AWS says exactly that: “Before you update your DB instances or Multi-AZ DB clusters to use the new CA certificate, make sure that you update your clients or applications connecting to your RDS databases.”⁴

This is the fine print of the managed-database deal. The provider takes the chores that happen every day and every month. The one chore left over happens every few years, which is precisely why it falls through. It is too rare to appear in a quarterly checklist and too wide to fail quietly. When it goes, the blast radius is every application instance that verifies certificates, and the failure surfaces as a mysterious security error instead of a planning miss.

The fix is embarrassingly cheap, which is the strange part. It is not engineering work. It is a date on a calendar. describe-certificates shows the ValidTill date for every certificate authority in your account, and the instance view shows which CA each database currently trusts. Those dates can go straight into the same calendar you keep patching and contract renewals on. Download the combined bundle, which contains the old and new CAs together, and your application stays connected through the transition either way.

A hosted database really does remove most of the operational work. What it cannot remove is trust, because trust lives in your application by design. And trust is the one component left in the system that still fails on the manufacturer’s calendar rather than under load. Put the expiry date somewhere a human will see it. Somewhere that is not an SSL error message in a log bucket nobody is tailing at two in the morning.