Software Defined Networking の証明書の管理

2025-07-07

適用対象: Azure Local 2311.2 以降。Windows Server 2022、Windows Server 2019、Windows Server 2016

この記事では、ソフトウェア定義ネットワーク (SDN) を展開するとき、および System Center Virtual Machine Manager (SCVMM) を SDN 管理クライアントとして使用する場合に、ネットワークコントローラーの Northbound および Southbound 通信の証明書を管理する方法について説明します。

注

ネットワークコントローラーの概要については、ネットワークコントローラーに関する記事を参照してください。

ネットワークコントローラー通信をセキュリティで保護するために Kerberos を使用していない場合は、認証、承認、および暗号化に X.509 証明書を使用できます。

Windows Server 2019 および 2016 Datacenter の SDN では、自己署名証明書と証明機関 (CA) で署名された x.509 証明書の両方がサポートされています。このトピックでは、これらの証明書を作成し、それらをセキュリティで保護されたネットワークコントローラーのノースバウンド通信チャネルに適用して、管理クライアントとネットワークデバイス (Software Load Balancer (SLB) など) とサウスバウンド通信に適用する方法についての手順を説明します。

証明書ベースの認証を使用する場合は、次の方法で使用される 1 つの証明書をネットワークコントローラーノードに登録する必要があります。

ネットワークコントローラーノードと管理クライアント (System Center Virtual Machine Manager など) の間の Secure Sockets Layer (SSL) を使用した Northbound 通信の暗号化。
ネットワークコントローラーノードと Hyper-V ホストや Software Load Balancers (SLB) などのサウスバウンドのデバイスおよびサービス間の認証。

X.509 証明書の作成と登録

自己署名証明書または CA が発行した証明書のいずれかを作成し、登録することができます。

注

SCVMM を使用してネットワークコントローラーを展開する場合は、ネットワークコントローラーサービステンプレートの構成中に Northbound 通信の暗号化に使用される X.509 証明書を指定する必要があります。

証明書の構成には、次の値を含める必要があります。

RestEndPoint テキストボックスの値は、ネットワークコントローラーの完全修飾ドメイン名 (FQDN) または IP アドレスである必要があります。
RestEndPoint の値は、x.509 証明書のサブジェクト名 (共通名、CN) と一致する必要があります。

自己署名 X.509 証明書の作成

ネットワークコントローラーの単一ノードおよび複数ノードの展開の場合は、次の手順に従って、自己署名された X.509 証明書を作成し、秘密キー (パスワード保護) を使用してエクスポートできます。

自己署名証明書を作成する際は、次のガイドラインを参考にできます。

DnsName パラメーターにはネットワークコントローラー REST エンドポイントの IP アドレスを使用できますが、ネットワークコントローラーノードがすべて単一の管理サブネット (たとえば、単一ラック) 内に配置されている必要があるため、これは推奨されません。
複数ノードのネットワークコントローラー展開の場合、指定した DNS 名がネットワークコントローラークラスターの FQDN になります (DNS ホスト A レコードが自動的に作成されます)。
単一ノードのネットワークコントローラーの展開では、DNS 名は、ネットワークコントローラーのホスト名の後に完全なドメイン名を付けることができます。

複数ノード

New-SelfSignedCertificate の Windows PowerShell コマンドを使用して、自己署名証明書を作成できます。

構文

New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong Cryptographic Provider" -FriendlyName "<YourNCComputerName>" -DnsName @("<NCRESTName>")

使用例

New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong Cryptographic Provider" -FriendlyName "MultiNodeNC" -DnsName @("NCCluster.Contoso.com")

単一ノード

New-SelfSignedCertificate の Windows PowerShell コマンドを使用して、自己署名証明書を作成できます。

構文

New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong Cryptographic Provider" -FriendlyName "<YourNCComputerName>" -DnsName @("<NCFQDN>")

使用例

New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong Cryptographic Provider" -FriendlyName "SingleNodeNC" -DnsName @("SingleNodeNC.Contoso.com")

CA 署名付き X.509 証明書の作成

CA を使用して証明書を作成するには、Active Directory 証明書サービス (AD CS) を使用して公開キーインフラストラクチャ (PKI) を展開しておく必要があります。

注

サードパーティの CA または openssl などのツールを使用して、ネットワークコントローラーで使用する証明書を作成できます。ただし、このトピックの手順は AD CS 固有のものです。サードパーティの CA またはツールを使用する方法については、使用しているソフトウェアのドキュメントを参照してください。

CA を使用して証明書を作成するには、次の手順を実行します。

自分または組織のドメインまたはセキュリティ管理者が証明書テンプレートを構成します。
ユーザーまたは組織のネットワークコントローラー管理者または SCVMM 管理者が、CA に新しい証明書を要求します。

証明書の構成要件

次の手順で証明書テンプレートを構成するときに、構成するテンプレートに次の必須要素が含まれていることを確認します。

証明書のサブジェクト名は、Hyper-V ホストの FQDN である必要があります。
証明書は、ローカルコンピューターの個人用ストア (My – cert:\localmachine\my) に配置する必要があります。
証明書には、サーバー認証 (EKU: 1.3.6.1.5.5.7.3.1) とクライアント認証 (EKU: 1.3.6.1.5.5.7.3.2) の両方のアプリケーションポリシーが必要です。

注

Hyper-V ホスト上の個人 (My – cert:\ localmachine\my) 証明書ストアに、ホストの完全修飾ドメイン名 (FQDN) としてサブジェクト名 (CN) が指定された x.509 証明書が複数ある場合は、SDN で使用される証明書に、OID 1.3.6.1.4.1.311.95.1.1.1 を持つカスタム拡張キー使用法プロパティが追加されていることを確認します。そうでない場合、ネットワークコントローラーとホスト間の通信が機能しない可能性があります。

証明書テンプレートを構成する

注

この手順を実行する前に、証明書テンプレートコンソールで証明書の要件と利用可能な証明書テンプレートを確認する必要があります。既存のテンプレートを変更するか、既存のテンプレートの複製を作成してから、テンプレートのコピーを変更することができます。既存のテンプレートのコピーを作成することをお勧めします。

AD CS がインストールされているサーバーのサーバーマネージャーで、[ツール] をクリックし、[証明機関] をクリックします。証明機関 Microsoft 管理コンソール (MMC) が開きます。
MMC で、CA 名をダブルクリックし、[証明書テンプレート] を右クリックしてから、[管理] をクリックします。
証明書テンプレートコンソールが開きます。すべての証明書テンプレートが詳細ウィンドウに表示されます。
詳細ウィンドウで、複製するテンプレートをクリックします。
[操作] メニューをクリックし、[テンプレートの複製] をクリックします。テンプレートの [プロパティ] ダイアログボックスが開きます。
テンプレートの [プロパティ] ダイアログボックスの [サブジェクト名] タブで、[要求で提供] をクリックします。 (ネットワークコントローラーの SSL 証明書にはこの設定が必要です。)
テンプレートの [プロパティ] ダイアログボックスの [要求処理] タブで、[秘密キーのエクスポートを許可する] が選択されていることを確認します。また、[署名と暗号化] の目的が選択されていることを確認します。
テンプレートの [プロパティ] ダイアログボックスの [拡張機能] タブで、[キー使用法] を選択し、[編集] をクリックします。
[署名] で、[デジタル署名] が選択されていることを確認します。
テンプレートの [プロパティ] ダイアログボックスの [拡張機能] タブで、[アプリケーションポリシー] を選択し、[編集] をクリックします。
[アプリケーションポリシー] で、[クライアント認証] と [サーバー認証] が表示されていることを確認します。
証明書テンプレートのコピーを、「ネットワークコントローラーテンプレート」などの一意の名前で保存します。

CA に証明書を要求する

証明書スナップインを使用して、証明書を要求することができます。事前設定され、証明書の要求を処理する証明機関 (CA) の管理者によって提供された任意の種類の証明書を要求することができます。

ユーザーまたはローカル管理者は、この手順を完了するうえで必要となる最小のグループメンバーです。

コンピューターの証明書スナップインを開きます。
コンソールで、［証明書 (ローカルコンピューター)］をダブルクリックします。 [個人] 証明書ストアを選択します。
[操作] メニューで [** すべてのタスク] を選択し、[** 新しい証明書の要求] をクリックして証明書の登録ウィザードを起動します。 [次へ] をクリックします。
「管理者によって構成された証明書登録ポリシー」を選択し、[次へ] をクリックします。
(前のセクションで構成した CA テンプレートに基づく)「Active Directory の登録ポリシー」を選択します。
[詳細] セクションを展開し、次の項目を構成します。
[キー使用法] にデジタル署名 * * と * * キーの暗号化の両方が含まれていることを確認します。
[アプリケーションポリシー] にサーバー認証(1.3.6.1.5.5.7.3.1) とクライアント認証(1.3.6.1.5.5.7.3.2) の両方が含まれていることを確認します。
[プロパティ] をクリックします。
[サブジェクト] タブの [サブジェクト名] の [種類] で、[共通名] を選択します。 [値] には「ネットワークコントローラー REST エンドポイント」を指定します。
[適用] をクリックし、[OK] をクリックします。
[登録] をクリックします。

[証明書] MMC で、[個人] ストアをクリックして、CA から登録した証明書を表示します。

証明書をエクスポートして SCVMM ライブラリにコピーする

自己署名証明書または CA 署名付き証明書を作成した後、証明書スナップインから秘密キー (.pfx 形式) と秘密キー (Base-64 .cer 形式) なしで証明書をエクスポートする必要があります。

次に、2 つのエクスポートされたファイルを、NC サービステンプレートのインポート時に指定した ServerCertificate.cr および NCCertificate.cr フォルダーにコピーする必要があります。

証明書スナップイン (certlm .msc) を開き、ローカルコンピューターの [個人] 証明書ストアで証明書を探します。
証明書を右クリックし、[すべてのタスク] をクリックして、[エクスポート] をクリックします。証明書のエクスポートウィザードが開きます。 [次へ] をクリックします。
[はい、秘密キーをエクスポートします] オプションを選択して、[次へ] をクリックします。
[Personal Information Exchange - PKCS #12 (.PFX)] を選択し、既定の [証明のパスにある証明書を可能であればすべて含む] を受け入れます。
エクスポートする証明書のユーザー/グループとパスワードを割り当て、[次へ ] をクリック。
[エクスポートするファイル] ページで、エクスポートしたファイルを配置する場所を参照し、名前を付けます。
同様に、.CER 形式で証明書をエクスポートします。注: .CER 形式にエクスポートする場合は、[はい、秘密キーをエクスポートします] オプションをオフにします。
PFX を ServerCertificate.cr フォルダーにコピーします。
.CER ファイルを NCCertificate.cr フォルダーにコピーします。

完了したら、SCVMM ライブラリ内のこれらのフォルダーを更新し、これらの証明書がコピーされていることを確認します。ネットワークコントローラーのサービステンプレートの構成と展開を続行します。

サウスバウンドのデバイスとサービスの認証

ホストと SLB MUX デバイスとのネットワークコントローラーの通信では、認証に証明書を使用します。ホストとの通信は OVSDB プロトコルを介して行われ、SLBMUX デバイスとの通信は WCF プロトコルを介して行われます。

Hyper-V ホストとネットワークコントローラーの通信

OVSDB を介してホストコンピューターに対して通信を行うには、ネットワークコントローラーがホストコンピューターに証明書を提示する必要があります。既定では、SCVMM はネットワークコントローラーで構成されている SSL 証明書を取得し、ホストとのサウスバウンド通信に使用します。

SSL 証明書にクライアント認証 EKU が構成されている必要があるのは、これが理由です。この証明書は、「サーバー」 REST リソースで構成されます (Hyper-V ホストは、ネットワークコントローラーでサーバーリソースとして表されます)。Windows PowerShell コマンド NetworkControllerServer を実行すると表示できます。

サーバー REST リソースの例を次に示します。

   "resourceId": "host31.fabrikam.com",
      "properties": {
        "connections": [
          {
            "managementAddresses": [
               "host31.fabrikam.com"
            ],
            "credential": {
              "resourceRef": "/credentials/a738762f-f727-43b5-9c50-cf82a70221fa"
            },
            "credentialType": "X509Certificate"
          }
        ],

相互認証の場合、Hyper-V ホストにはネットワークコントローラーと通信するための証明書も必要です。

証明機関 (CA) から証明書を登録できます。 CA ベースの証明書がホストコンピューターで見つからない場合、SCVMM は自己署名証明書を作成し、ホストコンピューター上にプロビジョニングします。

ネットワークコントローラーと Hyper-V ホストの証明書は、相互に信頼されている必要があります。 Hyper-V ホスト証明書のルート証明書は、ローカルコンピューターのネットワークコントローラーの信頼されたルート証明機関ストアに存在している必要があります。また、その逆も同様です。

自己署名証明書を使用している場合、SCVMM は、必要な証明書がローカルコンピューターの信頼されたルート証明機関ストアに存在することを確認します。

Hyper-V ホストに CA ベースの証明書を使用する場合は、ローカルコンピューターのネットワークコントローラーの信頼されたルート証明機関ストアに CA ルート証明書が存在することを確認する必要があります。

ネットワークコントローラーとのソフトウェアロードバランサー MUX 通信

ソフトウェアロードバランサーマルチプレクサ (MUX) とネットワークコントローラーは、認証用の証明書を使用して、WCF プロトコルを介して通信します。

既定では、SCVMM はネットワークコントローラーで構成されている SSL 証明書を取得し、Mux `デバイスとのサウスバウンド通信に使用します。この証明書は「NetworkControllerLoadBalancerMux」REST リソースで構成され、PowerShell コマンドレット「NetworkControllerLoadBalancerMux」を実行すると表示できます。

MUX REST リソースの例 (一部):

      "resourceId": "slbmux1.fabrikam.com",
      "properties": {
        "connections": [
          {
            "managementAddresses": [
               "slbmux1.fabrikam.com"
            ],
            "credential": {
              "resourceRef": "/credentials/a738762f-f727-43b5-9c50-cf82a70221fa"
            },
            "credentialType": "X509Certificate"
          }
        ],

相互認証の場合、SLB MUX デバイスにも証明書が必要です。この証明書は、SCVMM を使用してソフトウェアロードバランサーを展開する際、SCVMM によって自動的に構成されます。

重要

ホストおよび SLB ノードでは、信頼されたルート証明機関の証明書ストアに、「発行先」と「発行元」が異なる証明書が含まれていないことが重要です。この問題が発生すると、ネットワークコントローラーとサウスバウンドのデバイス間の通信が失敗します。

ネットワークコントローラーと SLB MUX 証明書は相互に信頼されている必要があります (SLB MUX 証明書のルート証明書は、ネットワークコントローラーコンピューターの信頼されたルート証明機関ストアに存在する必要があり、その逆も同様です)。自己署名証明書を使用している場合、SCVMM は、必要な証明書がローカルコンピューターの信頼されたルート証明機関ストアに存在することを確認します。