次の方法で共有

Linux 上の Microsoft Connected Cache の HTTPS サポートを有効にする

この記事では、Linux ホスト マシンで実行されている Microsoft Connected Cache for Enterprise ノードで 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 を使用できる必要があります。 次のコマンドを実行して、チェックします。

    sudo ss -tulpn | grep :443
    出力例 意味
    tcp LISTEN 0 128 0.0.0.0:443 0.0.0:* users:(("nginx",pid=1234,fd=6)) ポート 443 が開き、受信接続をリッスンしています (この場合は nginx)。 接続キャッシュでポート 443 を使用するには、競合するサービスを停止する必要があります。
    出力なし ポート 443 が使用されていないか、リッスンしていません。 HTTPS のセットアップに進みます。

  • ファイアウォールの構成を確認する

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

いずれかのプレリキットの詳細については、「 HTTPS on Linux リファレンス ページ」を参照してください。

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

重要

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

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

  1. ターミナルを開き、抽出されたデプロイ パッケージを含むフォルダーに移動します。

  2. CSR 生成スクリプトに実行アクセス許可を追加します。

    sudo chmod +x ./generateCsr.sh

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

    基本構文

    ./generateCsr.sh [Required Parameters] [Subject Parameters] [SAN Parameters]

    必須パラメーター

    パラメーター 型 説明
    -algo String 証明書アルゴリズム: RSA、 EC、 ED25519、または ED448
    -keySizeOrCurve String RSA の場合: キー サイズ (2048、 3072、 4096)。 EC の場合: 曲線名 (prime256v1、 secp384r1)
    -csrName String 生成された CSR ファイルの名前

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

    パラメーター 必須 説明 例
    -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"しかない場合、証明書の検証は失敗します。

    SAN パラメーター (少なくとも 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 スクリプト パラメーターの詳細とシナリオベースの例については、「 HTTPS on Linux リファレンス ページ」を参照してください。

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

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

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

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

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

CSR に署名する

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

    重要

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

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

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

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

    注

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

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

    PEM エンコードの確認:

    grep "BEGIN CERTIFICATE" xxxx.crt

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

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

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

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

    注意

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

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

  1. ターミナルを開き、接続キャッシュ インストーラーの場所に移動します。

  2. 証明書インポート スクリプトに実行アクセス許可を追加します。

    sudo chmod +x ./importCert.sh

  3. importCert.shのパラメーターを構成し、特定の値を使用してスクリプトを実行します。

    基本構文

    ./importCert.sh [Required Parameters]

    必須パラメーター

    パラメーター 型 説明
    -certName String 署名済み TLS 証明書の完全なファイル名 (.crt 拡張子の有無にかかわらず)

    例

    ./importCert.sh -certName "myTlsCert.crt"

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

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

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

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

HTTPS サポートを無効にする

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

  1. Linux ホストでターミナルを開き、抽出されたデプロイ パッケージを含むフォルダーに移動します。

  2. TLS 無効化スクリプトに実行アクセス許可を追加します。

    sudo chmod +x ./disableTls.sh

  3. 無効化スクリプトを実行します (パラメーターは必要ありません)。

    ./disableTls.sh

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

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

次のステップ

  • Last updated on