• Guide, Sicurezza, Sistemi Operativi
• 22 Marzo 2017

Prima di implementare una Certification Authority (CA) occorre pianificare attentamente la infrastruttura della Public Key Infrastructure (PKI) più adatta alla propria organizzazione. La prima valutazione che occorre fare è quella del numero di CA necessarie valutando le il grado di sicurezza necessario per la PKI, le necessità di alta disponibilità e il carico amministrativo necessario per la gestione.

Una CA in ambiente Windows può essere di tipo Standalone, che non richiedere l’integrazione con Active Directory, ma più complessa da amministrare in quanto non consente l’utilizzo dei modelli di certificato. In alternativa è possibile avere CA di tipo Enterprise che devono essere integrate in Active Directory, ma la cui gestione è più semplice grazie ai modelli di certificato.

Inoltre le CA si suddividono ancora in Root CA o Subordinate CA. Le Root CA sono in cima alla catena dei certificati e rilasciano i certificati alle Subordinate CA. Dal momento che il primo obbiettivo durante la pianificazione di una PKI è quello di preservarne la sicurezza evitandone la compromissione, una struttura PKI che ben si concilia con tali esigenze di sicurezza con carico amministrativo di gestione non elevato è quella Two-Tier (a due livelli) riportata nel 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 di conseguenza 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.

Come riportato in Optimizing the Revocation Experience conviene però gestire la Certificate Revocation List (CRL) solo tramite HTTP anziché tramite LDAP configurando un server web che si occuperà della pubblicazione evitando di assegnare tale ruolo alla Subordinate CA per ragioni di sicurezza soprattutto nel caso in cui la CRL debba essere pubblicata in Internet:

“Although AD DS enables publication of CRLs to all domain controllers in the forest, we recommend implementing HTTP instead of LDAP for revocation information publication. Only HTTP enables the use of the ETag and Cache-Control: Max-age headers providing better support for proxies and more timely revocation information. In addition, HTTP provides better heterogeneous support as HTTP is supported by most Linux, UNIX, and network device clients.”

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 del server web per la distribuzione della CRL

Prima di procedere all’installazione delle CA occorre provvedere a installare e configurare il server web che si occuperà di pubblicare la CRL e i certificati delle CA necessari nei casi in cui i certificati distribuiti non contengano la catena dei certificati.

Il server web che pubblicherà la CRL può essere un server in Workgroup per il quale è stato configurato un record DNS di tipo A relativo all’Hostname e un record DNS di tipo CANAME per evitare l’URL della CRL che sarà contenuto all’interno di ogni certificato faccia riferimento all’hostname del server sia per consentire la configurazione dell’alta disponibilità della CRL che per ragioni di sicurezza in modo da evitare di diffondere informazioni sull’infrastruttura interna.

Nello scenario di esempio saranno creati i seguenti record DNS:

Aggiungere sul server il ruolo Web Server (IIS) con le impostazioni di default.

Creare una cartella dedicata a contenere le CRL e i certificati delle CA che saranno poi pubblicati dal server web, per sicurezza creare tale cartella in disco dedicato diverso dal disco di sistema. Nello scenario di esempio verrà creata la cartella CertEnroll sul volume S:. Creare sul server web un account locale che non sia membro di alcun gruppo locale a cui condividere tale cartella in scrittura, tale account verrà poi utilizzato dalle CA per caricare le CRL e i certificati delle CA in modo che il server web li possa pubblicare. Nello scenario di esempio verrà creato un account CAUser.

Configurare in IIS una Virtual Directory nel Default Web Site che punta alla cartella S:\CertEnroll con accesso anonimo, nello scenario di esempio la Virtual Directory sarà denominata CertEnroll. Per configurare l’accesso anonimo alla Virtual Directory aggiungere gli utenti ANONYMOUS LOGON e Everyone nel tab Security che per default avranno i privilegi di accesso in lettura.

Configurare delle Regole di Filtro per la Virtual Directory per consentire il double escaping per evitare che il carattere “+” che è contenuto nel URI delle delta CRL venga bloccato, a riguardo si veda AD CS: Web server should allow URI containing the “+” character to enable publishing of delta CRLs:

“The certificate revocation list (CRL) distribution point extension on this certification authority (CA) includes a URI for a remote Web server. If the Web server is running IIS 7.0 with the default configuration, then delta CRL URIs that contain the plus sign (+) will be blocked.

Request filtering in Internet Information Services (IIS) scans the content of incoming requests, which can be blocked or allowed to meet the requirements of an organization’s security policy. In IIS 7.0, the default request filtering configuration blocks requests that include the plus sign (+) in the URI. The plus sign (+) is present in the URI of delta CRLs and must be allowed by the Web server.”

Riavviare IIS tramite Internet Service Manager o tramite il comando:

Per pubblicare la CRL e il Certificato della CA non è possibile utilizzare HTTPS a riguardo si vedano i post How to Publish the CRL on a Separate Web Server (di Carol Bailey dipente Microsoft) e Designing CRL Distribution Points and Authority Information Access locations (Vadims Podāns Microsoft MVP Cloud and Datacenter Management).

“Certificate revocation lists cannot be accessed over HTTPS so to add HTTP access to one of your Internet-based site system servers would greatly increase the risk of an attacker connecting to this server.”

“NEVER use HTTPS protocol for CRT/CRL file retrieval, because CryptoAPI will permanently fail to fetch this URL.”

Nel prossimo articolo Deploy PKI in Windows Server 2016 – Parte 2 – Installazione e configurazione di una Root CA Offline vedremo come installare e configurare la Root CA