Let's Encrypt 決定要規劃 Wildcard SSL Certificate 了

Let's Encrypt 把時間表喊出來了,預定在 2018 年年初開放使用:「Wildcard Certificates Coming January 2018」。

Wildcard SSL Certificate 會需要走新的 ACME v2 協定認證:

Wildcard certificates will be offered free of charge via our upcoming ACME v2 API endpoint. We will initially only support base domain validation via DNS for wildcard certificates, but may explore additional validation options over time.

跟前陣子提到的「ACME v2 API Endpoint Coming January 2018」是相同的時間。

這好讚...

另外一套用 shell script 寫的 ACME client (或者說 Let's Encrypt client)

acme.sh 是另外一套用 shell script 寫的 ACME client,由西安的 Neilpang 寫的。我也包成 Ubuntu PPA 了:「PPA for acme.sh」。

我建議的用法是先建立 /etc/acme.sh,把各種設定都放到這個目錄裡面,然後用這樣的指令執行:

$ sudo acme.sh --issue -d www.example.com -w /srv/www.example.com/webroot/ --home /etc/acme.sh/

不過 acme.sh 有個問題,沒有將檔案與目錄權限處理好... 我申請完後發現目錄是 drwxr-xr-x,而 key 是 -rwxr-xr-x,這樣會有安全性的問題,需要自己再修改。

letsencrypt.sh 改名為 dehydrated

Twitter 上被提醒 letsencrypt.sh 改名為 dehydrated 了:

在「renamed project to dehydrated and main script to dehydrated.sh」這邊可以看到對應的 commit。

原有的 letsencrypt.sh PPA 仍然會保留,但不會再更新 (維持 letsencrypt.sh 所發行的最後一個版本,0.3.0),要使用的人請使用 dehydrated PPA,目前是 0.3.1。

原先的設定要搬過去的話有不少要改:

  • /usr/sbin/letsencrypt.sh -> /usr/sbin/dehydrated (執行檔)
  • /etc/letsencrypt.sh/ -> /etc/dehydrated/ (設定檔與 cert & key 的目錄)
  • /var/www/letsencrypt/ -> /var/www/dehydrated/ (challenge 的目錄)

既然 cert & key 的目錄也換了,apachenginx 的設定也要記得換,我這邊還要多換 Postfix 的設定...

接下來要改對應的教學文件...

OpenBSD 將 ACME Client (Let's Encrypt Client) 納入系統

看到 OpenBSD 直接把 ACME 協定的 client 放進系統內,而 ACME 也就是 Let's Encrypt 所使用的協定:「Let's Encrypt client imported into -current」:

CVSROOT:/cvs
Module name:src
Changes by:florian@cvs.openbsd.org2016/08/31 16:01:42

Added files:
usr.sbin/acme-client: ChangeLog Makefile acctproc.c base64.c 
                      certproc.c chngproc.c dbg.c dnsproc.c 
                      extern.h fileproc.c http.c http.h jsmn.c 
                      jsmn.h json.c keyproc.c letskencrypt.1 
                      main.c netproc.c revokeproc.c rsa.c rsa.h 
                      sandbox-pledge.c util-pledge.c util.c 

Log message:
Import Kristaps' letskencrypt and call it acme-client in tree.
OK to get it in deraadt@ (and probably beck@)

At least deraadt@, beck@ and otto@ are fine with the name and the
disagreements stopped.

用的是 acme-client,先前叫做 letskencrypt,以 C 開發的 ACME client。

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.

用 Shell Script 寫的 Let's Encrypt Client

在找 Let's Encrypt 安裝方法時找到的專案:「letsencrypt/acme client implemented as a shell-script」。

整個專案用 bash 寫,用到的 dependency 都非常基本,「比較特別的」只有 curlopenssl,這兩個套件應該不是什麼問題... XD

沒有安裝問題 (因為只有一個 shell script 檔案),用起來也很簡單,執行速度也比官方快多了 (畢竟官方的考慮比較多),之後應該就會用這個吧... 另外自動化的部份也應該會用這個解決 :o

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