letsencryptの成長が目覚ましいですね。
そもそもLet's Encryptだったり、LetsEncryptだったり検索キーワードが複数あるため情報が散らばっているせいで、最新情報を追いにくくはありますが、そんな影響をものともしないくらいの成長具合が見られます。
かつては、letsencryptだった実行コマンドが、letsencrypt-autoになったり、certbotに変わったりして、現在は、certbot-autoで落ち着いたようです。
シェルに書いたり、Dockerで記述したりする記事を見かけますが、実行コマンドが変わっても修正箇所を最小限にしたりと、みんないろんな工夫をしているようです。
実際にはまったこと
以下のようなシェルスクリプトを用意して、その下の手順通り進めたところ、letencrypt側のエンドポイントにステージング環境が採用されて、ルート証明書が「Fake LE Intermediate X1」というフェイク証明書になってしまいました。
#!/bin/sh
#証明書のドメイン（,区切りで複数のドメインも指定可能）
DOMAIN=<YOUR DOMAIN>
#ドキュメントルート（上のドメインで接続可能である必要がある）
WEBROOT=<YOUR DOCUMENTROOT>
#メールアドレス（トラブル時にメールが届く）
EMAIL=<YOUR MAIL>
/usr/local/certbot/certbot-auto certonly -m $EMAIL /
--agree-tos --non-interactive $* /
--webroot -w $WEBROOT -d $DOMAIN
手順
※前提として、DNSの設定、Webサーバのセットアップ、certbotのインストールは完了していること。
1. 上記のletsencrypt.shを任意の場所に配置する。
2. 下記コマンドでテストサーバに接続して証明書を取得する。（※これが誤り）
sudo ./letsencrypt.sh --test-cert
3. 下記コマンドで、本番用の証明書を取得する。
sudo ./letsencrypt.sh --force-renewal
--force-renewを実行しすぎて、証明書取得の利用制限の閾値を超える
1日で5回、1週間で20回のどちらかの制限にかかって、証明書取得ができなくなりました。（どちらにかかったのか確認するすべがない）
日本語公式ページにも以下のように書いてあり、無効な証明書を取得していました。
--test-cert もしくは --staging
SSL/TLS サーバ証明書の取得時に、ステージングサーバを使用して、無効な証明書を取得します。
オプション --server https://acme-staging.api.letsencrypt.org/directory を指定するのと同じ動作です。
(デフォルト: False)
どうやって解決したか
メインのドメインはEV証明書も必要なため有償の証明書を割り当てていたため、letsencryptのドメインに含めることができず、泣く泣くサブドメインの変更を余儀なくされました。
ところが、変更後のサブドメインの証明書を取得する際には、2.の手順のところで、--dry-runを指定した後で、--force-renewalを指定して再度実行したところ正しいルート証明書を取得することができました。
