CA/Browser Forum 在三月底的會議記錄

CA/Browser Forum 三月底的會議記錄裡看到了關於 wildcard ssl certificate 的一些討論,還蠻有趣的:「2016-03-31 Minutes」。

主要是第五條的記錄,在討論更廣泛的 wildcard 用法。首先是 Microsoftww*.example.com 這種 domain 的認定:

Rick said there was a Microsoft tech note that allows ww*.example.com. Jody confirmed the platform supports it.

但有爭論,而且目前看起來暫時沒有打算要實作:

Rick suggested the BRs be updated to include that. Ryan said that is not a good thing as there are multiple specs that treat this differently and historical context which would make it hard for Google to support such a ballot. Kirk asked why Peter put this in the ballot. He responded that this was raised in the past where people found a discrepancy in relation to other docs. However, given there was not consensus, he would remove from the proposed ballot. Ryan said there is a need for clarification because CAs seem to be interpreting this differently. Peter said he would create a new definition called “wildcard domain name” with an exact definition to avoid confusion and add clarity. Rick said that ideally Microsoft should remove that functionality and update the tech notes. Jody said he would need to consult with his expert on this. Peter said the goal of this ballot was to make it a “consensus” ballot and would remove anything controversial.

看起來還沒有完全定下來,之後的會議記錄可以再看看進展。這對安全性也頗有幫助,舉例來說,我就可以針對不同的服務發不同的 wildcard ssl certificate,像是 test-*.example.com 這樣,而不用另外再建立機制避免 private key 的外流。

StartSSL 的認證出包

這幾天還蠻歡樂的新聞,StartSSL 的認證過程出包,可以用任何 email 收認證信:「StartSSL Domain validation (Vulnerability discovered).」。直接看這張圖就好:

這樣傳不是問題 (因為你還是可以在 server 端再確認一次),而是改了會動 (樂):

這家公司最近傳出好多負面新聞... (啊,我把他們家的 root certificate 標成 untrusted 一陣子了 XD)

Certificate Transparency 開始紀錄 Untrusted CA

Google 宣佈他們開始收 Untrusted CA 的 Certificate Transparency 記錄:「Certificate Transparency for Untrusted CAs」,主要是這兩種 CA:

  • Those that were once trusted and have since been withdrawn from the root programs.
  • New CAs that are on the path to inclusion in browser trusted roots.

也就是被幹掉的,以及申請中的... 這樣可以後續追蹤很多東西。

Let's Encrypt 的官方版本 Client 將會改名

Let's Encrypt 的官方 Client 決定改名,不過目前還沒有公佈新的名字:「New Name, New Home for the Let's Encrypt Client」。

主要是兩個原因,第一個是避免商標問題:

[...] we want the client to be distributable and customisable without having to create a complex process for deciding whether customized variants are appropriate for use with Let’s Encrypt trademarks.

另外一個是希望之後有其他的 CA 也可以用:

Another reason is that we want it to be clear that the client can work with any ACME-enabled CA in the future, not just Let’s Encrypt.

把 Let's Encrypt 的說明放到 letsencrypt.tw 了

我寫了一份 Let's Encrypt 的說明 (以 letsencrypt.sh 為主),包括下載、安裝、server 設定、設定與 auto-renew。另外我也把為什麼這樣設計的想法寫在文章的後半部,這主要是在摸索自動化設定時想出來的,也許可以幫到一些人。

先前註冊了 letsencrypt.tw,也就拿來用了。

整個網站以 CC0 授權放出,希望能藉此推廣台灣使用 HTTPS。

也因此希望大家多分享到其他社群網站,讓更多人可以知道這個好用的 CA 與工具。

如果有任何建議,也歡迎在這篇文章下面留言。

StartSSL 將 auth.startssl.com 放在奇虎 360 的機房內

話說最近用 Nuzzel 用的還算開心,可以抓到不少文章,但意外的是這篇在 Nuzzel 上沒看到,是在 Allen OwnFacebook 時間軸上看到的 (這則)。

原文出自「Why I stopped using StartSSL (Hint: it involves a Chinese company)」。

最主要的安全問題在於 auth.startssl.com 放在中國公司奇虎 360 的機房內,而這是身份認證用的伺服器。基於中國是個人治而非法治的國家 (i.e. 無法確保 CA 的稽核機制是有效的),我決定把 StartSSL 的 root certificate 從 trusted chain 裡面拔掉,以免中獎...

Let's Encrypt 進入 Public Beta 開放給大眾使用

Let's Encrypt 進入 Public Beta,這代表不再需要提出申請才能用了:「Entering Public Beta」。

We’re happy to announce that Let’s Encrypt has entered Public Beta. Invitations are no longer needed in order to get free certificates from Let’s Encrypt.

話說翻資料的時候翻到 Namecheap 對 Let's Encrypt 作出反擊,只能說吃樣很難看:「SSL from Namecheap - What's the difference: Encryption, Validation & Trust」。

人們選擇 Namecheap 的 SSL certificate 不是因為他好,而是因為他便宜,加上這家公司不像 GoDaddy 那樣邪惡。

現在有免費的 SSL certificate 出來競爭 (於是根本打不贏) 就放 FUD 攻擊,吃相極為難看。有人針對 Namecheap 的文章駁斥了裡面大量錯誤的論點:「Comment on Namecheap's SSL」。

接下來應該可以弄不少來玩,來整理文章把申請與自動 renew 的步驟做出來...

Hostname 與 Username 的保留名稱問題

在「Hostnames and usernames to reserve」這邊提到公開服務時的保留名稱問題。

首先是提到 hostname 的部分,被各協定使用到的都散落在各標準裡,另外就是利用前幾天提到的「Mozilla 維護的 Public Suffix List」加減擋 cookie...

比較感興趣的是 email 的部分的標準,這邊主要在討論 SSL certificate 的註冊。在「Baseline_Requirements_V1_3_1」的 3.2.2.4. Authorization by Domain Name Registrant 的第四項提到:

Communicating with the Domain’s administrator using an email address created by pre‐pending ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ in the local part, followed by the at‐sign (“@”), followed by the Domain Name, which may be formed by pruning zero or more components from the requested FQDN;

也就是指出只能用上面提到的這幾個 mail address 來認證。不過為了安全起見,RFC 2412 定義的也應該擋下來。這兩組標準列出來的 username 都算是合理,沒什麼問題。

最後則是討論 path part,這點倒是有不少地雷可以看看,尤其是最新的 ACME 產生的問題 XDDD

Dell 在出廠的電腦上裝自己的 Root Certificate,順便把 Private Key 也裝進去了...

Dell 在出廠的電腦上裝了 Root Certificate (eDellRoot),並且附上 Private Key:「Dell apologizes for HTTPS certificate fiasco, provides removal tool」。

出自 Redditrotorcowboy 的爆破:「Dell ships laptops with rogue root CA, exactly like what happened with Lenovo and Superfish」。

Dell 官方的正式回應:「Response to Concerns Regarding eDellroot Certificate」。

由於有 Private Key,有人架了一個檢測網站,在「Are you affected by the eDellRoot-Certificate issue?」這邊可以確認電腦是否中獎。

大家都超愛搞這套的 XDDD

把家裡的機器換上 Let's Encrypt 的 SSL certificate

依照「Beta Program Announcements」這邊的指示去填單申請 Let's Encrypt 的 SSL certificate (先幫 home.gslin.org 申請),等了好幾天,在剛剛收到信就弄了弄,還蠻順利就設好了。

可以看到 Let's Encrypt Authority X1DST Root CA X3 簽名的情況,而後者已經被大多數瀏覽器所確認了:

首先是先把 letsencrypt client 拉下來:

$ git clone https://github.com/letsencrypt/letsencrypt

接著執行認證:

$ cd letsencrypt
$ ./letsencrypt-auto --agree-dev-preview --server https://acme-v01.api.letsencrypt.org/directory certonly

執行時會先建立環境 (由於需要寫到 /etc/letsencrypt 裡面,會需要 root 或 sudo 權限)。

接下來會跳出一些畫面讓你設定,包括 hostname 以及聯絡資訊,再來就是認證的方式 (我是跳出使用 apache 或是 standalone web server),由於我的 port 443 已經被 apache 吃掉,所以需要用 apache。

最後認證成功會出現:

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/home.gslin.org/fullchain.pem. Your cert will
   expire on 2016-02-02. To obtain a new version of the certificate in
   the future, simply run Let's Encrypt again.

有效期限 90 days,雖然裡面是講 fullchain.pem,但其實每個檔案都有拆開放,看一下 /etc/letsencrypt/live/home.gslin.org/ 路徑裡的檔案,設定對應的 cert/chain/key 應該還是比較習慣的作法。

官方目前的建議是 60 days 重新 renew 一次,也許可以設成 cron,每兩個月自動更新一次 (並且 reload apache)。