• Guide, Open Source, Sicurezza
• 3 Maggio 2017

Introduzione

Il 18 novembre 2014 è stata annunciata ufficialmente al pubblico Let’s Encrypt, una certification authority che automatizza gratuitamente la creazione, la validazione, il rilascio ed il rinnovo di certificati X.509 per il protocollo TLS. Let’s Encryp esce dalla beta il 12 aprile 2016 e a oggi, stando alle statistiche pubblicate al link Let’s Encrypt Growth, sono stati generati 33,7 milioni di certificati. Lo scopo di Let’s Encrypty è quello di abilitare la gestione del ciclo di vita dei certificati SSL/TSL per l’utilizzo da parte di siti web in modo rendere sicure le connessioni HTTPS.

Let’s Encrypt si basa sul protocollo ACME ( Automated Certificate Management Environment) del tipo challenge-response in cui il server (Let’s Encrypt) presenta al client (il web server) un insieme di challenge che il proprietario del dominio deve risolvere per provare di essere il responsabile del dominio. Il protocollo ACME prevede anche altri tipi di challenge, in particolare Let’s Encrypt prevede il supporto a challenge di tipo DNS che richiedono di inserire un record di tipo TXT contenente un token presso il server DNS del dominio per cui si richiede il certificato. Le richieste effettuate tramite il protocollo ACME avvengono attraverso JSON firmati (detti anche JSON web signature o JWS) scambiati su connessioni HTTPS. Per ulteriori informazioni sul funzionamento di Let’s Encrypt si veda How It Works.

Per quanto riguarda la compatibilità con Let’s Encrypt è necessario il certificato IdenTrust’s DST Root X3 sia incluso nello store dei certificati attendibili e che siano supportati i certificati SHA2, in ogni caso è possibile eseguire un test di validità del proprio sito web sul sito SSL Labs’ Server Test. Come riportato in Certificate Compatibility i certificati Let’s Encrypt sono supportati in: Mozilla Firefox v2.0 e successivi, Google Chrome, Internet Explorer su Windows XP SP3 e superiore, Microsoft Edge, Android OS v2.3.6 e successivi, Safari per macOS v4.0 e successivi, Safari per iOS v3.1 e successivi, Debian Linux v6 e successivi, Ubuntu Linux v12.04 e successivi, NSS Library v3.11.9 e successivi, Amazon FireOS (Silk Browser), Cyanogen con versione superiore a 10, Jolla Sailfish OS con versione superiore a 1.1.2.16, Kindle con versione superiore a 3.4.1, Java 7 con versione 7u111 e successivi, Java 8 con versione 8u101 e successivi.

Come riportato nelle FAQ i certificati Let’s Encrypt sono di tipo Domain Validation (DV) e possono quindi essere usati su ogni server che utilizzi un nome a dominio come web servers, mail servers, FTP servers, etc, viceversa per necessità quali Email encryption e code signing che richiedono certificati di tipo differente dai Domain Validation i certificati rilasciati da Let’s Encrypt non possono essere utilizzati. Let’s Encrypt non ha in progetto il supporto al rilascio di certificati di tipo Organization Validation (OV) o Extended Validation (EV). Tramite Let’s Encrypt è comunque possibile ottenere certificati per nomi a dominio multipli (certificati SAN o UCC) tramite il meccanismo Subject Alternative Name (SAN), mentre al momenti non vi sono piani di supporto per certificati wildcard anche se non è detto che tali certificati non possano essere emessi in futuro.

Per quanto riguarda la sicurezza è il ciclo di vita dei certificati rilasciati da Let’s Encrypt va precisato che hanno durata di 90 giorni e che possono essere rinnovati dopo 60 giorni (si veda Why ninety-day lifetimes for certificates? per maggiori dettagli), mentre per quanto riguarda la chiave privata questa è sempre generata e mantenuta sui propri server e non dalla Let’s Encrypt certificate authority, in altre parole la chiave priva non sarà mai memorizzata sui server Let’s Encrypt. La lista degli indirizzi IP tramite cui Let’s Encrypt valida il server web non è resa disponibile in quanto tali IP possono cambiare nel tempo oltre al fatto che in futuro potrebbe essere implementata una validazione multipla da parte di più IP.

La gestione della richiesta di un certificato Let’s Encrypt deve essere fatto tramite un client ACME, l’utilizzo di chiavi private esistenti o Certificate Signing Request (CSR) è consentito, ma no n supportato da tutti gli ACME Client.

Implementazione di Let’Encrypt in ambiente Windows

Il client suggerito dal team di Let’s Encrypt per iniziare a lavorare con i loro certificati automatici è Certbot che però al momento è disponibile solo per sistemi operativi UNIX-like, ma come riportato nella pagina ACME Client Implementations sono stati sviluppati vari client e librerie per la gestione dei certificati tramite il protocollo ACME.

In ambiente Windows sono al momento disponibili i seguenti:

• ACMESharp una libreria scritta in .NET e un client PowerShell (al momento l’ultima release è la 0.8.2 del 4 gennaio 2017)
• letsencrypt-win-simple un client a riga di comando scritto in .NET e basato sulla libreria ACMESharp (al momento l’ultima release è la 1.9.3 del 19 marzo 2017)
• Certify GUI un client GUI WinForms scritto in .NET che implementa un wrapper per gli script PowerShell della libreria ACMESharp (al momento l’ultima release è la 0.9.96 del 20 febbraio 2017)
• oocx/acme.net una libreria scritta in .NET e un client a riga di comando (al momento l’ultima release è la 0.0.65 del 4 dicembre 2015)
• kelunik/acme-client un client scritto in PHP (al momento l’ultima release è la 0.2.13 del 5 gennaio 2017)

Nel seguente articolo verrà utilizzato il client letsencrypt-win-simple per richiedere e gestire il rinnovo di un certificato Let’s Encrypt per un sito web ospitato in IIS in ambiente Windows Server 2016, prima di poter procedere alla configurazione è necessario che siano rispettai i seguenti prerequisiti:

• I server web deve poter accedere in HTTPS al dominio letsencrypt.org
• Il server web deve poter essere raggiunto tramite HTTP (TCP 80) e tramite HTTPS (TCP 443)
• Il nome di dominio DNS a cui il server web deve rispondere deve essere registrato sui DNS pubblici

Installazione e configurazione di IIS

Installare IIS con le impostazioni di default.

Per ragioni di sicurezza è consigliabile spostare il Default Web Site su un volume dedicato copiando la directory di default %SystemDrive%\inetpub\wwwroot tramite il seguente comando (nell’esempio la directory del default web site sarà sposta in W:\inetpub\wwwroot):

XCOPY %SystemDrive%\inetpub\wwwroot W:\inetpub\wwwroot /E /O /I

Modificare il path del Default Web Site tramite IIS manager impostando la proprietà Physical Path del Web Site:

Definire il binding del Default Web Site sul nome di dominio per cui occorrerà generare il certificato sulla porta 80.

Riavviare IIS tramite il comando:

IISRESET /RESTART

Testare l’accesso al Default Web Site con una pagina di prova ed eliminare i file di default.

Richiesta di un certificato Let’s Encrypt tramite client ACME

Dopo aver scaricato l’ultima versione di letsencrypt-win-simple (al momento la 1.9.3), disponibile al seguente link https://github.com/Lone-Coder/letsencrypt-win-simple eseguire letsencrypt.exe con privilegi di amministratore locale il quale tramite una procedura guidata eseguirà la richiesta del certificato per il dominio desiderato alla Certification Autority di Let’s Encrypt.

Passo 1: Digitare l’indirizzo mail a cui verranno inviati eventuali errori durante il rinnovo del certificato.

Si noti che verrà richiesto un certificato con periodo di rinnovo di 60 giorni e che per default il path in cui verranno memorizzati i file di configurazione e il certificato sarà %AppData%\letsencrypt-win-simple\httpsacme-v01.api.letsencrypt.org.

Passo 2: Accettare il LET’S ENCRYPT SUBSCRIBER AGREEMENT (Y), i documenti relativi alle policy e agli aspetti legali di Let’s Encrypt sono disponibili al seguente Policy and Legal Repository.

Passo 3: Selezionare l’opzione di generare i certificati per tutti gli hosts (A)

In questa fase della configurazione vengono eseguite le seguenti 4 operazioni:

Passo3 – Operazione 1: Validazione del dominio

Nella directory che contiene il Web Site (W:\inetpub\wwwroot nell’esempio) viene scritta la challenge answer restituita dai servizi di Let’s Encrypt, che di fatto è un file che risiede nella subdirectory .well-know/acme-challenge inoltre viene creato il file web.config nella subdirectory .well-know/acme-challenge per aggiungere le estensionless mime type. Perché l’operazione riesca l’utente con cui si esegue letsencrypt-win-simple dovrà avere i privilegi di accedere in lettura e scrittura alla directory che contiene il Web Site. Affinchè la challenge answer possa poi essere controllata dai servizi di Let’s Encrypt occorre che sia accessibile via HTTP, quindi è necessario che sia possibile accedere pubblicamente all’URL http://nomesito/.well-know/acme-challenge in modo da poter verificare la corrispondenza della challenge answer con quanto registrato nei DNS pubblici.

La challenge answer viene sottoposta alla validazione da parte dei servizi di Let’s Encrypt.

Terminata la validazione vengono eliminati il file della challenge answer, il file web.config e le subdirectory .well-know/acme-challenge e .well-know.

Per maggiori informazioni sulle operazioni di veda How It Works.

Passo3 – Operazione 2: Richiesta del certificato

Per impostazione predefinita i file relativi al certificato richiesto e quelli relativi alla CA di Let’s Encrypt vengono salvati in %AppData% \letsencrypt-win-simple\httpsacme-v01.api.letsencrypt.org

Per maggiori informazioni sulle operazioni di veda How It Works.

Passo3 – Operazione 3: Installazione del certificato nello store dei certificati per renderlo disponibile ad IIS

Passo3 – Operazione 4: Configurazione del binding del Web Site IIS per l’utilizzo di HTTPS tramite il certificato rilasciato da Let’s Encrypt

Passo 4: Configurazione di un’operazione pianificata per il rinnovo del certificato.

Per gestire il rinnovo del certificato viene creata un’operazione pianificata e viene richiesto di specificare l’account con cui eseguire l’operazione schedulata, tale account dovrà avere i privilegi necessari per accedere in lettura e scrittura sulla directory del sito web in modo da poter creare la challenge answer di rinnovo in modo analogo a quanto visto nel Passo3.

I certificati di Le’s Encrypt hanno una durata massima di 90 giorni, ma possono essere rinnovati dopo 60 giorni. L’operazione pianificata viene schedulata per l’esecuzione giornaliera in modo da poter essere ripetuta per un mese in caso di problemi di rinnovo.

Il comando eseguito dall’operazione pianificata è il seguente (nel seguente esempio il tool letsencrypt-win-simple è memorizzato in W:\Util\letsencrypt-win-simple.V1.9.3):

W:\Util\letsencrypt-win-simple.V1.9.3\letsencrypt.exe --renew --baseuri "https://acme-v01.api.letsencrypt.org/"

Conclusione

Let’s Encrypt fornisce oltre alla possibilità di ottenere in modo gratuito certificati SSL/TSL per rendere sicure le connessioni HTTPS anche un approccio semplice per gestire il rinnovo automatico di tali certificati evitando problematiche connesse a certificati scaduti. Sebbene Let’s Encrypt sia particolarmente attenta alla sicurezza in quanto i sui servizi sono resi disponibili dall’Internet Security Research Group (ISRG) va ovviamente tenuto in considerazione che la sicurezza sarà un aspetto su cui occorrerà ancora lavorare.

Infatti una CA che ha le carte in regola per un’adozione su larga scala grazie soprattutto alla gratuità dei propri servizi attrae ovviamente l’attenzione di chi cerca canali con cui diffondere malware. A fine marzo infatti è stato reso noto come in certe situazione Let’s Encrypt sia stata sfruttata per veicolare phishing da parte di siti che tentavano di spacciarsi come PayPal sfruttando il fatto che la verifica del dominio si basa su un controllo della corrispondenza del nome a dominio registrato e non sul contenuto del sito, per un approfondimento si veda il seguente post Let’s Encrypt issues certs to ‘PayPal’ phishing sites: how to protect yourself.

Ovviamente se si desidera proteggere il proprio sito web in IIS tramite un reverse proxy o si vuole utilizzare Let’s Encrypt con un Azure Web Site sarà necessario configurare Let’s Encrypt sul reverse proxy a riguardo si vedano i seguenti:

• Experiment: how to assign a domain name and activate HTTPS on a Free or Shared Azure web site un articolo di Fabrizio Accatino (della community Torino Technologies Group gemellata con ICTPower.it) in cui viene analizzato come implementare Let’s Encrpt su un Azure Free Web Site tramite un reverse proxy basato su NGINX in esecuzione su una Azure A0-Basic Virtual machine.
• Reverse Proxy With IIS and Lets Encrypt un articolo di Murray Grant che analizza come utilizzare IIS per realizzare un reverse proxy HTTPS basato sui certificati Let’s Encrypt.
• Configurazione di un Reverse Proxy con IIS un articolo di Vito Lucatorto (della community ICTPower.it) che analizza come configurare IIS per realizzare un reverse proxy.
• Setup IIS with URL Rewrite as a reverse proxy for real world apps un articolo di Paul Cociuba (Microsoft .Net Escalation Engineer) che analizza l’utilizzo di URL Rewrite in IIS per realizzare un reverse proxy.
• How-to Guide LetsEncrypt a 2012 R2 Web Application Proxy una guida che analizza l’implementazione di Let’s Encrypt nel ruolo Web Application Proxy di Windows Server 2012 R2.