TLS certificate rotation is a fact of life for developers who have cloud-driven applications. All TLS certificates must expire at some point, or else the effectiveness of the encryption of your data in transit will be weakened. Deciding on the lifespan of a certificate or any other kind of machine identity is a compromise to be made between usability and security. Shorter lifespans reduce the attack surface for dreadful man-in-the-middle attacks, but they also can cause headaches for organizations, especially those that don’t have proper automated machine identity management. The users of your applications may also be affected because these users will need to rotate their certificates on their end, even if their client software does it for them. There could also be complications in the DevOps lifecycle, which emphasizes how important automating machine identity management is.
On January 7th, Amazon Web Services reminded their users that developers who implement TLS certificate validation to their databases will need to rotate to the new certificate as soon as possible. The message was communicated by a blog post written by Amazon’s Jeff Barr. That day has passed, so if your organization uses Amazon Aurora, Amazon Relational Database Service, or Amazon DocumentDB, you should rotate to the new certificate right away! On March 5th, your old CA-2019 will expire. You must act now!
Here’s the timeline of the process as described on the blog. On September 19th, 2019, the new CA-2019 certificates were made available. If you use TLS certificate validation with Amazon Aurora, Amazon Relational Database Service, or Amazon DocumentDB, that’s the version you should be using now. As of January 14th, 2020, new database instances use CA-2019 automatically. Your older database instances should rotate to a CA-2019 certificate. But if there are compatibility problems, you can temporarily revert to the old certificates. That’s not recommended though. So, if I were you, I would try to fix any pertinent compatibility issues as soon as possible so you can use the CA-2019 certificates.
Between February 5th and March 5th, Amazon Relational Database Service will install but not automatically activate the new CA-2019 certificates on any existing database instances. That’s another reason why you’ll want to fix any compatibility issues in your application’s databases as soon as possible. Then on March 5th, the old CA-2015 certificates will expire! So, if you haven’t updated to CA-2019 by now, the clock is ticking. But as these certificates have five-year lifespans, hopefully you’ve had time to update your application’s backend accordingly. If your application doesn’t implement certificate validation for your databases, you’ll probably want to do so in the near future in order to improve your security. You should still probably rotate to CA-2019 so you’ll be prepared.
The AWS certificate matter is a specific issue, but it reflects the reality of all cryptographic certificate implementations in websites, web apps, and other cloud-driven applications. Even if your organization doesn’t use Amazon Aurora, Amazon Relational Database Service, Amazon DocumentDB, or AWS at all, there’s something to be learned here. Your organization must take control of your cloud certificates. They all eventually expire and will need to be replaced. Certificate outage can cause downtime for your applications, and users will be inconvenienced. Downtime usually leads to financial losses and unhappy customers. Losing control of your certificates and other machine identities breaks the functionality of applications.
If you use Amazon Aurora, Amazon Relational Database Service, or Amazon DocumentDB and you haven’t switched to the CA-2019 certificate by March 5th, your AWS-driven applications will break. They will become dysfunctional for your users. But if your apps use different technologies, they will also break if you let a certificate expire without replacing it properly! And if you lose track of some of your certificates, cyber attackers could exploit them to perform man-in-the-middle attacks on your applications! No matter which cloud and database technologies you use, you must make sure these incidents never happen with proper machine identity management.
If your application on AWS does use Amazon Aurora, Amazon Relational Database Service, or Amazon DocumentDB, the AWS blog explained the steps involved for rotating to CA-2019. Because AWS hasn’t fully automated this, you may have to do a bit of extra work. But probably the easiest way to rotate is to add some code to your CLI:
$ aws rds modify-db-instance --db-instance-identifier database-1 \
--ca-certificate-identifier rds-ca-2019 –apply-immediately
With that code and some additions, perhaps developers can write scripts so your rotation to CA-2024 in a few years can be made easier. If you write a script to do something in a few years though, be very careful to test your code and check your application’s compatibility and readiness!
Here are some final notes. Amazon Aurora Serverless handles certificate rotation automatically through AWS Certificate Manager. If that’s what you use, no action on your part is necessary for the rotation. As far as cluster scaling is concerned, new nodes to existing clusters receive the CA-2019 certificate if one or more of the existing nodes already have it. If they don’t, make sure you manually rotate to CA-2019! And finally, if your AWS databases are hosted in the Asia Pacific (Hong Kong), Middle East (Bahrain), or China (Ningxia) regions, rotation won’t be necessary. Whew!
Rotating to CA-2019 is of great importance when it comes to maintaining the security of your applications. But with all the hassle, you can see why automating as much of your certificate management as possible will make life easier for developers and take human error out of the rotation process.