1
votes

I have a question related to the expiration of the Amazon rds-ca-2015-root certificate for Postgres databases which is scheduled to expire Mar 5 of 2020. I would like to prepare my java client software components so they have minimal downtime when the server switches to the new 2020 certificate. The clients use a jks truststore with the RDS certificate when authenticating the server with SSL. I'm assuming the 2020 certificate will be made available 30 days prior or so, i.e. Feb 5 of 2020.

This is what I think I should do, and I'm looking for some confirmation that this will indeed work as I expect:

  1. Sometime prior to the expiration, push a software update to the clients with a truststore file containing both the 2015 certificate and the 2020 certificate. The client should continue happily along authenticating against the 2015 certificate. The new cert has a different signature/fingerprint and will not match. It should be ignored.

  2. Just prior to the expiration, modify the RDS instance to use the 2020 certificate. Requires server reboot. Clients will then match against the 2020 certificate, ignoring the 2015 certificate whose signature no longer matches. Downtime is limited only to the reboot of the server.

  3. Sometime later, push a new update to the clients with a truststore removing the 2015 certificate.

Is this the correct approach? Is there any reason to think in #1, the java clients will try and fail to authenticate against the 2020 certificate instead because it is matching against the same Subject and Issuer? Or conversely, in #3, they try and fail to authenticate against the 2015 certificate because of the identical fields?

I guess to put the question another way, can a client (java or otherwise) hold two public certificates for server authentication, where one is either expired or not yet valid, yet both refer to the same subject and issuer, and potentially even have the same public key if Amazon doesn't rotate their keys (although I would assume best practice says they will).

2

2 Answers

0
votes

Yes you have it all correct. For reference, I came across Amazon RDS Customers: Update Your SSL Certificates which confirms the process. The cert references are from 2015, but the process is still the same.

Regards to having two valid certs in the client store with the same subject, and how the client matches:

The verification is done by building a certification path, by chaining the Issuer DN (Distinguished Name) of the certificate to verify to the Subject DN of a CA certificate you trust.

See In SSL how a certificate is matched/found in truststore?

Since the CAs are different, the certs can coexist in the same truststore, and it will resolve to the correct cert.

0
votes

Before upgrading Certificate authority in RDS to rds-ca-2019, without connection interruption, you can upgrade certificate on client-side.

If your RDS has rds-ca-2015, you should upgrade client-side key with this https://s3.amazonaws.com/rds-downloads/rds-combined-ca-bundle.pem.

As per AWS document https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html It says rds-combined-ca-bundle.pem file has both certs intermediate and root.

Once your applications have combined-ca file then you should proceed to upgrade your RDS to Certificate authority rds-ca-2019.

This way without downtime you can upgrade Certificate authority in RDS to rds-ca-2019.