AWS Database Blog
Amazon RDS customers: Update your SSL/TLS certificates by March 5, 2020
This post was originally published on December 20, 2019 and has been updated as of March 4, 2020. Please see new dates and suggested timeline below.
IMPORTANT UPDATE: If you are experiencing connectivity issues after the RDS Root CA expires, please skip down to the What do I have to do to maintain connectivity? section.
If you are an Amazon RDS and Amazon Aurora customer, you might have received emails from AWS notifying you about rotating your SSL/TLS certificates. The current SSL/TLS certificates for RDS DB instances will expire on March 5, 2020 as part of standard maintenance and security best practices for RDS. This blog post gives you more details about the upcoming expiration, explains how to tell if you are affected, and lets you know what you should do to maintain connectivity to your database instance.
What is going on?
As part of the standard maintenance and security best practices for RDS, the SSL/TLS certificates for RDS DB instances and Aurora DB clusters expire and are replaced every five years. The current certificate will expire on March 5, 2020. Your database clients and applications that use SSL/TLS with certificate validation to connect to an RDS DB instance or Aurora cluster will lose connectivity beginning March 5, 2020 if you do not update the SSL/TLS certificate on both the client and the database server.
Additionally, any new RDS DB instances and Aurora DB clusters created after January 14, 2020 will have the new certificates. All RDS DB instances and Aurora DB clusters created prior to that point will have the old certificates. If you wish to temporarily revert new DB instances or Aurora clusters manually to use the old certificate, you can do so using the AWS Management Console, the RDS API, or the AWS CLI. However, as noted above, these and all other DB instances and DB clusters should be updated to use the new certificates by March 5, 2020. DB instances and DB clusters created prior to January 14, 2020 will still use the old certificates.
How can we know whether applications connect to RDS databases via SSL/TLS or not?
Below you will find links to the engine-specific documentation that can help you determine whether your applications use SSL/TLS to connect to your database, whether your client application requires certificate verification, and how you can update your application trust stores with the updated SSL/TLS certificates. Although we have included the most common scenarios, the methods for updating applications for new SSL/TLS certificates vary so some specific application scenarios may not be fully addressed.
While all RDS Engines provide some mechanism to see whether open connections to your database are using SSL/TLS, it is important to understand a few nuances of this information. First, some RDS Engines require specific configuration settings or users with specific permissions to see this data, which you will find noted in each engine’s documentation referenced below. Second, the data that each RDS Engine provides on whether connections are using SSL/TLS only show current connections. If you have many applications, only some of which use SSL/TLS and connect intermittently, you may need to capture this information multiple times over a longer period to ensure an accurate perspective. Lastly and most importantly, there is currently no easy method from the Database Engine itself to determine if your applications require certificate verification as a prerequisite to connect. The only option here is to inspect your applications’ source code or configuration file. Although the engine-specific documentation outlines what to look for in most common database connectivity interfaces, we strongly recommend you work with your application developers to determine whether certificate verification is used and the correct way to update the client applications’ SSL/TLS certificates for your specific applications.
For Amazon RDS:
For Amazon Aurora:
How do I know if my RDS databases are affected?
If you have applications that connect to RDS for Aurora MySQL, Aurora PostgreSQL, MySQL, MariaDB, SQL Server, Oracle or PostgreSQL, and that use SSL/TLS with certificate validation, those applications are affected by this change.
If your applications do not use SSL/TLS to connect to your RDS database instance, or if your applications do not require server certificate validation, then this change will not impact your connectivity.
What do I have to do to maintain connectivity?
To maintain connectivity, you need to update the SSL/TLS certificates in all the trust stores used by all applications that connect to RDS databases with the new published CA Certificates by March 5, 2020. Make this update by following these steps:
- Download the new SSL/TLS certificates from Using SSL to Encrypt a Connection to a DB Instance.
- Update your database client applications to use the new certificate bundle. Note that the certificate bundle contains certificates for both the old and new CA, so you can upgrade your application safely and maintain connectivity during the transition period.
- Use the RDS console or the
modify-db-instanceCLI command to change the Certificate Authority (CA) tords-ca-2019. IMPORTANT: When you schedule this operation, please make sure you have updated your client-side trust store beforehand.- For next maintenance window execution:
- For immediate execution:
For more detailed instructions, please visit:
If you are unable to complete all three steps by March 5, 2020, which is the last date to update your certificates, your client or application may be unable to connect to your database instance using SSL or TLS.
What steps do I need to take to complete my update?
Completing the CA certificate rotations is a two-step process. First, you must update your client application or service to include the latest CA certificates in its trust store using the combined bundle that contains both the new and the old CA certificates. After this is done, you must update your RDS DB instances to rotate to the new CA certificates. Instructions are provided below:
We strongly recommend that you perform these steps in a test or staging environment before completing these steps in a production environment.
I don’t use SSL/TLS. Do I need to rotate the CA certificate?
If you are 100% certain that you do not use SSL/TLS, you will not be required to rotate your CA certificate before the March 5, 2020 deadline. If you are not 100% certain that you do not use SSL/TLS, please review the documentation below to verify whether your applications connect using SSL/TLS:
Then complete your client application and database certificate updates to avoid potential risk of disruption.
Please note that database security best practices are to use SSL/TLS connectivity and to request certificate verification as part of the connection authentication process.
I don’t use SSL/TLS, can I rotate the certificate without restarting my database?
If you do not want to restart your database, you can use a new CLI option for the modify-db-instance CLI command (--no-certificate-rotation-restart) specifically to rotate and stage the new certificates on the database host to avoid a restart. However, new certificates will be picked up by the database only when a planned or unplanned database restart happens.
For RDS for Oracle databases, no restart is required.
If I do use SSL/TLS, do I need to restart my database to rotate my certificate?
Yes, if and when you perform the CA certificate update on your database, there will be a restart. For those customers who are using SSL/TLS to connect to their databases and require certificate verification, you will need to restart on or before March 5, 2020. You can choose to schedule the operation to be in the next maintenance window or run immediately by using the RDS console, RDS API, or the AWS CLI.
The only exception to the above is for Oracle databases. If you are using RDS for Oracle, only the database listener will be restarted but the databases themselves will not. Existing database connections will remain unaffected while new connections will see errors for a brief period while the listener is restarted.
Which RDS database engines are impacted?
Amazon Aurora PostgreSQL, Amazon Aurora MySQL, Amazon RDS for PostgreSQL, Amazon RDS for MySQL, Amazon RDS for MariaDB, Amazon RDS for Oracle, Amazon RDS for SQL Server.
Which RDS database engines are not impacted?
Aurora Serverless DB clusters are not impacted because they use AWS Certificates Manager to manage certificate rotations.
Which RDS regions are excluded from this rotation?
Middle East (Bahrain) region, Asia Pacific (Hong Kong) region and China (Ningxia) and GovCloud are excluded from this rotation.
What applications are impacted?
Any application that connects to an RDS database using SSL/TLS, and which also requires server certificate validation against the application’s trust store (or a hardcoded client certificate) is impacted by this change.
What happens if I don’t make the required change by March 5, 2020?
If you do not make the change by March 5, 2020, your applications that connect via SSL/TLS and verify that the CA certificate will no longer be able to communicate with their RDS DB instances.
Can the deadline be extended beyond March 5, 2020?
The deadline cannot be extended beyond March 5, 2020.
I have a multi-AZ configuration. Will my standby DB instance(s) also get the new certificates?
Yes, for multi-AZ deployments, the standby DB instance automatically gets the new CA certificate from the primary DB instance.
Will an Amazon RDS DB instance failover in a Multi-AZ configuration change my CA Certificate?
No, your Amazon RDS DB instance will remain on the same CA certificate.
How do I know which of my RDS DB instances are using the old certificate?
On the left navigation panel in the RDS console, there is now a Certificate update tab. Choose the tab to show a temporary page with your affected DB instances. This page will only show your affected DB instances when you select the appropriate AWS Region (if you switch to an AWS Region without affected DB instances, your table will be empty).
AWS API/CLI: In the Describe DB Instances API, there is a parameter called CACertificateIdentifier of string format. All new CA certificates are identified as ‘rds-ca-2019.’ Check for all DB instances that are not ‘rds-ca-2019’ to determine which DB instances are not using the new certificates.
If I am not using SSL/TLS to connect to my Amazon RDS DB instance or Amazon Aurora DB cluster today, but I am planning to in the future, what should I do?
If you are planning to use SSL/TLS in the future, we recommend that you update your CA certificates as soon as possible.
What happens if I have two instances in my Aurora DB cluster and I create a third instance in my DB cluster?
If your instances are running on certificate ‘rds-ca-2019‘, the new instance will be ‘rds-ca-2019‘.
If your instances are running on certificate ‘rds-ca-2015‘, the new instance will be ‘rds-ca-2015‘.
If your instances are running on a mix of certificate ‘rds-ca-2015‘ and ‘rds-ca-2019‘ the new instance will be ‘rds-ca-2019‘.
When is the updated server certificate going to expire?
The updated server certificate has an expiration date of August 22, 2024.
Does CloudFormation support the new certificates?
Yes, we added CloudFormation support on December 20, 2019. To make the change, use the following property in your CFN template: “CACertificateIdentifier” – it accepts a string. The full specifications of the property are listed below.
If I applied the new server certificate, can I revert it back to the old certificate?
Yes, it is possible to revert back to the rds-ca-2015 certificate using the RDS Console or CLI until March 05, 2020.
For detailed instructions on reverting the certificate refer to the documentation.
If we restore from a snapshot or a point in time restore, will it have the new certificate?
In the case that you restore a snapshot after January 14, 2020 it will create new instances with the new CA certificate.
I have read replicas. What actions, if any, do I need to take?
The CA Certificate update must be executed on each of the read replicas. These updates can happen among the Primary and Read Replica DB instances in any particular order.
What if I have questions or issues?
If you have questions or issues, contact AWS Support or your Technical Account Manager (TAM).
About the Author
Nitesh Mehta is a Sr. Product Manager with Amazon Web Services.