Most AWS regions have a looming deadline (2024-08-22) to rotate an SSL/TLS certificate in AWS RDS/Aurora. An RDS instance that keeps using the old certificate beyond this date may stop working because clients may refuse the expired certificate.

As the administrator an AWS organization, how do I identify instances across the organization that need attention?

The AWS News Blog article Rotate Your SSL/TLS Certificates Now - Amazon RDS and Amazon Aurora Expire in 2024 explains the problem well. To summarize:

  • A DB instance created before 2024-01-25 by default uses the certificate rds-ca-2019
  • The rds-ca-2019 certificate expires on 2024-08-22
  • Since 2022, AWS lets you use certificates valid for 40 years (rds-ca-rsa2048-g1) and 100 years (rds-ca-rsa4096-g1 and rds-ca-ecc384-g1)
  • The issue affects plain old RDS instances and plain old RDS clusters
  • The issue does not affect Aurora Serverless v1
  • The issue does affect Aurora Serverless v2

The article isn’t clear on why Aurora Serverless v1 is an exception, so I had to read around to find out. From the documentation I learned the distinguishing features.

  • An Aurora Serverless v2 cluster uses the special DB instance class db.serverless
  • An Aurora Serverless v2 cluster, like a plain old RDS cluster, uses the provisioned engine mode
  • An Aurora Serverless v1 cluster uses no DB instances
  • An Aurora Serverless v1 cluster uses the serverless engine mode

Sources: CreateDBCluster EngineMode, Migrating to Aurora Serverless v2.

Confusingly, the DBInstanceClass documentation doesn’t list db.serverless at all.

To to find certificates that need rotation, I need to look just at the DB instances. The certificate isn’t a property of the cluster, but of the instances in the cluster.

Now that I understand the theory, I’m ready to identify the instances that need attention.

The main article shows how to do this in one account, but I have hundreds. How do I find all the problem DB instances across my organization?

Because I’ve set up AWS Config with a configuration aggregator across my organization, I have a quick way to solve this using the advanced query interface.

I read the resource schema in GitHub to discover that the AWS::RDS::DBInstance type has a property called configuration.cACertificateIdentifier. Watch out for the weird capitalization!

Use a query like this to list all the DB instances across your organization.

SELECT
  accountId,
  awsRegion,
  resourceName,
  configuration.cACertificateIdentifier
WHERE
  resourceType = 'AWS::RDS::DBInstance'
ORDER BY
  accountId,
  awsRegion,
  resourceName;

The first three columns uniquely identify and locate each instance in the in the organization. The last column is the property I need to check.

You’ll get a result set shaped like this:

accountId awsRegion resourceName configuration.cACertificateIdentifier
111111111111 eu-west-1 demoinstance1 rds-ca-rsa2048-g1
222222222222 eu-central-1 demoinstance2 rds-ca-rsa2048-g1
333333333333 eu-central-1 demoinstance3 rds-ca-2019

The example result allows me to split the instance into two groups, ignore and inform.

I ignore demoinstance1 and demoinstance2. They need no more attention because they use one of the long-lived certificates.

I inform the responsible team about demoinstance3 because it uses the certificate rds-ca-2019 that is about to expire. Now they can plan a remediation.

In this article I’ve discussed the upcoming deadline to rotate a SSL/TLS certificate for RDS/Aurora DB instances. You’ve seen where to get more information to understand the problem both from the AWS News blog and from the RDS service documentation. Finally you’ve seen how to use AWS Config’s organization aggregator and advanced query feature to report on the certificate configuration across all the DB instances in the AWS organization.