Azure Application Gatewayでのクライアント証明書認証の設定方法

クライアントセキュリティ技術情報

2025年06月27日 2025年06月27日

近年、ゼロトラストアーキテクチャの考え方が広がる中で、社内外からのアクセスを安全に制御する仕組みとして、ロードバランサーでの相互TLS（mTLS）が注目されています。業務システムや社内ポータルなどへのアクセス制御をより強固にするためには、ネットワーク境界での認証・検証が不可欠です。そこで、今回は、Microsoft Azureの負荷分散サービスであるAzure Application Gateway（以下、「App Gateway」）にて、弊社のクライアント証明書サービス「マネージドPKI Lite byGMO」で発行したテスト証明書での相互TLS（mTLS）を検証しましたので、その設定方法とその設定後の結果を紹介します。

初めに
App GatewayのTLS化
クライアント証明書認証の有効化
Webアプリケーションへの証明書情報の送信
アクセス結果
まとめ

初めに

事前準備として、Azure VM インスタンス（Ubuntu + Apache）で構築したWebサーバの前段にApp Gatewayを配置する構成を作成しておきます。

簡単ですが、今回は以下の構成になります。
なお、App Gatewayのレベルは「Standard V2」となっております。（「Basic」では相互TLSは利用できません）この時点では、クライアントPCとApp Gatewayはhttpで通信を行っている状態とします。

App GatewayのTLS化

それでは、App GatewayのTLS化の設定をしていきます。

まずはApp Gatewayでhttpsをリッスンするようにしていきます。

① Azure管理コンソールからApp Gatewayメニューにアクセスし対象のゲートウェイを選択し、リスナーの追加をおこないます。
左ペインの「リスナー」をクリックし、「＋リスナーの追加」をクリックします。

② httpsをリッスンするためのリスナーを構成します。
サーバ証明書をアップロードします。
※サーバ証明書は、当社のサイトから45日間有効なテスト用のパブリック証明書が取得できます。

なお、AzureにアップロードするデータはPKCS#12形式である必要があります。秘密鍵と証明書（サーバ証明書および中間CA証明書）をPKCS12ファイルにまとめる場合はOpenSSLなどで行なうことが可能です。


openssl pkcs12 -export -out servercert.pfx \
-in /path/to/certificate.cer ¥
-inkey /path/to/private.key ¥
-certfile /path/to/intermediate-ca.cer \
-password pass:MySecurePassword123

※45日間有効なテスト用のパブリックサーバ証明書の利用における中間CA証明書（上記のintermediate-ca.cer)はこちらにあります。

③ httpsリスナーを構成した後に、httpリスナーに割り当てたルールをhttpsリスナーに変更します。

④ この状態で保存すると、HTTPSリスナーが有効となってApp Gatewayがhttps対応となります。
あわせて、HTTPリスナーへのアクセスをHTTPSリスナーへのリダイレクトに変更しておきます。

クライアント証明書認証の有効化

次に、mTLS（クライアント証明書認証）を有効にします。

今回は、当社のテスト用クライアント証明書管理システムで発行した証明書を使用します。

① SSLプロファイルを作成します。

クライアント証明書を発行するCAの証明書をアップロードします。
CAチェーンには、今回はこちらにある２つの証明書をテキストエディタで開き、それぞれのテキストを結合します。


-----BEGIN CERTIFICATE-----
MIIFODCCBCCgAwIBAgIQeEqpED+lwQQhLxtUbFMdAjANBgkqhkiG9w0BAQsFADBU
(中間CA証明書データ、以下略)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIDkDCCAnigAwIBAgILBAAAAAABIVhTCKMwDQYJKoZIhvcNAQELBQAwVDEgMB4G
(ルート証明書データ、以下略)
-----END CERTIFICATE-----

② 次に、Azure管理コンソールで対象のApplication Gatewayの管理画面の左側メニューより「設定」から「SSL設定」をクリックし、「＋SSLプロファイル」をクリックします。
続けて、「Client Authentication」タブで、テキストを編集したファイルをアップロードし、追加します。

アップロード後は以下の画面になります。

③ HTTPSリスナーの設定画面に戻り、作成したSSLプロファイルをリスナーに割り当てます。

この変更が反映されるとmTLS化が行われ、ブラウザからのアクセス時にクライアント証明書が求められるようになります。

④ 失効確認をAzure CLlで有効化します。
※本記事の作成時点では、Azure Portal上で失効確認の有効化はできないようです。


az network application-gateway update -n 
 -g  --ssl-profiles [0].client-auth-configuration.verify-client-revocation=OCSP

verify-client-revocationには”OCSP”を設定します。(失効確認をしない場合は”None”を設定します。)
上記SSLプロファイルの[0]は、設定ファイルの"sslProfiles"の配列の位置になり([0]は先頭のもの) 、以下で確認できます。


az network application-gateway ssl-profile list --gateway-name  -g

以下のコマンドでSSLプロファイルの現在の設定内容を確認できます。


az network application-gateway ssl-profile show --gateway-name  -g 　--name

Webアプリケーションへの証明書情報の送信

Application Gatewayでは、クライアント証明書の検証をおこないますが、サブジェクトなどの証明書内容のチェックは行いません。

弊社のマネージドPKI Lite byGMO (共用のCAによるクライアント証明書発行サービス)では、サブジェクトOやOUが専用ベースDNで指定したものと一致するか確認する必要があるので、HTTPヘッダーにそれら情報を追加してバックエンドアプリなどで判定する必要があります。
※グローバルサインでは、プライベートCAによるクライアント証明書発行サービスも行っており、その場合はこの判定は必須ではありません。

① Azure管理コンソールで対象のApplication Gatewayの管理画面の左側メニューより「設定」から「書き換え」をクリックし、「＋書き換えセット」をクリックします。
次に、「書き換えセットの作成」内の「①名前と関連付け」から、作成する書き換えセットをすでに作成したルールに紐づけます。