Überprüfen der HTTPS-Konfiguration für Microsoft Connected Cache auf Linux

Dieser Artikel enthält Anweisungen zum Überprüfen der HTTPS-Unterstützung auf Microsoft Connected Cache für Unternehmen und Bildungseinrichtungen Knoten, die auf Linux ausgeführt werden.

Testen von HTTP- und HTTPS-Inhaltsdownloads

Vor dem Testen müssen Sie ermitteln, wie Clients eine Verbindung mit Ihrem Connected Cache-Server herstellen. Dies ist dieselbe Verbindungsmethode, die Sie während der CSR-Generierung im alternativen Antragstellernamen (Subject Alternative Name, SAN) Ihres Zertifikats konfiguriert haben.

Die folgenden curl-Befehle testen sowohl den HTTP- als auch den HTTPS-Inhaltsabruf:

• HTTPS-Test:

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

  Erfolgreiche Ausgabe erwartet:

  * 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-Test:

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

  Erfolgreiche Ausgabe erwartet:

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

Dienstseitige Überprüfung

Führen Sie die folgenden Tests auf Ihrem Linux Hostcomputer aus:

• Testen der Konnektivität mit wget:

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

  Erwartetes Ergebnis:HTTP/1.1 200 OK gibt eine erfolgreiche HTTPS-Verbindung an.

• Überprüfen Sie die Zertifikatdetails:

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

  Erwartetes Ergebnis: Zertifikatdetails, einschließlich Antragsteller-, Aussteller- und SAN-Werten, sollten Ihrer Konfiguration entsprechen.

• Überprüfen Sie container status und Protokolle:

  # 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)
  

  Erwartetes Ergebnis: Der Container sollte sich im "Up"-status befinden, und Protokolle sollten TLS/SSL-Aktivitäten ohne Fehler anzeigen.

• Testen des SSL/TLS-Handshakes:

  Testen Sie den SSL/TLS-Handshake, ohne das Zertifikat zu überprüfen:

      # 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
  

Clientseitige Überprüfung

Führen Sie die folgenden Befehle auf einem Clientgerät (nicht auf Ihrem Linux Hostcomputer) aus.

Voraussetzung: Stellen Sie sicher, dass der Host über eine Richtlinie als Ziel verwendet wird. Aktualisieren Sie die IP-Adresse des verbundenen Caches (den Wert für die Richtlinie "DOCacheHost") auf die für Ihre Umgebung relevante Adresse:

$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

• Anfordern des Downloads der Teams-App aus Connected Cache über HTTPS:

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

  Erwartetes Ergebnis: Der Download wird ohne Fehler abgeschlossen und sollte schneller als typische Internetdownloads sein.

• Überprüfen Sie, ob Inhalte tatsächlich zwischengespeichert werden (und nicht nur auf CDN zurückfallen):

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

  Erwartetes Ergebnis:BytesFromCacheServer sollte größer als 0 sein, was auf eine erfolgreiche Zwischenspeicherung hinweist.

• Wenn Ihr verbundener Cache Linux Server-Windows-Clients, testen Sie Folgendes auf diesen Computern:

  # 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]/"
  

• Testen Sie, ob auf Port 443 zugegriffen werden kann:

      # 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]
  

Problembehandlung

Wenn bei einem Überprüfungsschritt ein Fehler auftritt, verwenden Sie die folgenden Tests, um die Ursache zu isolieren. Jeder Test umgeht einen Teil des Verbindungsprozesses. Wenn der Test erfolgreich ist, wissen Sie, dass der umgangene Teil das Problem ist.

Fehler bei der Zertifikatüberprüfung

Symptome:SSL certificate problem, certificate subject name does not match

Diagnosetest: Der folgende Befehl verwendet das Flag, um die -k Zertifikatüberprüfung vollständig zu überspringen. Dadurch wird curl aufgefordert, eine Verbindung herzustellen, ohne das Zertifikat des Servers zu überprüfen. Auf diese Weise können Sie ermitteln, was das Problem ist: das Zertifikat oder etwas anderes.

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

Wenn der Test erfolgreich ist: Server und Netzwerk funktionieren ordnungsgemäß. Das Problem liegt beim Zertifikat selbst. Überprüfen Sie Folgendes:

• Die SAN-Konfiguration stimmt mit Ihrer Verbindungsmethode (IP-Adresse oder Hostname) überein.
• Das Zertifizierungsstellen-Stammzertifikat wird im vertrauenswürdigen Speicher des Clients installiert.

Wenn der Test fehlschlägt: Das Problem ist nicht das Zertifikat. Weitere Informationen finden Sie weiter unten unter Verbindungsfehler .

Zertifikatsperrfehler

Symptome: Langsame HTTPS-Antworten oder Timeouts

Diagnosetest: Der folgende Befehl verwendet das Flag, um die --ssl-no-revoke Überprüfung der Zertifikatsperrliste (Certificate Revocation List, CRL) zu überspringen. Normalerweise kontaktiert der Client den CRL-Verteilungspunkt Ihrer Zertifizierungsstelle, um zu überprüfen, ob das Zertifikat nicht widerrufen wurde. Wenn dieser Endpunkt nicht erreichbar ist, führt dies zu Langsamkeit oder Timeouts.

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

Wenn der Test erfolgreich ist: Die Verbindung funktioniert, wenn die Sperrüberprüfung übersprungen wird, was bestätigt, dass der Client den CRL-Verteilungspunkt nicht erreichen kann. Überprüfen Sie, ob Ihre Firewall den Zugriff auf die in Ihrem Zertifikat aufgeführten Zertifikatsperrlisten-URLs zulässt.

Wenn der Test fehlschlägt: Das Problem ist keine Sperrüberprüfung. Weitere Informationen finden Sie weiter unten unter Verbindungsfehler .

Verbindungsfehler

Symptome:Connection refused, Could not resolve host

Wenn Sie überhaupt keine Verbindung herstellen können (im Gegensatz zum Herstellen einer Verbindung, aber Zertifikatfehler), hängt das Problem in der Regel mit dem Netzwerk oder der Firewall zusammen.

Bei HTTPS-Verbindungsfehlern:

• Überprüfen, ob Firewallregeln ordnungsgemäß konfiguriert sind

• Überprüfen Sie, ob kein anderer Dienst Port 443 verwendet:

  sudo ss -tulpn | grep :443
  

• Überprüfen Sie, ob der Connected Cache-Container ausgeführt wird:

  sudo docker ps | grep mcc
  

Bei HTTP-Verbindungsfehlern: Vergewissern Sie sich, dass der verbundene Cachedienst ausgeführt wird und auf Port 80 zugegriffen werden kann.

sudo ss -tulpn | grep :80

Bei Problemen mit der DNS-Auflösung: Überprüfen der Hostnamenauflösung und Netzwerkkonnektivität

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

Interferenzen von Unternehmensproxys

Symptome: Die Zertifikatüberprüfung schlägt trotz korrekter Konfiguration fehl.

Lösung: Stellen Sie sicher, dass der Unternehmensproxy keinen HTTPS-Datenverkehr zu Ihrem Connected Cache-Server abfängt. Erwägen Sie die Deaktivierung der TLS-Überprüfung für internen verbundenen Cachedatenverkehr.

Zusätzliche Ressourcen

• Https in Linux Übersicht
• HTTPS auf Linux-Referenz
• Problembehandlung beim verbundenen Cache