次の方法で共有


カスタム ルート 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 によって署名されたリーフ証明書を作成できます。

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

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

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

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

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

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

[前提条件]

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

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

  • 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. メッセージが表示されたら、ルート キーのパスワードと、国/地域、州、組織、OU、完全修飾ドメイン名 (発行者のドメイン) などのカスタム CA の組織情報を入力します。

    ルート証明書を作成する

  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 は、この特定の要求に対して証明書を発行します。

サーバー証明書の 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 サイトのドメインであり、発行者とは異なる必要があります。

    サーバー証明書

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
    

    証明書の検証

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

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

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

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

IIS

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

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

アパッシュ

次の構成は、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 サーバー ブロック の例です。

TLS を使用した NGINX

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

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

    信頼されたルート証明書

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

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

OpenSSL を使用して構成を確認する

または、OpenSSL を使用して証明書を確認できます。

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

OpenSSL 証明書の検証

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

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

Azure Portal

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

ポータルを使用して証明書を追加するスクリーンショット。

Azure PowerShell

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

次の例では、信頼されたルート証明書をアプリケーション ゲートウェイに追加し、新しい 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 プローブ

次のステップ

Application Gateway での SSL\TLS の詳細については、Application Gateway での TLS 終了とエンド ツー エンド TLS の概要に関するページを参照してください。