Informations de référence sur la prise en charge HTTPS pour Linux pour Microsoft Connected Cache

Cet article fournit plus de détails sur le flux de configuration https Linux sur le cache connecté.

Conditions préalables

Méthodes de connexion client

Essayez ce qui suit pour déterminer la méthode de connexion appropriée à votre serveur de cache connecté, afin de configurer la prise en charge https.

  • Vérifier la configuration de la stratégie d’optimisation de la distribution

    Si votre réseau utilise l’option DHCP 235 pour publier le serveur de cache connecté :

    resolvectl status | grep -A 10 "Link"

    Recherchez les informations DNS ou de domaine fournies par DHCP qui peuvent référencer votre serveur de cache connecté.

  • Vérifier les fichiers de configuration réseau

    Selon votre distribution Linux, la configuration réseau peut contenir des références statiques de cache connecté :

    # For systems using NetworkManager
cat /etc/NetworkManager/system-connections/*

# For systems using netplan (Ubuntu 18.04+)
cat /etc/netplan/*.yaml

# For traditional /etc/network/interfaces
cat /etc/network/interfaces

  • Tester la connectivité au serveur de cache connecté

    La commande suivante vérifie la connectivité TCP au port 80 sur le serveur de cache connecté :

    nc -zv [insert-mcc-server-ip-or-hostname] 80

    Sortie attendue :Connection to [server] 80 port [tcp/http] succeeded!

    Pour obtenir des informations plus détaillées :

    curl -v -I http://[insert-mcc-server-ip-or-hostname]/

Disponibilité du port 443

  • Autre commande pour case activée disponibilité du port 443 :

    sudo netstat -tulpn | grep :443

  • Vérifiez quel processus utilise actuellement le port 443 :

    sudo lsof -i :443

Détails de la configuration du pare-feu

Utilisez ce qui suit pour case activée si votre pare-feu intercepte le trafic HTTPS vers votre serveur de cache connecté (par exemple, via une inspection TLS)

Distributions Linux courantes :

Ubuntu/Debian (UFW) :

# Check firewall status
sudo ufw status

# Allow port 443
sudo ufw allow 443/tcp

# Reload firewall
sudo ufw reload

# Verify rule was added
sudo ufw status numbered

RHEL/CentOS/Fedora (pare-feu) :

# Check firewall status
sudo firewall-cmd --state

# Allow port 443 temporarily (until reboot)
sudo firewall-cmd --add-port=443/tcp

# Allow port 443 permanently
sudo firewall-cmd --permanent --add-port=443/tcp

# Reload firewall
sudo firewall-cmd --reload

# List all rules
sudo firewall-cmd --list-all

iptables (traditionnel) :

# Check current rules
sudo iptables -L -n -v

# Add rule for port 443
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Save rules (location varies by distribution)
# For Ubuntu/Debian:
sudo iptables-save | sudo tee /etc/iptables/rules.v4

# For RHEL/CentOS:
sudo service iptables save

Considérations relatives à SELinux

Si vous exécutez RHEL/CentOS/Fedora avec SELinux activé, vous devrez peut-être configurer les stratégies SELinux :

# Check SELinux status
sestatus

# Allow HTTP/HTTPS traffic
sudo setsebool -P httpd_can_network_connect 1

# If using custom ports, add them to SELinux
sudo semanage port -a -t http_port_t -p tcp 443

Générer une demande de signature de certificat

exemples de paramètres Scenario-Based

Passez en revue les exemples de paramètres basés sur un scénario et apportez des modifications à votre generateCsr.sh commande en conséquence :

Office unique - Adresse IP uniquement

Scénario : Petite succursale où les clients sont configurés pour se connecter au cache connecté à l’aide d’une adresse IP statique (par exemple, via la stratégie DOCacheHost définie sur « 192.168.1.100 »).

./generateCsr.sh \
    -algo RSA \
    -keySizeOrCurve 2048 \
    -csrName "mcc-branch-office" \
    -subjectCommonName "192.168.1.100" \
    -subjectCountry "US" \
    -subjectState "TX" \
    -subjectOrg "Contoso Corp" \
    -sanIp "192.168.1.100"

Entreprise Standard - Nom d’hôte DNS

Scénario : Environnement d’entreprise dans lequel les clients se connectent via un nom d’hôte normalisé (mcc-server.contoso.com).

./generateCsr.sh \
    -algo RSA \
    -keySizeOrCurve 4096 \
    -csrName "mcc-enterprise-prod" \
    -subjectCommonName "mcc-server.contoso.com" \
    -subjectCountry "US" \
    -subjectState "Washington" \
    -subjectOrg "Contoso Corporation" \
    -sanDns "mcc-server.contoso.com"

Environnement de découverte DHCP

Scénario : Environnement utilisant l’option DHCP 235 pour la découverte du cache connecté dans lequel les clients peuvent se connecter à l’aide du nom d’hôte réel du serveur ou du nom fourni par DHCP.

./generateCsr.sh \
    -algo RSA \
    -keySizeOrCurve 2048 \
    -csrName "mcc-dhcp-discovery" \
    -subjectCommonName "cache-server.corporate.local" \
    -subjectCountry "US" \
    -subjectState "FL" \
    -subjectOrg "Corporate IT Services" \
    -sanDns "cache-server.corporate.local,mcc-auto.corporate.local,fileserver.corporate.local"

Environnement hybride - Connexions clientes mixtes

Scénario : Environnement mixte pendant la migration où certains clients hérités utilisent toujours des adresses IP tandis que les clients plus récents utilisent des noms DNS. Couvre les deux méthodes de connexion.

./generateCsr.sh \
    -algo RSA \
    -keySizeOrCurve 2048 \
    -csrName "mcc-hybrid-migration" \
    -subjectCommonName "mcc-cache.contoso.com" \
    -subjectCountry "US" \
    -subjectState "CA" \
    -subjectOrg "Contoso Inc" \
    -sanDns "mcc-cache.contoso.com,cache.contoso.local" \
    -sanIp "10.0.1.50,192.168.100.10"

Multisite avec nommage régional

Scénario : Organization volumineux avec plusieurs nœuds de cache connecté à l’aide d’une convention de nommage cohérente (format mcc-region-site). Cet exemple concerne un nœud de centre de données Seattle.

./generateCsr.sh \
    -algo RSA \
    -keySizeOrCurve 4096 \
    -csrName "mcc-seattle-dc1" \
    -subjectCommonName "mcc-sea-dc1.corp.contoso.com" \
    -subjectCountry "US" \
    -subjectState "Washington" \
    -subjectOrg "Contoso Corporation" \
    -sanDns "mcc-sea-dc1.corp.contoso.com,mcc-seattle.contoso.com"

Environnement de développement/test

Scénario : Environnement de développement avec des exigences de nommage souples. Prend en charge les tests localhost et l’accès réseau lab.

./generateCsr.sh \
    -algo RSA \
    -keySizeOrCurve 2048 \
    -csrName "mcc-dev-lab" \
    -subjectCommonName "localhost" \
    -subjectCountry "US" \
    -subjectState "Dev" \
    -subjectOrg "IT Development" \
    -sanDns "localhost,mcc-dev.lab.local,devserver.local" \
    -sanIp "127.0.0.1,192.168.10.100,10.10.10.50"

Haute sécurité avec courbe elliptique

Scénario : organization de sécurité nécessitant un chiffrement ECC moderne pour améliorer les performances et la conformité aux normes de sécurité les plus récentes.

./generateCsr.sh \
    -algo EC \
    -keySizeOrCurve secp384r1 \
    -csrName "mcc-secure-prod" \
    -subjectCommonName "mcc-secure.defense.gov" \
    -subjectCountry "US" \
    -subjectState "VA" \
    -subjectOrg "Department of Defense" \
    -sanDns "mcc-secure.defense.gov"

Déploiement de machines virtuelles/cloud

Scénario : Nœud de cache connecté déployé sur une machine virtuelle cloud ou une machine virtuelle avec une connectivité publique et privée. Les clients locaux se connectent via une adresse IP/un nom d’hôte privé, tandis que les clients basés sur le cloud peuvent utiliser le nom DNS public.

./generateCsr.sh \
    -algo RSA \
    -keySizeOrCurve 2048 \
    -csrName "mcc-cloud-hybrid" \
    -subjectCommonName "mcc-eastus.cloudapp.azure.com" \
    -subjectCountry "US" \
    -subjectState "WA" \
    -subjectOrg "Contoso Corporation" \
    -sanDns "mcc-eastus.cloudapp.azure.com,mcc-cloud.contoso.local,mcc-vm01.contoso.com" \
    -sanIp "10.0.1.10,172.16.0.50"

Environnement de conteneur Docker

Scénario : Cache connecté s’exécutant dans un conteneur Docker où les clients se connectent à l’adresse IP de l’ordinateur hôte, mais le certificat doit prendre en compte la mise en réseau des conteneurs.

./generateCsr.sh \
    -algo RSA \
    -keySizeOrCurve 2048 \
    -csrName "mcc-docker-host" \
    -subjectCommonName "mcc-docker.company.local" \
    -subjectCountry "US" \
    -subjectState "CA" \
    -subjectOrg "Company IT" \
    -sanDns "mcc-docker.company.local,localhost" \
    -sanIp "192.168.1.100,172.17.0.1,127.0.0.1"

Signer la demande de signature de certificat

Convertir en type de fichier .crt

  • Si vous recevez .cer:

    mv xxxx.cer xxxx.crt

    Ou avec OpenSSL :

    openssl x509 -in xxxx.cer -out xxxx.crt

  • Si vous recevez .der:

    openssl x509 -inform DER -in xxxx.der -out xxxx.crt

Vérifier le contenu du certificat

Après la conversion, vérifiez que le certificat est correct :

openssl x509 -in xxxx.crt -text -noout

Chercher:

  • Objet: Doit correspondre à votre objet CSR
  • Autre nom de l’objet : Doit contenir tous vos SAN configurés
  • Validité: Dates Not Before et Not After
  • Algorithme de signature : Doit correspondre à l’algorithme choisi (RSA, EC, etc.)

Ressources supplémentaires

  • Last updated on