Archives de catégorie : Let’s Encrypt

Des certificats gratuits avec Let’s Encrypt dans IIS

Ça fait longtemps que j’avais ce billet dans les cartons, en fait depuis ma série de billets sur Let’s Encrypt avec les WebApp (plus d’un an déjà). Je l’utilise depuis longtemps dans mes machines virtuelles (tant qu’elles sont joignables sur Internet avec un nom public).

Let’s Encrypt, ce n’est pas tout jeune mais c’est toujours pas un citoyen de première classe dans IIS. La solution ne dispose pas d’un client natif, il faut en passer par un client tiers. Personnellement, je suis resté sur le premier que j’ai trouvé à l’époque : LetsEncrypt-Win-Simple, disponible sur Github. Comme MVP, j’ai beau avoir accès à des solutions gratuites comme Digicert mais je suis resté sur Let’s Encrypt, allez savoir, …

Avant de commencer, quelques rappels avec les limitations de Let’s Encrypt disponibles ici. Ceci posé, on va retenir la contrainte suivante :

The main limit is Certificates per Registered Domain (20 per week). A registered domain is, generally speaking, the part of the domain you purchased from your domain name registrar. For instance, in the name www.example.com, the registered domain is example.com. In new.blog.example.co.uk, the registered domain is example.co.uk. We use the Public Suffix List to calculate the registered domain.

Dans le contexte d’Azure, ça prend toute son importance car par défaut, mes machines virtuelles partagent toutes un même domaine DNS public : Azure.com. Si on tente d’utiliser Let’s Encrypt dans ces conditions, on arrive à la situation ci-dessous :

clip_image001

 

Ce point résolu, on sait maintenant il nous faut un nom DNS distinct. J’ai donc créé un enregistrement DNS de type CNAME dans mon domaine DNS public, pointant sur le FQDN public de ma machine virtuelle.

clip_image002

 

Dans ma machine virtuelle, j’ai choisi la simplicité en installant IIS. C’est la méthode la plus simple pour gérer un certificat. Il suffit juste d’ajouter un hostname à un site web existant. Je référence ici l’enregistrement DNS CNAME enregistré dans mon domaine public.

clip_image003

 

Le client Let’s Encrypt utilisé (LetsEncrypt-Win-Simple) détecte automatiquement le FQDN précédemment référencé dans IIS.

clip_image004

 

On notera que le certificat généré est bien exportable. C’est bien pratique.

clip_image005

 

La particularité des certificats délivrés par Let’s Encrypt, c’est leur durée de vie à 90 jours. Pour moi, ce n’est pas une contrainte vue la durée de vie de mes maquettes. Le client LetsEncrypt-Win-Simple propose tout de même de mettre en place une tâche planifiée qui se chargera du renouvellement à votre place, nice to have.

clip_image006

 

Les informations collectées (compte disposant du niveau de privilège administrateur local) sont nécessaires pour mettre en place une tâche planifiée pour gérer le renouvellement automatique de notre certificat tous les trois mois.

clip_image007

 

Dans IIS, on constate bien la présence d’un nouveau binding pour du SSL.

clip_image008

 

Petite subtilité, le certificat n’a pas été placé dans le magasin « LocalMachine\My » mais dans le magasin « LocalMachine\WebHosting ». C’est un peu différent mais c’est très utile quand on a une ferme de serveurs web devant partager le même certificat.

clip_image009

 

Au passage, on remarquera la durée de vie de trois mois. C’est tout pour let’s Encrypt. En même temps, ça respecte ma formule magique : Simple and secure by design but Business compliant.

 

BenoitS – Simple and Secure by design but Business compliant (with disruptive flag enabled)

Mise en oeuvre de Let’sEncrypt dans le PaaS Azure (3/3)

Maintenant, les détails qui comptent. On a noté que notre certificat a une durée de vie de trois mois. Mais comment alors sera-t-il renouvelé ? Réponse, grâce à un WebJob. Le problème, c’est qu’au terme de la mise en œuvre, ce WebJob est arrêté, donc aucune possibilité que le renouvellement automatique fonctionne.

clip_image001

 

Une fois démarré, ce sera beaucoup mieux.

clip_image002

 

Par ce que le diable se cache toujours dans les détails, essayons de lire les logs associés à la Web Extension Lets’ Encrypt. Il doit manquer quelque chose :

clip_image003

 

Ce qui manque, c’est un repository pour déverser les logs. Ce que nous dit le message, c’est que la configuration de la Web Application ne fournit pas les informations nécessaires pour la Web Extension. Ça tombe bien, j’avais justement prévu un compte de stockage pour cela :

Get-AzureRmStorageAccount -ResourceGroupName DemoLetsencrypt -StorageAccountName DemoLetsencryptlogs

$keys = Get-AzureRmStorageAccountKey -ResourceGroupName DemoLetsEncrypt -StorageAccountName DemoLetsEncryptLogs

clip_image004

 

Ce qui nous reste à faire, c’est de formater convenablement les informations dans cela dans une Application Settings nommé :

AzureWebJobsDashboard avec le contenu suivant :

DefaultEndpointsProtocol=https;AccountName=DemoLetsencryptlogs;AccountKey=<Contenu de ma clé primaire>;

clip_image005

 

Au passage on découvre que les paramètres que nous avons renseignés lors de la configuration de la Web Extension. Ne reste plus qu’à les sauvegarder et redémarrer le Web Job. Si la chaine de connexion est correctement formatée, alors, on devrait trouver la journalisation de l’extension dans le Storage Account que nous avons provisionné lors de la mise en place des prérequis.

clip_image006

 

Si on regarde dans la WebJob elle-même, on peut consulter ses logs directement à ce niveau.

clip_image007

 

Au passage, les logs vont vous apprendre un dernier truc. Pensez à activer l’option « Always-On » sinon en cas de crash du compute qui porte notre Web App, notre WebJob ne redémarre pas automatiquement. Donc pensez à activer cette option.

clip_image008

 

Voilà ce qui clos notre mise en œuvre de Let’s Encrypt dans le Paas Azure.

­

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Mise en oeuvre de Let’sEncrypt dans le PaaS Azure (1/3)

Le cloud, c’est un jeu de lego. Pour produire un service, on va combiner différents services. Ce qui est intéressant, c’est qu’il n’y a pas une seule combinaison mais bien plusieurs. Plus les Plateformes développent leurs services, plus on dispose de nouvelles combinaisons.

Dans ce jeu de Lego, on retrouve souvent des certificats. Lors du déploiement de solutions dans Azure, on va utiliser des solutions comme Azure Key Vault pour y stocker nos certificats. C’est un sujet que j’ai déjà évoqué dans plusieurs billets sur Azure Key Vault. Dans Azure, on peut aussi demander de générer nos propres certificats avec le App Service Certificate. Ce service permet de générer automatiquement (ainsi que renouveler) nos certificats. Au moment d’écrire ce billet, le service App Service Certificate ne propose que GoDaddy comme fournisseur. C’est une démarche intéressante mais pour nos développeurs, c’est une solution payante. En toute logique, nos développeurs vont se tourner vers des certificats auto-signés (beurk). Pourtant, en creusant un peu dans les tréfonds des Web Application, on peut trouver des solutions bien plus élégantes. Le projet Let’s Encrypt et celle-ci et est disponible sous forme de Web App Extension dans les App Services. C’est un peu moins intégré que le App Service Certificate mais ce n’est pas impossible à mettre en œuvre. C’est le sujet de ce billet : Comment utiliser la solution Let’s Encrypt avec Paas App Service. Ce billet sera organisé en plusieurs parties :

Dans mon introduction, j’ai parlé de Web Application. Donc logiquement on connait déjà les prérequis ou presque :

  • Un groupe de ressources histoire de regrouper nos ressources.
  • Un Service Plan qui va porter notre Web App (subtilité, il nous faudra un Service Plan nous autorisant d’utiliser le SSL et les Custom Domains)

 

Commençons par créer notre groupe de ressources avec simple ligne PowerShell :

New-AzureRmResourceGroup -Name « DemoLetsEncrypt » -Location « West Europe »

clip_image001

 

Ci-dessous la configuration retenue pour la Web Application.

clip_image002

 

Dans ma configuration, je n’ai pas retenu d’implémenter App Insight. A l’heure où j’écris ce billet, App Service est encore en Preview et pas disponible dans toutes les régions Azure. La subtilité, c’est le choix de l’App Service Plan. J’ai retenu le plan B1 qui est le premier à proposer le support des Custom Domains ainsi que celui des certificats.

clip_image003

 

Avec un peu de PowerShell, on peut retrouver les ressources provisionnées :

Get-AzureRmResourceGroup -Name DemoLetsEncrypt | Find-AzureRmResource

clip_image004

 

Avant de poursuivre, on va mettre en place les prérequis pour le Custom Domain. Dans ma zone DNS « Simplebydesign.fr », j’ai créé un enregistrement CNAME pour le nom « DemoLetsEncrypt » qui pointe sur le nom DNS Azure de mon site « demoletsencrypt.azurewebsites.net ». Pour instant le site ne répond qu’au seul hostname « demoletsencrypt.azureWebsite.Net ». On va juste lui en adjoindre un nouveau :

clip_image005

 

Si on n’a pas été patient dans la propagation de la zone DNS, cela va échouer. A noter que dans Azure, on peut contourner ce genre de problème et obtenir un service plus intégré en utilisant le service DNS d’Azure. Techniquement, un sous-domaine DNS de la zone « simplebydesign.fr » serait délégué au service Azure DNS qui se chargera de la gestion de cette zone. Avec cette approche, nous pourrons créer l’enregistrement DNS depuis Azure et nous assurer de sa propagation dans les secondes qui suivent mais revenons à notre billet. Lorsqu’on est patient, cela fonctionne.

clip_image006

 

Quelques secondes plus tard, notre site web répondra à son nom Azure mais aussi à son nouveau Custom Domain

clip_image007

 

Dernière étape dans nos prérequis, la mise en place d’un Storage Account. Nous allons en avoir besoin avec Lets’Encrypt pour permettre à la Web Extension d’y déverser ses logs :

New-AzureRmStorageAccount -ResourceGroupName « DemoLetsEncrypt » -AccountName « demoletsencryptlogs » -Location « West Europe » -SkuName « Standard_LRS » -Kind « Storage »

clip_image008

 

Remarque : Pour faire simple, j’ai utilisé un Storage Account standard, je n’ai pas cherché à optimiser avec du stockage chaud/froid. Ce n’est pas le but de ce billet.

 

Voilà pour les prérequis à la mise en œuvre de la Web Extension de Lets Encrypt. Prochaine étape, son installation et sa configuration.

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)