次の方法で共有


カスタム ルート CA を使用して Azure Application Gateway の自己署名証明書を生成する

Application Gateway v2 SKU では、信頼されたルート証明書を使用して、バックエンド サーバーとの TLS 接続を許可します。 このプロビジョニングにより、v1 SKU で必要だった認証証明書 (個々のリーフ証明書) の使用が削除されます。 この "ルート証明書" は、バックエンド証明書サーバーからの Base-64 エンコード X.509(.CER) 形式のルート証明書です。 サーバー証明書を発行したルート証明機関 (CA) が識別され、サーバー証明書が TLS/SSL 通信に使用されます。

Application Gateway は、よく知られている CA (GoDaddy や DigiCert など) によって署名されている Web サイトの証明書を既定で信頼します。 その場合は、ルート証明書を明示的にアップロードする必要はありません。 詳細については、「Application Gateway での TLS 終了とエンド ツー エンド TLS の概要」を参照してください。 ただし、開発/テスト環境があり、検証済みの CA 署名付き証明書を購入したくない場合は、独自のカスタム ルート CA とそのルート CA によって署名されたリーフ証明書を作成できます。

Note

自己生成証明書は既定では信頼されないため、メインに含めるのが難しい場合があります。 また、強力でない可能性のある旧式のハッシュや暗号スイートが使用される場合もあります。 セキュリティを強化するには、よく知られている証明機関によって署名された証明書を購入してください。

次のオプションを使用して、バックエンド TLS 接続用のプライベート証明書を生成できます。

  1. ワンクリックのプライベート 証明書ジェネレーター ツールを使用します。 指定した doメイン 名 (共通名) を使用して、このツールは、この記事に記載されている手順と同じ手順を実行して、ルート証明書とサーバー証明書を生成します。 生成された証明書ファイルを使用すると、すぐにルート証明書 (.CER) ファイルをゲートウェイのバックエンド設定と対応する証明書チェーン (.PFX) をバックエンド サーバーに送信します。 PFX ファイルのパスワードは、ダウンロードした ZIP ファイルにも指定されます。

  2. OpenSSL コマンドを使用して、ニーズに応じて証明書をカスタマイズおよび生成します。 これを完全に自分で行う場合は、この記事の指示に従ってください。

この記事では、次のことについて説明します。

  • 独自のカスタム証明機関を作成する
  • カスタム CA によって署名された自己署名証明書を作成する
  • Application Gateway に自己署名ルート証明書をアップロードしてバックエンド サーバーを認証する

前提条件

  • Windows または Linux を実行しているコンピューター上の OpenSSL

    証明書の管理に使用できるツールは他にもありますが、このチュートリアルでは OpenSSL を使用します。 OpenSSL は、Ubuntu など、多くの Linux ディストリビューションにバンドルされています。

  • Web サーバー

    たとえば、Apache、IIS、NGINX などで証明書をテストします。

  • Application Gateway v2 SKU

    まだアプリケーション ゲートウェイを使用していない場合は、「クイック スタート: Azure Application Gateway による Web トラフィックのルーティング - Azure portal」を参照してください。

ルート CA 証明書を作成する

OpenSSL を使用してルート CA 証明書を作成します。

ルート キーを作成する

  1. OpenSSL がインストールされているコンピューターにサインインし、次のコマンドを実行します。 これにより暗号化されたキーが作成されます。

    openssl ecparam -out contoso.key -name prime256v1 -genkey
    

ルート証明書を作成して自己署名する

  1. 次のコマンドを使用して、証明書署名要求 (CSR) を生成します。

    openssl req -new -sha256 -key contoso.key -out contoso.csr
    
  2. プロンプトが表示されたら、ルート キーのパスワード、カスタム CA (国または地域、都道府県、組織、OU など) の組織情報、完全修飾ドメイン名 (発行者のドメイン) を入力します。

    create root certificate

  3. 次のコマンドを使用して、ルート証明書を生成します。

    openssl x509 -req -sha256 -days 365 -in contoso.csr -signkey contoso.key -out contoso.crt
    

    上のコマンドで、ルート証明書が作成されます。 これを使用して、サーバー証明書に署名します。

サーバー証明書を作成する

次に、OpenSSL を使用してサーバー証明書を作成します。

証明書のキーを作成する

次のコマンドを使用して、サーバー証明書のキーを生成します。

openssl ecparam -out fabrikam.key -name prime256v1 -genkey

CSR (証明書署名要求) を生成する

CSR は、証明書を要求するときに CA に与えられる公開キーです。 CA は、この特定の要求に対して証明書を発行します。

Note

サーバー証明書の CN (共通名) は、発行者のドメインと別のものである必要があります。 たとえば、この例では、発行者の CN は www.contoso.com で、サーバー証明書の CN は www.fabrikam.com です。

  1. 次のコマンドを使用して CSR を生成します。

    openssl req -new -sha256 -key fabrikam.key -out fabrikam.csr
    
  2. プロンプトが表示されたら、ルート キーのパスワード、カスタム CA の組織情報 (国または地域、都道府県、組織、OU、完全修飾ドメイン名) を入力します。 これは Web サイトのドメインであり、発行者とは別のものにする必要があります。

    Server certificate

CSR とキーを使用して証明書を生成し、CA のルート キーで署名する

  1. 次のコマンドを使用して、証明書を作成します。

    openssl x509 -req -in fabrikam.csr -CA  contoso.crt -CAkey contoso.key -CAcreateserial -out fabrikam.crt -days 365 -sha256
    

新しく作成された証明書を検証する

  1. 次のコマンドを使用して、CRT ファイルの出力を印刷し、その内容を検証します。

    openssl x509 -in fabrikam.crt -text -noout
    

    Certificate verification

  2. ディレクトリ内のファイルを検証し、次のファイルがあることを確認します。

    • contoso.crt
    • contoso.key
    • fabrikam.crt
    • fabrikam.key

Web サーバーの TLS 設定で証明書を構成する

Web サーバーで fabrikam.crt ファイルと fabrikam.key ファイルを使用して TLS を構成します。 Web サーバーで 2 つのファイルを受け取ることができない場合は、OpenSSL コマンドを使用して、単一の .pem または .pfx ファイルに結合することができます。

IIS

証明書をインポートし、IIS のサーバー証明書としてアップロードする方法については、「インポートした証明書を Windows Server 2003 の Web サーバーにインストールする方法」を参照してください。

TLS バインドの手順については、「IIS 7 で SSL を設定する方法」を参照してください。

Apache

次の構成は、Apache で SSL 用に構成された仮想ホストの例です。

<VirtualHost www.fabrikam:443>
      DocumentRoot /var/www/fabrikam
      ServerName www.fabrikam.com
      SSLEngine on
      SSLCertificateFile /home/user/fabrikam.crt
      SSLCertificateKeyFile /home/user/fabrikam.key
</VirtualHost>

NGINX

次の構成は、TLS 構成での NGINX サーバー ブロックの例です。

NGINX with TLS

サーバーにアクセスして構成を確認する

  1. ご利用のマシンの信頼できるルート ストアにルート証明書を追加します。 Web サイトにアクセスするときに、証明書チェーン全体がブラウザーに表示されることを確認します。

    Trusted root certificates

    Note

    DNS の構成によって、Web サーバー名 (この例では www.fabrikam.com) から Web サーバーの IP アドレスが得られるようになっていることが前提です。 そうでない場合は、ホスト ファイルを編集して名前を解決することができます。

  2. Web サイトを参照し、ブラウザーのアドレス ボックスにあるロック アイコンをクリックして、サイトと証明書の情報を確認します。

OpenSSL を使用して構成を検証する

OpenSSL を使用して証明書を検証することもできます。

openssl s_client -connect localhost:443 -servername www.fabrikam.com -showcerts

OpenSSL certificate verification

ルート証明書を Application Gateway の HTTP 設定にアップロードする

Application Gateway に証明書をアップロードするには、.crt 証明書を Base-64 エンコード形式の .cer にエクスポートする必要があります。 .crt には既に Base-64 エンコード形式の公開キーが含まれているため、ファイル拡張子の名前を .crt から .cer に変更するだけです。

Azure Portal

信頼されたルート証明書をポータルからアップロードするには、[バックエンド設定] を選択し、[バックエンド プロトコル][HTTPS] を選択します。

Screenshot of adding a certificate using the portal.

Azure PowerShell

Azure CLI または Azure PowerShell を使用して、ルート証明書をアップロードすることもできます。 次のコードは Azure PowerShell のサンプルです。

Note

次のサンプルでは、バックエンド プールとリスナーが既に存在すると仮定して、信頼されたルート証明書をアプリケーション ゲートウェイに追加し、新しい HTTP 設定を作成して、新しい規則を追加します。

## Add the trusted root certificate to the Application Gateway

$gw=Get-AzApplicationGateway -Name appgwv2 -ResourceGroupName rgOne

Add-AzApplicationGatewayTrustedRootCertificate `
   -ApplicationGateway $gw `
   -Name CustomCARoot `
   -CertificateFile "C:\Users\surmb\Downloads\contoso.cer"

$trustedroot = Get-AzApplicationGatewayTrustedRootCertificate `
   -Name CustomCARoot `
   -ApplicationGateway $gw

## Get the listener, backend pool and probe

$listener = Get-AzApplicationGatewayHttpListener `
   -Name basichttps `
   -ApplicationGateway $gw

$bepool = Get-AzApplicationGatewayBackendAddressPool `
  -Name testbackendpool `
  -ApplicationGateway $gw

Add-AzApplicationGatewayProbeConfig `
  -ApplicationGateway $gw `
  -Name testprobe `
  -Protocol Https `
  -HostName "www.fabrikam.com" `
  -Path "/" `
  -Interval 15 `
  -Timeout 20 `
  -UnhealthyThreshold 3

$probe = Get-AzApplicationGatewayProbeConfig `
  -Name testprobe `
  -ApplicationGateway $gw

## Add the configuration to the HTTP Setting and don't forget to set the "hostname" field
## to the domain name of the server certificate as this will be set as the SNI header and
## will be used to verify the backend server's certificate. Note that TLS handshake will
## fail otherwise and might lead to backend servers being deemed as Unhealthy by the probes

Add-AzApplicationGatewayBackendHttpSettings `
  -ApplicationGateway $gw `
  -Name testbackend `
  -Port 443 `
  -Protocol Https `
  -Probe $probe `
  -TrustedRootCertificate $trustedroot `
  -CookieBasedAffinity Disabled `
  -RequestTimeout 20 `
  -HostName www.fabrikam.com

## Get the configuration and update the Application Gateway

$backendhttp = Get-AzApplicationGatewayBackendHttpSettings `
  -Name testbackend `
  -ApplicationGateway $gw

Add-AzApplicationGatewayRequestRoutingRule `
  -ApplicationGateway $gw `
  -Name testrule `
  -RuleType Basic `
  -BackendHttpSettings $backendhttp `
  -HttpListener $listener `
  -BackendAddressPool $bepool

Set-AzApplicationGateway -ApplicationGateway $gw

アプリケーション ゲートウェイのバックエンドの正常性を確認する

  1. アプリケーションゲートウェイの [バックエンド正常性] ビューをクリックして、プローブが正常であるかどうかを確認します。
  2. HTTPS プローブの状態が正常であることがわかるはずです。

HTTPS probe

次のステップ

Application Gateway の SSL/TLS の詳細については、「Application Gateway での TLS 終了とエンド ツー エンド TLS の概要」を参照してください。