Utiliser un certificat Letsencrypt

Letsencrypt permet d'obtenir des certificats SSL DV gratuitement. Plus important que l'aspect gratuit, c'est l'automatisation qui est importante: une fois que c'est en place, les certificats seront renouvelés automatiquement par la suite (et heureusement, parce que les certificats signés par l'autorité de Letsencrypt sont valides seulement 90 jours)

Installation sur une iPasserelle

Pour installer le client:

yum install smeserver-letsencrypt-client

Il ne reste qu'à le configurer:

db configuration setprop Letsencrypt Uri prod

L'URI par défaut est staging qui pointe sur un serveur de test de Letsencrypt. Ça permet de faire des tests pour s'assurer que tous nos noms DNS sont bien en place et de ne pas saturer le serveur de production. Ça permet aussi de ne pas atteindre la limite de certificat qui est assez faible sur les serveurs de productions de Letsencrypt

Une fois les tests fait en staging, pour passer en prod, il faut supprimer la clé du compte pour que le client Letsencrypt en génère une nouvelle qu'il enregistrera sur le serveur de production de Letsencrypt.

rm -f /home/e-smith/db/letsencrypt.sh/private_key.*

Par défaut, tous les domaines déclarés sur le serveur et tous les noms DNS attachés au domaine principal seront ajouté en tant que SubjectAltName dans le certificat. Il est possible d'en désélectionner quelques un

db domains setprop domaine.org Letsencrypt disabled
db hosts wpad.domaine.net disabled
signal-event letsencrypt-update

Domaines ProxyPass

Sans entrer dans les détails du fonctionnement du protocole ACME utilisé pour valider un nom de domaine, les serveurs de letsencrypt doivent pouvoir faire des requêtes sur /.well-known/acme-challenge

Pas de problème particulier pour les domaines classiques, mais pour les domaines qui font du ProxyPass, on peut avoir plusieurs cas de figure, et plusieurs réglages possibles, avec la prop ProxyPassACMEChallenges

disabled les requêtes /.well-known/acme-challenge sont traitées par l'iPasserelle, et pas renvoyées vers le backend
only seules les requêtes vers /.well-known/acme-challenge sont renvoyées vers le backend. Toutes les autres requêtes sont traitées par l'iPasserelle
enabled tout est renvoyé vers le backend, y compris les requêtes vers /.well-known/acme-challenge

db domains setprop backup.domaine.net ProxyPassACMEChallenge enabled
signal-event letsencrypt-update

Il y a un autre cas, un peu plus rare: quand un nom doit être valide pour 2 machines différentes. Exemple d'usage

Une seule IP publique disponible
Un serveur de sauvegarde interne faisant fonctionner BackupPC, accessible sur l'adresse https://backup.domaine.net
Depuis l'extérieur, impossible de joindre directement cette interface (sauf à utiliser un VPN), on met donc en place un ProxyPass restreint (limité à certaines IP) pour accéder à l'interface de gestion des sauvegardes

Problème: le nom backup.domaine.net doit être valide pour l'iPasserelle et le serveur de sauvegardes. Il faut donc à la fois traiter les requêtes vers /.well-known/acme-challenge, et les renvoyer vers le backend. IL y a un réglage pour ça

db domains setprop backup.domaine.net ProxyPassACMEChallenges enabled
db domains setprop backup.domaine.net ProxyPassACMEChallengesDisableOnRenew enabled
signal-event letsencrypt-update

Avec ce réglage, en temps normal, les requêtes vers /.well-known/acme-challenge sont renvoyées vers le backend. Mais uniquement quand letsencrypt renouvelle ses certificats sur l'iPasserelle, elles sont traités en local