Let’s Encryptのワイルドカード証明書発行

無料SSL証明書のLet’s EncryptがACMEv2プロトコルでワイルドカード証明書発行に対応しました。

ACMEv1でも、サブドメインを羅列することで１枚の証明書に複数ドメインの証明を混載できましたが、具体的なサブドメインは発行時点で決まっている必要があります。

ワイルドカード発行にはDNS認証が必要

certbotクライアントの公式ドキュメントのDNS pluginsに”Doing domain validation in this way is the only way to obtain wildcard certificates from Let’s Encrypt.” と記載されているとおり、ワイルドカード証明書を発行するには、DNS上で認証する必要があります。

Let’s Encrypt証明書の有効期限は3ヶ月に限定されており、更新の自動化を考慮に入れると、certbotのDNSプラグインが対応しているネームサーバーの利用が前提となります。

Google Cloud DNSやAmazon Route53などが対象となっており、今回はCloud DNSで検証しました。（Cloud DNSへの移行手順は別記事参照）

certbotで証明書更新

ワイルドカード証明書取得には、DNSプラグインを利用できるcertbotが必要です。

CertbotのDockerhubリポジトリで各種dockerイメージが提供されています。
たとえばGoogle Cloud DNS用の場合、 certbot/dns-googleを利用します。

certbotコマンド例は以下のようなものになります。

$ certbot certonly --dns-google \
 --dns-google-credentials </path/to/service-account.json> \
 --non-interactive --force-renewal \
 --agree-tos -m <[email protected]> \
 -d <example.com> -d <*.example.com>

dns-googleプラグインにより–dns-googleオプションが利用可能になっています。
オプションの設定値は、プラグイン別リファレンスに掲載されています。

ACME認証の過程でDNSのtxtレコードを書き換える動作となるため、APIクレデンシャルの指定が必要になります。（Google Cloudのクレデンシャルについては、別記事参照）

なお、dns-googleの実装はServiceAccountのproject内でCloudDNSのマネージドゾーンを検索するため、CloudDNSの定義と同一プロジェクトのServiceAccountである必要があります。ServiceAccountに別プロジェクトのCloudDNS操作権限を追加してもエラーになるため注意が必要です。

証明書取得対象のドメインは-dオプションで指定でき、ベースドメインと*サブドメインの2種類指定しました。