Il y a 2 ans, les mainteneurs du système de scripts acme.sh (Automated Certificate Management Environment) ont intégré haproxy. Les développeurs de haproxy ont modifié le reverse proxy pour pouvoir gérer les certificats. Pourquoi c’est important ?

Dans le fracas des IA, web 3 et autres buzzwords à la mode, il est des changements qui passent inaperçus, alors qu’ils facilitent la vie et améliorent la qualité des services en ligne. On peut penser par exemple à io_uring et aujourd’hui on voudrais vous parler de l’intégration entre haproxy et le protocole ACME.

HAproxy, ACME kesako ?

HAproxy dont beaucoup ne savent pas dans quel sens le prononcer “Ha ! Proxy !” (on dit souvent [aʃ a pʁɔksi] ou H. A. proxy pour High Availability Proxy) est le couteau suisse du reverse proxy. Un reverse proxy permet de faire un intermédiaire réseau entre l’extérieur d’une plateforme numérique (Internet) et les services qui tournent à l’intérieur. Il ouvre un ou plusieurs ports réseau sur internet et redistribue les requêtes de différents protocoles vers les services dits “backends” ou “arrières”. Il sait aussi bien traiter les requêtes web HTTP, HTTP2 que des protocoles binaires TCP.

deux services sont exposés par haproxy. Un service web sur les ports 80/443 qui correspond à un serveur d’application interne qui tourne sur le port 8080 et un service mail de type SMTP sur les ports 25/465 qui correspond à un serveur mail interne sur le port 587.

Ce qui en terme de configuration HAproxy donnerait :

frontend ft_web
    bind :::80 v4v6
    bind :::443 v4v6 ssl crt /etc/haproxy/certs/ 
    mode http
    use_backend bk_web
    
frontend ft_mail
    bind :::25 v4v6
    bind :::465 ssl crt /etc/haproxy/certs/
    mode tcp
    use_backend bk_mail

backend bk_web
    mode http
    server web serveur01:8080
    
backend bk_mail
    mode tcp
    server mail serveur02:587

Les intérêts de haproxy sont multiples :

1. un composant unique permet le contrôle de tous les flux (pour désactiver des flux en cas d’urgence, avoir des statistiques…)
2. il permet d’avoir plusieurs serveurs backend et de faire de la répartition de charge (on pourrait ajouter des serveurs web et des serveurs mail par exemple)
3. cela permet (d’où son nom) de faire de la haute disponibilité : si un serveur back ne fonctionne plus, il distribuera les flux sur ceux qui sont disponibles
4. les certificats de sécurité peuvent être traités à un seul endroit (on le voit avec les directives ssl crt)
5. si des serveurs manquent de fonctionalités (par ex Server Name Indication pour être “multi-tenant” et avoir plusieurs domaines sur un seul type de service) il peut assurer le lien avec les serveurs back.

Les certificats de sécurité permettent de s’assurer que le serveur distant est bien le serveur sur lequel on pense aller (évite les usurpations de services), et de chiffrer les informations qui sont échangées avec le serveur. Mais ils demandent d’être renouvelés plus ou moins régulièrement. Letsencrypt est un service en ligne qui fournit des certificats (avec participation libre). Ces certificats doivent être renouvelés tous les 3 mois. Ce renouvellement a été automatisé avec le protocole ACME (Automated Certificate Management Environment).

Le système de scripts acme.sh (en shell) ou certbot (en python) assurent ces échanges ACME avec le service letsencrypt. Mais pour créer et renouveller un certificat pour mon-super-domaine.com il faut prouver que vous êtes bien le propriétaire de ce domaine. Il existe 3 méthodes :

1. HTTP01 : vous devez placer un fichier mon-super-domaine.com/.well-known/acme-challenge/clé_fournie_par_le_serveur_acme qui contient une valeur que seul vous connaissez ;
2. DNS01 : vous devez placer une clé dans la configuration DNS de votre nom de domaine qui contient la valeur fournie
3. TLS-SNI-01 qui permettait la validation uniquement au niveau TLS mais qui a été déprécié.

La grande majorité des sites utilisent la méthode web/HTTP qui est plus simple car il suffit d’avoir un serveur web (les plateformes de service internet n’ont pas toujours un serveur DNS). C’est là que ça se complique car, comme on l’a vu, c’est simple de fournir les certificats de sécurité avec HAproxy mais il n’est pas un serveur web. Donc, le renouvellement doit être assuré par un autre service (par exemple nginx, apache, …) ce qui est gènant :

• si vous avez plusieurs serveurs web, soit tous peuvent assurer ce renouvellement, soit vous devez router différemment avec le proxy vers le serveur qui gère ces renouvellements ;
• il y a un couplage entre le serveur haproxy et les services (DNS, HTTP) qui assurent la preuve de création et renouvellement ;
• dans ces serveurs web, vous pouvez avoir une section SSL qui ne fonctionnera que lorsque le certificat sera établi. Donc vous devez modifier la configuration en cours de création du certificat. Souvent les scripts le font ;
• une fois le certificat établi, vous devez le recopier pour HAproxy donc il faut utiliser un hook à la création ou au renouvellement pour garder les certificats synchrones entre le système de script et haproxy
• vous devez redémarrer haproxy pour mettre à jour son cache (ou utiliser la socket d’administration du serveur)

L’intégration entre les scripts acme.sh et haproxy permet de gérer les certificats uniquement par haproxy. De plus, acme.sh a intégré l’utilisation de la socket d’administration haproxy. Ansi, lorsque le certificat est créé ou renouvelé, haproxy est mis à jour dynamiquement. Plus besoin de redémarrer. Voici la séquence qui est exécutée lors d’une création ou renouvellement de certificat :

séquence d’établissement de certificat entre les acteurs acme.sh, HAproxy, le service letsencrypt et le serveur de DNS

Elle est pas belle la vie ?

Nous avons intégré ce fonctionnement (qui nécessite la version 2.8 de HAproxy, la version par défaut sur la Debian 12 est la 2.6), et fait un role ansible pour le déploiement.

On vous retrouve en pleine forme pour les événements de la rentrée :

Nagios

Introduction

Introduction