Let's Encrypt 簽發新的 Intermediate CA

Let's Encrypt 宣佈簽發新的 Intermediate CA:「New Intermediate Certificates」。

這次用 ISRG Root X1 簽了很多東西出來:

On Wednesday, March 13, 2024, Let’s Encrypt generated 10 new Intermediate CA Key Pairs, and issued 15 new Intermediate CA Certificates containing the new public keys.

ISRG Root X1 簽了五組 2048-bit RSA 的 intermediate CA,被叫做 R10~R14:

We created 5 new 2048-bit RSA intermediate certificates named in sequence from R10 through R14. These are issued by ISRG Root X1. You can think of them as direct replacements for our existing R3 and R4 intermediates.

另外 ISRG Root X1 也簽出五組 P-384 ECDSA 的 intermediate CA,被叫做 E5~E9;另外 ISRG Root X2 也簽了 E5~E9:

We also created 5 new P-384 ECDSA intermediate certificates named in sequence from E5 through E9. Each of these is represented by two certificates: one issued by ISRG Root X2 (exactly like our existing E1 and E2), and one issued (or cross-signed) by ISRG Root X1.

所以總共是產生了 10 組 intermediate certificate,然後簽了 15 組 intermediate CA 出來。

另外這邊有個比較特別的是 ISRG Root X1 (RSA 4096) 也簽了 ISRG Root X2 (ECDSA P-384),理論上 ISRG Root X2 這組後續應該也會開始放到各家的 root store 裡面...

用官方的圖可以說明這些關係:

目前還沒上線,先簽出來並且公告,後續才會切換過去。

另外在紋章裡面提到了 app 應該避免對 intermediate certificate 鎖定 (key pinning):

We are very hopeful that these steps will prevent intermediate key pinning altogether, and help the WebPKI remain agile moving forward.

Intermediate CA 在安全理由上是需要定時更換的,真的要做的話,應該是對 Root CA 做比較好。

Firefox 與 Chrome 處理 Intermediate CA 的不同方式

Fediverse 上看到「The recording of my "Browsers biggest TLS Mistake" lightning talk at #37C3」這個,這是出自 37C3 的 lightning talk,影片不長,只有五分鐘,可以在「Browsers biggest TLS mistake」這邊看到。

正常的 HTTPS server 會送出 Intermediate CA certificate 與自己的 TLS certificate:

當伺服器端沒有設定好,通常是只送出自己的 TLS certificate:

這種情況在 Firefox 裡有處理,軟體本身會預載所有的 Intermediate CA 避免這種問題 (當然會需要跟著軟體更新),這點在三年前有提到過:「Firefox 試著透過預載 Intermediate CA 降低連線錯誤發生的機率?」,也就是這張投影片提到的情況:

Chrome 則是去看目前的 cache 資料,找看看是不是在其他地方有看到適合的 Intermediate CA 可以接起來:

這好像可以解釋為什麼之前遇到類似的問題的時候,在 Chrome 上面會需要進 chrome:// 裡面清東西才能重製...

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 (台灣時間) 會過期,今天晚上可以看一下情況...

Squid + GnuTLS 不支援 Intermediate Certificate 的問題

先前在「架設 Proxy over TLS」這邊提到了我用 Squid 架 Proxy over TLS 的服務起來用,本來在家裡跑得好好的,但到了公司發現卻不能用,追蹤後發現是目前 Ubuntu 裡面包的 Squid + GnuTLS 沒有辦法支援 intermediate certificate 的問題,而且有人問過了:「[squid-users] HTTPS_PORT AND SSL CERT」。

這邊先講測試的方法,然後後面再講解法。

測試的方式可以用 openssl s_client -connect hostname:port 測,正常的情況會可以看到兩層。

在這邊的例子裡,R3 簽了 home.gslin.orgDST Root CA X3 簽了 R3,而 DST Root CA X3 則在 root certificate 名單中:

$ openssl s_client -connect home.gslin.org:443
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = home.gslin.org
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:CN = home.gslin.org
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---

如果沒有送出 Intermediate Certificate 的話就會導致信任鏈無法建立,像是我故意設計的 nointermediate.gslin.com 這樣,R3 簽了 nointermediate.gslin.com,但 R3 並沒有在 root certificate 的名單中:

$ openssl s_client -connect nointermediate.gslin.com:443
CONNECTED(00000003)
depth=0 CN = nointermediate.gslin.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = nointermediate.gslin.com
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN = nointermediate.gslin.com
verify return:1
---
Certificate chain
 0 s:CN = nointermediate.gslin.com
   i:C = US, O = Let's Encrypt, CN = R3                                
---

而想到的解法就是重新包一份 Squid 出來用,把本來的 --with-gnutls 改成 --with-openssl

這邊會先裝 Build-Depends 裡面指定的東西,然後加裝 libssl-dev,接著換掉 --with-gnutls 後編譯,最後產生 .deb

sudo apt install -y ed libltdl-dev pkg-config build-essential cdbs debhelper dpkg-dev lsb-release dh-apparmor libcppunit-dev libcap2-dev libdb-dev libecap3-dev libexpat1-dev libgnutls28-dev libkrb5-dev comerr-dev libldap2-dev libnetfilter-conntrack-dev libpam0g-dev libsasl2-dev libxml2-dev nettle-dev libssl-dev
apt-get source squid
cd squid/squid-4.10
sed -i -e 's/--with-gnutls/--with-openssl/' debian/rules
cd ..
dpkg-buildpackage -rfakeroot -uc -b

編好的 .deb 就可以拿到其他機器上裝了,然後就可以吐出 intermediate certificate 了...

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 生了新的 Root 與 Intermediate Certificate

Let's Encrypt 弄了新的 Root Certificate 與 Intermediate Certificate:「Let's Encrypt's New Root and Intermediate Certificates」。

一方面是本來的 Intermediate Certificate 也快要要過期了,另外一方面是要利用 ECDSA 降低傳輸時的頻寬成本:

On Thursday, September 3rd, 2020, Let’s Encrypt issued six new certificates: one root, four intermediates, and one cross-sign. These new certificates are part of our larger plan to improve privacy on the web, by making ECDSA end-entity certificates widely available, and by making certificates smaller.

本來有 Let's Encrypt Authority {X1,X2,X3,X4} 四組 Intermediate Certificate,都是 RSA 2048 bits。

其中 X1 與 X2 差不多都到期了 (cross-signed 的已經過了,自家 ISRG Root X1 簽的剩不到一個月),不過這兩組已經沒在用了,這次就不管他了。

而 X3 與 X4 這兩組則是明年到期,會產生出新的 Intermediate Certificate,會叫做 R3 與 R4,跟之前一樣會被自家 ISRG Root X1 簽,以及 IdenTrust DST Root CA X3 簽:

For starters, we’ve issued two new 2048-bit RSA intermediates which we’re calling R3 and R4. These are both issued by ISRG Root X1, and have 5-year lifetimes. They will also be cross-signed by IdenTrust. They’re basically direct replacements for our current X3 and X4, which are expiring in a year. We expect to switch our primary issuance pipeline to use R3 later this year, which won’t have any real effect on issuance or renewal.

然後是本次的重頭戲,會弄出一個新的 Root Certificate,叫做 ISRG Root X2,以及兩個 Intermediate Certificate,叫做 E1 與 E2:

The other new certificates are more interesting. First up, we have the new ISRG Root X2, which has an ECDSA P-384 key instead of RSA, and is valid until 2040. Issued from that, we have two new intermediates, E1 and E2, which are both also ECDSA and are valid for 5 years.

主要的目的就是降低 TLS 連線時的 bandwidth,這次的設計預期可以降低將近 400 bytes:

While a 2048-bit RSA public key is about 256 bytes long, an ECDSA P-384 public key is only about 48 bytes. Similarly, the RSA signature will be another 256 bytes, while the ECDSA signature will only be 96 bytes. Factoring in some additional overhead, that’s a savings of nearly 400 bytes per certificate. Multiply that by how many certificates are in your chain, and how many connections you get in a day, and the bandwidth savings add up fast.

另外一個特別的修改是把名字改短 (把「Let's Encrypt Authority」拿掉),也是為了省傳輸的成本:

As an aside: since we’re concerned about certificate sizes, we’ve also taken a few other measures to save bytes in our new certificates. We’ve shortened their Subject Common Names from “Let’s Encrypt Authority X3” to just “R3”, relying on the previously-redundant Organization Name field to supply the words “Let’s Encrypt”. We’ve shortened their Authority Information Access Issuer and CRL Distribution Point URLs, and we’ve dropped their CPS and OCSP urls entirely. All of this adds up to another approximately 120 bytes of savings without making any substantive change to the useful information in the certificate.

這個部份讓我想到之前寫的「省頻寬的方法:終極版本...」這篇,裡面提到 AWS 自家的 SSL Certificate 太胖,改用 DigiCert 的反而可以省下不少錢 XDDD

另外也提到了這次 cross-sign 的部份是對 ECDSA Root Certificate 簽 (ISRG Root X2),而不是對 ECDSA Intermediate Certificate 簽 (E1 與 E2),主因是不希望多一次切換的轉移期:

In the end, we decided that providing the option of all-ECDSA chains was more important, and so opted to go with the first option, and cross-sign the ISRG Root X2 itself.

這算是蠻重要的進展,看起來各家 client 最近應該都會推出新版支援。

Let's Encrypt 從七月開始將會改用自己的 Root 簽發憑證

Let's Encrypt 宣佈了以後的憑證的簽發計畫:「Transitioning to ISRG's Root」。

主要的改變是 2019/07/08 之後提供的 intermediate CA 會改變,從現在的 cross-sign 變成只有自己的 Root CA:

On July 8, 2019, we will change the default intermediate certificate we provide via ACME. Most subscribers don’t need to do anything. Subscribers who support very old TLS/SSL clients may want to manually configure the older intermediate to increase backwards compatibility.

目前的簽發用的兩個中介憑證 (Let's Encrypt Authority X3Let's Encrypt Authority X4) 是由 Let's Encrypt 自己的 ISRG Root X1IdenTrustDST Root CA X3 所 共同簽署的:

這是因為 IdenTrust 的 DST Root CA X3 憑證很久前就被各家瀏覽器信任 (像是 Mozilla 的「Request to add two additional IdenTrust root CA certificates」這篇,可以看到 2007 年就被放進去了),而 Let's Encrypt 當時為了更快把可用的產品推出,所以跟 IdenTrust 合作,採用 cross sign 的方式讓 Let's Encrypt 簽出來的憑證被一般瀏覽器與函式庫所信任。

現在差不多過了三年半,Let's Encrypt 成為目前世界上最大的 SSL Certificate 發放單位,加上自己的 Root CA (ISRG Root X1) 也都差不多被整合進各家系統內了,所以打算要獨立自己簽了。

不過系統上可以設定,使用者如果有遇到相容性問題 (太舊的系統可能還是不包含 Let's Encrypt 自家的 ISRG Root X1),還是可以設定使用有 cross-sign 的版本 (維持現狀)。與 IdenTrust 的 cross-sign 會維持到 2021 年九月,大約再兩年多一些:

Our current cross-signature from IdenTrust expires on March 17, 2021. The IdenTrust root that we are cross-signed from expires on September 30, 2021. Within the next year we will obtain a new cross-signature that is valid until September 29, 2021. This means that our subscribers will have the option to manually configure a certificate chain that uses IdenTrust until September 29, 2021.

對於自用來說應該沒什麼大影響,主要是企業用戶要注意相容性...

CloudFlare 的 Origin CA:保護 CloudFlare 到 Origin 這段的傳輸過程

CloudFlare 推出的 Origin CA 用來保護從 CloudFlare 到 Origin Server 這段的過程:「Introducing CloudFlare Origin CA」,也就是右半部這段:

CloudFlare 把這個新功能包裝得很神,但實際上只是弄個 CA 出來跑而已,僅此而已。

當然,由於他不需要處理 Public CA 的問題,所以有很多在一般 TLS 連線需要做的檢查步驟可以被簡化,藉此達到效能改善,包括了省掉 intermediate certificates、OCSP 以及 SCTs:

With Origin CA certificates, we’ve stripped everything that’s extraneous to communication between our servers and yours to produce the smallest possible certificate and handshake. For example, we have no need to bundle intermediate certificates to assist browsers in building paths to trusted roots; no need to include signed certificate timestamps (SCTs) for purposes of certificate transparency and EV treatment; no need to include links to Certification Practice Statements or other URLs; and no need to listen to Online Certificate Status Protocol (OCSP) responses from third-parties.

進而省下大量的連線成本:

Eliminating these unnecessary components typically found in certificates from public CAs has allowed us to reduce the size of the handshake by up to 70%, from over 4500 bytes in some cases to under 1300.

Let's Encrypt 建立 Root Certificate 與 Intermediate Certificate

Let's Encrypt 的 Root Certificate 與 Intermediate Certificate 建出來了:「Let's Encrypt Root and Intermediate Certificates」。

Intermediate Certificate 除了會讓自己的 Root Certificate 簽名外,也會讓 IdenTrust 的 DST Root CA X3 簽 (目前各大瀏覽器與 SSL library 都有支援)。

目前是 RSA key,之後會生出 ECDSA key:

All ISRG keys are currently RSA keys. We are planning to generate ECDSA keys later this year.