はじめに
本記事は AEON Advent Calendar 2025 および エーピーコミュニケーションズ Advent Calendar 2025 の17日目の記事です。
ここ数年、AzureをTerraformやら手作業やらで触ったり調べたりする機会が非常に多く、Azureのイイところも悪いところも経験してきているなあ、と実感しているのですが、
その中でも結構クセがあるって分かりにくいな、と感じているのが証明書管理系のサービスです。
自分がうまく使えてないだけの可能性もあるので、自身の理解をまとめて知見の共有がてら、「お前の使い方は間違っている」的なマサカリがあったら嬉しい悲鳴を上げようと思っています。
なお、AWSやGoogle Cloudも多少は触ったことがあるのですが、証明書系はほぼ触ってないので特に比較は行いません。他所だったらこれができるよ、みたいな話もいただけると嬉しいです。
前置きが長くなってきたので始めたいと思います。
Azureの証明書管理サービス
Azureには主に以下のような証明書管理サービスがあります。
- App Service 証明書
- Azure マネージド証明書
- （Azure Key Vault）
それぞれサービス特性やクセもあるので1つ1つ解説していきたいと思います。
1. App Service 証明書
Azureで証明書を作成しよう、と考えたとき、まず最初に挙がるのが App Service 証明書 だと思います。
GoDaddyから証明書の購入から、証明書の保持、自動更新などを一括でやってくれるサービスです。
もちろん証明書機関から購入なので、証明書の購入費用も発生します。
App Service 証明書で作成した証明書ファイル自体の格納はAzure Key Vaultに格納します。
Azure Key Vaultは証明書以外にもパスワードなどのシークレット文字列や暗号化鍵の保管やローテーションもでき、Azure内の他サービスとデータ内容を意識することなく連携できるのがいいところですね。
ここだけ聞くといい感じの連携がされているのですが、実は証明書更新のタイミングで陥りやすい罠があります…
Key Vaultが扱うオブジェクト種別が微妙にかみ合わない
前述したKey Vaultが扱うキー、シークレット、証明書という各種データストアがありますが、Azureサービスによって連携できるオブジェクトストアが違います。
App ServiceやApplication GatewayなどのWebサービスで証明書をバインドしたい場合は、主に証明書ストアからバインドする証明書を選択することになります。
しかし、App Service 証明書が格納されるのはKey Vaultの証明書…ではなくシークレットストアです。
簡単に図にするとこのような形です。
図のようにApplication Gatewayなど一部のサービスはAzure Portalで操作すると証明書ストアを参照しますが、コマンドやAPIを利用するとシークレットストアを参照することができます。
証明書を参照するために、Key Vault 内ではシークレット識別子が Application Gateway によって使用されます。 Azure PowerShell、Azure CLI、または Azure Resource Manager の場合、バージョンを指定しないシークレット識別子を使用することを強く推奨します。 このようにすると、キー コンテナー内で新しいバージョンが使用可能な場合、Application Gateway が証明書を自動的にローテーションします。 バージョンのないシークレット URI の例は https://myvault.vault.azure.net/secrets/mysecret/ です。 次のセクションで提供されている PowerShell の手順を参照できます。
Azure portal では、シークレットではなく Key Vault 証明書のみがサポートされます。 Application Gateway は引き続き Key Vault からのシークレットの参照をサポートしますが、PowerShell、Azure CLI、API、Azure Resource Manager テンプレート (ARM テンプレート) など、ポータル リソース以外を使用している場合のみに限られます。 Application Gateway で使用できるようにするには、Key Vault 証明書にエクスポート可能な秘密キーが必要です。
上記のようなシークレットストアを参照できるものはシークレットストアを利用させ、証明書ストアを利用しないといけない場合はシークレットストアに格納された証明書をエクスポートして証明書ストアにアップロードする必要があります。
これを更新の度に実施するのは、やり忘れそうで本当に怖いですね。
手動だけでなく、自動化することも可能なものではありますが、マネージドでやってほしいな、と思う部分ですね。
実際に、シークレットストアを参照しているつもりが証明書ストアを参照していて、自動更新されずに有効期限切れエラーが表示されてしまった、ということもありました…
証明書の自動更新が全自動で発動しない場合がある
また、ここは認証機関のGoDaddyの仕様のようなので受け入れるしかありませんが、395日以上ドメイン検証を実施していない証明書に関してはドメインの再検証を実施する必要があります。
ドメインの検証・再検証は対象ドメインに指定のTXTレコードを登録する方法の他、メール等で検証する方法もあります。
現行の証明書の有効期限はデフォルトで1年になっているので、証明書を作成した翌年は自動更新されますが、2年後は395日を過ぎているので、ドメインの再検証が必要になります。
また、ドメインの再検証は395日以降なら実施しておくことは可能ですが、
2年目の有効期限が切れる30日より前に再検証を実施した場合、次の更新は自動更新になりますが、さらに翌年は再検証が必要になります。
2年目の有効期限が切れる30日以内に再検証を実施した場合は、2回分は自動更新できるので、いつ再検証を実施するかはきちんとルール化しておいた方が良いと思います。
今後証明書の有効期間を半年、3か月と短くしていく動きが出てくることが各所で予告されていますが、
App Service証明書にも適用された場合は、いつドメインの再検証を実施するかも今後考えていく必要があるでしょう。
2. Azure マネージド証明書
次にAzureのマネージド証明書です。
マネージド証明書のような総称は実際にはないようで私が勝手につけたものですが、
代表的なものはApp Service マネージド証明書ですね。（会話してるとApp Service 証明書とゴッチャになります…）
他にもContainer AppsやFront Doorなどにもそれぞれのマネージド証明書がありますが、私はあまり扱ったことがないので、基本的にはApp Service マネージド証明書のことを取り上げます。
App Service マネージド証明書はDigiCertが発行する証明書を利用できますが、ある程度の制約はありますが、なんと無料で利用できます。
制約としては、以下のようなものがあります。
- 証明書を割り当てるApp Serviceが必要になる
- （ルートドメインの場合は）パブリックアクセスできるアプリ上にある必要がある
- 証明書のエクスポートは不可
- 最大 64 文字、英数字、ダッシュ (-)、ピリオド (.) のみのカスタム ドメインをサポート
- ワイルドカード証明書はサポートされない
- プライベート DNS はサポートされない
最後の「プライベート DNS はサポートされない」を補足すると、
（App Service証明書でも登場した）ドメイン検証をするときにTXTレコードやCNAMEレコードを登録するのですが、
これはAzureのプライベートDNSのような限られたネットワークでしか参照できないDNSではなく、パブリックなDNSにレコードを登録する必要がある、という意味になります。
Application GatewayをL7ロードバランサーを配置して、そのバックエンドとしてApp Serviceなどの各種アプリを配置するという構成が多いですが、
通常はApplication GatewayのリスナーはカスタムドメインにしてバックエンドのApp Serviceはデフォルトのドメインである azurewebsites.net で名前解決できれば、ドメインの不一致はありますがアクセスには問題ありませんでした。
しかし、OAuth2.0等を利用してリダイレクトをさせる場合などは、カスタムドメインが必要になり、証明書も必要になって、App Service 証明書が1．のように運用コストがかかってしまう、という場合にApp Service マネージド証明書を使っていました。
App Service マネージド証明書に関する仕様変更が二転した
今年の下半期にApp Service マネージド証明書に関する仕様変更が二度ありました。
凄くざっくりに言うと、
- 2025年7月にApp Service マネージド証明書の作成・更新にパブリックアクセスが必要になった
- 2025年11月にApp Service マネージド証明書の作成・更新にパブリックアクセスが不要になった
ということがありました。
最初のパブリックアクセスが必要になった経緯としては、以下のようなDigiCertのセキュリティ強化のための仕様変更があったことに起因しています。
制約の2つ目に書いた「（ルートドメインの場合は）パブリックアクセスできるアプリ上にある必要がある」がサブドメインにも適用されるようになりました。
厳密には、ドメイン検証プロセスの透明性と説明責任を強化するために、DigiCertから実アプリの特定のエンドポイント（https://<hostname>/.well-known/pki-validation/fileauth.txt）にアクセスできる必要がなる、ということでした。
上記の構成のように、フロントにApplication Gatewayを配置していたので、App service は基本的にはプライベートエンドポイントを使用したプライベート通信のみ許可していたので、見事に直撃してしまいました。
そのため、App Service 証明書に切り替えるなどの検討をしていました。
そして、証明書の期限が迫ってきてサポートに念のための再確認を行ったところ、11月に仕様変更に対するアップデートがあり、
サイトでパブリック アクセスがブロックされている場合でも、先ほどのDigiCertからの実アプリの特定のエンドポイント（https://<hostname>/.well-known/pki-validation/fileauth.txt）へのアクセス要求のみ、App Service によって許可されるようになり、パブリックアクセスが必須ではなくなったということです。
なお、この処理はApp Serviceのフロントエンド（内部的に利用されているL7ロードバランサーの層）で処理されるため、実際にアプリが稼働しているワーカーインスタンスには到達しない、ということでした。
本件はこれで一件落着、となったのですが、仕様変更に振り回されて構成変更を迫られるのは、精神衛生上良くない体験ではありました…
3. Azure Key Vault
1.でApp Service 証明書のバックエンド的な紹介をしたKey Vaultですが、Key Vaultにも証明書を生成する機能があります。
生成できる証明書は
- 自己発行証明書（いわゆるオレオレ証明書）
- 統合されていない CA によって発行された証明書
- 統合された CA (DigiCert/GlobalSign)によって発行された証明書
自信で利用したことがあるのは自己発行証明書のみなのであまり語れることはないですが、
DigiCertと連携させる場合はDigiCert CertCentralのアカウントを作成し、APIキー等を設定することで証明書の生成や自動更新ができる、ということです。
まとめ
通常のリソースであれば作成時やアプリのデプロイ・テスト時にエラーを発見して修正する、という即時性がありますが、
証明書に関しては1年2年という時間経過してから問題を発覚することがある、という特異なものだと思います。
実際のトラブル発生時は何が問題か分からないところから最近のデプロイや構成の変更などの様々な情報の中から証明書の更新失敗などに気づく必要があるので、日頃から更新のタイミングを把握しておいたりと証明書の存在を頭の片隅に置いておく必要がある、と感じました。