Internet Information Services 8 – Centralized Certificates Storage

Buongiorno a tutti, oggi trattiamo una funzionalità tutta nuova di IIS 8 in Windows Server 2012. Ringraziamo per questo approfondimento Silvio Di Benedetto. Prima di addentrarci nell’argomento una piccola presentazione dell’autore:

Silvio Di Benedetto: è titolare della Inside Technologies, azienda di consulenza e docenza, oltre che essere Community Lead di WindowServer.it e Microsoft MVP per la categoria System Center Cloud and Datacenter Management.

 

Gestire più Web Server è sicuramente un'operazione molto impegnativa, perchè è necessario tenerli allineati a livello di update, di componenti e di certificati digitali.

I certificati digitali sono sicuramente uno degli aspetti più delicati e lo diventano ancora di più quando il numero dei front-end aumenta in modo sensibile: rinnovarlo su 10 web server in parallelo è impossibile, quindi queste operazioni sono da svolgere nella notte oppure durante il giorno, però mettendo fuori servizio per un certo lasso di tempo la macchina stessa.

Con Windows Server 2012 ed Internet Information Services 8, è stata introdotta una nuova feature che si chiama Centralized Certificates Storage. Il compito di questo componente è di gestire tutti i certificati dei propri siti web in modo centralizzato e distribuirli tramite una share di rete.

La prima cosa da fare è installare il componente, presente sotto Web Server -> Security - come mostra la figura

NB: Questa operazione va ripetuta per tutti i web server dove volete gestire i certificati in modo centralizzato.

Passo successivo è creare una cartella condivisa, inserendo i permessi corretti: la cosa migliore è quella di creare un utente dentro Active Directory; nel caso le macchine fossero in WORKGROUP, l'utente utilizzato dovrà essere creato localmente in ogni singola macchina. Terminata questa operazione, sarà possibile attivare la feature dentro IIS. Selezionare Centralized Certificates all'interno della Main Page del Web Server, come mostra la figura

Cliccando su Edit Feature Setting si aprirà una schermata per l'inserimento dei valori necessari per il corretto funzionamento, compilateli correttamente come mostra la figura 3. La voce legata al Private Key va inserita solo nel caso in cui ci siano certificati con chiavi private. In questo momento non è possibile inserire più password, quindi se ci fossero più certificati con chiave privata, tutti dovranno avere la stessa password.

 

Chiusa la schermata, partirà subito la scansione della cartella con conseguente esposizione dei certificati rilevati all'interno di essa - figura 4. Molto utile la funzione che mostra lo stato dei certificati, dividendo quelli non validi da quelli scaduti; questa cosa è molto importante per avere subito sott'occhio la situazione. I certificati devono essere tutti a chiave privata e devono essere nominati in questo modo:

· www.insidetech.lab - quando il certificato è legato ad un solo sito

_.insidetech.lab - quando il certificato è di tipo wildcard

 

L'associazione certificato/sito si fa sempre nel solito modo, ovvero selezionando il Bindings in HTTPS e scegliendo l'uso del CCS, come mostra la figura 5. In caso si stia usando un certificato che presenta dei Subject Alternative Name (SAN), è importante scegliere la voce Require Server Name Indication. Il SNI è un'estensione del protocollo SSL/TLS introdotto in IIS 8 per aumentare la scalabilità in scenari in cui c'è un solo certificato con tanti nomi al suo interno, che puntano ad un solo indirizzo IP (cosa abbastanza solita nelle soluzioni Cloud).

Da questo momento il sito web sarà agganciato ad uno store centralizzato che fornirà il certificato sempre aggiornato. La cosa molto interessante è legata al fatto che non è necessario installare localmente il certificato e, soprattutto, che non è necessario fare niente quando arriva il momento di fare il rinnovo, se non aggiornare il file .pfx all'interno della share di rete.