AWS Certificate Manager（ACM）で証明書管理をしていた経験から、Azureにおける証明書発行やドメイン検証の仕組みに興味を持ちました。特にDNSレコードの種類や検証方法に違いがあり、クラウド間の設計の差が垣間見えて興味深いポイントです。
今回は、Azureの App Service 証明書を使って証明書を発行し、ドメインに適用するまでをやってみました。
事前作業に作成しておくリソース
・KeyVault
証明書からKeyVaultへの操作を可能にするため、アクセス許可モデルは「コンテナーのアクセスポリシー」を設定。
・DNSゾーン
testtomi.com
証明書を実際に発行してみる
証明書作成
まずApp Service証明書を作成していきます。
Azureポータルから「App Service 証明書」で検索
ネイキッドドメインのホスト名は、DNSゾーンで作成したドメインを指定します。
証明書名はリソース名のため、ホスト名と合わせる必要はありません。
証明書が作成され、状態は発行の保留中であることが確認できます。
証明書発行
発行のため、証明書の構成を行います。
左ペイン 設定>証明書 の構成 を選択し、手順1：格納をクリックします。
キーコンテナーから選ぶで事前に作成していたKeyVaultを選択してください。
証明書の構成タブに戻ると手順1：格納にチェックが付いてます。次に手順2：確認をクリックします。
ドメインの検証を選択すると、ドメイン確認トークンがTXTレコードに自動で追加されます。
DNSゾーンにTXTレコードが追加された後、ドメインの検証の画面に戻って確認を押下します。
通知でドメイン確認トークンの作成が表示されたら成功です。
画面更新かけると、証明書はドメイン確認済みになります。
証明書の構成タブに戻ると手順2：確認、手順3：割り当てに対して同時にチェックが付いてます。
ここまで完了するとApp Service 証明書が発行済みになりました！
TXTレコードかCNAMEレコードか
気になったのが証明書のドメインをレコードセットに登録する際の種類です。
Azureだとドメインの検証の際に、TXTレコードが自動的に追加されました。
公式ドキュメントも参考にしてみます。
対してAWSでACMを発行した時は、自動でCNAMEレコードに割り当てられました。
公式ドキュメントにも書いてありますし、
私が行った際もCNAMEレコードでした。
AzureではTXTレコード、AWSではCNAMEレコードと、証明書検証のDNSレコード種類に差異がありました。
今回は理由まで調べきれませんでしたが、この差異の背景についてはさらに調査・勉強していきます。
(2025/11/13 追記）
ご教示いただいた内容ありますので追記します。
ドメインの所有者であることの検証方法は標準化されておらず、事業者ごとに個別に実装されているのが現状かと思います。
昔から多くの事業者は、ドメインの頂点に TXT レコードを登録させて検証する方法を用いています。
頂点の TXT レコードはいろいろな値が設定され管理しにくくなっています。
試しに1つの@ のTXTレコードに3つの値を登録してみました。
3more record(s)のように複数の値が登録でき、確かに管理しにくそうです。
ACMのように特定のホスト名でのレコードを登録させる仕組みは、非常に健全で良いことだと思いますし、DNS応答が小さくなるというメリットもあります。
また、CNAME を使うようにすることで、事業者側の何らかの理由で値をロールオーバーする必要が出てきた際に、利用者側に手間をかけないで済むといったメリットがあり、特定のホスト名を使う良いところです。