Überprüfen der HTTPS-Konfiguration für Microsoft Connected Cache unter Windows

Dieser Artikel enthält Anweisungen zum Überprüfen der HTTPS-Unterstützung auf Microsoft Connected Cache für Unternehmen und Bildungseinrichtungen Knoten unter Windows mit WSL (Windows-Subsystem für Linux).

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.

Führen Sie dann die folgenden curl-Befehle auf Ihrem Windows-Hostcomputer (dem Connected Cache-Server) aus, um sowohl den HTTP- als auch den HTTPS-Inhaltsabruf zu testen:

• HTTPS-Test

      curl.exe -v -o NUL "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.exe -v -o NUL "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 Windows-Hostcomputer aus:

• Testen der Konnektivität mit PowerShell:

      Invoke-WebRequest -Uri "https://[mcc-connection]/[test-url]" -Headers @{"host"="swda01-mscdn.manage.microsoft.com"} -Method Head
  

  Erwartetes Ergebnis:StatusCode: 200 gibt eine erfolgreiche HTTPS-Verbindung an.

• Überprüfen Sie die Übermittlungsoptimierungsprotokolle auf HTTPS-Aktivitäten:

    # Search for HTTPS connections in recent logs
    Select-String -Path "C:\Windows\Logs\DeliveryOptimization\*.log" -Pattern "https://" | Select-Object -First 5
  
    # Search for your specific Connected Cache server connections
    Select-String -Path "C:\Windows\Logs\DeliveryOptimization\*.log" -Pattern "[mcc-connection]" | Select-Object -First 5
  

  Erwartetes Ergebnis: Protokolleinträge mit HTTPS-URLs und Ihrer Serveradresse für den verbundenen Cache deuten darauf hin, dass Clients HTTPS erfolgreich verwenden.

Clientseitige Überprüfung

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

Voraussetzung: Stellen Sie sicher, dass der Hostcomputer per 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.

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.exe -v -k -o NUL "https://[mcc-connection]/[test-url]"

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.exe -v --ssl-no-revoke -o NUL "https://[mcc-connection]/[test-url]"

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 und Portweiterleitung ordnungsgemäß konfiguriert sind

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

      netstat -an | findstr :443
  

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

   netstat -an | findstr :80

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

   nslookup [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.

Ressourcen

• HTTPS unter Windows – Übersicht
• HTTPS unter Windows–Referenz
• Problembehandlung beim verbundenen Cache