====== 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:

<code bash>
yum install smeserver-letsencrypt-client
</code>

Il ne reste qu'à le configurer:

<code bash>
db configuration setprop Letsencrypt Uri prod
</code>

<note>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</note>

<note tip>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.</note>

<code bash>
rm -f /home/e-smith/db/letsencrypt.sh/private_key.*
</code>

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

<code bash>
db domains setprop domaine.org Letsencrypt disabled
db hosts wpad.domaine.net disabled
signal-event letsencrypt-update
</code>

===== 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

<code bash>
db domains setprop backup.domaine.net ProxyPassACMEChallenge enabled
signal-event letsencrypt-update
</code>

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 ;-)

<code bash>
db domains setprop backup.domaine.net ProxyPassACMEChallenges enabled
db domains setprop backup.domaine.net ProxyPassACMEChallengesDisableOnRenew enabled
signal-event letsencrypt-update
</code>

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