Caddy の Azure DNS 連携用モジュールをリリースした

@kurokobo IT・プログラミング

作ったもの

Caddy の Automatic HTTPS で、DNS-01 チャレンジ に Azure DNS を利用するためのモジュールをリリースしました。

経緯

Caddy は、Apache HTTP Server や Nginx のような Web サーバの実装のひとつです。特徴的な機能はいくつかあり、その一つに、ドメイン名を指定して起動するだけで Let’s Encrypt を使った証明書の発行や更新を全自動で勝手にやってくれる Automatic HTTPS があります。

この証明書の発行の際、デフォルトでは HTTP-01 チャレンジか TLS-ALPN-01 チャレンジが行われますが、多少のカスタマイズで DNS-01 チャレンジも利用 できます。外部に公開していないサイトでも正規の証明書が利用できるほか、公開しているサイトでも 80 番ポートや 443 番ポートを閉塞できるなど、種々のメリットがあります。

一方で、残念ながら この機能が利用できる DNS プロバイダは現時点であまり豊富ではなく、例えば、今回使いたかった Azure DNS は未対応でした（go-acme/lego のラッパはある ものの、Deprecated 扱いなのであまり推奨されません）。

対応済みプロバイダには Amazon Route 53 などもあるので、使いたいゾーンだけそちらに委任するのがもちろんいちばんラクです。が、本家に PR を送ってレビュしてもらう 流れなど今まであまり経験がなく、ちょっとおもしろそうだったので、自分で作ることにしました。野良モジュールのままで終わらずに、採用してもらえてよかったです。英語はよくわかりません。

使い方

公式の Wiki で詳しく説明されていますが、xcaddy を使ってビルドするのが簡単です。リリースページ から（もしくは go get して）xcaddy のバイナリを持ってきて、--with でモジュールを渡します。

xcaddy build --with github.com/caddy-dns/azure@v0.1.0

これでモジュールが組み込まれた Caddy のバイナリ caddy ができあがります。コンテナで使いたい場合は Docker Hub の説明が詳しい ですが、以下のような Dockerfile でビルドするだけです。

FROM caddy:2.3.0-builder AS builder
RUN xcaddy build v2.3.0 \
    --with github.com/caddy-dns/azure@v0.1.0

FROM caddy:2.3.0
COPY --from=builder /usr/bin/caddy /usr/bin/caddy

あとは起動して Caddyfile か API 経由で設定を投げ込んでやれば、指定したドメインの証明書を取得するべく Let’s Encrypt と Azure DNS を使って DNS-01 チャレンジが始まります。完了すると、正規の証明書とともに HTTPS でホストされます。

hoge.example.com {
    tls hoge@example.com {
        dns azure {
            tenant_id {$AZURE_TENANT_ID}
            client_id {$AZURE_CLIENT_ID}
            client_secret {$AZURE_CLIENT_SECRET}
            subscription_id {$AZURE_SUBSCRIPTION_ID}
            resource_group_name {$AZURE_RESOURCE_GROUP_NAME}
        }
    }
    respond "Hello, world!"
}

簡単ですね。Azure への認証は今のところ Client Credential のみです。

余談： 証明書の透明性

若干本筋から逸れますが、Let’s Encrypt に限らず、認証局から取得した証明書のドメイン名は自動的に公開される 仕様なので、その点は認識が必要です。つまり、秘密にしたくてこっそり用意したサブドメインであっても、証明書を取得した時点で、認証局がその FQDN に対して証明書を発行した事実は公開 されます。

これはいわゆる 証明書の透明性、Certificate Transparency（CT）と呼ばれる仕組みで、主にドメインの所有者やサイトの運営者などが不正な証明書の発行を監視・検証できるようにするためのものです。

気にしていないと意外と知らない部分かもしれませんが、CT の公開ログを検索できる次のようなサイトも存在しており、ドメイン名を入力すると、そのドメイン下で過去に証明書が発行された FQDN を簡単に調べられます。

第三者から監視・検証できるようにすることで透明性が得られる（とされる）一方で、ドメイン名から FQDN がわかるだけでなく、探し方を工夫すると共通のサブドメインを持つ世界中の FQDN がわかってしまうこともあって、サブドメインの存在を秘匿できずに悪意ある第三者にとっての情報源になってしまう懸念もあり、当然いろいろな議論はあるようです。

だからといって一利用者が何かをできるわけでもないのですが、少なくとも、現状はそういう仕様であることは認識しておくとよいですね、というお話でした。

余談は以上です。

@kurokobo

くろいです。ギターアンサンブルやら音響やらがフィールドの IT やさんなアルトギター弾き。たまこう 48 期ぎたさん、SFC '07 おんぞう、新日本ギターアンサンブル、Rubinetto。今は野良気味。

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です