Debian 9 上的客戶端錯誤地報告 letencrypt 頒發的域的過期證書

如果我嘗試從 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 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 或其他）可能是可以考慮的選項。

引用自：https://serverfault.com/questions/1079199