App Service/Static Web Appsにおけるカスタムドメインの構成と一般的なデジタル証明書の発行プロセスの対応について
はじめに
App ServiceやStatic Web Appsでは既定のドメインとしてazurewebsites.netであったりazurestaticapps.netといったURLでHTTPSの暗号化に対応した通信ができています。
しかしながら、すでに運用している既存のドメインでApp ServiceやStatic Web Appsのサイトも運用したいといった要求は当然にしてあります。
今回はこうした手順とともに一般的なデジタル証明書の発行プロセスに対応づけた説明をしていきたいと考えています。
なお、Azureサービス側で必ずしもそのような動作になっているということではなく概念的にこのような操作に結びつけられると考えるというお話しだということだということで了承ください。
カスタムドメインを構成する
まずは、App Service/Static Web Appsでどのようなカスタムドメインを使用するかを設定します。
例えば、Static Web Appsならばここです。
サービス側にどのドメインで使いたいかを設定します。
一般的なデジタル証明書の発行プロセスですとこれはCSRと秘密鍵の生成プロセスに相当すると考えられます。
そうすると、App Service/Static Web Appsから設定したドメインを所有していることの証明としてCNAMEレコードとTXTレコード(オプションだけどもセキュリティ的な意味合いから設定することを強く推奨)について指定通りの設定値にするように指示されます。
これは、一般的なデジタル証明書の発行プロセスですとドメイン所有の証明プロセスであると考えられます。
そもそも、サーバ証明書にはドメインの所有権のみを審査する証明書、さらにそれに加えて運営の実在性を審査した証明書、さらにその確認方法が国際的な基準で定められているEV証明書といわれるものが存在します。
今回、App Serviceなどで発行される証明書はドメインの所有権のみを審査してます。
DNSレコードを作成する
CNAMEレコードまたはAレコードを使ってカスタムDNS名をApp Sercie/Static App Serviceにマップします。
検証
App Sercie / Static App Service側で検証作業をします。
正しく構成された場合は、一般的な認証プロセスで言うと認証局が自身の秘密鍵を使ってCSRに電子署名をしてデジタル証明書をつくりApp Service/Static Web Appsに設定した状態と考えられます。
まとめ
一般的なドメイン証明書の発行プロセスといえば、ドメインの所有権を確かに持っているということを証明するというプロセスに他なりません。
例えば、ここに上げたとおり、DNSのレコードに指定通りの文字列を書き込めるとか、Webサーバーの指定の箇所に指定のファイルをおけるとか指定のアドレスから指定のアドレスにメールを送信できるなどで所有権を証明することをしてきました。
App Sercie/Static App Serviceではこのドメインの所有権をDNSのレコードに指定の文字列を書き込めるということで証明するという手段をとっています。
Discussion