Windows Server 2025 / Configurare HTTPS in IIS e verificare il certificato dal client

HTTPS in IIS richiede un certificato corrispondente al nome richiesto, la relativa chiave privata sul server e un binding HTTPS che utilizzi quel certificato. Verificate anche attendibilità del client, validità, condizioni di controllo della revoca e certificato effettivamente presentato, soprattutto dopo un rinnovo.

Controllare separatamente nome, chiave, fiducia e binding

HTTPS protegge il traffico HTTP con Transport Layer Security (TLS), il protocollo di sicurezza del trasporto. Il server presenta un certificato che collega un’identità a una chiave pubblica; il client controlla nome, validità e catena di attendibilità. La chiave privata resta sul server per dimostrare il possesso della chiave associata. Subject Alternative Name (SAN) è l’estensione che elenca i nomi ammessi: qui deve includere web.lab.example.test.

Aprire l’IP non equivale ad aprire il nome: un SAN DNS per web.lab.example.test non copre automaticamente 172.24.50.30. Lo standard di identità dei servizi TLS RFC 9525 usa identificatori SAN; una corrispondenza nel solo Common Name non basta. Il nome .test appartiene a questo laboratorio interno; servizi reali richiedono nomi controllati dall’organizzazione e un’autorità di certificazione (CA) appropriata. La guida HTTPS di IIS distingue certificato e binding; i suoi esempi storici SSL non raccomandano di abilitare protocolli obsoleti.

Creare un certificato per la prova isolata

Verificate prima LabSite con il nome web.lab.example.test, la risoluzione a 172.24.50.30 e la pagina HTTP attesa. Usate soltanto WEB1 e CLIENT1 isolati, senza esporre il servizio. Il certificato autofirmato è una prova: emittente e titolare fanno riferimento allo stesso certificato e i client non gli attribuiscono automaticamente fiducia. Non sostituisce emissione, validazione o gestione delle chiavi di produzione. Registrate prima binding, regole e stato dei due archivi di certificati.

Eseguite le righe una alla volta localmente su WEB1 in Windows PowerShell con privilegi elevati. Se la creazione fallisce, fermatevi e non usate un eventuale vecchio valore rimasto in labCertificate. Registrate l’impronta Thumbprint del nuovo oggetto fuori dalla sessione. Un mese di durata è una scelta del laboratorio: AddMonths(1) significa un mese di calendario, non una politica della CA né necessariamente 30 giorni. New-SelfSignedCertificate descrive nomi DNS in SAN e archivio del computer:

$labCertificate = New-SelfSignedCertificate -DnsName 'web.lab.example.test' -CertStoreLocation 'Cert:\LocalMachine\My' -FriendlyName 'LabSite HTTPS test' -NotAfter (Get-Date).AddMonths(1)
$labCertificate | Select-Object Subject,Thumbprint,NotAfter,HasPrivateKey

Su WEB1 aprite certlm.msc → Personale → Certificati e individuate l’impronta esatta registrata. Controllate SAN, scopo di autenticazione server, emittente, date e chiave privata associata. Ci si aspetta HasPrivateKey = True, ma questo indica soltanto l’associazione a una chiave, non che il servizio possa usarla. La gestione degli archivi di certificati Windows distingue computer locale e utente corrente. Prima di ripetere esaminate gli oggetti presenti, evitando copie indistinguibili. Il nome descrittivo non identifica un certificato univocamente.

Aggiungere il binding HTTPS sulla porta 8443

1. In Gestione IIS → WEB1 → Certificati server aggiornate la vista e trovate il nuovo certificato. Confrontate impronta e date registrate, non solo il nome descrittivo.
2. Aprite LabSite → Binding → Aggiungi e scegliete https, IP 172.24.50.30 e porta 8443. Verificate prima conflitti con combinazioni o servizi esistenti.
3. Inserite web.lab.example.test e selezionate Richiedi indicazione nome server. Non usate per errore il nome StatusSite.
4. Scegliete LabSite HTTPS test e confermate che corrisponda all’impronta registrata su WEB1. Se non compare o manca la chiave, controllate archivio e oggetto invece di selezionare un nome simile.
5. Controllate combinazione completa, duplicati e stato del sito. Mantenete HTTP 8080 invariato durante la prova per distinguere i due accessi.
6. Dopo aver verificato il profilo Dominio su WEB1, create Lab-IIS-HTTPS-8443 solo se non esiste: wf.msc → Regole connessioni in entrata → Nuova regola → Porta → TCP locale 8443 → Consenti → solo Dominio. In Proprietà → Ambito limitate IP remoti a 172.24.50.0/24. Esaminate altre regole e criteri senza ampliare profili o spegnere il firewall.

Server Name Indication (SNI), indicazione del nome server, permette al client di inviare il nome richiesto durante la negoziazione TLS e aiuta a selezionare il certificato quando si condividono IP e porta. Consultate gli attributi di binding e SNI. La porta 8443 separa la prova da HTTP 8080; la porta HTTPS usuale è 443. SNI non aggiunge attendibilità né modifica SAN. Un client privo del supporto necessario non autorizza a disabilitare la validazione.

Verificare fiducia e certificato reale da CLIENT1

Da CLIENT1 aprite https://web.lab.example.test:8443/. Prima di aggiungere fiducia è previsto un avviso per questo certificato autofirmato, ma un avviso può indicare anche altri problemi. Non ignoratelo per dichiarare successo e non inserite credenziali. Se il browser permette di esaminare il certificato senza proseguire, confrontate impronta, nome e validità con il registro WEB1. Se l’impronta è diversa o non riuscite a identificarlo, fermatevi e controllate il binding prima di importare fiducia.

1. Su WEB1, in certlm.msc → Personale → Certificati, selezionate per impronta il certificato di prova → Tutte le attività → Esporta. Scegliete di non esportare la chiave privata e un file pubblico .cer con nome e percorso nuovi, senza sovrascrivere altri file.
2. Trasferite quel .cer a CLIENT1 tramite un percorso di laboratorio fidato. Non create né distribuite un PFX con la chiave privata: al client serve il certificato pubblico, non la chiave server.
3. Aprite il file pubblico e confrontate l’impronta con il valore registrato su WEB1 attraverso un canale fidato indipendente da un file di origine sconosciuta. Controllate anche nome e validità. Se non coincide, non importate.
4. Su CLIENT1 come utente che eseguirà la prova, aprite certmgr.msc → Autorità di certificazione radice attendibili → Certificati → Tutte le attività → Importa. Scegliete solo il .cer verificato e confermate Utente corrente e questo archivio. Annotate impronta e ambito per rimuoverlo alla fine. Non importate su PC di produzione o tramite criteri di dominio.
5. Chiudete e riaprite il browser dello stesso utente e visitate https://web.lab.example.test:8443/. Controllate connessione senza avvisi, impronta e contenuto della pagina, non soltanto una scheda aperta.

Aggiungere una radice cambia ciò che è attendibile in quel contesto. Importate solo il certificato di prova creato e verificato, mai uno sconosciuto per togliere un avviso. Se il problema resta, controllate SAN, orari di client e server, validità, impronta effettivamente presentata e criteri del browser o dell’organizzazione. Utente corrente riguarda quell’utente: non dimostra che altri utenti o servizi usino lo stesso archivio. Non distribuite questa fiducia mediante criteri di dominio e non passate all’archivio globale per far funzionare la prova.

Test-NetConnection -ComputerName web.lab.example.test -Port 8443

TcpTestSucceeded: True dimostra soltanto una connessione TCP a 8443, non la negoziazione TLS, il nome, la catena o la pagina. Nel browser controllate certificato reale e percorso di certificazione, la stessa impronta registrata e il contenuto LabSite atteso. L’assenza di avvisi insieme a questi controlli è diversa dall’aver proseguito ignorando un avviso. Questa prova non dimostra neppure che funzioni il controllo di revoca di una CA reale.

Controllare i binding durante rinnovo e pulizia

Emettere o importare un sostituto nell’archivio non garantisce che IIS lo presenti. Controllate nuova chiave utilizzabile, nomi, catena, scopo e validità; aggiornate il binding previsto e confermate nuova impronta e pagina da un client separato. Registrate prima impronta e binding precedenti. Conservate il vecchio certificato finché dipendenze e necessità di ritorno siano chiare: un certificato scaduto o revocato non è un ripiego valido. Non sostituite tutti i binding automaticamente in base allo stesso nome descrittivo.

• Assegnate responsabile, metodo di rinnovo e avvisi per errori di emissione o distribuzione, non solo per l’arrivo della scadenza.
• Prevedete tempo prima della scadenza per approvazione, installazione, aggiornamento del binding e validazione dal client. Un avviso senza chi deve intervenire non completa il processo.
• Per certificati e criteri che richiedono verifica della revoca, mantenete accessibili le effettive posizioni di liste di revoca o risposte di stato. Non inventate questi percorsi per il certificato autofirmato né disabilitate controlli globali per nascondere un errore.
• Automatizzando il rinnovo controllate anche associazione del binding e certificato realmente servito. Un nuovo oggetto nell’archivio non dimostra che il traffico lo stia usando.

Per la pulizia rimuovete solo il binding HTTPS aggiunto a LabSite e la regola Lab-IIS-HTTPS-8443. Controllate dipendenze di altri binding o servizi prima di rimuovere da WEB1 → Computer locale → Personale il certificato di prova identificato dall’impronta. Su CLIENT1 aprite certmgr.msc e rimuovete solo la voce aggiunta da questa prova in Utente corrente → Autorità di certificazione radice attendibili con la stessa impronta. Verificate l’ambito se una vista eredita voci da un altro archivio, senza cancellare radici altrui o certificati dal nome simile. Decidete separatamente se mantenere HTTP 8080 o progettare un reindirizzamento HTTPS già verificato: aggiungere HTTPS non reindirizza né elimina automaticamente HTTP.