次の方法で共有

Windows で Microsoft Connected Cache の HTTPS サポートを有効にする

この記事では、Windows ホスト コンピューターで実行されている Microsoft Connected Cache for Enterprise および Education ノードで HTTPS サポートを有効にする手順について説明します。

セットアップ プロセスでは、ホスト コンピューターで証明書署名要求 (CSR) を生成し、エンタープライズまたはパブリック PKI を使用して CSR に署名してから、ホスト マシンにインポートし直す必要があります。

前提条件

HTTPS 機能を設定する前に、次の要件が満たされていることを確認します。

  • キャッシュ ノードが GA ソフトウェア バージョン上にある

    1. Azure portalを開き、キャッシュ ノードを格納する Connected Cache for Enterprise リソースに移動します。
    2. [ キャッシュ ノード管理] で、HTTPS を有効にするキャッシュ ノードを見つけます。
    3. ノードが GA バージョンにあることを確認します。 [移行済み ] 列に [はい] または [N/A] が表示されます。
    4. GA バージョン ([ 移行済み ] 列の [いいえ]) にない場合は、キャッシュ ノードを選択し、[ デプロイ ] タブに移動し、指示に従って接続済みキャッシュを再デプロイします。

  • 証明機関 (CA) へのアクセス

    エンタープライズ PKI またはパブリック CA のいずれかにアクセスする必要があります。 エンタープライズ PKI を使用している場合は、CA に CSR を送信するためのorganizationの要件をチェックします。

  • クライアント接続方法を文書化する

    クライアントが接続キャッシュ サーバーへの接続に使用する IP アドレスまたはホスト名 (FQDN) をメモします。 この値は、CSR の生成プロセス中にサブジェクト代替名 (SAN) 入力として使用されます。

  • ポート 443 の可用性を確認する

    接続キャッシュとの HTTPS 接続を確立するには、ホスト コンピューターでポート 443 を使用できる必要があります。 次のコマンドを実行して、チェックします。

      netstat -an | findstr :443
    出力例 意味
    TCP 0.0.0.0:443 0.0.0.0:0 LISTENING ポート 443 が開き、受信接続をリッスンしています。 HTTPS のセットアップに進みます。
    出力なし ポート 443 が使用されていないか、リッスンしていません。 HTTPS のセットアップに進みます。
    TCP [your IP]:443 [remote IP]:[port] ESTABLISHED ポート 443 は、接続でアクティブに使用されています。 接続キャッシュでポート 443 を使用するには、競合するサービスを停止する必要があります。

  • 企業プロキシの構成を確認する

    ファイアウォールまたは企業プロキシが接続キャッシュ サーバーへの HTTPS トラフィックを傍受した場合 (TLS 検査など)、証明書の構成に関係なく、証明書の検証は常に失敗します。

プレキットの詳細については、 Windows 上の HTTPS リファレンス ページを参照してください。

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

重要

各キャッシュ ノードには、独自の CSR/証明書が必要です (共有できません)。

  • 一貫性のある名前付けを使用する: mcc-node1.company.com、mcc-node2.company.com など。
  • どの証明書がどのノードに属するかを文書化する
  • ワイルドカード証明書は機能しません。 接続キャッシュへの HTTPS 接続に使用される CSR/証明書は、セキュリティのために各キャッシュ ノードに一意に関連付けられます。

  1. 管理者として PowerShell を開き、PowerShell スクリプトを含む接続済みキャッシュ フォルダーに移動します。

    次のコマンドを実行して、この [接続済みキャッシュ スクリプト] フォルダーに移動します。

       cd (deliveryoptimization-cli mcc-get-scripts-path)

  2. generateCsr.ps1のパラメーターを構成し、指定した値でスクリプトを実行します。

    基本構文

       .\generateCsr.ps1 [Required Parameters] [Subject Parameters] [SAN Parameters]

    必須パラメーター

    パラメーター 説明
    -algo 証明書アルゴリズム: RSA、 EC、 ED25519、または ED448
    -keySizeOrCurve RSA の場合: キー サイズ (2048、 3072、 4096)。 EC の場合: 曲線名 (prime256v1、 secp384r1)。 ED25519と ED448 の場合: キー サイズは必要ありません。
    -csrName CSR ファイルに必要な名前
    -RunTimeAccountName 接続キャッシュ ソフトウェアを実行するアカウント。 これは、接続キャッシュ ランタイム アカウントとして指定するアカウントのユーザー名を含む PowerShell 変数である必要があります。 たとえば、ローカル ユーザー アカウントの $User = "LocalMachineName\Username" 。 グループ管理サービス アカウント (gMSA) を使用している場合は、 "Domain\Username$"形式にする必要があります。
    -mccLocalAccountCredential 接続キャッシュ ランタイム アカウントの PowerShell 資格情報オブジェクト。 これは、ローカル ユーザー アカウント、ドメイン ユーザー アカウント、またはサービス アカウントを使用している場合にのみ必要です。 コマンド $myLocalAccountCredential = Get-Credential を使用して、資格情報取得 GUI をキューに入れます。

    注

    gMSA ランタイム アカウントを使用する場合は、-RunTimeAccountNameの代わりにパラメーター -RunTimeAccountを使用します。

    この不一致は、Windows インストーラーの次のリリースで修正される予定です。

    サブジェクト パラメーター

    パラメーター 必須 説明 例
    -subjectCommonName はい 証明書の共通名 "localhost", "example.com"
    -subjectCountry なし 2 文字の国コード "US", "CA", "GB"
    -subjectState なし 都道府県 "WA", "TX", "Ontario"
    -subjectOrg なし 組織名 "MyCompany", "ACME Corp"

    Warning

    SAN 構成は、証明書の検証に不可欠です。 証明書は、クライアントが接続済みキャッシュに接続する方法と正確に一致する必要があります。それ以外の場合、クライアントはキャッシュ ノードをバイパスします。

    たとえば、クライアントが IP アドレス 192.168.1.100 経由で接続しても、証明書に -sanDns "server.local"しかない場合、証明書の検証は失敗します。

    サブジェクトの別名 (少なくとも 1 つ必要)

    パラメーター 説明 例
    -sanDns DNS 名 (コンマ区切り) "localhost,example.com,api.example.com"
    -sanIp IP アドレス (コンマ区切り) "127.0.0.1,192.168.1.100"
    -sanUri URI (コンマ区切り) "https://example.com,http://localhost"
    -sanEmail Email アドレス (コンマ区切り) "admin@example.com,user@domain.com"
    -sanRid 登録済み ID (コンマ区切り)
    -sanDirName ディレクトリ名 (コンマ区切り)
    -sanOtherName その他の名前 (コンマ区切り)

    CSR スクリプト パラメーターの詳細とシナリオベースの例については、「Windows での HTTPS リファレンス」を参照してください。

  3. CSR 生成プロセスが正常に完了したことを検証します。

    エラーが発生した場合は、スクリプト出力で指定されたフォルダー内のタイムスタンプ付き GenerateCsr.log ファイルを見つけます。 "ログの詳細なエラー情報を確認する:" で始まる出力行を探します。ディレクトリは (...\Certificates\logs) で終わります。

    • ファイル形式: GenerateCsr_YYYYMMDD-HHMMSS.log
    • 例： GenerateCsr_20251201_143022.logは、2025 年 12 月 1 日午後 2:30:22 に作成されたファイルです

  4. ホスト コンピューター上の Certificates フォルダー に生成された CSR ファイルを見つけて、必要に応じて転送します

    証明書フォルダーの場所は、スクリプト出力で指定されます。最初は "... で作成された CSR ファイル" から始まります。 ディレクトリは (...\Certificates\certs) で終わります。

CSR に署名する

  1. パブリック証明機関またはエンタープライズ証明機関 (CA) を選択して CSR に署名する

    重要

    CA 署名は、クライアントの信頼されたルート ストア内のルート証明書と一致する必要があります。

    ほとんどのお客様は、CSR に署名するためにエンタープライズ PKI インフラストラクチャを利用しています。 パブリック CA を使用する必要がある場合は、次のリソースを検討してください。

  2. 選択した CA に CSR を送信し、署名された証明書を保存します。

    署名済み証明書は、 X.509 エンコードの .crt 形式である必要があります。 CA で他の形式が提供されている場合は、Windows 上の HTTPS リファレンスをチェックして.crt 形式に変換する方法について説明します。

    注

    接続キャッシュでは 、現在、パスワードで保護された形式 (.pfx、.p12、.p7b) はサポートされていません。 これらのサポートは、証明書自動化ロードマップの一部としてすぐに追加されます。

  3. 署名された証明書が正しい形式であることを確認します。

    PEM エンコードの確認:

    Get-Content "xxxx.crt" | Select-String "BEGIN CERTIFICATE"

    正常な出力が予想されます。

    -----BEGIN CERTIFICATE-----

  4. 署名済み証明書を Windows ホスト コンピューターの [証明書] フォルダー に移動します。

    これは、CSR が生成された後に最初に見つかったフォルダーと同じフォルダーになります(...\Certificates\certs)。

    注意

    秘密キーを共有しないでください。接続キャッシュには署名付き証明書のみが必要です。

署名済み TLS 証明書をインポートする

注

importCert スクリプトは現在サポートされていません。

  • gMSA ランタイム アカウントを使用して、Windows Server 2022 または Windows Server 2025 で実行されているキャッシュ ノード。
  • パラメーターは、サポートされている Windows バージョンで gMSA を使用する場合に -RunTimeAccountName されます (代わりに -RunTimeAccount を使用します)。

どちらの問題も、Windows インストーラーの次のリリースで解決されます。

  1. 管理者として PowerShell を開き、PowerShell スクリプトを含む接続済みキャッシュ フォルダーに移動します。

  2. importCert.ps1のパラメーターを構成し、指定した値でスクリプトを実行します。

    基本構文

      .\importCert.ps1 [Required Parameters]

    必須パラメーター

    パラメーター 説明
    -certName 署名済み TLS 証明書の完全なファイル名 (.crt 拡張子の有無にかかわらず)
    -RunTimeAccountName 接続キャッシュ ソフトウェアを実行するアカウント。 これは、接続キャッシュ ランタイム アカウントとして指定するアカウントのユーザー名を含む PowerShell 変数である必要があります。 たとえば、ローカル ユーザー アカウントの $User = "LocalMachineName\Username" 。 グループ管理サービス アカウント (gMSA) を使用している場合は、 "Domain\Username$"形式にする必要があります。
    -mccLocalAccountCredential 接続キャッシュ ランタイム アカウントの PowerShell 資格情報オブジェクト。 これは、ローカル ユーザー アカウント、ドメイン ユーザー アカウント、またはサービス アカウントを使用している場合にのみ必要です。 例: $myLocalAccountCredential = Get-Credential。

    例

      .\importCert.ps1 `
    -RunTimeAccountName $myLocalAccountCredential.Username `
    -LocalAccountCredential $myLocalAccountCredential `
    -certName "myTlsCert.crt"

  3. インポート プロセスが正常に完了したことを検証します。

    エラーが発生した場合は、スクリプト出力で指定されたフォルダー内のタイムスタンプ付き ImportCert.log ファイルを見つけます。 "ここでログを見つけることができます:.." で始まる出力行を探します。

    • ファイル形式: ImportCert_YYYYMMDD-HHMMSS.log
    • 例： ImportCert_20251201_143022.logは、2025 年 12 月 1 日午後 2:30:22 に作成されたファイルです

  4. 接続済みキャッシュにポート 443 を介して外部クライアントからアクセスできることを確認します。

    注

    ポート転送を構成する前に、ポート 443 が使用可能であることを確認します。 netstat -an | findstr :443

    転送ポート 443 トラフィック

    次のコマンドを使用して、Windows ホスト マシンから接続済みキャッシュ コンテナーへのトラフィックをブリッジします。

     $ipFilePath = Join-Path ([System.Environment]::GetEnvironmentVariable("MCC_INSTALLATION_FOLDER", "Machine")) "wslIp.txt"
 $ipAddress = (Get-Content $ipFilePath | Select-Object -First 1).Trim()
 netsh interface portproxy add v4tov4 listenport=443 listenaddress=0.0.0.0 connectport=443 connectaddress=$ipAddress

    これにより、ポート 443 の受信トラフィックがコンテナーの内部 IP にリダイレクトされるようにポート プロキシが設定されます。

    ファイアウォールでポート 443 を開く

    ポートフォワーディングが設定されていても、Windows ファイアウォールはポート 443 の着信または送信トラフィックをブロックする可能性があります。 次のコマンドを使用して、接続されたキャッシュとの間で HTTPS トラフィックが自由に流れるようにします。

     [void](New-NetFirewallRule -DisplayName "WSL2 Port Bridge (HTTPS)" -Direction Inbound -Action Allow -Protocol TCP -LocalPort "443")
 [void](New-NetFirewallRule -DisplayName "WSL2 Port Bridge (HTTPS)" -Direction Outbound -Action Allow -Protocol TCP -LocalPort "443")

証明書のインポートをさらに検証する手順については、「 Windows の HTTPS 検証」ページを参照してください。

HTTPS サポートを無効にする

接続済みキャッシュを HTTP 専用通信に戻す必要がある場合は、次の手順に従います。 このプロセスでは、CSR ファイル、証明書、ログなど、Certificates フォルダー内の何も削除されません。

  1. 管理者として PowerShell を開き、PowerShell スクリプト フォルダーに移動します。

  2. disableTls.ps1のパラメーターを構成し、区切った値でスクリプトを実行します。

    基本構文

      .\disableTls.ps1 [Required Parameters]

    必須パラメーター

    パラメーター 説明
    -RunTimeAccountName 接続キャッシュ ソフトウェアを実行するアカウント。 これは、接続キャッシュ ランタイム アカウントとして指定するアカウントのユーザー名を含む PowerShell 変数である必要があります。 たとえば、ローカル ユーザー アカウントの $User = "LocalMachineName\Username" 。 グループ管理サービス アカウント (gMSA) を使用している場合は、 "Domain\Username$"形式にする必要があります。
    -mccLocalAccountCredential 接続キャッシュ ランタイム アカウントの PowerShell 資格情報オブジェクト。 これは、ローカル ユーザー アカウント、ドメイン ユーザー アカウント、またはサービス アカウントを使用している場合にのみ必要です。 例: $myLocalAccountCredential = Get-Credential。

    注

    gMSA を使用する場合は、-RunTimeAccountNameの代わりにパラメーター -RunTimeAccountを使用します。 この不一致は、スクリプトで間もなく修正される予定です。

    例

      .\disableTls.ps1 `
    -RunTimeAccountName $myLocalAccountCredential.Username `
    -LocalAccountCredential $myLocalAccountCredential `

  3. 無効化プロセスが正常に完了したことを検証します。

  4. HTTPS が無効になった後、HTTP 要求は機能し、HTTPS 要求は失敗する必要があります。 これをテストする方法については、 Windows の HTTPS 検証ページ を参照してください。

次のステップ

  • Last updated on