Let's Encrypt 的 ACMEv1 將在今年十一月進入日落階段

Let's Encrypt 推出 ACMEv2 後要終止 ACMEv1 的計畫,是今年三月發的消息,但一直沒注意到,剛剛翻到「acme-client(1) moves to Let's Encrypt v02 API」時才看到的:「End of Life Plan for ACMEv1」。

日落分成幾個階段,第一個階段是今年十一月終止透過 ACMEv1 註冊新帳號:

In November of 2019 we will stop allowing new account registrations through our ACMEv1 API endpoint. Existing accounts will continue to function normally.

第二個階段是明年六月終止透過 ACMEv1 申請新的 certificate:

In June of 2020 we will stop allowing new domains to validate via ACMEv1.

第三個階段是 2021 年會開始測試關閉 ACMEv1 的 renew 功能,一個月不會超過一次,每次大約 24 小時,這是讓 client 有機會丟出錯誤訊息:

Starting at the beginning of 2021 we will occasionally disable ACMEv1 issuance and renewal for periods of 24 hours, no more than once per month (OCSP service will not be affected).

最後的階段是 2021 年的六月,會完全關閉 ACMEv1 所有的服務:

In June of 2021 we will entirely disable ACMEv1 as a viable way to get a Let’s Encrypt certificate.

目前在用的都支援 ACMEv2 了,應該是 ok...

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.

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

ACME,RFC 8555

這邊講的是因為 Let's Encrypt 所發明的 ACME 協定,可以協助自動化發憑證的協定。

剛剛看到「Automatic Certificate Management Environment (ACME)」這個頁面,上面標 PROPOSED STANDARD,但點進去的 txt 檔開頭則是 Standards Track 了:

Internet Engineering Task Force (IETF)                         R. Barnes
Request for Comments: 8555                                         Cisco
Category: Standards Track                             J. Hoffman-Andrews
ISSN: 2070-1721                                                      EFF
                                                             D. McCarney
                                                           Let's Encrypt
                                                               J. Kasten
                                                  University of Michigan
                                                              March 2019

不知道是不是兩邊不同步 (或是我對流程有誤會?),但這有一個標準文件可以參考了...

讓 OpenLDAP 伺服器使用 Let's Encrypt 簽的憑證

OpenLDAP 伺服器可以吃 Let's Encrypt 發的憑證以提供 LDAPS 服務,只是 SSL 設定方法跟其他軟體不太一樣,第一次設會花不少時間...

這邊的檔案目錄是以 Dehydrated 申請 Let's Encrypt 的憑證來設定。官方推薦的 Certbot 應該也有類似的檔案:

TLSCACertificateFile /etc/dehydrated/certs/x.y.z/chain.pem
TLSCertificateFile /etc/dehydrated/certs/x.y.z/cert.pem
TLSCertificateKeyFile /etc/dehydrated/certs/x.y.z/privkey.pem

這樣不管 Let's Encrypt 拿 Let’s Encrypt Authority X3 (目前的主力憑證) 還是 Let’s Encrypt Authority X4 (備用的憑證) 簽,OpenLDAP 這邊才會串出正確的 certficiate chain。(用 OpenSSLs_client -connect x.y.z:636 與 ldapsearch 測過)

要找問題的話,ldapsearch 有 -v (verbose) 與 -d 9 (debug) 可以看連線過程的細節,拿著錯誤訊息去餵搜尋引擎會有不少幫助...

在找資料時發現網路上有不少文件教大家直接在 client 端的 /etc/ldap/ldap.conf 修改 TLS_REQCERT 的值,從預設的 demand 改成 allow (或是 never),但這樣將強制檢查的條件改弱,安全性反而降低了。比較好的方式還是修正 server 端的錯誤設定。

國內使用 Let's Encrypt 的商業網站...

因為前一篇「Symantec 系列的 SSL Certificate 陸續開始失效...」的關係,當時是針對 針對 .tw 結尾的站台,用 OpenSSL 掃了一份 issuer= 下來,剛好可以拿來翻一下有誰換去 Let's Encrypt 了...

蝦皮的主站台直接都用 Let's Encrypt 了:

host=shopee.tw  issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
host=www.shopee.tw      issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3

然後在「SSL Server Test: shopee.tw (Powered by Qualys SSL Labs)」這邊可以看到是 wildcard,而且是多個 wildcard 合併一張...

如果把 Let's Encrypt 自動化,省下來最多的通常都不是憑證費用,而是 renew 時請款流程的人力成本與忘記 renew 時的出包成本... XD

Let's Encrypt 被所有主流瀏覽器直接支援了...

Let's Encrypt 宣佈他們的憑證被所有主流瀏覽器直接支援了,也就是都在各平台的 trusted store 內了:「Let's Encrypt Root Trusted By All Major Root Programs」,看起來這次加入的是 Microsoft 的產品:

As of the end of July 2018, the Let’s Encrypt root, ISRG Root X1, is directly trusted by Microsoft products. Our root is now trusted by all major root programs, including Microsoft, Google, Apple, Mozilla, Oracle, and Blackberry.

先前是靠 IdenTrust 的 cross signing 讓各瀏覽器信任,在「Chain of Trust」這邊有圖說明:

另外查了一下 cross signing 的資訊,以 Let's Encrypt Authority X3 這張的 cross signing 可以看到 cross sign 簽了五年,到 2021 年:(憑證可以從 letsencryptauthorityx3.pem.txt 這邊取得,用 openssl x509 -in letsencryptauthorityx3.pem.txt -text 看到)

    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Internet Security Research Group, CN = ISRG Root X1
        Validity
            Not Before: Oct  6 15:43:55 2016 GMT
            Not After : Oct  6 15:43:55 2021 GMT
        Subject: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

這樣約滿不知道會不會續簽...

把本來 dehydrated 的 PPA 改成 dehydrated-lite

本來有做 dehydratedPPA (在「PPA for dehydrated : Gea-Suan Lin」這邊),後來在 17.10+ 就有更專業的人包進去了 (參考「Ubuntu – Package Search Results -- dehydrated」),為了避免名稱相同但是內容物差很多,我把 PPA 的名字換成 dehydrated-lite 了 (參考「PPA for dehydrated (lite) : Gea-Suan Lin」)。

然後 0.6.2 的 dehydrated 針對 ACMEv2 有修正,這在 0.6.1 時會產生 certificate 裡有多餘資訊 (而 PPA 版的 gslin/dehydrated 只會停留在 0.6.1),這點需要注意一下:

Don't walk certificate chain for ACMEv2 (certificate contains chain by default)

之後再找機會拔掉 gslin/dehydrated,也許會照著現在 APT 內的架構來做...

用 GitHub + Netlify + Cloudflare 管理靜態網站...

最近 GitHub Pages 支援 HTTPS (透過 Let's Encrypt,參考「GitHub 透過 Let's Encrypt 提供自訂網域的 HTTPS 服務」這篇),但測了一下不是我想要的效果,就找了一下網路上的資源,結果有找到還算可以的方案...

  • 先把網站放在 GitHub 上。(不需要設定 GitHub Pages)
  • 然後用 Netlify 變成網站並且開啟 HTTPS。(可以選擇使用系統內提供的 Let's Encrypt,會透過 http-01 認證。如果因為 DNS 還沒生效的話也沒關係,可以之後再開。)
  • 然後用 Cloudflare 管理 DNS 的部份 (主要是因為他的 root domain 可以設 CNAME,一般會提到的 ALIAS 就是指這個)。

這樣整個靜態服務都不用自己管理,而且有蠻多 header 可以設定,其中與 GitHub Pages 最主要的差異是 Netlify 支援 301/302 redirect。而關於 Netlify 的設定範例 (簡單的),可以參考我在 GitHub 上的 git.tw repository。

然後 Netlify 上可以自己設定 header,當設定 HSTS 之後,SSL Labs 的跑分也可以到 A+。

整包目前看起來唯一的限制是 Netlify 的 125k requests/month (平均下來大約 4k requests/day),不過只拿來做 redirect 應該還好...

PS:如果有人要推薦其他的組合也歡迎...

GitHub 透過 Let's Encrypt 提供自訂網域的 HTTPS 服務

以往在 GitHub 上如果要使用 HTTPS 只能使用 *.github.io 網域,現在 GitHub 宣佈透過 Let's Encrypt 的服務支援了:「Custom domains on GitHub Pages gain support for HTTPS」:

We have partnered with the certificate authority Let’s Encrypt on this project. As supporters of Let’s Encrypt’s mission to make the web more secure for everyone, we’ve officially become Silver-level sponsors of the initiative.

不過目前只支援 CNAME record (標準) 或是 ALIAS record 的方式 (非標準,也稱為 ANAME,有些 DNS provider 有支援,主要用在網域本身 (i.e. root domain) 無法使用 CNAME)。

如果是使用 A record,則是需要更新 IP 位置:

If you are using A records, you must update your site’s DNS records with new IP addresses. Please see our guide to setting up your custom domain with Pages and update any A records you might have set.

另外也提供 HTTP 轉 HTTPS 的選項:

以前 HTTPS 還得自己弄伺服器處理,現在可以直接往 GitHub 上丟了...

另外用查出來的 IP 看了一下架構,IP 是 Fastly 的,所以應該是跟 Fastly 合作,但不確定是 Fastly 自己搞定 Let's Encrypt 的憑證,或是 Fastly 提供 Port 80/443 的 TCP Proxy?

Google Chrome 67 將可以在 DevTools 裡看到 SCT 的內容

Twitter 上看到 Google Chrome 67 (下一個版本) 的 DevTools 將會顯示憑證上的 Certificate Transparency 資訊:

現在要看這個資訊比較麻煩,之後可以在瀏覽器裡直接讀就會簡單一些了...

話說回來,Let's Encrypt 上個月也支援 SCT 了:「Engineering deep dive: Encoding of SCTs in certificates」,不過目前只能先用 command line 工具看... 我拉了 Let's Encrypt 官方網站的 certificate 可以看到 (Let's Encrypt 那篇文章裡的範例),但我自己 blog 的 certificate (序號 04ef0022ed7d5417f1ccbc011acf7fea9830) 看起來是在 Let's Encrypt 支援 SCT 之前申請的,沒看到 SCT 資訊... 要等下一次的 renew 了。