准备在 2020 年更新 AWS RDS public 证书 (Postgres)
Preparing for renewal of AWS RDS public certificate in 2020 (Postgres)
我有一个关于 Postgres 数据库的 Amazon rds-ca-2015-root 证书到期的问题，该证书已安排将于 2020 年 3 月 5 日到期。我想准备我的 java 客户端软件组件，以便在服务器切换到新的 2020 证书时它们的停机时间最短。当使用 SSL 验证服务器时，客户端使用带有 RDS 证书的 jks truststore。我假设 2020 年证书将在 30 天前左右提供，即 2020 年 2 月 5 日。
这是我认为我应该做的，我正在寻找一些确认这确实会像我预期的那样工作：
在到期之前的某个时间，使用包含 2015 证书和 2020 证书的信任库文件向客户端推送软件更新。客户端应该愉快地继续根据 2015 证书进行身份验证。新证书具有不同的 signature/fingerprint，因此不会匹配。应该忽略。
在到期之前，修改 RDS 实例以使用 2020 证书。需要重新启动服务器。然后，客户端将匹配 2020 证书，忽略签名不再匹配的 2015 证书。停机时间仅限于服务器重启。
稍后，使用删除 2015 证书的信任库向客户端推送新更新。
这是正确的做法吗？是否有任何理由认为在#1 中，java 客户端将尝试对 2020 证书进行身份验证但失败，因为它与相同的主题和颁发者匹配？或者相反，在 #3 中，由于相同的字段，他们尝试对 2015 证书进行身份验证但失败了？
我想换一种方式提出问题，客户端（java 或其他方式）是否可以持有两个 public 证书用于服务器身份验证，其中一个已过期或尚未生效，但两个引用相同的主题和发行者，如果亚马逊不轮换他们的密钥，甚至可能有相同的 public 密钥（尽管我认为最佳实践说他们会）。
是的，你完全正确。作为参考，我遇到了 Amazon RDS Customers: Update Your SSL Certificates，它证实了这个过程。证书参考来自 2015 年，但过程仍然相同。
关于在客户端存储中具有相同主题的两个有效证书，以及客户端如何匹配：
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.
见
由于 CA 不同，证书可以共存于同一个信任库中，并且它将解析为正确的证书。
在将 RDS 中的证书颁发机构升级到 rds-ca-2019 之前，在不中断连接的情况下，您可以在客户端升级证书。
如果你的 RDS 有 rds-ca-2015，你应该用这个升级客户端密钥
https://s3.amazonaws.com/rds-downloads/rds-combined-ca-bundle.pem.
根据 AWS 文档
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html
它说 rds-combined-ca-bundle.pem 文件同时具有中间证书和根证书。
一旦您的应用程序具有 combined-ca 文件，那么您应该继续将您的 RDS 升级到证书颁发机构 rds-ca-2019。
通过这种方式，您可以在不停机的情况下将 RDS 中的证书颁发机构升级到 rds-ca-2019。
我有一个关于 Postgres 数据库的 Amazon rds-ca-2015-root 证书到期的问题，该证书已安排将于 2020 年 3 月 5 日到期。我想准备我的 java 客户端软件组件，以便在服务器切换到新的 2020 证书时它们的停机时间最短。当使用 SSL 验证服务器时，客户端使用带有 RDS 证书的 jks truststore。我假设 2020 年证书将在 30 天前左右提供，即 2020 年 2 月 5 日。
这是我认为我应该做的，我正在寻找一些确认这确实会像我预期的那样工作：
在到期之前的某个时间，使用包含 2015 证书和 2020 证书的信任库文件向客户端推送软件更新。客户端应该愉快地继续根据 2015 证书进行身份验证。新证书具有不同的 signature/fingerprint，因此不会匹配。应该忽略。
在到期之前，修改 RDS 实例以使用 2020 证书。需要重新启动服务器。然后，客户端将匹配 2020 证书，忽略签名不再匹配的 2015 证书。停机时间仅限于服务器重启。
稍后，使用删除 2015 证书的信任库向客户端推送新更新。
这是正确的做法吗？是否有任何理由认为在#1 中，java 客户端将尝试对 2020 证书进行身份验证但失败，因为它与相同的主题和颁发者匹配？或者相反，在 #3 中，由于相同的字段，他们尝试对 2015 证书进行身份验证但失败了？
我想换一种方式提出问题，客户端（java 或其他方式）是否可以持有两个 public 证书用于服务器身份验证，其中一个已过期或尚未生效，但两个引用相同的主题和发行者，如果亚马逊不轮换他们的密钥，甚至可能有相同的 public 密钥（尽管我认为最佳实践说他们会）。
是的，你完全正确。作为参考，我遇到了 Amazon RDS Customers: Update Your SSL Certificates，它证实了这个过程。证书参考来自 2015 年，但过程仍然相同。
关于在客户端存储中具有相同主题的两个有效证书，以及客户端如何匹配：
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.
见
由于 CA 不同，证书可以共存于同一个信任库中，并且它将解析为正确的证书。
在将 RDS 中的证书颁发机构升级到 rds-ca-2019 之前，在不中断连接的情况下，您可以在客户端升级证书。
如果你的 RDS 有 rds-ca-2015，你应该用这个升级客户端密钥 https://s3.amazonaws.com/rds-downloads/rds-combined-ca-bundle.pem.
根据 AWS 文档 https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html 它说 rds-combined-ca-bundle.pem 文件同时具有中间证书和根证书。
一旦您的应用程序具有 combined-ca 文件，那么您应该继续将您的 RDS 升级到证书颁发机构 rds-ca-2019。
通过这种方式，您可以在不停机的情况下将 RDS 中的证书颁发机构升级到 rds-ca-2019。