Linuxでの Microsoft 接続キャッシュの HTTPS 構成の検証

この記事では、Linuxで実行されているエンタープライズおよび教育機関向け Microsoft 接続キャッシュ ノードで HTTPS サポートを検証する方法について説明します。

HTTP および HTTPS コンテンツのダウンロードをテストする

テストする前に、クライアントが接続キャッシュ サーバーに接続する方法を特定する必要があります。 これは、CSR の生成中に証明書のサブジェクト代替名 (SAN) で構成したのと同じ接続方法です。

次の curl コマンドは、HTTP と HTTPS の両方のコンテンツ取得をテストします。

• HTTPS テスト:

  curl -v -o /dev/null "https://[mcc-connection]/[test-url]" --include -H "host:swda01-mscdn.manage.microsoft.com"
  

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

  * Connected to [your-server] ([ip-address]) port 443 (#0)
  * TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  * Server certificate: [your-certificate-subject]
  < HTTP/1.1 200 OK
  < Content-Length: [file-size]
  

• HTTP テスト:

  curl -v -o /dev/null "http://[mcc-connection]/[test-url]" --include -H "host:swda01-mscdn.manage.microsoft.com"
  

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

  * Connected to [your-server] ([ip-address]) port 80 (#0)
  < HTTP/1.1 200 OK
  < Content-Length: [file-size]
  

サービス側の検証

Linux ホスト コンピューターで次のテストを実行します。

• wget を使用して接続をテストする:

  wget --server-response --spider --header="host: swda01-mscdn.manage.microsoft.com" "https://[mcc-connection]/[test-url]"
  

  予期される結果:HTTP/1.1 200 OK は、HTTPS 接続が成功したことを示します。

• 証明書の詳細を確認します。

  echo | openssl s_client -connect [mcc-connection]:443 -servername [mcc-connection] 2>/dev/null | openssl x509 -text -noout
  

  予想される結果: サブジェクト、発行者、SAN の値を含む証明書の詳細は、構成と一致する必要があります。

• コンテナーの状態とログを確認します。

  # Check if the Connected Cache container is running
  sudo docker ps | grep mcc
  
  # View recent container logs for HTTPS activity
  sudo docker logs --tail 50 $(sudo docker ps -q --filter ancestor=mcr.microsoft.com/mcc/linux)
  

  予想される結果: コンテナーは "Up" 状態である必要があり、ログにはエラーのない TLS/SSL アクティビティが表示されます。

• SSL/TLS ハンドシェイクのテスト:

  証明書を検証せずに SSL/TLS ハンドシェイクをテストします。

      # Basic connection test
      openssl s_client -connect [mcc-server]:443
  
      # Test with SNI (Server Name Indication)
      openssl s_client -connect [mcc-server]:443 -servername [hostname]
  
      # View certificate details during connection
      echo | openssl s_client -connect [mcc-server]:443 2>/dev/null | openssl x509 -noout -text
  

クライアント側の検証

(Linux ホスト コンピューターではなく) クライアント デバイスで次のコマンドを実行します。

前提 条件： ホストがポリシーを使用して対象になっていることを確認します。 接続キャッシュ IP アドレス ("DOCacheHost" ポリシーの値) を、環境に関連するものに更新します。

$parentKeyPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization"
if (!(Test-Path $parentKeyPath))
  {
     New-Item -Path $parentKeyPath -ItemType RegistryKey -Force -ErrorAction Stop | Out-Null
  }
Set-ItemProperty -Path $parentKeyPath -Name "DOCacheHost" -Value "[mcc-connection]" -ErrorAction Stop

• HTTPS 経由で接続キャッシュから Teams アプリのダウンロードを要求します。

  Add-AppxPackage "https://installer.teams.static.microsoft/production-windows-x64/25177.2002.3761.5185/MSTeams-x64.msix"
  

  予想される結果: ダウンロードはエラーなしで完了し、一般的なインターネットダウンロードよりも高速である必要があります。

• コンテンツが実際にキャッシュされていることを確認します (CDN にフォールバックするだけでなく)。

  Get-DeliveryOptimizationStatus | Select-Object DownloadMode, TotalBytesDownloaded, BytesFromCacheServer
  

  予期される結果:BytesFromCacheServer は 0 より大きくする必要があります。キャッシュが成功したことを示します。

• 接続済みキャッシュLinuxサーバー Windows クライアントの場合は、これらのマシンから次をテストします。

  # Test TCP connection
  Test-NetConnection -ComputerName [mcc-server] -Port 443
  
  # Test HTTPS connection
  Invoke-WebRequest -Uri "https://[mcc-server]/" -UseBasicParsing
  
  # View certificate details
  $cert = [System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
  Invoke-WebRequest -Uri "https://[mcc-server]/"
  

• ポート 443 にアクセスできるかどうかをテストします。

      # Using telnet
      telnet [mcc-server-ip] 443
  
      # Using nc (netcat)
      nc -zv [mcc-server-ip] 443
  
      # Using nmap (if installed)
      nmap -p 443 [mcc-server-ip]
  

トラブルシューティング

検証手順が失敗した場合は、次のテストを使用して原因を特定します。 各テストでは、接続プロセスの 1 つの部分がバイパスされます。 テストが成功した場合は、バイパスされた部分が問題であることがわかります。

証明書の検証エラー

症状:SSL certificate problem、 certificate subject name does not match

診断テスト: 次のコマンドでは、 -k フラグを使用して証明書の検証を完全にスキップします。 これにより、サーバーの証明書を確認せずに接続するように curl に指示されます。 これにより、何が問題なのか、つまり証明書か他の問題かを判断できます。

curl -v -k -o /dev/null "https://[mcc-connection]/[test-url]" --include -H "host:swda01-mscdn.manage.microsoft.com"

テストが成功した場合: サーバーとネットワークが正常に動作しています。 問題は、証明書自体にあります。 次のことを確認します。

• SAN 構成が接続方法 (IP アドレスまたはホスト名) と一致する
• CA ルート証明書がクライアントの信頼されたストアにインストールされている

テストが失敗した場合: 問題は証明書ではありません。 以下の 「接続エラー」 を参照してください。

証明書失効エラー

症状： 低速な HTTPS 応答またはタイムアウト

診断テスト: 次のコマンドでは、証明書失効リスト (CRL) チェックをスキップするために、 --ssl-no-revoke フラグを使用します。 通常、クライアントは CA の CRL 配布ポイントに接続して、証明書が失効していないことを確認します。 そのエンドポイントに到達できない場合は、低速またはタイムアウトが発生します。

curl -v --ssl-no-revoke -o /dev/null "https://[mcc-connection]/[test-url]" --include -H "host:swda01-mscdn.manage.microsoft.com"

テストが成功した場合: 失効チェックがスキップされると接続が機能し、クライアントが CRL 配布ポイントに到達できないことを確認します。 ファイアウォールで証明書に記載されている CRL URL へのアクセスが許可されていることを確認します。

テストが失敗した場合: 問題は失効チェックではありません。 以下の 「接続エラー」 を参照してください。

接続エラー

症状:Connection refused、 Could not resolve host

接続できない場合 (ただし、証明書エラーが表示されるのではなく)、この問題は通常、ネットワークまたはファイアウォールに関連しています。

HTTPS 接続エラーの場合:

• ファイアウォール規則が正しく構成されていることを確認する

• 他のサービスでポート 443 が使用されていないことを確認します。

  sudo ss -tulpn | grep :443
  

• 接続キャッシュ コンテナーが実行されていることを確認します。

  sudo docker ps | grep mcc
  

HTTP 接続エラーの場合: Connected Cache サービスが実行されており、ポート 80 にアクセスできることを確認する

sudo ss -tulpn | grep :80

DNS 解決の問題の場合: ホスト名の解決とネットワーク接続を確認する

nslookup [mcc-connection]
# OR
dig [mcc-connection]

企業プロキシの干渉

症状： 証明書の検証は、正しい構成にもかかわらず失敗します。

ソリューション： 企業プロキシが接続キャッシュ サーバーへの HTTPS トラフィックをインターセプトしないようにします。 内部接続キャッシュ トラフィックの TLS 検査を無効にすることを検討してください。

その他のリソース

• Linuxの HTTPS の概要
• Linuxリファレンスの HTTPS
• 接続済みキャッシュのトラブルシューティング