Tag: letsencrypt

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。(用 OpenSSL 的 s_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

本來有做 dehydrated 的 PPA (在「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 了。

Let's Encrypt 的 Wildcard Certificate 開放使用！

Twitter 上看到這則 tweet，Let's Encrypt 正式開放 Wildcard Certificate 了：

參考「ACME v2 and Wildcard Certificate Support is Live」這邊的說明，裡面有提到 Wildcard Certificate 需要有 ACMEv2 的 client：

Wildcard certificates are only available via ACMEv2. In order to use ACMEv2 for wildcard or non-wildcard certificates you’ll need a client that has been updated to support ACMEv2. It is our intent to transition all clients and subscribers to ACMEv2, though we have not set an end-of-life date for our ACMEv1 API yet.

翻了一下「ACME Client Implementations」，我常用的 dehydrated 也支援 ACMEv2 了，而且剛好前幾天我更新了 PPA (參考「PPA for dehydrated : Gea-Suan Lin」)，把最新版 (0.5.0 後的 6e802dd) 包進去了，等下來測試看看要怎麼玩 XDDD

然後我之後打算把 letsencrypt.tw 的資料改丟到我的 Wiki 上，這樣改起來比較簡單...

Let's Encrypt 的 Wildcard Certificate 將會再延...

先前有提到 Let's Encrypt 的 Wildcard Certificate 從一月延到二月底 (表訂 2/27，參考先前的「Let's Encrypt 的 Wildcard SSL Certificate 延至二月底推出」這篇)，今天想說歐美的時區也差不多要過完 2/27 了，結果翻資料發現在「ACMEv2 and Wildcard Launch Delay」這邊又宣佈延期了，這次也不給時間了 XDDD

主要是 TLS-SNI 認證方式的前提有問題，導致 Let's Encrypt 臨時調度人力處理這個包 (可以參考「2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure」這篇，裡面有提到共用產生的問題假設)：

The biggest reason for this delay is the recent TLS-SNI deprecation. This unexpectedly pulled most engineering resources away from ACMEv2 and wildcard support for approximately two weeks.

然後 2/27 的說明提到目前是沒什麼大問題，但目前還在 QA 階段，然後目前先不給 release date：

Feb 27 Update: There are no known major issues with the ACMEv2/wildcard test endpoint. ACMEv2 and wildcard support quality assurance is continuing. No release date to announce yet.

就只能繼續等了... XD