HTTPS-Unterstützung für Linux-Referenz für Microsoft Connected Cache

Dieser Artikel enthält weitere Details zum Linux-HTTPS-Setupflow für connected Cache.

Voraussetzungen

Clientverbindungsmethoden

Probieren Sie Folgendes aus, um die geeignete Verbindungsmethode für Ihren Connected Cache-Server für die Einrichtung der HTTPS-Unterstützung zu ermitteln.

  • Überprüfen der Konfiguration der Übermittlungsoptimierungsrichtlinie

    Wenn Ihr Netzwerk DHCP-Option 235 verwendet, um den Connected Cache-Server anzukündigen:

    resolvectl status | grep -A 10 "Link"

    Suchen Sie nach VON DHCP bereitgestellten DNS- oder Domäneninformationen, die möglicherweise auf Ihren Connected Cache-Server verweisen.

  • Überprüfen der Netzwerkkonfigurationsdateien

    Abhängig von Ihrer Linux-Distribution kann die Netzwerkkonfiguration statische Verweise auf den verbundenen Cache enthalten:

    # 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

  • Testen der Konnektivität mit dem verbundenen Cacheserver

    Der folgende Befehl überprüft die TCP-Konnektivität mit Port 80 auf dem Connected Cache-Server:

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

    Erwartete Ausgabe:Connection to [server] 80 port [tcp/http] succeeded!

    So erhalten Sie ausführlichere Informationen:

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

Port 443 Verfügbarkeit

  • Alternativer Befehl zum Überprüfen der Port 443-Verfügbarkeit:

    sudo netstat -tulpn | grep :443

  • Überprüfen Sie, welcher Prozess derzeit Port 443 verwendet:

    sudo lsof -i :443

Details zur Firewallkonfiguration

Verwenden Sie Folgendes, um zu überprüfen, ob Ihre Firewall HTTPS-Datenverkehr zu Ihrem Connected Cache-Server abfängt (z. B. über TLS-Überprüfung).

Allgemeine Linux-Distributionen:

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 (firewalld):

# 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 (traditionell):

# 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

Überlegungen zu SELinux

Wenn Sie RHEL/CentOS/Fedora mit aktiviertem SELinux ausführen, müssen Sie möglicherweise SELinux-Richtlinien konfigurieren:

# 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

Csr generieren

Beispiele für Scenario-Based-Parameter

Überprüfen Sie szenariobasierte Parameterbeispiele, und bearbeiten Sie Ihren generateCsr.sh Befehl entsprechend:

Einzelnes Office – nur IP-Adresse

Szenario: Kleine Filiale, in der Clients so konfiguriert sind, dass sie über eine statische IP-Adresse eine Verbindung mit Connected Cache herstellen (z. B. über die DOCacheHost-Richtlinie, die auf "192.168.1.100" festgelegt ist).

./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"

Enterprise Standard – DNS-Hostname

Szenario: Unternehmensumgebung, in der Clients eine Verbindung über einen standardisierten Hostnamen (mcc-server.contoso.com) herstellen.

./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"

DHCP-Ermittlungsumgebung

Szenario: Umgebung mit DHCP-Option 235 für die Ermittlung des verbundenen Caches, in der Clients eine Verbindung mit dem tatsächlichen Hostnamen des Servers oder dem von DHCP bereitgestellten Namen herstellen können.

./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"

Hybridumgebung – Gemischte Clientverbindungen

Szenario: Gemischte Umgebung während der Migration, in der einige Legacyclients weiterhin IP-Adressen verwenden, während neuere Clients DNS-Namen verwenden. Deckt beide Verbindungsmethoden ab.

./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"

Mehrere Standorte mit regionaler Benennung

Szenario: Große organization mit mehreren Verbundenen Cacheknoten unter Verwendung einer konsistenten Namenskonvention (mcc-region-site-Format). Dieses Beispiel gilt für einen Rechenzentrumsknoten in 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"

Entwicklungs-/Testumgebung

Szenario: Entwicklungsumgebung mit gelockerten Benennungsanforderungen. Unterstützt localhost-Tests und Lab-Netzwerkzugriff.

./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"

Hohe Sicherheit mit elliptischer Kurve

Szenario: Sicherheitsbewusste organization, die moderne ECC-Kryptografie für eine bessere Leistung und Einhaltung neuerer Sicherheitsstandards erfordern.

./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"

Cloud-/VM-Bereitstellung

Szenario: Connected Cache-Knoten, der auf einer Cloud-VM oder einem virtuellen Computer mit öffentlicher und privater Konnektivität bereitgestellt wird. Lokale Clients stellen eine Verbindung über private IP-Adresse/Hostname her, während cloudbasierte Clients den öffentlichen DNS-Namen verwenden können.

./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"

Docker-Containerumgebung

Szenario: Connected Cache wird im Docker-Container ausgeführt, in dem Clients eine Verbindung mit der IP-Adresse des Hostcomputers herstellen, aber das Zertifikat das Containernetzwerk berücksichtigen muss.

./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"

Sign CSR

Konvertieren in den CRT-Dateityp

  • Wenn Sie erhalten .cer:

    mv xxxx.cer xxxx.crt

    Oder mit OpenSSL:

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

  • Wenn Sie erhalten .der:

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

Überprüfen des Zertifikatinhalts

Überprüfen Sie nach der Konvertierung, ob das Zertifikat korrekt ist:

openssl x509 -in xxxx.crt -text -noout

Schaue nach:

  • Betreff: Sollte ihrem CSR-Thema entsprechen
  • Alternativer Antragstellername: Sollte alle konfigurierten SANs enthalten
  • Gültigkeit: Datumsangaben "Not Before" und "Not After"
  • Signaturalgorithmus: Sollte mit Dem von Ihnen gewählten Algorithmus (RSA, EC usw.) übereinstimmen

Zusätzliche Ressourcen

  • Last updated on