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:
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.
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.
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).