java - stunnel - 如何不间断地更换服务器证书

Question

我正在尝试了解用于在 stunnel 上到期时更换证书的程序。所以我在 Windows 上安装了一个简单配置的 stunnel:

[test1]
accept = 127.0.0.1:21234
connect = 127.0.0.1:21235
cert = p1.pem

p1.pem 文件具有以下结构:

-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQD1f+2n88ThTvLn ....
-----END PRIVATE KEY-----

-----BEGIN CERTIFICATE-----
MIIEFjCCAv6gAwIBAgIUHD/p+ctiyaWxZCd1LiFqC5vzKGQwDQYJKoZIhvcNAQEL ....
-----END CERTIFICATE-----

使用 java 客户端应用程序，我可以成功打开到端口 21234 的 SSL 连接。

p1.pem 证书是使用 openssl 创建的自签名证书。在 p1.pem 证书过期之前，我们需要有一段时间服务器可以接受两个证书(例如 p1.pem 和 p2.pem)。

我尝试将这两个文件连接成 p1p2.pem 结构:

-----BEGIN PRIVATE KEY-----
p1 key
-----END PRIVATE KEY-----

-----BEGIN CERTIFICATE-----
p1 cert
-----END CERTIFICATE-----

-----BEGIN PRIVATE KEY-----
p2 key
-----END PRIVATE KEY-----

-----BEGIN CERTIFICATE-----
p2 cert
-----END CERTIFICATE-----

当我尝试使用相同的 java 客户端应用程序时，它使用 p1 的公共(public)证书，但使用 p2 的公共(public)证书，它返回:

Exception in thread "main"
javax.net.ssl.SSLHandshakeException:sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find v alid certification path to requested target at
sun.security.ssl.Alerts.getSSLException(Unknown Source) at
sun.security.ssl.SSLSocketImpl.fatal(Unknown Source) at
sun.security.ssl.Handshaker.fatalSE(Unknown Source) at
sun.security.ssl.Handshaker.fatalSE(Unknown Source) at
sun.security.ssl.ClientHandshaker.serverCertificate(Unknown Source) at
sun.security.ssl.ClientHandshaker.processMessage(Unknown Source) at
sun.security.ssl.Handshaker.processLoop(Unknown Source) at
sun.security.ssl.Handshaker.process_record(Unknown Source) at
sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source) at
sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source) at
sun.security.ssl.SSLSocketImpl.writeRecord(Unknown Source) at
sun.security.ssl.AppOutputStream.write(Unknown Source) at
java.io.OutputStream.write(Unknown Source) at clt.main(clt.java:16) Caused by:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at
sun.security.validator.PKIXValidator.doBuild(Unknown Source) at
sun.security.validator.PKIXValidator.engineValidate(Unknown Source) at
sun.security.validator.Validator.validate(Unknown Source) at
sun.security.ssl.X509TrustManagerImpl.validate(Unknown Source) at
sun.security.ssl.X509TrustManagerImpl.checkTrusted(Unknown Source) at
sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(Unknown Source) ... 10 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target at
sun.security.provider.certpath.SunCertPathBuilder.build(Unknown Source) at
sun.security.provider.certpath.SunCertPathBuilder.engineBuild(Unknown Source) at
java.security.cert.CertPathBuilder.build(Unknown Source) ... 16 more

Answer 1

TLDR:您无法转换服务器

一个 TLS 服务器，包括 stunnel，一次只使用一个证书和 key ，或者可选地每个 SNI(即主机域名)使用一个证书和 key 如果客户端发送 SNI，浏览器总是这样做(至少从 2010 年开始)和 最近 版本的 Java(IIRC 某处 8 月中旬以上)通常 这样做，但这可能取决于代码如何设置和打开 SSLSocket，它你不显示或描述。 (如果可能的话要查看网络跟踪(如果在 Windows 上可能不是用于环回/本地主机)或使用 sysprop javax.net.debug=ssl,handshake 运行 Java 并查看。)这是因为客户端不向服务器提供任何关于它“想要”哪个 CA 或其他证书的信息；在 1.2 和 1.3 中，它可以指定它将接受的签名算法，但这通常不会区分旧证书和新证书。

stunnel 特别是仅使用 cert=(或 key=，如果指定)文件中的 first 私钥，虽然它可以使用cert= 文件中的多个 chain 证书，它仅使用第一个作为 entity 证书，同时用于给定的“服务”和 SNI。并且您的 p2.cert 可能不是 p1.cert 的有效链证书，因此您发布的 stunnel 配置始终使用 p1.key 和 p1.cert。如果“... java 客户端应用程序...使用 p2 的公共(public)证书”意味着您将 p2 而不是 p1 放入客户端的信任库中，那么客户端当然不会验证与使用 p1 的服务器的连接.

更新或以其他方式转换(服务器)证书的正常方法是在长期 CA 下使用 CA 颁发的证书，以便服务器可以颁发新的证书证书和客户端将信任它，因为 CA 继续有效并且没有过期。

如果您必须更换自签名证书，唯一能最大限度减少中断的方法是:

1. 将客户端或所有客户端配置为接受旧证书和新证书(这可能涉及也可能不涉及暂时关闭每个客户端，但可以在不同时间完成多个客户端，特别是如果它们是一个池或集群或以其他方式共同提供某种高可用性功能)

2. 然后将服务器从旧服务器更改为新服务器(stunnel 可以在不关闭的情况下重新加载)，

3. 然后可选地从客户端中删除旧的(如有必要，这可以等到他们下一次因其他原因停机，甚至等到下一次证书更换)。

但您可能不需要。假设您使用的是具有正确含义的“自签名”——使用它包含的相同 key 签名的证书，而不是仅由您签名，因此必须在客户端信任库中进行配置，因为它上面没有可用于验证它的证书——然后通过我测试一个默认的 Java 客户端(即，一个使用默认 validator ，正如您的代码明确所做的那样，并且不在外部添加任何其他验证，我们无法从此处得知)，那么它将接受一个信任库中的自签名证书即使过期。 (奇怪的是，因为官方 API CertPathValidator 确实 拒绝了它。稍后我将尝试对此进行更多研究。)设置测试机(可能是虚拟机，所以你不会冒损坏任何重要文件的风险)并提前它的日期，看看它是否有效，你可能会避免整个问题。