Indice dei contenuti
Se vi siete imbattuti in questo articolo è molto probabile che stiate combattendo contro un noto glitch della IIS Manager Console, ovvero del pannello di gestione del servizio Internet Information Services - il server web fornito nativamente con tutte le principali versioni di Windows e Windows Server.
Nello specifico, il problema è legato al fatto che il certificato, pur dando l'impressione di essere stato aggiunto alla lista della sezione Certificati del Server, di fatto viene rifiutato: la riprova di questo è data dal fatto che, uscendo e rientrando nell'interfaccia Certificati del Server, il certificato risulta "scomparso", ovvero non più presente nell'elenco.
Questo insolito comportamento, in base al quale il certificato sembra essere stato aggiunto ma in realtà è stato rifiutato, è causato da un bug dell'interfaccia della sezione Certificati del Server presente fin dalle primissime versioni di IIS e mai corretto: in ogni caso, al di là di questo piccolo problema di visualizzazione e dell'assoluta mancanza di un messaggi odi errore, il concetto di fondo è che il certificato inserito presenta alcuni problemi e, di conseguenza, non può essere accettato da IIS.
Prima di spiegare il perché, è opportuno fare un paio di passi indietro e comprendere cosa è un certificato SSL e come funziona la sua registrazione all'interno del registro dei certificati (il cosiddetto "portachiavi") di un sistema operativo. Se la cosa non vi interessa, e/o avete fretta di leggere la soluzione, potete saltare gran parte dei contenuti di questo articolo e recarvi direttamente al paragrafo Il Ruolo di IIS: in caso contrario... buona lettura!
Certificato SSL: di cosa si tratta?
Con i termini Certificato SSL, Certificato Digitale o Certificato HTTPS si intende un documento elettronico che attesta l'associazione univoca tra una chiave pubblica e l'identità di un soggetto (una persona, una società, un computer, etc) che dichiara di utilizzarla nell'ambito delle procedure di cifratura asimmetrica e/o autenticazione tramite firma digitale. Tale certificato, fornito da un ente terzo fidato e riconosciuto come autorità di certificazione (CA), è a sua volta autenticato per evitarne la falsificazione sempre attraverso firma digitale, ovvero cifrato con la chiave privata dell'associazione la quale fornisce poi la rispettiva chiave pubblica associata per verificarlo.
Il tipo e il livello di crittografia utilizzata dai certificati SSL varia nel corso del tempo, seguendo l'inevitabile evolversi degli algoritmi di sicurezza e la capacità di calcolo degli elaboratori. Al momento (ottobre 2018) lo standard più diffuso tra quelli disponibili sul mercato, acquistato dalla quasi totalità dei siti e delle aziende informatiche, prevede l'utilizzo di una chiave RSA da 2048 bit e una cifratura a 256 bit.
Certificate Signing Request (CSR)
Il rilascio di un certificato può avvenire soltanto previa generazione di una Certificate Signing Request, ovvero una richiesta di firma formale da parte di colui che vuole ricevere/acquistare il certificato (che chiameremo per comodità richiedente) e rivolta all'autorità di certificazione esterna di cui sopra (che chiameremo CA).
La CSR è un blocco di testo codificato che contiene una serie di informazioni che verranno incluse nel certificato, come nome dell'organizzazione, nome comune (nome dominio), località e paese; contiene inoltre anche la chiave pubblica (public key) che verrà inclusa nel certificato.
Chiave Pubblica e Chiave Privata
La CSR viene generalmente generata sul server fisico o virtualizzato in cui verrà installato il certificato, ma può anche essere generata dal pannello di controllo del proprio servizio di hosting, dal servizio presso cui si acquista il certificato o da un altra macchina: tutti questi metodi sono ugualmente validi e sicuri, a patto che il sistema di generazione del CSR crei e fornisca al richiedente anche la chiave privata (private key), che sarà necessaria per l'installazione (e per il corretto funzionamento) del certificato emesso in base a quella determinata CSR. L'insieme di chiave pubblica e chiave privata è noto come coppia di chiavi. Il loro funzionamento è semplice da immaginare: la chiave pubblica, presente nel CSR e nel certificato stesso, sarà inviata a tutti i server che effettueranno la connessione con il server in modalità SSL, che potranno utilizzarla per decriptare il certificato stesso e confermarne quindi l'identità e la validità; la chiave privata, presente soltanto nel portachiavi della macchina sulla quale è installato il certificato, è utilizzata per effettuare l'encrypting del certificato. A verifica avvenuta, la medesima tecnica sarà utilizzata anche per encriptare e decriptare tutti i dati trasmessi tra le due macchine.
Emissione del certificato (CER / CRT)
Nei paragrafi precedenti abbiamo visto come il richiedente, al fine di ottenere un certificato SSL, genera una CSR e la relativa chiave privata, inviando la prima all'Autorità di Certificazione e tenendo la seconda per sé. La CA, non appena riceve il CSR (e il relativo pagamento), provvede quindi a generare il certificato, firmandolo a sua volta con una propria chiave privata e consegnando la relativa chiave pubblica al richiedente. Quest'ultimo riceve dunque un file di testo contenente il certificato (solitamente con estensione CER o CRT) e uno o più certificati intermedi, ovvero quelli rilasciati alla CA stessa da una CA di ordine superiore (CA root) e necessari per poter autenticare tutta la catena dei certificati rilasciati (certificate chain). Per una panoramica sui vari formati utilizzati per l'invio dei certificati SSL dai vari provider, CA e rivenditori, consigliamo di dare un'occhiata a questo articolo.
Al richiedente non resta dunque che installare il certificato - insieme, eventualmente, alla certificate chain - sul proprio sistema. Questo, a seconda della configurazione del server, può avvenire in uno o più punti dell'infrastruttura:
- A livello di Reverse Proxy (es. NGINX), nei casi in cui la connessione viene gestita da un reverse proxy che si occupa di gestire l'encryption/decryption del canale SSL prima di inoltrare le connessioni al web server retrostante: questo è il tipico scenario delle configurazioni in modalità edge-proxy basate su NGINX + IIS, NGINX + Apache o NGINX + PHP-FPM, di cui abbiamo parlato diffusamente nella nostra serie di articoli su NGINX.
- A livello di Firewall (es. Kerio Control), nei casi in cui il Firewall è dotato di una funzionalità di reverse proxy e questa viene utilizzata in luogo della configurazione di cui sopra o in aggiunta ad essa.
- A livello di Web Server (es. IIS, Apache, NGINX), nei casi in cui il Web Server è chiamato a gestire direttamente l'encryption/decryption del canale SSL, a prescindere che vi siano o meno reverse proxy a monte delle connessioni in entrata.
Il ruolo di IIS
Come possiamo comprendere leggendo il paragrafo precedente, IIS entra in gioco quando il Web Server è chiamato a gestire direttamente l'encryption/decryption del canale SSL - a patto, ovviamente, che si tratti del Web Server utilizzato dal richiedente.
Chiarito questo, possiamo tornare a parlare del nostro problema principale: come mai IIS non è in grado di accettare il certificato SSL fornito dall'Autorità di Certificazione, se questo è stato emesso senza errori di sorta? La risposta, in base a quanto abbiamo spiegato sopra, non può che essere una: perché non possiede la chiave privata necessaria per decriptare il certificato stesso, o ne possiede una diversa da quella generata insieme alla richiesta CSR inviata alla CA e da questa utilizzata per creare il certificato.
Questa eventualità, relativamente a IIS, capita solitamente in uno dei seguenti casi:
- Si sta cercando di installare un certificato su una macchina diversa da quella utilizzata per creare la CSR. Si tratta di gran lunga della casistica più comune ed è dovuta al fatto che, quando si genera una CSR con lo strumento Crea richiesta di certificato di IIS, la chiave privata non viene "consegnata" al richiedente sotto forma di file ma viene salvata all'interno del registro dei certificati di Windows: in altre parole, viene memorizzata "segretamente" nel sistema, così da poter essere richiamata al momento dell'installazione del certificato... ma soltanto se il certificato viene installato su quella stessa macchina. In tutti gli altri casi, il certificato non potrà essere installato e si verificherà l'errore/bug al quale il presente articolo è dedicato.
- Si sta cercando di importare un certificato che è stato esportato senza chiave privata, ovvero senza alcuna possibilità di completare l'operazione. Anche in questo caso si tratta quasi sempre di un errore dovuto all'ingenuità del richiedente, il quale effettua una "migrazione" (tipicamente da una macchina IIS a un'altra macchina IIS) e dimentica di esportare il certificato, limitandosi a tentare di installare sulla nuova macchina il certificato ricevuto dalla CA, oppure lo esporta senza includere la chiave privata.
Come si può facilmente notare, in entrambi i casi l'errore è indirettamente provocato dalla "mancata consegna" da parte di Windows/IIS del file relativo alla chiave privata: un behaviour che è pesso fonte di confusione per il richiedente, che - se non è pratico di certificati - rischia di "dimenticarla" sul server dal quale è stata inizialmente creata la CSR.
Possibili soluzioni
La soluzione a questo problema può essere molto semplice oppure piuttosto complessa a seconda delle informazioni di cui il richiedente dispone. Le elenchiamo di seguito, in ordine di semplicità.
- Se si dispone ancora di almeno una macchina IIS su cui il certificato risulta correttamente installato è sufficiente esportare il certificato, utilizzando la funzionalità "Esporta..." presente nel pannello IIS Manager > Certificati del Server. Si tratta indubbiamente della soluzione più semplice, in quanto sarà generato un file PFX che potrà poi essere importato facilmente all'interno del "nuovo" IIS.
- Se si possiede la chiave privata in formato file, è possibile creare un file PFX mediante lo strumento gratuito OpenSSL, nativo per Linux ma disponibile anche per Windows a questo indirizzo. Le istruzioni su come generare un PFX partendo da uno (o più) certificati CER/CRT e una chiave privata sono spiegate in questo articolo.
- Se si possiede di un backup PFX della chiave privata e/o dell'intera richiesta CSR, è possibile utilizzare lo strumento OpenSSL per estrarre il file .key: una volta ottenuto, si potrà procedere con il punto 2 descritto sopra. Per una guida su come estrarre una chiave privata da un PFX è possibile dare un'occhiata a questo articolo.
- Se si dispone ancora della macchina IIS con cui è stata creata la richiesta CSR, sarà necessario prima effettuare un backup PFX della richiesta CSR (e relativa chiave primaria) come descritto in questo articolo, quindi estrarre la chiave primaria (vedi punto 3) e infine creare il PFX con la suddetta chiave ed il certificato CRT (come spiegato nel punto 2).
Inutile dire che tutte le soluzioni, con la sola eccezione della prima, richiedono necessariamente che il richiedente disponga anche del certificato CER o CRT. In caso contrario, e/o in tutti i casi in cui non si disponga né della chiave privata, né di un computer su cui questa è installata e/o di un backup della stessa, sarà necessario richiedere nuovamente il certificato presso la CA mediante una nuova CSR: mi raccomando, questa volta provvedete a farvi un backup della chiave privata seguendo le istruzioni contenute in questo articolo!
Conclusioni
Per il momento è tutto: spero che questa panoramica sui certificati SSL e del ruolo di IIS nella gestione degli stessi possa essere utile ai tanti amministratori che si imbattono in questo tipo di problemi nel corso della loro attività lavorativa. Alla prossima!
