• Guide, Sicurezza, Sistemi Operativi
• 27 Marzo 2017

L’implementazione di una Certification Authority (CA) nella propria infrastruttura prevede una preventiva analisi della struttura della Public Key Infrastructure (PKI) più adatta alla propria organizzazione e la predisposizione dei prerequisiti necessari. La trattazione delle componenti di una PKI e della configurazione di un server web per la pubblicazione della CRL e dei certificati delle CA è disponibile nel precedente articolo Deploy PKI in Windows Server 2016 – Parte 1.

Di seguito analizzeremo l’installazione e la configurazione di una Root CA Offline, nell’ipotesi di voler realizzare una CA Two-Tier (a due livelli) facendo riferimento al seguente schema che verrà utilizzato come scenario di esempio.

La Root CA viene mantenuta normalmente spenta, di conseguenza è preferibile che non sia integrata in Active Directory e quindi dovrà essere Standalone e non Enterprise, mentre la Subordinate CA a cui verrà demandano il compito di rilasciare i certificati sarà di tipo Enterprise per beneficiare dell’utilizzo dei modelli di certificato e dell’integrazione con Active Directory.

Sebbene spesso la giustificazione del fatto che la Root CA Offline è preferibile che sia non joinata ad un domino Active Directory, e quindi Standalone e non Enterprise, sia imputata al fatto che la scadenza della password dell’account computer che per default avviene ogni 30 giorni, causando l’impossibilità di utilizzare il secure channel. In realtà come indicato nel post Machine Account Password Process dal momento che il processo di rinnovo della password dell’account computer è avviato dal client non vi alcun rischio che il secure channel non possa essere utilizzato anche se la Root CA viene mantenuta spenta per lunghi periodi.

“Question: If a workstation does not change its password, will it not be allowed to log onto the network?

Answer: Machine account passwords as such do not expire in Active Directory. They are exempted from the domain’s password policy. It is important to remember that machine account password changes are driven by the CLIENT (computer), and not the AD. As long as no one has disabled or deleted the computer account, nor tried to add a computer with the same name to the domain, (or some other destructive action), the computer will continue to work no matter how long it has been since its machine account password was initiated and changed.

So if a computer is turned off for three months nothing expires. When the computer starts up, it will notice that its password is older than 30 days and will initiate action to change it. The Netlogon service on the client computer is responsible for doing this. This is only applicable if the machine is turned off for such a long time.

Before we set the new password locally, we ensure we have a valid secure channel to the DC. If the client was never able to connect to the DC (where never is anything prior the time of the attempt – time to refresh the secure channel), then we will not change the password locally.”

In realtà il vero motivo per cui è preferibile la Root CA sia Standalone è che per avere un’elevata sicurezza non dovrebbe essere connessa alla rete neppure quando viene avviata saltuariamente per installare gli aggiornamenti automatici, ma attestata su una rete separata che consenta la comunicazione con l’infrastruttura solo per permettere l’aggiornamento della CRL e del certificato della CA sul server web che si occupa di pubblicarli.

Per ulteriori informazioni si vedano:

• Certification Authority Guidance
• Securing Public Key Infrastructure (PKI)
• Server Certificate Deployment
• AD CS Step by Step Guide: Two Tier PKI Hierarchy Deployment

Installazione e configurazione della Root CA Offline

Per configurare il servizio di CA occorre aggiungere il ruolo Active Directory Certificate Services selezionando l’installazione del servizio Certification Autority.

Terminata l’installazione è possibile configurare il servizio della CA in base alle seguenti impostazioni utilizzando le credenziali di amministratore locale.

Per sicurezza il nome della CA non fa alcun riferimento all’hostname del server e il database dei certificati viene mantenuto in un disco separato da quello di sistema.

Configurazione Estensioni della Root CA Offline per impostare i CRL (Certificate Revocation List) Distribution Points (CDP)

Lo scopo delle estensioni CRL CDP è quello di indicare ai client dove trovare le CRL aggiornate firmate dalla CA, tali informazioni verranno poi inserite nei certificati generati dalla CA.

Per impostazione predefinita vi sono quattro CRL CDP già configurati e su alcuni di essi occorre eseguire alcune impostazioni affinché l’unico riferimento alla CRL che verrà inserito nei certificati rilasciati sia quello dell’URL del server Web che pubblica la CRL. Nello scenario di esempio l’URL di pubblicazione della CRL è http://crl.ictpower.local/CertEnroll.

Il CRL CDP locale è usato dalla CA e non necessita di essere modificato.

Il CRL CDP ldap deve essere modificato in modo da non pubblicare la CRL, volendo è anche possibile rimuovere tale CRL CDP dal momento che di fatto non verrà utilizzato.

Il CRL CDP http è già impostato in modo da non pubblicare la CRL, volendo è anche possibile rimuovere tale CRL CDP dal momento che di fatto non verrà utilizzato.

Il CRL CDP file deve essere modificato in modo da non pubblicare la CRL, volendo è anche possibile rimuovere tale CRL CDP dal momento che di fatto non verrà utilizzato.

Creare un CRL CDP per l’URL http con le opzioni di inclusione nella CRL per l’URL http://crl.ictpower.local/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl.

Applicare le modifiche riavviando i servizi della CA.

Configurazione Estensioni della Root CA Offline per impostare gli Access Information Access (AIA) Distribution Points (CDP)

Lo scopo delle estensioni AIA CDP è quello di indicare ai client dove trovare il certificato della CA per eseguire la verifica dell’attendibilità nel caso in cui il certificato non contenga al suo interno la catena dei certificati, tali informazioni verranno poi inserite nei certificati generati dalla CA.

L’ AIA CDP locale per impostazione predefinita non viene incluso nei certificati e quindi non necessita di essere modificato.

L’AIA CDP ldap per impostazione predefinita non viene incluso nei certificati e quindi non necessita di essere modificato, volendo è anche possibile rimuovere tale AIA CDP dal momento che di fatto non verrà utilizzato.

L’AIA CDP http per impostazione predefinita non viene incluso nei certificati e quindi non necessita di essere modificato, volendo è anche possibile rimuovere tale AIA CDP dal momento che di fatto non verrà utilizzato.

L’AIA CDP file deve essere modificato in modo da non essere incluso nei certificati, volendo è anche possibile rimuovere tale AIA CDP dal momento che di fatto non verrà utilizzato.

Creare un AIA CDP per l’URL http con le opzioni di inclusione nella CRL per l’URL http://crl.ictpower.local/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt

Applicare le modifiche confermando il riavvio dei servizi delle CA.

Configurazione della CRL della Root CA Offline

Impostare la pubblicazione della CRL ad un periodo superiore a quello a cui si prevede di avviare periodicamente la Root CA Offline che normalmente sarà mantenuta spenta. Tramite le proprietà dei Certificati revocati si imposta un intervallo di pubblicazione di 4 settimane ipotizzando che settimanalmente la CA sarà avviata per installare eventuali aggiornamenti del sistema.

Verificare in C:\Windows\System32\CertSrv\CertEnroll che la CRL sia stata pubblicata, è possibile avviare la pubblicazione della CRL tramite la voce del menu contestuale All Tasks\Pubblish dei Certificati revocati, oppure mediante il comando:

Configurazione della validità dei certificati emessi dalla Root CA Offline

Per default la validità dei certificati emessi da una CA Standalone è di un anno, ma tale impostazione è modificabile tramite certutil che a sua volata modificherà le impostazioni nel registro.

Dal momento che la durata del certificato della CA è stato impostato a 20 anni con previsione di rinnovo ogni 10 anni la validità dei certificati emessi verrà impostata a 10 anni tramite il comando:

La chiave di registro in cui vene mantenuta tale impostazione è:

Al termine della configurazione riavviare il servizio della CA, ad esempio tramite il comando:

Copia della CRL e del certificato della Root CA Offline su server Web per la pubblicazione della CRL

Per consentire l’accesso al server web da parte della Root CA Offline l’approccio più corretto è quello di creare sul server web un account con privilegi di lettura e scrittura su una share che punti alla cartella che conterrà le CRL e i certificati delle CA come illustrato nel precedente articolo Deploy PKI in Windows Server 2016 – Parte 1. Nello scenario di esempio sul server web Web01 si ipotizza che siano state eseguite le seguenti configurazioni:

1. Creazione di un record DNS crl di tipo A per il server web consenta l’accesso a quest’ultimo tramite il nome crl.ictpower.local
2. Creazione di un account CAUpdate che verrà utilizzato dal server Root CA e Subordinate CA per accedere alla cartella condivisa in cui copiare CRL e certificato CA.
3. Creazione della share CertEnroll per concedere l’accesso in lettura e scrittura alla cartella S:\CertEnroll tramite l’account CAUpdate.

Sul server Root CA occorre quindi memorizzare sull’account che verrà utilizzato per aggiornare CRL e certificato CA sul server web le credenziali dell’account CAUpdate specificando come indirizzo del server crl.ictpower.local.

Aggiornare la CRL e copiare sul server web la CRL e il certificato CA della Root CA Offline tramite i comandi che possono anche essere eseguiti tramite un’operazione schedulata all’avvio della Root CA:

Nel prossimo articolo Deploy PKI in Windows Server 2016 – Parte 3 Installazione Subordinate CA vedremo come installare una Subordinate CA.