Tag: ca

Amazon RDS 的 TLS 連線所使用的 CA 要更新了

Amazon RDS 的 TLS (SSL) 連線所使用的 CA 要更新了：「Rotate Your SSL/TLS Certificates Now – Amazon RDS and Amazon Aurora Expire in 2024」。

如果沒有開 TLS 連線的話是不受影響 (像是內網裸奔)，但如果有在用 TLS 的話就要注意一下了，看起來得手動更新處理。

比較特別的是新的 CA 簽的超長：

Most SSL/TLS certificates (rds-ca-2019) for your DB instances will expire in 2024 after the certificate update in 2020. In December 2022, we released new CA certificates that are valid for 40 years (rds-ca-rsa2048-g1) and 100 years (rds-ca-rsa4096-g1 and rds-ca-ecc384-g1). So, if you rotate your CA certificates, you don’t need to do It again for a long time.

現有的 rds-ca-2019 可以在 https://s3.amazonaws.com/rds-downloads/rds-ca-2019-root.pem 這邊取得，用 openssl x509 -in rds-ca-2019-root.pem -text 可以看到資料。

到 crt.sh 上翻過一些字串，沒看到被簽的記錄，所以看起來無法透過一般 trusted store 裡面的 Root CA 一路信任下來。

新的 key 應該也是 Private Root CA，從名字看起來應該是對應的 key algorithm。其中 RSA 2048 的簽了 40 年，而 RSA 4096 與 ECC 384 的簽了 100 年，雖然說是自家弄的 CA，但目前的 compliance 沒有要求 key rotation 嗎...

Anyway，常用的區域基本上都是 August 22, 2024 這個日期，大約還有九個多月的時間更新，依照 AWS 的慣例，後面應該還會提醒幾次：

話說 2020 年的時候也有更新，當時是 Jeff Barr 出來說明的：「Urgent & Important – Rotate Your Amazon RDS, Aurora, and Amazon DocumentDB (with MongoDB compatibility) Certificates」，現在看起來一些常態性的說明都陸續交棒給 Channy Yun 了...

不過這次這樣搞 40 年 & 100 年，後續要更新應該都是演算法的推進了，比較不會是要到期...

Let's Encrypt 與 IdenTrust 延長三年的 cross sign 在 2024/10/01 要結束了

先前 Let's Encrypt 跟 IdenTrust 的 cross sign 會在 2024/10/01 到期，可以參考 3958242236 這邊的資訊，可以看到由 IdenTrust 的 DST Root CA X3 對 Let's Encrypt (ISRG) 的 ISRG Root X1 簽名，時間是到 2024/09/30 18:14:03 GMT (換算大概是台灣隔日的清晨兩點多)：

Issuer: (CA ID: 276)
    commonName                = DST Root CA X3
    organizationName          = Digital Signature Trust Co.
Validity
    Not Before: Jan 20 19:14:03 2021 GMT
    Not After : Sep 30 18:14:03 2024 GMT
Subject: (CA ID: 7394)
    commonName                = ISRG Root X1
    organizationName          = Internet Security Research Group
    countryName               = US

所以 Let's Encrypt 這邊也整理出了對應的落日計畫：「Shortening the Let's Encrypt Chain of Trust」。

第一波是 2024/02/08，從這個時間點開始 Let's Encrypt 的 ACME 服務預設組出來的 SSL certificate 將不會帶 IdenTrust 提供的 cross sign 憑證，但你還是可以自己另外設定取用：

On Thursday, Feb 8th, 2024, we will stop providing the cross-sign by default in requests made to our /acme/certificate API endpoint. For most Subscribers, this means that your ACME client will configure a chain which terminates at ISRG Root X1, and your webserver will begin providing this shorter chain in all TLS handshakes. The longer chain, terminating at the soon-to-expire cross-sign, will still be available as an alternate chain which you can configure your client to request.

再來是過期前的 90 天多一點的 2024/06/06，Let's Encrypt 的 ACME 服務將不會提供 cross sign 的憑證：

On Thursday, June 6th, 2024, we will stop providing the longer cross-signed chain entirely. This is just over 90 days (the lifetime of one certificate) before the cross-sign expires, and we need to make sure subscribers have had at least one full issuance cycle to migrate off of the cross-signed chain.

最後就是過期的日子 2024/09/30：

On Monday, September 30th, 2024, the cross-signed certificate will expire. This should be a non-event for most people, as any client breakages should have occurred over the preceding six months.

依照說明，應該是 Android 7.0 以及之前的版本會產生問題，照目前的數字看起來是 100% - 93.9% = 6.1%：

接下來一年應該會再低一些，但不確定會低多少，有機會 <5% 嗎？

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 裡面...

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 會產生問題，主因是 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 這類的管理工具，至少目前用起來沒什麼大問題...

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 的資料來看看到底有多少人用...

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 Labs 的 SSL 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.

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