aws/rds: Switch AWS RDS CA bundle to the officially documented URL #3307
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi folks !
AWS recently started sending out emails about the expiration of the
rds-ca-2019
CA (expires in 2024), suggesting we upgrade our instance tords-ca-rsa2048-g1
,rds-ca-rsa4096-g1
, orrds-ca-ecc384-g1
.The corresponding documentation is here, and includes instructions as to client configuration and where to retrieve CA information.
I'm assuming the URL used here is a former address, and that AWS has since then changed the address of the reference CA bundle, without updating the bundle at the former address.
Reproduction
Creating RDS instances with both
rds-ca-2019
andrds-ca-ecc384-g1
, I can confirm that the new bundle works with both, while the old one only works withrds-ca-2019
. I have not, however, explicitly listed each certificate in the old bundle to see if it's present in the new one. We can double-check before merging if you wish so, I'm however assuming AWS would not remove still-valid CAs from its bundle.I'm not using go-cloud directly however, only indirectly through https://github.com/cyrilgdn/terraform-provider-postgresql, so, I haven't been able to test this change directly.
However, using psql with
sslrootcert
should be a good indicator that the issue is in fact here.