Please act before October 31, 2019 to address an upcoming interruption of your applications using RDS and Aurora database instances.
To protect your communications with RDS database instances, a Certificate Authority (CA) generates time-bound certificates that are checked by your database client software to authenticate any RDS database instance(s) before exchanging information. Following industry best practices, AWS renews the CA and creates new certificates on a routine basis to ensure RDS customer connections are properly protected for years to come. The current CA expires on March 5, 2020, requiring updates to existing RDS database instances with certificates referencing the current CA.
You are receiving this message because you have an Amazon RDS database instance(s) in the US-EAST-1 or US-EAST-2 Region(s). If your applications connect to those instances using the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocol please follow the detailed instructions in the link below to complete your update(s). If not completed, your applications will fail to connect to your DB instances using SSL/TLS after March 5, 2020.
We encourage you to test these steps within a development or staging environment before implementing them in your production environments. Beginning today, you can start testing and updating your existing RDS database instances. For detailed instructions, please visit: Rotating your SSL/TLS certificate - Amazon Relational Database Service
Any new RDS instances created after November 1, 2019 will default to using the new certificates. If you wish to temporarily modify new instances manually to use the old (rds-ca-2015) certificates, you can do so using the AWS console or the AWS CLI. Any instances created prior to November 1, 2019 will have the rds-ca-2015 certificates until you update them to the rds-ca-2019 version.
Amazon Web Services, Inc. is a subsidiary of Amazon.com, Inc. Amazon.com is a registered trademark of Amazon.com, Inc. This message was produced and distributed by Amazon Web Services Inc., 410 Terry Ave. North, Seattle, WA 98109-5210
Is this something Convox will take care of automatically (the RDS instance is a Convox resource), or is it something we’re required to do ourselves?
Hi @alon, I got this message too (for both RDS and ElastiCache). I don’t think Convox is able to take care of this automatically, because the default upgrade process requires some downtime (1-2 minutes) while the database restarts. So Convox and AWS won’t automatically upgrade your RDS database.
I try to maintain 100% uptime for my application, so I’ve been looking at Bucardo for Postgres replication, and hopefully I can do a zero downtime upgrade for my database. Has anyone done this before, and do you have any advice that you could share? Thanks!
Does anything in the Convox rack or overall set-up use these CA files for connecting to RDS?
If so, where and how do we update these files?
If Convox is not using these CA files and we are not implementing them in the apps on our rack (by using VPC isolation, for example), does that mean we do not need to do anything?
@afam, @edward, @alon
Sorry for the delay here, it looks like AWS have now finally released support for updating this via CloudFormation so we should hopefully be able to roll out a supported option.
Keep an eye out!
Is there any progress on this? I’ve recently done this for my manually managed AWS RDS instances but now my RDS instances created by Convox using CloudFormation are the only outstanding instances in need of update to the new certificates.
Hi all!
So, the CloudFormation update that AWS released to allow us to update the CA automatically, would enforce and perform an immediate update on your affected Database resources. This would involve a small window of downtime. That’s obviously not ideal to have all your DB’s go offline at the same time while the rack is updating.
We’ve tried out various ways around this but our recommendation is for everyone affected to update the CA configuration for their affected instances themselves. You can have this take effect during the standard RDS maintenance windows, or at a time of your own choosing, and it doesn’t change the drift status in your CloudFormation stack.
If anyone needs guidance on how to update this in their AWS Console, it’s very simple and I’d be happy to throw together a quick walkthrough.
Thanks for clarifying this @ed_convox, its nice to know that the manual update will cause no problems with how Convox manages the CloudFormation stack.
