Archives de catégorie : PaaS

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 (2/3)

Après la mise en place des prérequis, passons à la configuration de Let’s Encrypt. Techniquement c’est une extension de la Web Application. C’est un plug-in que l’on va venir positionner.

clip_image001

 

Une fois l’extension ajoutée, on la retrouve dans la liste.

clip_image002

 

En cliquant sur la Web Extension, on peut avoir quelques informations et surtout l’accès au bouton « Browse ».

clip_image003

 

On obtient ainsi l’accès à la page de configuration de la Web Extension. C’est maintenant que cela commence à devenir intéressant.

clip_image004

 

Pour le premier paramètre, c’est simple, c’est notre tenant Azure Active Directory. La Web Extension va avoir besoin d’importer le certificat nouvellement généré dans la configuration de la Web Application. Le problème, c’est qu’une Web Extension n’a pas d’identité au sens propre. On va donc avoir besoin de lui en créer une. On y viendra. Pour l’instant, on a juste besoin du Tenant Azure Active Directory.

clip_image005

 

Pour le SubscriptionID, on va le retrouver simplement avec la commande Get-AzureRmContext :

clip_image006

 

C’est maintenant que cela se complique. Première chose dont on va avoir besoin, c’est le nom sous lequel la Web Application va se présenter à l’authentification devant le tenant Azure Active Directory. Avec un peu de PowerShell, on va extraire l’information :

$WebApp = Get-AzureRmWebApp -ResourceGroupName DemoLetsEncrypt

$WebApp

clip_image007

 

Ce qui va nous intéresser plus précisément c’est le hostname sous lequel le site web va être référencé comme application dans Azure Active Directory.

$WebApp.Hostnames

$Uri = $WebApp.HostNames | Select -Last 1

$Uri

clip_image008

 

$Uri = « https://$($uri)« 

$AppName = « DemoLetsEncrypt »

$Password = ‘{P@ssw0rd123}’

$NewApp = New-AzureRmADApplication -DisplayName $AppName -HomePage $uri -IdentifierUris $uri -Password $password

$NewApp

clip_image009

 

Il ne nous reste plus qu’à créer un nouveau Service Principal (un peu compte un compte de service du vieux temps du On-Premises) :

New-AzureRmADServicePrincipal -ApplicationId $Newapp.ApplicationId

clip_image010

 

Puis de lui affecter des permissions sur notre application nouvellement créée :

New-AzureRmRoleAssignment -RoleDefinitionName « Contributor » -ServicePrincipalName $NewApp.ApplicationId

clip_image011

 

Dernière chose dont nous allons avoir besoin, c’est l’ApplicationID associé à notre nouvelle application :

$NewApp.ApplicationId

clip_image012

 

Pour finaliser la configuration, nous avons juste besoin d’une permission pour l’application sur la Web Application

clip_image013

 

Si vous creusez un peu vous découvrirez les permissions minimales nécessaires pour cela. Prochaine étape, configurer les permissions sur le groupe de ressources ou plus précisément sur la Web Application.

clip_image014

 

Reste plus qu’à cliquer sur le bouton « Next ». Si les permissions sont les bonnes alors cela devrait fonctionner. L’extension est bien configurée mais pour l’instant le certificat n’est pas encore généré.

clip_image015

 

Pour générer notre certificat, il manque quelques informations. Cliquons donc sur le bouton « Next ». La première, ce sera de sélectionner le hostname pour lequel nous allons générer le certificat. Au moment de la rédaction de cet article, Let’s Encrypt ne propose pas encore la prise en charge des certificats Wildcard (bientôt).

clip_image016

 

Pour délivrer un certificat, nous avons besoin de fournir une adresse de messagerie et cliquer sur le bouton « Request and Install certificate ».

 

Remarque : Let’sEncrypt impose une limite, celle de ne de délivrer que cinq certificats par semaine pour un même domaine DNS. Il faudra utiliser le staging slots pour contourner cette limitation.

 

C’est l’heure du tour de magie. Si tout se déroule sans accros (un bon plan), alors nous devrions avoir le résultat ci-dessous :

clip_image017

 

Remarque : Faites attention à la date d’expiration du certificat. Oui, les certificats délivrés par l’autorité Let’s Encrypt ont une durée de vie de trois mois. Nous allons y revenir.

 

Nous pouvons revenir sur l’interface du portail Azure et constater la présence du certificat dans la Web Application

clip_image018

 

Ne nous reste plus qu’à mettre en place le binding

clip_image019

 

Le binding est maintenant en place

clip_image020

 

Et effectivement, le site web répond bien en HTTPS sur le Custom Domain configuré.

clip_image021

 

Au passage, le truc est propre puisque voilà le résultat au test SSL de Qualyst :

clip_image022

 

Maintenant, plus d’excuse pour les développeurs à continuer d’utiliser des certificats auto-signés. Il ne nous reste plus qu’à gérer les points de détails.

 

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)