Let's Encrypt 证书将在 90 天后过期。有自动更新工具（用有效期为 90 天的新证书替换过期证书）。有没有方法可以 100% 顺利地完成此更改，而不会出现链接中断、SSL 握手失败、证书消息错误等情况？
答案1
答案是“这取决于服务器应用程序是否编写正确”，但我认为前提问题是错误的。
@Ramhound 好的，但某一时刻，当前证书文件将被新证书替换。如果此时正在进行 SSL 握手，则可以使用新旧证书或类似的东西。我不知道证书使用的所有细节，但我猜如果证书替换没有经过特殊处理（在 OpenSSL、Web 服务器等中），至少一个 SSL 连接可能会中断。有人可能会说 1-2 个断开的连接损失不大，但如果可以避免这种情况会更好。– i486
但事实并非如此。TLS 库不会每次都重新读取证书文件——它只会读取一次文件，并在整个握手过程中使用内存中的表示。事实上，TLS 库通常甚至不会注意除非程序明确指示其重新读取这些文件，否则证书已更新。对于大多数基于 TLS 的守护程序，您需要在每次证书更新后明确触发配置重新加载。
完成后，新证书数据通常会加载到新的内存位置和任何合适的 TLS 库仍将在需要完成待处理的握手期间保留旧数据，仅在进行新连接时进行切换。
（例如：OpenSSL 使用“上下文”对象——一个用于构建连接的模板，并且SSL_CTX_use_certificate（）似乎明确地记录了对上下文的任何更改都不会影响现有的连接实例，尽管GitHub 上的相关讨论因此程序可能会选择完全创建一个新的上下文以确保安全。
类似地，在 GnuTLS 中，加载新证书将分配一个新的gnutls_certificate_credentials_t而现有的会话将继续使用旧的会话。）
所以您所说的“特殊处理”已经存在并由 API 强制执行；它已经是处理事情的正常方式。
注意全部TLS 证书最终会过期，并且全部需要更新和替换 - 这并不是 Let's Encrypt 独有的。事实上，这种情况通常是更差对于长期手动配置的证书，因为这些证书通常在过期后几小时或几天才更新（并且在有人注意到新连接已经显示警报之后），而通常的 LE 自动化会在过期前至少两周进行更新。