int-brain-lab / iblenv

Unified environment and Issue tracker for all IBL
MIT License
10 stars 10 forks source link

AWS certificates expire August 2024 #356

Closed juhuntenburg closed 5 months ago

juhuntenburg commented 5 months ago

https://health.aws.amazon.com/health/home#/account/dashboard/scheduled-changes?eventID=arn:aws:health:eu-west-2::event/RDS/AWS_RDS_PLANNED_LIFECYCLE_EVENT/AWS_RDS_PLANNED_LIFECYCLE_EVENT_db8dff01b98f0ce71cb908e759965405815f4a2c805c87c9293b379bcbb352eb&eventTab=affectedResources&viewType=table

Affected resources: alyx RDS, openalyx RDS

====================== You are receiving this message because your AWS Account has one or more Amazon RDS, or Amazon Aurora database instances in the EU-WEST-2 region using an SSL/TLS Certificate that is expiring on August 22, 2024.

A list of your affected resources can be found in the 'Affected resources' tab.

This is a follow-up notification for SSL/TLS CA certification expiration. If you believe you have already finished this work and still received this email it is likely because you created new instances using the 2019 CA. All newly created instances that don’t explicitly specify a different CA will use the 2019 CA until January 25, 2024 when the default will be switched to rds-ca-rsa2048-g1. For information on setting an account level CA override see the modify-certificates API documentation [1].

If your applications connect to these instances using the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocol, you will need to take action before August 22, 2024 to prevent connectivity failures to your existing database instances. Even if you don’t use SSL/TLS for the database instances, RDS recommends you rotate your CA. You may need to use SSL/TLS in the future.

To protect your communications with your database instances, a Certificate Authority (CA) generates time-bound certificates that are checked by your database client software to authenticate any database instance before exchanging information. Following industry best practices, AWS renews the CA and creates new certificates on a routine basis to ensure customer connections are properly protected for years to come. The current CA in EU-WEST-2 will expire on August 22, 2024. Before this date you will need to update your DB server certificate. The general process to do this is:

First, update your application clients with the new certificate, if your application client is using trust stores then add the new CA certificates into the trust stores of your client applications. RDS provides download links to the CA certificates here [2]. For more detailed instructions on updating the trust stores on your client application see [3].

Second, update the certificate on all your affected database instances to one of the newly issues CA’s. rds-ca-rsa2048-g1 is the default recommended CA because there is no algorithm change. The other CA’s use new key algorithm’s so it could require more testing of your client setup to ensure compatibility. For more information on the new CA’s see [4].

Third, since the 2019 CA is still the default CA you will need to set an account level CA override so your new instances will use one of the new CA’s. To do this a modify-certificates API is available that will allow you to override the default CA on newly created database instances to either the old or one of the new CAs. This override will only apply while the CA you are overriding to is valid. To use this API you will need to be running the AWS CLI version 1.17 or later. For more information see the modify-certificates API documentation [1]. There is also a describe-certificates API [5], that will indicate your current default CA override if you have one set. To set a specific CA during instance creation use the ca-certificate-identifier option on the create-db-instance API is available for you to create a DB instance with a specific CA. For more information, see the create-db-instance API documentation [6].

For more detailed instructions on how to perform these updates please see the Amazon RDS instances [7] and Amazon Aurora instances [8] documentation.

Please be aware of the following timeline:

  1. Now through August 22, 2024 - you can update client trust store at any time, then you can update your instances server certificate to one generated by one of the new CA’s

  2. Now through January 25, 2024 - new db instances will have the 2019 certificate by default, unless you specify a different CA via the ca-certificate-identifier option on the create-db-instance API; or you specify a default CA override for your account like mentioned in the above section.

  3. Starting January 26, 2024 - any new database instances will default to using the rds-ca-rsa2048-g1 certificate. If you wish for new instances to use a different certificate, you can specify which certificate to use with the AWS console or the AWS CLI. For more information, see the create-db-instance API documentation [6].

  4. Starting August 22, 2024 - the 2019 CA will expire. You will need to take action before August 22, 2024 to prevent connectivity failures to your existing database instances.

If you have questions or concerns, please contact AWS Support [9].

To learn more about planned lifecycle events and how they affect your AWS resources refer to the AWS Health User Guide [10].

[1] https://docs.aws.amazon.com/cli/latest/reference/rds/modify-certificates.html [2] https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html#UsingWithRDS.SSL.CertificatesAllRegions [3] https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL-certificate-rotation.html#UsingWithRDS.SSL-certificate-rotation-updating [4] https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html#UsingWithRDS.SSL.RegionCertificateAuthorities [5] https://docs.aws.amazon.com/cli/latest/reference/rds/describe-certificates.html [6] https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html [7] https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL-certificate-rotation.html [8] https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.SSL-certificate-rotation.html [9] https://console.aws.amazon.com/support/home [10] https://docs.aws.amazon.com/health/latest/ug/aws-health-planned-lifecycle-events.html

juhuntenburg commented 5 months ago

From Olivier: I'd suggest moving the certificates /domains from GANDI to route 53 (the AWS domain /certificate providers) as all of this is provided and we have only one stop to handle permissions and domains.

oliche commented 5 months ago

So this concerns only the SSL certificates for direct connections to the database, which we are not using.

The client side is easy, we would have to update our django settings this way:

    DATABASES = {
        'default': {
            'ENGINE': 'django.db.backends.postgresql_psycopg2',
            'NAME': os.environ['PGDATABASE'],
            'USER': os.environ['PGUSER'],
            'PASSWORD': os.environ['PGPASSWORD'],
            'HOST': os.environ['PGHOST'],
            'PORT': os.environ['PGPORT'],
            'OPTIONS': {'sslmode': 'require'},
        }

But I'm worried about this AWS gobbledygookbelow. It looks to me that it may be easier to have the certificate expire and then replaced by new defaults, that we'll setup if we want to.

Third, since the 2019 CA is still the default CA you will need to set an account level CA override so your new instances will use one of the new CA’s. To do this a modify-certificates API is available that will allow you to override the default CA on newly created database instances to either the old or one of the new CAs. This override will only apply while the CA you are overriding to is valid. To use this API you will need to be running the AWS CLI version 1.17 or later. For more information see the modify-certificates API documentation [1]. There is also a describe-certificates API [5], that will indicate your current default CA override if you have one set. To set a specific CA during instance creation use the ca-certificate-identifier option on the create-db-instance API is available for you to create a DB instance with a specific CA. For more information, see the create-db-instance API documentation [6].