Archives par étiquette : App Service

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)