Certificat Wildcard Lets Encrypt et HAProxy

Comment mettre en place sont certificat Wildcart Lets Encrypt sur HAProxy pour sécuriser nos sites web ?

Certificat Wildcard

Le certificat wildcard (ou certificat SSL wildcard) permet d’utiliser un seul et même certificat SSL pour couvrir l’ensemble des sous-domaines d’un site web. Il sécurise ceux-ci en fonction du niveau de certification demandé auprès de l’Autorité ad hoc. Et il répond aux différents besoins des protocoles de sécurité (HTTPS, SMTPS, POP3S).

L'objectif est de nous créer notre propre certificat Wildcard avec Lets Encrypt comme autorité certification. Dans ma situation je renouvelle tous les 3 mois manuellement.

Prérequis

Avoir son nom de domaine (CloudFlare s'occupe de mon nom de domaine kaze-cloud.fr)
Installer Cerbot avec le plugin pour CloudFlare
HA Proxy fonctionnel avec quelques déclaration
Déclarer un champ DNS similaire:

*.example.com.   3600  IN  A  203.0.113.1

Le caractère générique * est traité comme un substitut pour n'importe quel nom d'hôte. Cet exemple d'enregistrement DNS correspondrait à one.example.com et two.example.com. Il ne correspondrait pas à example.comtout court, ni à one.two.example.com, car le caractère générique * ne se développera que pour un nom d'hôte, pas pour plusieurs niveaux de noms.

De plus, un enregistrement DNS générique ne peut avoir qu'un seul caractère générique, donc *.*.example.com n'est pas autorisé.

Cerbot Lets Encrypt

Installer le paquet & plugin

sudo apt install certbot python3-certbot-dns-cloudflare

Créer notre fichier pour l'API de CloudFlare

touch cloudflareapi.txt

Son contenu:

# Cloudflare API credentials used by Certbot
dns_cloudflare_email = cloudflare@example.com
dns_cloudflare_api_key = CLE_API_CLOUDFLARE

Source

Génération du certificat

certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials cloudflareapi.txt \
  --dns-cloudflare-propagation-seconds 60 \
  -d '*.kaze-cloud.fr'

Notre clé priver, certificat, chaine de certification etc... sont dans le dossier /etc/letsencrypt/live

privkey.pem : la clé privée de votre certificat.
fullchain.pem : le fichier de certificat utilisé dans la plupart des logiciels de serveur.
chain.pem : utilisé pour l'agrafage OCSP dans Nginx >=1.3.7.
cert.pem : cassera de nombreuses configurations de serveur et ne devrait pas être utilisé sans lire davantage la documentation (voir le lien ci-dessous).

(Note : "OCSP stapling" est une technique de sécurité pour vérifier la validité d'un certificat SSL/TLS sans avoir à interroger le serveur d'autorité de certification à chaque connexion.)

On crée notre PEM :

cat /etc/letsencrypt/live/kaze-cloud.fr/{fullchain.pem,privkey.pem} > /etc/haproxy/ssl/kaze-cloud.fr.pem

Exemple de configuration HAProxy

On indique qu'il faut rediriger les requêtes HTTP vers HTTPS.

frontend http-front
    bind 172.16.30.112:80

    # Redirection HTTP vers HTTPS
    redirect scheme https code 301 if !{ ssl_fc }

On déclare un front en https.

frontend https-front
    bind 172.16.30.112:443 ssl crt /etc/haproxy/ssl/

    # Domaine Name
    acl ACL_seals hdr(host) -i seals-roubaix.kaze-cloud.fr seals-roubaix.loc>
    use_backend seals-backend if ACL_seals

On déclare un backend.

backend seals-backend
    stick-table type ip size 200k expire 30m
  stick on src
    balance leastconn
    option httpclose
    option forwardfor
    compression algo gzip
    server 0-web-roubaix.local     172.16.30.1:80 check
    server 1-web-roubaix.local     172.16.30.2:80 check

frontend http-front: Cette section configure le frontend pour le trafic HTTP (port 80). Il est lié à l'adresse IP 172.16.30.112 sur le port 80.
redirect scheme https code 301 if !{ ssl_fc }: Cette ligne spécifie une règle de redirection. Elle redirige tout le trafic HTTP (non sécurisé) vers HTTPS (sécurisé) en renvoyant un code de réponse HTTP 301 (redirection permanente). La condition if !{ ssl_fc } vérifie si la connexion n'est pas déjà sécurisée.
frontend https-front: Cette section configure le frontend pour le trafic HTTPS (port 443). Il est lié à l'adresse IP 172.16.30.112 sur le port 443 et utilise la configuration SSL spécifiée dans le répertoire /etc/haproxy/ssl/.
acl ACL_seals hdr(host) -i seals-roubaix.kaze-cloud.fr seals-roubaix.local: Cette ligne crée une liste d'accès (ACL) nommée "ACL_seals". Elle vérifie l'en-tête de l'hôte (header host) pour les noms de domaine spécifiés. Si le nom de domaine de la requête correspond à l'un de ceux-ci, la règle sera vraie.
use_backend seals-backend if ACL_seals: Cette ligne indique que si la règle de l'ACL "ACL_seals" est vraie (c'est-à-dire que le nom de domaine de la requête correspond), alors le trafic sera dirigé vers le backend "seals-backend".
backend seals-backend: Cette section configure le backend pour gérer le trafic provenant du frontend. Elle comprend les directives suivantes :
stick-table type ip size 200k expire 30m: Configure une table de stickiness basée sur les adresses IP pour mémoriser les connexions entrantes. Les connexions sont conservées pendant 30 minutes et la table peut stocker jusqu'à 200 000 entrées.
stick on src: Spécifie que la stickiness (mémorisation) est basée sur l'adresse IP source des clients.
balance leastconn: Cette ligne spécifie l'algorithme de répartition de charge "leastconn", qui dirige le trafic vers le serveur avec le moins de connexions actives.
option httpclose: Ferme la connexion HTTP après chaque transaction pour garantir qu'elle est réutilisable.
option forwardfor: Ajoute un en-tête "X-Forwarded-For" à la requête pour suivre l'adresse IP du client d'origine.
compression algo gzip: Active la compression GZIP pour les réponses HTTP si le client le supporte.
server 0-web-roubaix.local 172.16.30.1:80 check: Spécifie un serveur back-end avec l'adresse IP 172.16.30.1 et le port 80. L'option "check" signifie que HAProxy vérifiera la disponibilité de ce serveur en effectuant des vérifications régulières.
server 1-web-roubaix.local 172.16.30.2:80 check: De même, cette ligne configure un autre serveur back-end avec l'adresse IP 172.16.30.2 et le port 80, et HAProxy effectuera également des vérifications de disponibilité.

Relancer HAProxy:

systemctl restart haproxy