Roberto Massa
Ermanno GolettoUtilizzo di Azure DNS per la validazione automatica di Let’s Encrypt
In ICTPower ci siamo occupati a più riprese della Certification Authority Let’s Encrypt, ed abbiamo visto come è possibile utilizzarla in diversi scenari.
In Ambienti OpenSource, con la validazione basata su Apache, In un altro articolo abbiamo proposto lo scenario che si può utilizzare con IIS come base per la validazione.
In questo articolo vediamo quali sono le modalità di validazione per il rilascio ed il rinnovo dei certificati sulla base di ambienti DNS, in questo modo è possibile utilizzare un servizio DNS, anche in hosting, per la gestione del ciclo di vita dei certificati gestiti da Let’s Encrypt. Le procedure proposte si basano sul client Win-Acme (WACS) e quindi in ambiente Windows.
Let’s Encrypt utilizza, analogamente a quanto visto per la validazione tramite servizi WEB, un’automazione che provvede a gestire determinati record all’interno del DNS.
Figura 1 Validazione tramite servizio DNS generico
Nella figura 1 è riportato un esempio di come Win-Acme, tramite le opzioni avanzate, permette di utilizzare il DNS per la validazione.
Nell’esempio sopra Win-Acme ricerca uno script a cui passare “hostname, record name e token“, e se opportunamente eseguito interagisce con il servizio DNS in modo da “scrivere” all’interno queste informazioni che lette dalla CA prima del rilascio del certificato, attestano che il richiedente è il reale proprietario del dominio.
E’ quindi chiaro che la disponibilità da parte del fornitore del servizio DNS ad una gestione automatizzata è fondamentale.
Nel panorama Italiano, Aruba non permette questo tipo di automazione (almeno da richiesta fatta al supporto tecnico nel mese di febbraio 2018), ma come vedremo in seguito questo non è necessariamente un limite.
Esistono diversi gestori di servizi DNS che rilasciano nelle gallery relative alle automazioni, script nati per far interagire i client CertBot con il loro DNS in modo da automatizzare le richieste verso Let’s Encrypt.
La maggioranza delle automazioni finora sono relative ad ambienti Linux.
Nel nostro caso utilizziamo invece Azure-DNS per la validazione da parte della CA, non ci occuperemo di come effettuare la delega al servizio Azure della risoluzione per il dominio, questa attività è trattata in dettaglio in questo articolo e si presuppone sia già stata effettuata.
Prima di procedere con la richiesta del certificato vero e proprio è necessario configurare il servizio Azure-DNS in modo che permetta l’accesso ad un “utente” con le credenziali minime per poter creare e cancellare record all’interno del Database DNS.
Questa tipologia di accesso è possibile con la creazione di un Service Principal Account
che possiamo definire come una identità di livello applicativo.
Assign permissions to the app identity that are different than your own permissions. Typically, these permissions are restricted to exactly what the app needs to do.
Per poter creare una identità di questo tipo possiamo utilizzare Azure Powershell e con l’utilizzo di alcune command let procedere alla sua creazione, l’accesso all’ambiente PS avviene direttamente dal portale Azure
Figura 2 accesso alla Cloud Shell
La preparazione dell’ambiente non è immediata e può richiedere anche più di un minuto, terminato l’accesso, disponiamo di un ambiente comandi direttamente sulla sottoscrizione.
Per procedere alla creazione del Principal account che verrà utilizzato per l’automazione è sufficiente utilizzare questi comandi
$Password = ConvertTo-SecureString -String “InserireQuiLaPassword” -AsPlainText -Force
New-AzureRmADServicePrincipal -DisplayName LetsEncrypt -Password $Password
Figura 3 creazione del service principal
In questo modo è stato creato l’account “Letsencrypt” con la relativa password ed è necessario assegnare i permessi di accesso alla zona DNS relativa al dominio per il quale stiamo richiedendo il certificato
Figura 4 attribuzione dei permessi
Accedendo alla gestione della zona robimassa.cloud tramite Access Control (IAM) si attribuisce il ruolo di DNS Zone Contributor al Service Principal Letsencrypt creato in precedenza.
La preparazione dell’ambiente relativo al servizio DNS è completata e prima di procedere alla generazione del certificato è utile recuperare alcune informazioni che saranno poi richieste dal client Win-Acme.
- Tenant ID (directory ID) ossia l’identificativo della Directory a cui ci stiamo riferendo
- Client ID l’identificativo del Service Principal creato prima
- Secret la password definita per il Principal
- DNS Subscription ID l’identificativo del Servizio DNS in questo caso (robimassa.cloud)
- DNS Resource Group Name il resource group definito per la risorsa DNS pubblica
In questa guida si fa riferimento al dominio robimassa.cloud, forse è superfluo specificarlo, ma il dominio DEVE essere un dominio pubblico regolarmente raggiungibile e quindi acquistato tramite i normali canali commerciali, nello specifico questo dominio è stato acquistato da Aruba.
Generazione del certificato
Il client Win-Acme dovrà essere eseguito con l’opzione –centralsslstore in modo da permettere l’archiviazione dei certificati (SAN o singolo Host) all’interno di una cartella, questo è necessario nel nostro caso in quanto i certificati rilasciati non vengono associati in automatico ad un Host Web, ma sono archiviati per un utilizzo successivo.
letsencrypt.exe –centralsslstore C:\letsencrypt-san\
vengono richieste a questo punto le impostazioni di base che sono quelle viste in figura 1 ad eccezione della validazione, per la quale dovremo selezionare l’opzione 1 ossia [dns-01] Azure DNS
Figura 5 richiesta validazione su Azure DNS
Proseguendo dovremo fornire le indicazioni relative all’accesso automatico del client come riportato sopra, ed al termine completata l’esecuzione, verranno salvati i certificati nella directory.
Figura 6 richiesta certificato
A questo punto il certificato è correttamente salvato in formato pfx e disponibile ad essere utilizzato, può ancora essere definito un utente con cui verrà eseguita periodicamente la task di rinnovo.
Se fosse necessario verificare i certificati emessi è possibile, sempre client Win-Acme la procedure di verifica.
Figura 7 verifica dei certificati emessi
Riferimenti