Distribution EOLE

Avant tout, ceci est mon analyse (Philippe Caseiro) et n'engage que moi et je la livre pour alimenter le débât.

Let'sencrypt est un service en ligne de mise à disposition de certificats valides automatique.

Principe de fonctionnement :¶

Pour fonctionner le service let'sencrypt utilise un client qu'il faut installer sur la machine qui va recevoir le certificat.
Cette machine doit disposer d'un FQDN (fully qualified domain name), ce FQDN doit pointer vers une IP qui permet de joindre la dite machine sur le port 443.

Le client va faire une requête pour 1 ou plusieurs certificats, un certificat let's, encrypt est forcément en lien avec un et un seul FQDN. Une fois que le client
fait la requête auprès du service en ligne, le service en ligne va essayer d'ouvrir une session HTTPS sur le port 443 afin de récupérer un identifiant générer par le client et ainsi valider que le client est bien à l'origine de la demande de certificat.

Si l'échange fonctionne, le service envoie un certificat valide et le sauvegarde dans un /etc/letsencrypt.

Le client let'sencrypt permet également le renouvellement des certificats qui ont des durée de vie très courtes.

Comment utiliser let'sencrypt dans EOLE :¶

Les limitations du service let'sencrypt font que l'utilisation dans EOLE va également être limitée.

Avant tout, le service impose des FQDN valides, que l'on peut résoudre depuis internet et qui pointent effectivement vers la machine qui va utiliser ce FQDN, ce qui implique donc une disparition de l'usage des noms de domaine locaux en ".lan".

Donc première limite il faut un domaine DNS valide à partir du moment où on souhaite utiliser let'sencrypt.

Ensuite le certificat fourni par let'sencrypt ne porte qu'un seul et unique FQDN et aucun Alternate name, donc il faut soit :

• utiliser un seul nom DNS pour tous les services de la machine,
• demander un certificat par nom de service et utiliser que chaque service utilise le certificat qui lui est associé.

Donc pour EOLE soit on a un certificat global avec un FQDN global et on utilise ce FQDN, soit on permet que chaque service qui a besoin de SSL dispose d'un FQDN spécifique valide une fois de plus et donc résoluble depuis internet et que chaque service puisse faire une demande de certificat let'sencrypt.

Je précise que non let'sencrypt ne délivre pas de certificats wildcard.

À quoi pourrait donc bien servir let'sencrypt alors ?¶

Et bien simplement ce pourquoi il a été prévu, fournir des certificats valides pour des serveurs web, let'sencrypt pourrait être très utile pour avoir des certificats valides sur les AmonÉcole ou des Scribes qui fournissent des services web ouverts sur internet.

Let'sencrypt serait également très utile couplé avec un eole-web taillé pour l'hébergement web mutualisé.

Ce que let'sencrypt ne permet pas :¶

Let'sencrypt ne permet pas de se débarrasser des certificats auto-signés, car toutes les machines EOLE n'ont pas forcément un accès à internet pour en faire la requête et l'usage, malgré tout il faut continuer à faire du SSL même sur le réseaux local.

Idées a creuser.¶

1. Avoir un serveur ACME (ce qui revient à avoir une PKI automatisée) pour les machines EOLE avec un service DNS commun.

Utiliser le service let'sencrypt sans aucune modification dans EOLE.¶

Il est parfaitement possible d'utiliser let'sencrypt actuellement sans rien toucher, le principe est simple :

• Avoir un FQDN pour la machine
• La machine répond et est joignable sur le port 80 ou 443 depuis internet
• Suivre la doc let'sencrypt pour installer l'utilitaire et faire la demande de certificat (procédure plutôt simple)
• Remplacer les valeurs des variables %%server_cert %%server_pem %%server_key par les emplacements des fichiers du certificat let'sencrypt.

Par exemple pour une machine qui s'appelle "lab.eole.org" :

server_cert="/etc/letsencrypt/live/lab.eole.org/cert.pem" 
server_key="/etc/letsencrypt/live/lab.eole.org/privkey.pem" 
server_pem="/etc/letsencrypt/live/lab.eole.org/fullchain.pem" 

Avec cette méthode tous les services utilisent le certificat let'sencrypt et tous les services seront fonctionnels à partir du moment où ils sont appelés via le nom "lab.eole.org".

Attention la commande de l'utilitaire de let'sencrypt n'est pas facilement "automatisable" il a besoin de validation humaine au moins lors du premier usage.

Il est possible d'utiliser des outils alternatifs, comme acmetool (https://hlandau.github.io/acme/)