主页 / server / 问题 / 1079199
Accepted
P.Péter
Asked: 2021-10-01 08:40:25 +0800 CST

Debian 9 上的客户端错误地报告 letencrypt 颁发的域的过期证书

  • 772

如果我尝试从 debian 9 访问具有 certbot 颁发的证书的 HTTPS 服务器，我会收到以下错误：

 # curl -v https://hu.dbpedia.org/
 *   Trying 195.111.2.82...
 * TCP_NODELAY set
 * Connected to hu.dbpedia.org (195.111.2.82) port 443      (#0)
 * ALPN, offering h2
 * ALPN, offering http/1.1
 * Cipher selection:      ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
 * successfully set certificate verify locations:
 *   CAfile: /etc/ssl/certs/ca-certificates.crt
   CApath: /etc/ssl/certs
 * TLSv1.2 (OUT), TLS header, Certificate Status (22):
 * TLSv1.2 (OUT), TLS handshake, Client hello (1):
 * TLSv1.2 (IN), TLS handshake, Server hello (2):
 * TLSv1.2 (IN), TLS handshake, Certificate (11):
 * TLSv1.2 (OUT), TLS alert, Server hello (2):
 * SSL certificate problem: certificate has expired
 * Curl_http_done: called premature == 1
 * stopped the pause stream!
 * Closing connection 0
 curl: (60) SSL certificate problem: certificate has expired

但是，如果我从 debian 10 尝试相同的命令，它会成功。

我尝试使用 rsync 简单地将所有 ca-certificates 从 debian 10 VM 复制到 debian 9 VM（到 /usr/local/share/ca-certificates），然后运行update-ca-certificates似乎添加了 400 多个证书。不幸的是，它没有帮助。这并不奇怪，因为显然 debian 9 和 10 上似乎有相同的证书。

我的问题是：如何在不完全忽略证书验证的情况下从 debian 9 机器访问带有 certbot 证书的站点

debian ssl-certificate lets-encrypt debian-stretch

6 个回答

  1. Best Answer

    首先，Debian 9 已停产。但由于客户可能不受您的控制，您当然可能想在这种破坏中迎合他们。

    我认为虽然问题只提到certbot了，但它实际上是关于 Letsencrypt 的。
    （该工具certbot本身是一个 ACME 协议客户端，它也与其他基于 ACME 的 CA 一起使用，因此这里有一些混淆的空间。）

    手头的问题似乎是以下组合：

    • 旧的 Letsencrypt 根（“DST Root CA X3”）已过期
    • 新的默认LE 链试图通过呈现链的可选扩展来“额外兼容”，其中新根（“ISRG Root X1”）作为旧根的交叉签名中间体呈现（因为非常旧的 Android 版本仍然接受过期的根，但没有新的根）
    • Openssl 1.0 有一个错误，导致它只尝试它看到的第一个链，如果它不喜欢这样，它不会考虑任何其他可能性（即，以 X1 结尾的较短的新链与较长的“兼容性”扩展通过 X1 到 X3 的那条链）。
    • Debian 9 上的 libcurl3链接到 libssl 1.0

    如果您改为提供不尝试额外兼容的新 LE 证书链，只是在新根 (X1) 处结束，它允许 libssl 1.0 工作（但随后您会失去与真正旧 Android 的兼容性）。

    除此之外，其他 CA（ACME 或其他）可能是可以考虑的选项。

    • 26

  2. 警告！请规划操作系统升级路径。以下建议应仅在紧急情况下应用，以快速修复关键系统。

    以下解决方案适用于 Debian Jessy 8，也应该适用于 Stretch 9 缺少更新。我刚刚在docker run -it debian:jessie bash,上测试过apt-get update && apt-get install curl。

    前：

    # curl -I https://hu.dbpedia.org
curl: (60) SSL certificate problem: certificate has expired
More details here: http://curl.haxx.se/docs/sslcerts.html
....

    首先检查您是否存在违规的 DST Root CA X3 证书：

    # grep X3 /etc/ca-certificates.conf 
mozilla/DST_Root_CA_X3.crt

    旧的 Debian 版本也有正确的 ISRG Root X1：

    # grep X1 /etc/ca-certificates.conf 
mozilla/ISRG_Root_X1.crt

    这将禁用 X3：

    # sed -i '/^mozilla\/DST_Root_CA_X3/s/^/!/' /etc/ca-certificates.conf && update-ca-certificates -f

    您的域对 curl 的响应很好：

    # curl -I https://hu.dbpedia.org/
HTTP/1.1 200 OK
...

    再次，请计划升级。

    • 26

  3. DST 根 CA X3 根证书于 2021 年 9 月 30 日 14:01:15 GMT 过期。它被用作 Let's Encrypt 证书的认证路径之一 旧 cURL 版本有一个错误，会导致过期的根连接失败，而不是尝试本地 ca 存储中的其他根。

    截至 2021 年 9 月 30 日，用于 curl 的 ca 存储 ( https://curl.se/docs/caextract.html ) 仍包含过期的 DST Root CA X3 根证书，因此更新它不会解决问题。您可以更新您的 cURL（在某些情况下可能非常具有挑战性）或编辑本地 ca 存储（fe /etc/pki/tls/certs/ca-bundle.crt）并在“DST Root CA X3”行之后手动删除证书

    • 5

  4. 我刚刚在使用基于 Debian Stretch 的 Docker 映像时遇到了这个问题。解决方案很简单，我想 Debian 已经修补libssl1.0.2以修复 Håkan 提到的链选择问题。就我而言，仅更新证书并libssl1.0.2通过运行apt install -y libssl1.0.2 ca-certificates（apt update预先使用容器）就足够了。

    • 2

  5. 对于 Debian 8 和 9，我这样做只是为了更新主机上的证书，不再出现错误 60：SSL 证书问题：证书已过期： https ://github.com/xenetis/letsencrypt-expiration

    只需运行，它应该可以工作：

    wget -O - https://raw.githubusercontent.com/xenetis/letsencrypt-expiration/main/letsencrypt-expiration.sh | bash
    • 2

  6. 按照 Nicolo 的回答1，我在老化的 Debian 9 服务器上运行了脚本，但仍然收到相同的证书过期错误。update-ca-certificates手册页说

    此外，在 /usr/local/share/ca-certificates 下找到的所有扩展名为 .crt 的证书也被包含为隐式受信任的。

    截至今天，他共享的脚本将 ISRG & Let's Encrypt 证书下载为.pem文件，因此update-ca-certificates 不会自动包含它们。在对这些.pem文件建立软链接但带有.crt扩展名后，update-ca-certificates再次运行确实包含它们并且过期的证书错误消失了。谢谢您的回答！

    • 1

相关问题