Let's EncryptでECDSAな証明書

この記事の後にcertbotでオプション指定でECDSAな証明書が作成/更新可能になったので以下の手順は不要になっています。
certbotを使いLet's EncryptでECDSAな証明書を作る 2022年

個人的にはウェブサーバー用のSSL証明書はLet's Encryptを使うことが増えている。無料だからってだけでなくACME(クライアントのCertbot等)による証明書の新規発行・更新がアホみたいに簡単で楽だから。
同時に、SSLの証明書はそろそろRSAでなくECCなものにしたいという希望があるのだが、certbotにはRSA/ECCの切り替えオプションのようなものが無いみたい。
でも、Let's EncryptでECC(ECDSA)な証明書が発行できないわけではならしい

どうするか？

以前のECDSAな証明書の発行の記事の証明書発行手順で考えると、ECDSA用のCSRを認証局に送ったらECDSAな証明書を発行して貰えたわけだから、certbotを使う場合でもECDSA用のCSRを読ませて処理させれば良いってことになるよね。で、certbotにはたしかCSRファイルを指定するオプションがあった筈。

鍵(P-256)の作成

% openssl ecparam -name prime256v1 -genkey -out server.key

CSRの作成

% openssl req -new -sha256 -key server.key -out server.csr

certbotを使った証明書の発行

% /usr/local/bin/certbot certonly -w ウェブのドキュメントルート -d ドメイン/サブザメイン --csr 作成したCSRファイル --agree-tos --non-interactive --webroot --cert-path 発行したい証明書(単独)ファイル --fullchain-path 発行したい証明書(フルチェーン)ファイル

すでにcertbotで自動更新しているドメインでやるならcertbot delete等で、そのドメインを消しておいた方が良いかも。

Let's Encryptの証明書は3ヶ月で期限切れになるので頻繁な更新が必要。もちろん手動更新なんてやってられないので自動化させたい。

#!/bin/sh

domain="example.com"
webroot="/usr/local/www/example.com"
certpath="/usr/local/etc/nginx/ssl/example.com"

rm ${certpath}/server.pem
rm ${certpath}/fullchain.pem

/usr/local/bin/certbot certonly -w ${webroot} -d ${domain} --csr ${certpath}/server.csr --agree-tos --non-interactive --webroot --cert-path ${certpath}/server.pem --fullchain-path ${certpath}/fullchain.pem
cp ${certpath}/server.pem ${certpath}/public/
cp ${certpath}/fullchain.pem ${certpath}/public/
/usr/sbin/service nginx restart

こんな感じ。
最後の行はFreeBSDでNginxを再起動するコマンド。

これだとドメイン毎にスクリプトファイルを用意しないといけないので1つのスクリプトファイルを複数ドメインで使いまわしたいなら引数$1 $2などを使ったスクリプトに修正すればOK。
あと、上のスクリプトはCSRが使いまわしになるのでそれが気に入らなければCSR作成コマンドも入れる。
Webサーバなどの設定で証明書ファイルとして指定するのは${certpath}/public/にあるファイル。上のスクリプトでは更新に失敗すると${certpath}内の証明書が存在しない状態になるのでそれを指定したWebサーバを起動・再起動しようとすると失敗する。${certpath}/public/内には証明書が存在し続ける筈なので更新失敗による期限切れはあっても証明書が存在しないことによる起動失敗はない。
これを2ヶ月毎程度の頻度でcronで動かす。頻繁に動かすと発行制限食らうので注意。

ウェブサーバ側の設定はECDSAな証明書の発行の記事のままでいける筈。

HPKP

HPKPのピンはCSRを固定(使い回し)なら変わらないのでピン再作成は必要ない。CAに署名して貰った証明書のピンもCSRのピンと同じになる。
CSRからピンを作成する場合。

% openssl req -pubkey < server.csr | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64

サーバー証明書からピンを作成する場合。

% openssl x509 -pubkey < server.pem | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64

ついでに。

Let's Encrypt Authority X3のピン: (2017年12月現在)
pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg="

DST Root CA X3のピン: (2017年12月現在)
pin-sha256="Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys="

2018年6月10日追記:
HPKPはもはや採用するべきではないでしょう。糞扱いされて主要ブラウザの非サポート化も進行中です。

代替技術(仕様)としてはCertificate Transparency(CT 証明書の透明性)が筋~~だろうけど面倒なのでHPKPとは別の面で質が悪い気がします。HPKPの代替にはなりえませんがDNS CAAあたりでお茶を濁すのが簡単でよろしいかと~~。

2020年1月27日追記:
CA側でCertificate Transparency対応が進んで、CAが証明書にSCTを埋め込んで発行するというのが当たり前になったので、もはやCTは全く面倒ではありません。証明書の更新以外にウェブサイトの管理者の手間になるものはありません。任意でExpect-CTレスポンスヘッダを付けるくらい？