Valider la configuration HTTPS pour le cache connecté Microsoft sur Linux

Cet article fournit des instructions sur la façon de valider la prise en charge https sur Cache connecté Microsoft pour les entreprises et l’éducation nœuds s’exécutant sur Linux.

Tester les téléchargements de contenu HTTP et HTTPS

Avant de tester, vous devez identifier la façon dont les clients se connectent à votre serveur de cache connecté. Il s’agit de la même méthode de connexion que celle que vous avez configurée dans l’autre nom de l’objet (SAN) de votre certificat pendant la génération de csr.

Important

Remplacez [mcc-connection] et [test-url] dans toutes les commandes ci-dessous

Pour déterminer votre [mcc-connection]:

  • Si vous avez utilisé -sanIp dans votre csr : utilisez l’adresse IP (exemple : 192.168.1.100)
  • Si vous avez utilisé -sanDns dans votre csr : utilisez le nom d’hôte (exemple : mcc-server.contoso.com)

[test-url]est le chemin complet d’un test Intune application Win32 :ee344de8-d177-4720-86c1-a076581766f9/070a8fd4-79a7-42c8-b7c8-9883253bb01a/c7b1b825-88b2-4e66-9b15-ff5fe0374bc6.appxbundle.bin

Les commandes curl suivantes testent la récupération de contenu HTTP et HTTPS :

  • Test HTTPS :

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

    Sortie réussie attendue :

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

  • Test HTTP :

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

    Sortie réussie attendue :

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

Validation côté service

Effectuez les tests suivants sur votre ordinateur hôte Linux :

  • Tester la connectivité avec wget :

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

    Résultat attendu :HTTP/1.1 200 OK indique une connexion HTTPS réussie.

  • Vérifiez les détails du certificat :

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

    Résultat attendu : Les détails du certificat, y compris l’objet, l’émetteur et les valeurs SAN, doivent correspondre à votre configuration.

  • Vérifiez les status de conteneur et les journaux :

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

    Résultat attendu : Le conteneur doit être en status « Up » et les journaux doivent afficher l’activité TLS/SSL sans erreur.

  • Test de l’établissement d’une liaison SSL/TLS :

    Testez l’établissement d’une liaison SSL/TLS sans valider le certificat :

        # 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

Validation côté client

Exécutez les commandes suivantes sur un appareil client (et non sur votre ordinateur hôte Linux).

Condition préalable: Vérifiez que l’hôte est ciblé via la stratégie. Mettez à jour l’adresse IP du cache connecté (la valeur de la stratégie « DOCacheHost ») en fonction de ce qui est pertinent pour votre environnement :

$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

  • Demander le téléchargement de l’application Teams à partir du cache connecté via HTTPS :

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

    Résultat attendu : Le téléchargement se termine sans erreur et doit être plus rapide que les téléchargements Internet classiques.

  • Vérifiez que le contenu est réellement mis en cache (pas seulement pour revenir au CDN) :

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

    Résultat attendu :BytesFromCacheServer doit être supérieur à 0, ce qui indique une mise en cache réussie.

  • Si votre cache connecté Linux clients Windows du serveur, testez les éléments suivants à partir de ces machines :

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

  • Testez si le port 443 est accessible :

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

Résolution des problèmes

Si une étape de validation échoue, utilisez les tests suivants pour isoler la cause. Chaque test contourne une partie du processus de connexion. Si le test réussit, vous savez que la partie contournée est le problème.

Important

Remplacez [mcc-connection] et [test-url] dans toutes les commandes ci-dessous

Pour déterminer votre [mcc-connection]:

  • Si vous avez utilisé -sanIp dans votre csr : utilisez l’adresse IP (exemple : 192.168.1.100)
  • Si vous avez utilisé -sanDns dans votre csr : utilisez le nom d’hôte (exemple : mcc-server.contoso.com)

[test-url]est le chemin complet d’un test Intune application Win32 :ee344de8-d177-4720-86c1-a076581766f9/070a8fd4-79a7-42c8-b7c8-9883253bb01a/c7b1b825-88b2-4e66-9b15-ff5fe0374bc6.appxbundle.bin

Erreurs de validation de certificat

Symptômes :SSL certificate problem, certificate subject name does not match

Test de diagnostic : La commande suivante utilise l’indicateur pour ignorer entièrement la -k validation du certificat. Cela indique à curl de se connecter sans vérifier le certificat du serveur. De cette façon, vous pouvez déterminer quel est le problème : le certificat ou autre chose.

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

Si le test réussit : Le serveur et le réseau fonctionnent correctement. Le problème est lié au certificat lui-même. Vérifiez que :

  • La configuration SAN correspond à votre méthode de connexion (adresse IP ou nom d’hôte)
  • Le certificat racine d’autorité de certification est installé dans le magasin approuvé du client

Si le test échoue : Le problème n’est pas le certificat. Consultez Erreurs de connexion ci-dessous.

Erreurs de révocation de certificat

Symptômes: Réponses HTTPS lentes ou délais d’expiration

Test de diagnostic : La commande suivante utilise l’indicateur pour ignorer la --ssl-no-revoke vérification de la liste de révocation de certificats (CRL). Normalement, le client contacte le point de distribution de la liste de révocation de certificats de votre autorité de certification pour vérifier que le certificat n’a pas été révoqué. Si ce point de terminaison est inaccessible, il entraîne une lenteur ou des délais d’expiration.

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

Si le test réussit : La connexion fonctionne lorsque la vérification de révocation est ignorée, ce qui confirme que le client ne peut pas atteindre le point de distribution de la liste de révocation de certificats. Vérifiez que votre pare-feu autorise l’accès aux URL de liste de révocation de certificats répertoriées dans votre certificat.

Si le test échoue : Le problème n’est pas la vérification de la révocation. Consultez Erreurs de connexion ci-dessous.

Erreurs de connexion

Symptômes :Connection refused, Could not resolve host

Si vous ne pouvez pas vous connecter du tout (au lieu de vous connecter mais de voir des erreurs de certificat), le problème est généralement lié au réseau ou au pare-feu.

Pour les erreurs de connexion HTTPS :

  • Vérifier que les règles de pare-feu sont correctement configurées

  • Vérifiez qu’aucun autre service n’utilise le port 443 :

    sudo ss -tulpn | grep :443

  • Vérifiez que le conteneur de cache connecté est en cours d’exécution :

    sudo docker ps | grep mcc

Pour les erreurs de connexion HTTP : Vérifiez que le service de cache connecté est en cours d’exécution et que le port 80 est accessible

sudo ss -tulpn | grep :80

Pour les problèmes de résolution DNS : Vérifier la résolution de noms d’hôte et la connectivité réseau

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

Interférence de proxy d’entreprise

Symptômes: La validation du certificat échoue malgré une configuration correcte.

Solution: Assurez-vous que le proxy d’entreprise n’intercepte pas le trafic HTTPS vers votre serveur de cache connecté. Envisagez de désactiver l’inspection TLS pour le trafic interne du cache connecté.

Ressources supplémentaires

  • Last updated on