letsencrypt

Let's Encrypt 支援 ACME-CAA，可以再進一步限縮可以申請的使用人

前幾天在 Hacker News 上看到 Let's Encrypt 支援 ACME-CAA 的新聞：「Let's Encrypt now supports ACME-CAA: closing the DV loophole (devever.net)」，原文在「Let's Encrypt now supports ACME-CAA: closing the DV loophole」。

先前的「RFC 6844 - DNS Certification Authority Authorization (CAA) Resource Record」已經先定義了 DNS 上 CAA record 的規範，另外在 CA/Browser Forum 的 Baseline Requirements 裡面也要求了 CA 簽發單位必須遵守 CAA 設定。

但這邊還是有一些風險，像是當網站被其他人控制後 (或是中間有 BGP hijacking 的方式取得 TCP 層的控制權)，控制人就可以透過 http-01 的方式通過認證申請到 SSL certificate。而這次 Let's Encrypt 實做的 ACME-CAA 則是試著降低這個風險。

第一個是 accounturi 參數，可以指定只有某個 CA 裡的某個帳號可以申請，像是這樣：

example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://some/lets-encrypt/account-id"

第二個是限制 validationmethods 參數，限制只有某些方式可以申請，像是這邊限制只能透過 dns-01 申請：

example.com. IN CAA 0 issue "letsencrypt.org; validationmethods=dns-01"

不過支援 http-01 的不只 Let's Encrypt，至少也還有 ZeroSSL 與 Buypass，後續可以看看其他家會不會跟上，以及會不會放到 Baseline Requirements 裡面...

Let's Encrypt 更新了 ToS

在「Let's Encrypt’s subscriber agreement changes on Sept 21 (letsencrypt.org)」這邊看到的，Let's Encrypt 有提供 diff 的內容，在「LE-SA-v1.2-v1.3-diff.docx」這邊，你也可以用 Google Docs Viewer 看：「LE-SA-v1.2-v1.3-diff.docx」。

看起來主要是用語上的改變 (可能是律師的建議？)，除了 revoke 的章節外看起來沒什麼大變化。而 revoke 的章節部份增加了這兩段文字：

You warrant to ISRG and the public-at-large, and You agree, that before providing a reason for revoking Your Certificate, you will have reviewed the revocation guidelines found in the “Revoking Certificates” section of the Let’s Encrypt documentation available at https://letsencrypt.org/docs/ , and that you will provide Your corresponding revocation reason code with awareness of such guidelines.

You acknowledge and accept that ISRG may modify any revocation reason code provided by You if ISRG determines, in its sole discretion, that a different reason code for revocation is more appropriate or is required by industry standards.

不確定自動化的 client 需不需要重新再 accept 一次？

Let's Encrypt 撤銷了兩百萬個以 tls-alpn-01 驗證的憑證

前幾天 Let's Encrypt 決定撤銷大約兩百萬個以 tls-alpn-01 簽發的憑證：「2022.01.25 Issue with TLS-ALPN-01 Validation Method」，在 Hacker News 上的討論「Issue with TLS-ALPN-01 Validation Method (letsencrypt.org)」也可以翻一下。

這次主要是有兩個修改，第一個是要 TLSv1.2 以上，不支援舊版的 TLS 驗證：

First, we now guarantee that our client which reaches out to conduct the “acme-tls/1” handshake will negotiate TLS version 1.2 or higher. If your ACME client or integration only supports a maximum TLS version of 1.1 when conducting the TLS-ALPN-01 challenge, it will break. We are not aware of any ACME clients with this limitation.

另外一個是淘汰掉 legacy OID：

Second, we no longer support the legacy 1.3.6.1.5.5.7.1.30.1 OID which was used to identify the acmeIdentifier extension in earlier drafts of RFC 8737. We now only accept the standardized OID 1.3.6.1.5.5.7.1.31. If your client uses the wrong OID when constructing the certificate used for the TLS-ALPN-01 handshake, it will break. Please either update your client, or switch to using a different validation method.

目前還是以 http-01 與 dns-01 為主，暫時不用管，但如果有人用 tls-alpn-01 的稍微注意一下吧...

DST Root CA X3 將在今天 22:01:15 過期

先前提到 Let's Encrypt 發出的憑證在 9/30 會產生問題，主因是 IdenTrust 的 DST Root CA X3 會在 9/30 過期，交叉簽名加上 OpenSSL 1.0.2 的判斷條件太嚴格導致的：「OpenSSL 1.0.2 與 Let's Encrypt 在這個月月底的相容性問題」。

本來以為是 UTC 的 2021/09/30 23:59:59 之類的時間，結果因為要面對這個問題，需要確認正確的時間，結果發現不是 UTC 的 2021/09/30 23:59:59，而是一個奇怪的時間：

Validity
    Not Before: Sep 30 21:12:19 2000 GMT
    Not After : Sep 30 14:01:15 2021 GMT

所以是 2021/09/30 22:01:15 (台灣時間) 會過期，今天晚上可以看一下情況...

OpenSSL 1.0.2 與 Let's Encrypt 在這個月月底的相容性問題

看到 OpenSSL 的官方居然特地寫一篇與 Let's Encrypt 的相容性問題：「Old Let’s Encrypt Root Certificate Expiration and OpenSSL 1.0.2」。

這邊提到的 OpenSSL 1.0.2 很舊了 (在 Ubuntu 16.04 內是 1.0.2g)，理論上大多數的機器應該不太會遇到這個問題。

問題出自 Let's Encrypt 舊的 DST Root CA X3 將在這個月月底過期，這在 Let's Encrypt 的「DST Root CA X3 Expiration (September 2021)」這邊也有提到。

The currently recommended certificate chain as presented to Let’s Encrypt ACME clients when new certificates are issued contains an intermediate certificate (ISRG Root X1) that is signed by an old DST Root CA X3 certificate that expires on 2021-09-30.

理想上只有要任何一條 trust chain 成立，就應該會把這個憑證認為是合法的憑證，但這在 OpenSSL 1.0.2 (以及之前的版本) 不是這樣設計。

舊版的設計是只要有任何一條過期的憑證，就會把憑證認為過期而失效：

Unfortunately this does not apply to OpenSSL 1.0.2 which always prefers the untrusted chain and if that chain contains a path that leads to an expired trusted root certificate (DST Root CA X3), it will be selected for the certificate verification and the expiration will be reported.

OpenSSL 官方給了三個 workaround 可以做，另外我還有想到一個惡搞方式，是可以用其他家免費的憑證... 不過也是得測看看在 OpenSSL 1.0.2 下會不會動。

關於各家 ACME client (或者說 Let's Encrypt client？)

在「Another free CA as an alternative to Let's Encrypt (scotthelme.co.uk)」這邊引用的文章本來在討論又多了一家免費的 SSL certificate 可以用，但結果討論的主力都在講除了 Certbot 外還有什麼比較好用...

大家之所以厭惡 Certbot，先不講他需要依賴一堆 Python 的套件包，最主要的問題在於現在 Certbot 官方建議的指引裡面都要求你裝 Snap，而 Snap 這東西超級吃資源...

既然是資源問題，裡面可以看到 Dehydrated 又被拿出來推薦了，另外也有提到 acme.sh，不過我個人不太愛 acme.sh，主要是預設值跑去用 ZeroSSL 的 CA。

這種單檔就可以跑的很適合包進像是 Ansible 這類的管理工具，至少目前用起來沒什麼大問題...

Dehydrated 取得憑證的預設演算法改成 secp384r1

這兩天弄 dehydrated，結果發現 v0.7.0 取得憑證的預設演算法改成 ECC 的 secp384r1 了：

Using EC secp384r1 as default certificate type

這會導致很多「稍微舊一點」的 client 失效 (瀏覽器與 library)，不知道為什麼要預設... 目前避開的方法是強制在 /etc/dehydrated/config 內設定使用 rsa：

KEY_ALGO=rsa

剛剛把公司一堆機器改上去，然後把自己的 server 也加一加...

Let's Encrypt 升級資料庫伺服器 (AMD YES？)

Let's Encrypt 升級了 MariaDB 資料庫的伺服器 (跑 InnoDB)，特地寫了一篇文章出來講：「The Next Gen Database Servers Powering Let's Encrypt」。

CPU 的部份從本來的 2x Intel Xeon E5-2650 (Total 24 cores / 48 threads) 換成了 2x AMD EPYC 7542 (Total 64 cores / 128 threads)，這點在本來就是 CPU 滿載的情境下改善很大：

而本來的瓶頸一解決，也使得 API 的 latency 直接降下去：

回頭看一下架構，可以看到他們提到沒有使用分散式的資料庫，而是單台 database 硬撐，驗證了即使到了 Let's Encrypt 這種規模，以暴制暴還是很有效的：

We run the CA against a single database in order to minimize complexity. Minimizing complexity is good for security, reliability, and reducing maintenance burden. We have a number of replicas of the database active at any given time, and we direct some read operations to replica database servers to reduce load on the primary.

除了 CPU 暴力外，2TB RAM 與 24 顆 NVMe SSD 的搞法也是很讚的，擺明就是用記憶體拼 cache 的量，以及用大量的 NVMe SSD 疊 IOPS。

然後硬體還在成長，看起來暴力解應該會變成以後的基本答案了...

IdenTrust 願意再幫 Let's Encrypt 交叉簽三年

先前在「Let's Encrypt 在 Android 平台上遇到的問題」這邊提到了 IdenTrust 幫 Let's Encrypt 交叉簽名的有效日會在 2021 年的八月底左右到期，而這會導致比較舊的 Android 平台因為沒有內建 ISRG Root X1 這個憑證，造成 Let's Encrypt 簽出來的憑證在這些舊的 Android 裝置上都認不出來。

文章出來過了一個多月後，剛剛看到 Let's Encrypt 發佈消息，IdenTrust 願意再交叉簽名三年：「Extending Android Device Compatibility for Let's Encrypt Certificates」，當時猜測發文是要讓 IdenTrust 表態，看起來目的達成了...

話說中間跑出來的「ZeroSSL 也提供免費的 SSL Certificate (DV) 了」不知道後續會怎麼樣，之後可以看看 Certificate Transparency 的資料來看看到底有多少人用...

Dehydrated 使用 ZeroSSL 的方式

上一篇「ZeroSSL 也提供免費的 SSL Certificate (DV) 了」提到 ZeroSSL 的服務，而各家 acme client 也都陸陸續續支援了。

Dehydrated 是在 2020/09/15 的時候實做：「EAB + ZeroSSL support」，我就抓了個新版，更新之前自己包的 PPA dehydrated-lite...

Dehydrated 的設定方式還蠻簡單的，在 /etc/dehydrated/config 裡面這樣寫：

CA=zerossl
EAB_HMAC_KEY=x
EAB_KID=y

其中兩個 EAB 的資訊可以在 ZeroSSL 網站上面取得，然後其他就照舊跑...