次の方法で共有


証明書と App Service Environment v2

重要

この記事は、Isolated App Service プランで使用される App Service Environment v2 に関するものです。 App Service Environment v1 および v2 は、2024 年 8 月 31 日をもって廃止されます。 より強力なインフラストラクチャ上で実行できる、使いやすい新しいバージョンの App Service Environment があります。 新しいバージョンの詳細については、App Service Environment の概要に関するページから始めてください。 現在 App Service Environment v1 を使用している場合は、この記事の手順に従って新しいバージョンに移行ください。

2024 年 8 月 31 日の時点で、App Service Environment v1 および v2 ワークロードが運用環境内に残っている場合、これらは廃止された製品となるため、サービス レベル アグリーメント (SLA) とサービス クレジットは適用されなくなります。 App Service Environment v1 および v2 ハードウェアの廃止は開始されており、これにより、お使いのアプリやデータの可用性とパフォーマンスに影響が生じる可能性があります。

お客様は、App Service Environment v3 への移行をただちに完了する必要があります。そうしないと、アプリとリソースが削除される可能性があります。 Microsoft では、インプレース移行機能を使用して、残っている App Service Environment v1 と v2 の自動移行をベストエフォートで試みますが、自動移行後のアプリケーションの可用性については、いかなる主張および保証も行いません。 移行を完了し、ニーズに合わせて最適な App Service プラン SKU を選択するには、手動による構成が必要になる場合があります。 自動移行を実行できない場合、お使いのリソースとそれに関連するアプリ データは削除されます。 これらの極端なシナリオを両方とも回避するために、今すぐ対処することを強くお勧めします。

移行を完了するために時間的猶予が必要な場合は、30 日間の猶予期間を 1 回だけ要求することができます。 この猶予期間の詳細と要求方法については、猶予期間の概要を確認した後、Azure portal に移動し、お使いの各 App Service Environment の [移行] ブレードにアクセスしてください。

App Service Environment v1/v2 の提供終了に関する最新情報については、App Service Environment v1 と v2 の提供終了に関する更新情報の記事を参照してください。

App Service Environment (ASE) は、ご使用の Azure Virtual Network (VNet) 内で実行する Azure App Service のデプロイです。 これは、インターネットでアクセス可能なアプリケーション エンドポイントまたはご使用の仮想ネットワーク内にあるアプリケーション エンドポイントを使用してデプロイできます。 インターネットでアクセス可能なエンドポイントを使用して ASE をデプロイすると、そのデプロイは外部 ASE と呼ばれます。 仮想ネットワーク内にあるエンドポイントを使用して ASE をデプロイすると、そのデプロイは ILB ASE と呼ばれます。 ILB ASE の詳細については、ILB ASE の作成と使用に関するページを参照してください。

ASE は、シングル テナント システムです。 シングル テナントであるため、ASE でのみ利用でき、マルチテナント App Service では利用できない機能がいくつかあります。

ILB ASE 証明書

外部 ASE を使用している場合、アプリには <appname>.<asename>.p.azurewebsites.net でアクセスします。 既定では、ILB ASE を含め、すべての ASE が、その形式に従った証明書で作成されます。 ILB ASE がある場合、アプリには ILB ASE の作成時に指定したドメイン名に基づいて到達します。 アプリが TLS をサポートするためには、証明書をアップロードする必要があります。 内部証明機関を利用する、外部の発行者から証明書を購入する、自己署名証明書を使用する、のいずれかの手段で有効な TLS/SSL 証明書を取得します。

ILB ASE で証明書を構成するには、次の 2 つのオプションがあります。 ILB ASE に既定のワイルドカード証明書を設定するか、ASE 内の個別の Web アプリに証明書を設定します。 どちらを選択した場合でも、次の証明書属性を適切に構成する必要があります。

  • Subject: この属性は、ワイルドカード ILB ASE 証明書用に *.[your-root-domain-here] に設定する必要があります。 アプリ用に証明書を作成する場合は、これは [appname].[your-root-domain-here] にする必要があります。
  • Subject Alternative Name: この属性には、ワイルドカード ILB ASE 証明書用に、.[your-root-domain-here] と .scm.[your-root-domain-here] の両方を含める必要があります。 アプリ用に証明書を作成する場合は、これを [appname].[your-root-domain-here] と [appname].scm.[your-root-domain-here] にする必要があります。

3 番目のバリアントとして、ワイルドカード参照を使用する代わりに、証明書の SAN 内の個別のアプリ名をすべて含む ILB ASE 証明書を作成することができます。 この方法の問題は、ASE に配置するアプリの名前を事前にすべて把握しておく必要があることです。そうしないと、ILB ASE 証明書を常に更新し続ける必要があります。

ILB ASE に証明書をアップロードする

ポータルで ILB ASE が作成されたら、その ILB ASE 用に証明書を設定する必要があります。 証明書が設定されるまで、ASE には、証明書が設定されていないことを示すバナーが表示されます。

アップロードする証明書は .pfx ファイルである必要があります。 証明書がアップロードされた後、証明書が使用されるまで約 20 分間の遅延が発生します。

ASE の作成と証明書のアップロードは、ポータルで 1 つのアクションとして実行することはできません。また、1 つのテンプレートとしても実行できません。 別々のアクションとして、テンプレートからの ASE の作成に関するドキュメントに記載されているように、テンプレートを使用して証明書をアップロードすることはできます。

テストのために自己署名証明書をすばやく作成するには、次の少量の PowerShell を使用できます。

$certificate = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname "*.internal.contoso.com","*.scm.internal.contoso.com"

$certThumbprint = "cert:\localMachine\my\" + $certificate.Thumbprint
$password = ConvertTo-SecureString -String "CHANGETHISPASSWORD" -Force -AsPlainText

$fileName = "exportedcert.pfx"
Export-PfxCertificate -cert $certThumbprint -FilePath $fileName -Password $password

自己署名証明書を作成する場合、サブジェクト名を CN={ASE_NAME_HERE}_InternalLoadBalancingASE の形式にする必要があります。

アプリケーション証明書

ASE でホストされているアプリは、マルチテナント App Service で利用できるアプリ中心の証明書機能を使用できます。 これには次のような機能が含まれます。

  • SNI 証明書
  • IP ベースの SSL。外部 ASE でのみサポートされます。 ILB ASE では、IP ベースの SSL はサポートされていません。
  • KeyVault がホストされている証明書

これらの証明書をアップロードおよび管理する手順については、「Azure App Service で TLS/SSL 証明書を追加する」を参照してください。 Web アプリに割り当てたカスタム ドメイン名と一致するように証明書を構成するだけの場合は、これらの手順で十分です。 既定のドメイン名を使用して ILB ASE Web アプリ用に証明書をアップロードする場合は、前述のとおり、証明書の SAN 内の scm サイトを指定します。

TLS の設定

TLS の設定は、アプリ レベルで構成できます。

クライアントのプライベート証明書

一般的なユース ケースでは、クライアント/サーバー モデルでのクライアントとしてアプリを構成します。 プライベート CA 証明書を使用してサーバーをセキュリティで保護する場合は、ご使用のアプリにクライアント証明書をアップロードする必要があります。 次の手順では、アプリが実行されているワーカーの truststore に証明書を読み込みます。 1 つのアプリに証明書を読み込むと、証明書をもう一度アップロードしなくても、同じ App Service プラン内にある他のアプリにもその証明書を使用できます。

ASE 内のアプリに証明書をアップロードするには、次の手順を実行します。

  1. 証明書の .cer ファイルを生成します。
  2. Azure portal で証明書を必要とするアプリに移動します。
  3. アプリで SSL 設定に移動します。 [証明書のアップロード] をクリックします。 [パブリック] を選択します。 [ローカル コンピューター] を選択します。 名前を指定します。 .cer ファイルを参照して選択します。 [アップロード] を選択します。
  4. サムプリントをコピーします。
  5. [アプリケーション設定] に移動します。 サムプリントを値として使用して、アプリ設定 WEBSITE_LOAD_ROOT_CERTIFICATES を作成します。 複数の証明書がある場合は、次のように空白なしのコンマで区切ることで、同じ設定に配置することができます。

84EC242A4EC7957817B8E48913E50953552DAFA6,6A5C65DC9247F762FE17BF8D4906E04FE6B31819

証明書は、その設定を構成したアプリと同じ App Service プラン内のすべてのアプリで使用できます。 別の App Service プラン内のアプリに対してもその証明書を使用できるようにする必要がある場合は、その App Service プランで [アプリケーション設定] の操作を繰り返す必要があります。 証明書が設定されていることを確認するには、Kudu コンソールに移動し、PowerShell デバッグ コンソールで次のコマンドを発行します。

dir cert:\localmachine\root

テストを実行するには、自己署名証明書を作成し、次の PowerShell を使用して .cer ファイルを生成します。

$certificate = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname "*.internal.contoso.com","*.scm.internal.contoso.com"

$certThumbprint = "cert:\localMachine\my\" + $certificate.Thumbprint
$password = ConvertTo-SecureString -String "CHANGETHISPASSWORD" -Force -AsPlainText

$fileName = "exportedcert.cer"
export-certificate -Cert $certThumbprint -FilePath $fileName -Type CERT