[アップデート] AWS Certificate Manager (ACM) の新しい HTTP 検証パブリック証明書を使ってみた
いわさです。
AWS Certificate Manager (ACM) で発行した証明書は、対象ドメインの所有権を検証する必要があります。
これまで DNS 検証と E メール検証がサポートされていたのですが、先日のアップデートで新たに HTTP 検証が追加されました。
本日はこの HTTP 検証証明書を実際に使ってみたので、検証手順や使い方などを紹介します。
証明書の発行
まず初めに一番重要な点ですが、この HTTP 検証タイプの証明書は、先日実装された CloudFront のマルチテナントディストリビューション機能の利用が前提となります。
この中でディストリビューションテナントを作成する際にテナントごとにドメインを指定する形になるのですが、そのドメインがマルチテナントディストリビューションで共有されている証明書をカバーされていない場合に、自動で HTTP 検証タイプの証明書が発行されます。
本日時点では ACM コンソールや API から手動でこのタイプの証明書を発行することは出来ません。手動で発行できるのは従来どおりの DNS 検証と E メール検証のみです。
実際に発行してみましょう。
ディストリビューションテナントの追加時に、テナント固有の発行済み証明書を選択せずに、かつマルチテナントディストリビューションでカバーされていない証明書を指定してみます。
私の場合はマルチテナントディストリビューションでは*.tak1wa.com
というワイルドカード証明書を使っていました。全く関係のないtenant3.hoge-iwasa.net
という別のドメインを指定してみます。
そうすると「This domain isn't covered by a certificate.」と表示されましたね。
そして下部には「Domain ownership verification required」というメッセージも表示されました。ドメイン所有権の検証が必要ということです。
テナント追加後、ドメインの検証が必要だと表示されていますね。ちなみにこの状態だと CloudFront のエンドポイントとしてまだ認識されておらず、Route 53 上でもエイリアスレコードとして参照が出来ていない状態になります。
ACM のコンソールを見てみると、バージニア北部に新しい未検証の証明書が発行されていることが確認できると思います。
発行までの流れはこんな感じです。
証明書の検証
では、次は発行された証明書を検証してみましょう。
発行された証明書を確認してみると、検証するための情報としてリダイレクト元、リダイレクト先の2つの情報があります。
今 CloudFront でホスティングしているかどうかにかかわらず、ACM はこのリダイレクト元の URL にアクセスし、リダイレクト先テキストファイルの内容が取得できるかどうかを検証しています。
よって、このリダイレクト元のパスに対してリダイレクト先への転送設定をしてやることで検証できる状態になります。
このリダイレクト設定ですが、手動設定と自動設定の2つがあります。
ざっくり言うと手動設定は運用中のドメインに対してダウンタイムが発生しないように証明書だけ発行するために使い、自動設定はこれから使う新しいドメインに対していきなり CloudFront 上で検証まで自動設定する方法です。
どちらのパターンも試してみたので紹介します。
手動で検証
まずは手動検証の場合です。
運用中を想定し、CloudFront ではなく ALB で何か Web サイトをホスティングしている想定で次のようにロードバランサーを作成し、カスタムドメインのエイリアスレコードがこのエンドポイントを指すように構成済みです。
適当な静的レスポンスを返しています。
% curl http://hoge0501alb.tak1wa.com/
hoge
CloudFront のディストリビューションテナントで同じドメインを指定します。
証明書の検証などが必要なので、バナーの「Complete domain setup」を押します。
今回のように使用済みのドメインのためにダウンタイムを許容できない場合、「I have existing traffic」を選択します。
ドメイン検証方法を選択します。
ドメイン証明のために、対象ドメインを使って検証用トークンに HTTP アクセスできる状態にすれば良いので、前述のようにリダイレクトさせても良いですし、検証用トークンファイルを対象パスに埋め込んでも良いです。
「Manual file upload」を選択すると検証用のトークンファイルが取得できるので、それを Web サイト上に配置します。
今回は次のリダイレクトを使いました。
先ほどの ACM で確認した内容と同じですが、ACM 用の URL へリダイレクト設定を行ってやります。
今回は ALB を使っているのでリスナールールでリダイレクト設定をしました。
% curl http://hoge0501alb.tak1wa.com/.well-known/pki-validation/2fef7070270bd05cfd392252752387bb.txt -I
HTTP/1.1 301 Moved Permanently
Server: awselb/2.0
Date: Wed, 30 Apr 2025 20:35:47 GMT
Content-Type: text/html
Content-Length: 134
Connection: keep-alive
Location: https://validation.us-east-1.acm-validations.aws:443/550669467088/.well-known/pki-validation/2fef7070270bd05cfd392252752387bb.txt
設定後しばらく先ほどのディストリビューションのドメイン検証画面で待つと、証明書の検証に成功しました。
ACM にコンソール上も「発行済み」ステータスに更新されています。
ここまでで証明書の発行が完了しました。
あとは CloudFront にドメイン検証できるようにして証明書の適用を行います。
コンソールで設定方法が表示されるのですが、_cf-challenge.example.com
の TXT レコードでディストリビューションエンドポイントを指してやります。
あとは発行された証明書を Apply します。
これで証明書が適用され使用できる状態になりました。
この時点ではまだ、対象ドメインのエイリアスレコードは旧環境(ALB)を指した状態です。
移行の準備が整ったら、最後に名前解決先を変更して完了です。
ダウンタイムなしで証明書やディストリビューションエンドポイントの検証を済ませることが出来ましたね。
自動で検証
次は自動で検証を行ってみます。
こちらはまだドメインが未使用だったり、ドメイン検証中のダウンタイムが許容できる場合に使うことが出来ます。
Lightsail に別のドメインと DNS があったので、そちらにドメインへのレコードを作成します。
今度はディストリビューションテナントのドメイン検証で「I don't have traffic yet」を選択します。
数分かかりますが、あとは勝手にドメイン検証の必要な処理を行ってくれます。待ちましょう。
少し待つとドメイン検証が終わり、証明書が利用できるようになりました。
ACM コンソールから見てみると発行済みステータスになっていますね。なぜか2つ発行されているのが気になりますが。
先ほどと同じように証明書がディストリビューションに適用され、使用可能な状態になりました。
確認してみると、検証トークンが自動で設定されていることがわかります。
こちらはリダイレクトではなくトークン値がそのまま埋め込まれていますね。ちなみにディストリビューションの各設定を確認してみましたが、それらしい設定は確認出来なかったので内部的に設定されているようです。
% curl https://tenant3.hoge-iwasa.net/.well-known/pki-validation/d628d08a120e860e0b098e60232688fd.txt -i
HTTP/2 200
content-type: application/json
content-length: 32
date: Wed, 30 Apr 2025 20:23:13 GMT
x-amzn-trace-id: Root=1-681286b1-08d1c0e916d99548571f955b
x-amzn-requestid: 130c4ca4-de2c-47e6-925c-ac49079b2d3e
x-amz-apigw-id: J2n7vGxYoAMEDeA=
x-cache: Miss from cloudfront
via: 1.1 0d3f57e6ba69d6dd9b6fa0186088b98c.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT57-P6
x-amz-cf-id: CHdU2xW0MZIvYHr_ynKZY9Cesb558ZKPKMn6loq3748cJXVcvhFnUQ==
27faf575cfcd40ae92905fc7c400fc8d%
さいごに
本日は AWS Certificate Manager (ACM) の新しい HTTP 検証パブリック証明書を使ってみました。
独自ドメインのテナントが大量に作成されるような使い方だと、個別に ACM 発行するよりある程度自動でやってくれるこの機能のほうが便利かもしれませんね。
本日時点ではマルチテナントディストリビューション向けの機能ですが、DNS サーバーに触れない状態とかでも検証できるので、マルチテナント以外でも発行できるようにしてもらっても良いなと思いました。