Informazioni di riferimento sul supporto HTTPS per Linux per Microsoft Connected Cache

Questo articolo fornisce maggiori dettagli per il flusso di installazione HTTPS di Linux nella cache connessa.

Prerequisiti

Metodi di connessione client

Provare quanto segue per determinare il metodo di connessione appropriato al server di Cache connessa, ai fini della configurazione del supporto HTTPS.

  • Controllare la configurazione dei criteri di ottimizzazione recapito

    Se la rete usa l'opzione DHCP 235 per annunciare il server cache connessa:

    resolvectl status | grep -A 10 "Link"
    

    Cercare informazioni sul dns o sul dominio fornite da DHCP che potrebbero fare riferimento al server cache connessa.

  • Controllare i file di configurazione di rete

    A seconda della distribuzione Linux, la configurazione di rete può contenere riferimenti statici alla cache connessa:

    # 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
    
  • Testare la connettività al server della cache connessa

    Il comando seguente controlla la connettività TCP alla porta 80 nel server Cache connessa:

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

    Output previsto:Connection to [server] 80 port [tcp/http] succeeded!

    Per ottenere informazioni più dettagliate:

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

Disponibilità della porta 443

  • Comando alternativo per controllare la disponibilità della porta 443:

    sudo netstat -tulpn | grep :443
    
  • Controllare quale processo sta attualmente usando la porta 443:

    sudo lsof -i :443
    

Dettagli di configurazione del firewall

Usare quanto segue per verificare se il firewall intercetta il traffico HTTPS verso il server della cache connessa (ad esempio, tramite l'ispezione TLS)

Distribuzioni Linux comuni:

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 (con firewall):

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

# 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

Considerazioni su SELinux

Se si esegue RHEL/CentOS/Fedora con SELinux abilitato, potrebbe essere necessario configurare i criteri 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

Generare csr

Esempi di parametri Scenario-Based

Esaminare gli esempi di parametri basati su scenari e apportare modifiche al generateCsr.sh comando di conseguenza:

Single Office - Solo indirizzo IP

Scenario: piccola succursale in cui i client sono configurati per la connessione alla cache connessa usando un indirizzo IP statico(ad esempio, tramite il criterio DOCacheHost impostato su "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"

Enterprise Standard - Nome host DNS

Scenario: ambiente aziendale in cui i client si connettono tramite nome host standardizzato (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"

Ambiente di individuazione DHCP

Scenario: ambiente che usa l'opzione DHCP 235 per l'individuazione della cache connessa in cui i client possono connettersi usando il nome host effettivo del server o il nome fornito da 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"

Ambiente ibrido - Connessioni client miste

Scenario: ambiente misto durante la migrazione in cui alcuni client legacy usano ancora indirizzi IP mentre i client più recenti usano nomi DNS. Vengono illustrati entrambi i metodi di connessione.

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

Multisito con denominazione a livello di area

Scenario: organizzazione di grandi dimensioni con più nodi della cache connessa che usano una convenzione di denominazione coerente (formato mcc-region-site). Questo esempio è relativo a un nodo del data center di 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"

Ambiente di sviluppo/test

Scenario: ambiente di sviluppo con requisiti di denominazione meno rigorosi. Supporta i test localhost e l'accesso alla rete 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"

Alta sicurezza con curva ellittica

Scenario: organizzazione attenta alla sicurezza che richiede la crittografia ECC moderna per migliorare le prestazioni e la conformità agli standard di sicurezza più recenti.

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

Distribuzione cloud/macchina virtuale

Scenario: nodo della cache connessa distribuito in una macchina virtuale cloud o in una macchina virtuale con connettività pubblica e privata. I client locali si connettono tramite IP privato/nome host, mentre i client basati sul cloud possono usare il nome DNS pubblico.

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

Ambiente contenitore Docker

Scenario: Cache connessa in esecuzione nel contenitore Docker in cui i client si connettono all'IP del computer host, ma il certificato deve tenere conto della rete dei contenitori.

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

Firma csr

Converti in tipo di file con estensione crt

  • Se si riceve .cer:

    mv xxxx.cer xxxx.crt
    

    Oppure con OpenSSL:

    openssl x509 -in xxxx.cer -out xxxx.crt
    
  • Se si riceve .der:

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

Verificare il contenuto del certificato

Dopo la conversione, verificare che il certificato sia corretto:

openssl x509 -in xxxx.crt -text -noout

Cercare:

  • Oggetto: Deve corrispondere all'oggetto csr
  • Nome alternativo soggetto: Deve contenere tutti i nomi SAN configurati
  • Validità: Non prima e non dopo le date
  • Algoritmo di firma: Deve corrispondere all'algoritmo scelto (RSA, EC e così via)

Risorse aggiuntive