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 ForumBaseline 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,至少也還有 ZeroSSLBuypass,後續可以看看其他家會不會跟上,以及會不會放到 Baseline Requirements 裡面...

Amazon CA 在 renew 時將引入動態的 Intermediate CA

上個月 AWS 發的公告,其實已經生效了,但整理的時候才發現還沒寫:「Amazon introduces dynamic intermediate certificate authorities」。

先介紹一下 Amazon CA,這是 Amazon 自己維護的 Root CA,有走過 CA/Browser Forum 的規範與稽核,以及各家瀏覽器額外的要求,所以是個用戶端預設都有信任的 CA。

這個服務後來也被用在 AWS Certificate Manager (ACM) 上,由 ACM 申請到的憑證也都可以掛到 AWS 的各種服務上。

通常 root CA 的憑證不會直接拿來簽最終使用者使用的憑證 (leaf certificate),而是 root CA 的憑證先簽 intermediate CA 的憑證,然後 intermediate CA 可能有好幾層一路簽下來,到最後面再用 intermediate CA 的憑證簽最終使用者使用的憑證。

這次公告的內容就題到了,之前的 intermediate CA 是一個固定範圍的量,而且會確保 renew 時用的 intermediate CA 跟先前的是相同的:

Before this change, Amazon maintained a limited number of intermediate CAs and issued and renewed certificates from the same intermediate CAs.

這次則是會變成動態:

With this change, leaf certificates issued to you will be signed by different intermediate CAs.

生效日期是這個月十一日,其實已經生效了:

Starting October 11, 2022 at 9:00 AM Pacific Time, public certificates obtained through ACM will be issued from one of the multiple intermediate CAs that Amazon manages.

一般的用戶端 (像是瀏覽器) 基本上應該是不會有問題,因為大多數預設都是信任 root CA,而非 intermediate CA,而這次的改變還是可以從 root CA 產生出對應的 trust chain。

官方有提到一個有可能的情況:如果你的應用程式有設定 certificate pinning 的話,應該是對 root CA 設定,而非對 intermediate CA 或是 leaf 做:

If you use intermediate CA information through certificate pinning, you will need to make changes and pin to an Amazon Trust Services root CA instead of an intermediate CA or leaf certificate.

這個也算通則,因為就 certificate pinning 想要做到的效果,對 root CA 做就就行了...

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

先前提到 Let's Encrypt 發出的憑證在 9/30 會產生問題,主因是 IdenTrustDST 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 這類的管理工具,至少目前用起來沒什麼大問題...

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

先前在「Let's Encrypt 在 Android 平台上遇到的問題」這邊提到了 IdenTrustLet'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 的資料來看看到底有多少人用...

ZeroSSL 也提供免費的 SSL Certificate (DV) 了

Facebook 上被朋友敲可以測 ZeroSSL,另外一個透過 ACME 協定提供免費的 SSL Certificate,不過目前只有支援單一網域名稱 (DV):「Another free CA as an alternative to Let's Encrypt (scotthelme.co.uk)」。

我先前就有在測 ZeroSSL,不過驗證一直過不去,當時有在 Twitter 上找 ZeroSSL 帳號問,但 ZeroSSL 的人說 ACME 的部份不在客服範圍,就先丟著...

剛剛發現是自己耍笨了,原因是 nginx 沒設好造成驗證卡住,一改好後就正常了。

SSL LabsSSL Server Test 翻了一下,他的 Root CA 看起來歷史更久,應該是有機會解決 Let's Encrypt 明年會產生的 Root CA 憑證信任問題,也就是先前在「Let's Encrypt 在 Android 平台上遇到的問題」提到的問題,在 Hacker News 上的討論也可以看到有人提到這點:

Good to know, and I'm glad there's an alternative to Let's Encrypt, just in case. Is ZeroSSL trusted by old Android devices? If so, that might be a work-around for Let's Encrypt's cross-signing from IdenTrust expiring.

不過也有些人有疑慮,畢竟提供這個服務後面的公司幹過不少壞事:

If zerossl is reselling/a subsidiary of sectigo, that’s enough reason to never use this.
Sectigo is the new name for Comodo. The same bunch of pricks who tried to trademark “Let’s Encrypt”.

Other players in the acme cert “business” is great. Renaming a slime ball name and carrying on like nothing happened is not ok.

但看起來至少是多了一個選擇...

Firefox 試著透過預載 Intermediate CA 降低連線錯誤發生的機率?

在「Preloading Intermediate CA Certificates into Firefox」這邊看到 Mozilla 的人打算在 Firefox 上預載所有的 Intermediate CA,以降低 HTTPS 連線發生錯誤的作法。這點在 Mozilla 的 Wiki 上也有記錄:「Security/CryptoEngineering/Intermediate Preloading」。

的確如文章裡說的,沒有正確放入 Intermediate CA 是個 server 設定上很常見的錯誤。像是前幾天看到「【茶包射手日記】網站憑證無效案例分析」這篇講的摩斯 https://www.mos.com.tw/ 其實就是這個案例,用 SSL Labs 的工具就可以掃出來問題:「SSL Report: www.mos.com.tw (210.59.225.242)」。

問題出在於沒有送出正確的 Intermediate CA(s),所以在 Android 上找不到一條完整的 trust chain:

不過在 Windows 系統內的 CA store 是可以建立出一條完整的 trust chain,所以 Windows 上的 Microsoft EdgeGoogle Chrome 是不會有問題的 (這兩個都吃系統的 CA store):

Linux 上的 Google Chrome 就會出問題 (這邊會吃 Google 自家的 CA store 資料,就是 Android 那包)。

交叉比對中華電信自家的網站,像是「SSL Report: www.cht.com.tw (2001:b000:1a4:d000:203:75:129:111)」這組,可以看到同樣都叫做「Chunghwa Telecom Co., Ltd. / Public Certification Authority - G2」的 Intermediate CA,但有兩種不同的 SHA256,可以翻到是:「609930eb807ad420afda2a8aa61b67483039168cd766e09942a48bfe7f3bdc10」與「f5fb67c8453eda34dbec8a766574f07a03548c084af2f5e6455ea769608d9ad5」,點入裡面的「Trust」tab 中可以看到中華自己的 CA 與 ePKI 的 CA 都有交叉簽,但卻不是每一個 CA 都有被所有瀏覽器認可,所以在設定的時候就得注意...

話說回來,現在因為 CA/B Forum 的標準有強制要送 CT (Certificate Transparency),的確是有辦法抓出所有的 Intermediate CA 沒錯,但瀏覽器幫使用者預載感覺好像怪怪的?

In essence, Firefox pre-downloads all trusted Web Public Key Infrastructure (PKI) intermediate CA certificates into Firefox via Mozilla’s Remote Settings infrastructure. This way, Firefox users avoid seeing an error page for one of the most common server configuration problems: not specifying proper intermediate CA certificates.

目前大約有 2000 筆資料:

Given this information, we periodically synthesize a list of these intermediate CA certificates and place them into Remote Settings. Currently the list contains over two thousand entries.

這個比較像是 client 端的 hack?

Let's Encrypt 在 Android 平台上遇到的問題

同樣是「Standing on Our Own Two Feet」這篇文章,Let's Encrypt 預期明年九月後會在 Android 上遇到嚴重的相容性問題。

很舊的裝置主要是透過 IdenTrust 的 Root CA (DST Root CA X3) 對 Let's Encrypt 的 Intermediate CA (目前主要是 Let's Encrypt Authority X3) 簽名,從而建立憑證的信任鍊,而新的裝置除了 IdenTrust 的 CA 外,也信任了 Let's Encrypt 自家的 Root CA (ISRG Root X1):(出自「Chain of Trust」)

在 2016 年四月正式對外啟用時主要是靠 IdenTrust 的 cross-sign,而也是在 2016 年時 Let's Encrypt 自家的 Root CA (ISRG Root X1) 陸陸續續被各家收進 CA store。

所以這個時間點之前的 Android (大約是 7.1.1) 算是個相容性的分界線,在這個版本前 (而且系統無法更新的) 都只能靠 IdenTrust 的 cross-sign,這看起來大約有 33.8%,實際的流量大約是 1%~5%:

Currently, 66.2% of Android devices are running version 7.1 or above. The remaining 33.8% of Android devices will eventually start getting certificate errors when users visit sites that have a Let’s Encrypt certificate. In our communications with large integrators, we have found that this represents around 1-5% of traffic to their sites. Hopefully these numbers will be lower by the time DST Root X3 expires next year, but the change may not be very significant.

目前還有大約十個月左右的緩衝期,但大家都知道 Android 的更新速度,就十個月來說看起來不太樂觀...

官方有給他們不願意再取得一次 cross-sign 的原因,不過我覺得這個理由就很怪了,這個描述看起來是 IdenTrust 不願意再簽發一次?直覺覺得 IdenTrust 站在商業立場應該是很願意才對?而且除了 IdenTrust,應該也有其他家會有興趣?

Can we get another cross-signature? We’ve explored this option and it seems unlikely. It’s a big risk for a CA to cross-sign another CA’s certificate, since they become responsible for everything that CA does.

也有可能是放個話讓 IdenTrust 表態?先繼續看下去...

最差的情況應該就是沒有 cross-sign,然後也沒提供其他的 workaround,這樣就是買一般的 SSL certificate 來解了...