Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
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/interfacesTestare 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] 80Output 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 :443Controllare 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.crtOppure con OpenSSL:
openssl x509 -in xxxx.cer -out xxxx.crtSe 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)