Publié par
Il y a 1 année · 8 minutes · Back

Un pas de plus vers le HTTPS avec AWS Certificate Manager (ACM)

Ces derniers mois sont riches en annonces de sécurité. Après Let’s Encrypt, c’est au tour d’un autre grand du Web d’annoncer un service permettant d’obtenir des certificats HTTPS. En effet, le 21 janvier 2016, Amazon a lancé le service AWS Certificate Manager (ACM) sur sa plateforme cloud. Pour le moment, disponible uniquement dans la région US East (N. Virginia), il permet d’obtenir gratuitement un certificat à validation de domaine (DV) et s’occupe du renouvellement ainsi que de la configuration des équipements AWS.

TL;DR

  • Gratuit
  • Certificat de type Domain Validation (DV)
  • SAN et wilcard
  • Certificats valides 13 mois
  • Renouvellement automatique
  • Uniquement disponible pour des ressources AWS (Elastic Load Balancing et Cloudfront)

Le service

Ce service propose d’obtenir des certificats HTTPS à validation de domaine (DV) pour les ressources AWS telles que Elastic Load Balancing et Cloudfront. En plus de l’obtention, il gère la complexité inhérente au déploiement, au renouvellement et à la configuration du certificat.

ACM dispose d’un atout de taille car il permet de délivrer des certificats wildcards sans débourser un centime, ce qui est rare chez les autorités de certification. Bien entendu, les certificats SAN sont également de la partie, mais avec une limitation aggressive à 10 noms de domaines (voir les limites).

Le workflow induit par l’utilisation du service ACM est très simple puisque le développeur n’aura qu’à générer le certificat et s’assurer de la possession du nom de domaine.

AWS-1

Le développeur demande à ACM de délivrer un certificat qu’il pourra ensuite positionner sur un Elastic Load Balancer ou une distribution Cloudfront.

Obtention

Pour obtenir un certificat, rien de plus simple. Il suffit de se rendre sur le service Certificate Manager de la console AWS, de cliquer sur le bouton
Request a certificate » et de remplir le ou les noms de domaine à sécuriser.

Avant de délivrer le certificat, ACM vérifie que vous contrôlez bien le domaine pour lequel vous demandez le certificat. Contrairement à Let’s Encrypt, qui vise une validation automatique, le service d’AWS nécessite une intervention humaine pour approuver le nom de domaine. En effet, après avoir enregistré la demande, il faudra cliquer sur le lien présent dans l’email de validation pour confirmer l’action. Cet email est envoyé :

  • aux trois contacts enregistrés dans le WHOIS (domain registrant, technical contact, administrative contact)
  • aux cinq adresses d’administration les plus communes (administrator@DOMAIN, hostmaster@DOMAIN, postmaster@DOMAIN, webmaster@DOMAIN, admin@DOMAIN)

Les demandes de signatures de certificats (CSR) sont valides 72H. Passé ce délai, il faudra supprimer la requête et en recréer une nouvelle. Dans certains cas, il se peut que le certificat ne soit pas délivré car ACM vérifie que les URLs présentes dans le certificat en question ne sont pas identifiées comme étant des sites malveillants, de phishing ou encore porteurs de malwares.

Renouvellement

Une des complexités du workflow traditionnel est liée à l’expiration du certificat, dont le renouvellement est souvent oublié par la suite. Afin d’éviter ce problème, ACM tente le renouvellement automatique 60 jours avant le délai d’expiration qui est de 13 mois. Pour que le renouvellement s’effectue avec succès, les conditions suivantes doivent être réunies :

  • tous les noms de domaine présents dans le certificat doivent être résolus sur une IP contrôlée par Amazon ;
  • les ressources accessibles via les nom de domaine du certificat doivent accepter les connexions SSL/TLS d’internet.

Point d’attention dans le cas d’un certificat de type wildcard, le renouvellement automatique ne pourra s’opérer car il est impossible de vérifier toutes les conditions nécessaires.  Si la procédure automatique échoue, ACM se rabat sur une méthode alternative tel que l’envoi de mail au gérant du domaine (voir la liste dans le chapitre obtention). Pour les certificats non utilisés, c’est à dire non liés à un service tel qu’Elastic Load Balancing ou CloudFront, ACM n’essaie pas de les renouveler.

Autorité de certification

En juin 2015 Amazon lançait son autorité de certification (CA). En attendant de rentrer dans le store de tous les navigateurs du marché, Amazon a reçu une signature croisée de la part de Starfield Technologies, ce qui permet aux navigateurs les plus anciens d’accorder leur confiance aux certificats émis par AWS Certificate Manager.

AWS2

Les navigateurs (ici Firefox) affiche bien le certificat comme valide.

AWS3

En regardant attentivement la hiérarchie du certificat, nous apprenons qu’il a directement été signé par l’autorité intermédiaire « Amazon » qui par logique est signée par son autorité racine « Amazon Root CA 1 ». Cette dernière est elle même signée par une autorité historique Starfield.

Périmètres et limites

Le service est pensé exclusivement pour AWS puisque les certificats émis par ACM sont uniquement utilisables sur des Elastic Load Balancers et des Cloudfronts. Oubliez donc l’installation sur votre reverse proxy préféré. Certains préféreront donc utiliser Let’s Encrypt : ce dernier est plus ouvert et délivre notamment la clé privée, ce qui vous permet de gérer comme bon vous semble le certificat. En effet, pour les certificats délivrés par ACM, la clé privée est conservée par AWS et il n’est pas possible d’y accéder. 
Par défaut, le service est limité à 20 délivrances de certificats par an et à 20 certificats actifs simultanés (pending ou issued). Les noms de domaines dans un certificat SAN sont au nombre de 10. Comme pour la plupart des services, ces limites peuvent être augmentées en contactant le support.

Cas concret : sécurisation d’un Jenkins

Afin de montrer la facilité de mise en place du HTTPS, nous allons sécuriser un serveur Jenkins. Bien que disposant de services de continuous deployment / delivery (CodeDeploy et CodePipeline), il n’est pas rare d’installer un Jenkins sur une infrastructure Amazon. Il est néanmoins impératif de le sécuriser via du HTTPS pour éviter toute diffusion de mots de passes en clair sur le réseau. Nous allons voir comment servir en quelques clics le contenu du Jenkins en HTTPS.

L’infrastructure est composée d’une instance EC2 hébergeant le Jenkins. Les utilisateurs accèdent à l’interface du logiciel à travers un load balancer qui permet d’isoler la machine dans un subnet privé afin de limiter les connexions SSH. Il servira par la même occasion à héberger le certificat.

AWS4

Étape 1 : obtention du certificat

Pour notre cas, nous allons effectuer les démarches à travers la console, mais sachez qu’il est possible de le faire via la CLI ou le SDK.

a – Ajout des noms de domaines

L’interface est simple et claire, puisqu’il suffit de rentrer le nom de domaine dans le champ prévu à cet effet. Pour un certificat SAN, cliquez sur le bouton « Add another name to this certificate » et saisissez un nouveau nom de domaine. Pour un wilcard, indiquez une étoile dans la partie la plus à gauche du nom de domaine.

AWS5

Après avoir vérifié et confirmé votre requête en cliquant sur « Review and request » un mail vous sera envoyé.

b – Réception du mail

AWS6

Le mail est envoyé aux adresses administrative du sous domaine. A titre d’information, il a été reçu sur admin@acm1.domain.fr. Cliquez sur le lien d’approbation pour être aiguillé sur le site d’Amazon.

c – Validation de la demande

Le site récapitule une dernière fois les informations avant que vous approuviez.

AWS7

Quand vous revenez dans la console, celle-ci indique que le certificat est délivré, mais qu’il n’est pas encore utilisé. En effet, nous ne l’avons pas encore associé à un équipement AWS (Load Balancer ou Cloudfront)

AWS8

Étape 2 : configuration du Load Balancer

a – Configurer le security group

Le security group du load balancer doit accepter les connexions sur le port 443.

AWS9

b – Association du certificat au load balancer

Une fois que vous vous êtes assuré d’autoriser le trafic sur le port dédié au HTTPS, il faut ajouter un listener sécurisé sur le load balancer et lui affecter le certificat. Le premier choix« Choose an existing certificate from AWS Certificate Manager » correspond à notre cas.

AWS10

Après avoir validé en cliquant sur Save, le load balancer écoute sur le port 443 et redirige le trafic sur le port 8080 de la machine (port d’écoute par défaut du Jenkins)

AWS11

Cette étape terminée, le Jenkins est désormais sécurisé.

Pour conclure

Le service est bien intégré avec les outils AWS et propose des fonctionnalités séduisantes comme les wilcards.

Un des points faibles de la solution est que les certificats émis ne pourront pas être utilisés ni au dehors d’une infrastructure AWS ni sur vos équipements, même si ceux-ci sont sur AWS. À titre d’exemple, nous n’avons pas pu utiliser Nginx en reverse proxy sur l’instance EC2 pour gérer le HTTPS mais il a été nécessaire de placer un load balancer en amont. Cela est certes plus restrictif que d’autres projets du genre tels que Let’s Encrypt mais vous bénéficiez en contrepartie de la gestion et du renouvellement automatique sans configuration supplémentaire.

Parmi les quelques points d’amélioration, nous aimerions voir l’intégration d’ACM avec Route 53, le service de DNS d’AWS, et pouvoir ainsi bénéficier de l’obtention automatique sans intervention humaine si le nom de domaine est géré par Route 53. L’email de confirmation serait donc superflu car Amazon dispose de toutes les informations nécessaires pour prouver que vous êtes bien le détenteur du nom de domaine.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *