ACMEd est un client pour let's encrypt afin d'obtenir un certificat SSL, orienté vers la modularité et la sécurité.
Il est moins simple à utiliser que le client par défaut car il demande plus de paramétrage, mais en contrepartie il ne vous met pas des fichiers crasseux et mal configurés n'importe où.
Attention, ce tutoriel est fait par quelqu'un qui n'y comprend rien. Il peut contenir des erreurs, voire des failles de sécurité pour votre installation. Lisez le manuel, comprenez-le, puis vérifiez et améliorez cet article.
Pour être compilé, ACMEd nécessite une version de Rust plus récente que celle qui est présente dans les dépôts officiels à l'heure actuelle. Du coup, nous allons installer Rust via Rustup. Rustup n'étant pas dans les dépôts officiels du tout, nous allons l'installer avec la manière « sale » officielle. Il est donc recommandé de compiler ACMEd dans une machine virtuelle puis de téléverser le résultat sur le serveur afin de l'y installer.
Installation des dépendances :
apt install openssl libssl-dev build-essential pkg-config curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
Récupération du code source et compilation :
curl -L 'https://github.com/breard-r/acmed/archive/v0.7.0.tar.gz' --output 'acmed.tar.gz' tar -xzvf acmed.tar.gz cd 'acmed-0.7.0' make
Création de l'archive :
mkdir acmed_archive make DESTDIR="acmed_archive" BINDIR="/usr/sbin" install tar -czvf acmed_archive.tar.gz acmed_archive
Téléversez ensuite acmed_archive.tar.gz
sur le serveur.
Avec les accès root, extrayez l'archive précédemment téléversée :
tar -xzvf acmed_archive.tar.gz
Pour lire les pages de manuel incluses avant d'installer :
man acmed_archive/usr/share/man/man8/acmed.8.gz
Installez OpenSSL uniquement s'il n'y a pas déjà LibreSSL :
apt install openssl
Si vous n'avez jamais installé ACMEd sur la machine, créez les répertoires suivants :
mkdir -p -m 700 /etc/acmed/accounts mkdir -p -m 755 /etc/acmed/certs
Si ACMEd était déjà installé et que vous le mettez à jour, sauvegardez le fichier de configuration :
cp /etc/acmed/acmed.toml /etc/acmed/acmed.toml.save
Listez ensuite le contenu extrait de l'archive :
find acmed_archive -type f
Cette commande affiche l'ensemble des fichiers devant être copiés sur le système, avec leur chemin complet. Par exemple, acmed_archive/usr/sbin/acmed
doit être copié dans /usr/sbin/acmed
et acmed_archive/usr/share/man/man8/acmed.8.gz
doit être copié dans /usr/share/man/man8/acmed.8.gz
.
Stoppez le service ACMEd si ce dernier était en-train de tourner. Copiez ensuite chaque fichier vers sa destination en utilisant la commande cp -p
. Par exemple :
cp -p acmed_archive/usr/sbin/tacd /usr/sbin/tacd
N'écrasez pas inutilement le fichier de configuration !
Sa configuration se trouve dans le fichier /etc/acmed/acmed.toml
, c'est donc là qu'il faut définir les domaines pour lesquels on souhaite obtenir un certificat. Afin d'être en mesure de prouver la propriété d'un domaine, il faut que le dossier /var/www/nom_de_domaine/.well-known/acme-challenge/
soit accessible aussi bien par le serveur web que par ACMEd.
Pour contrôler ACMEd:
systemctl restart acmed.service systemctl stop acmed.service systemctl start acmed.service
Pour visualiser les logs d'ACMEd (les options -n
et -f
sont fort utiles suivant les cas) :
journalctl -u acmed.service
Le niveau de log est défini dans le fichier /lib/systemd/system/acmed.service
. Si vous modifiez ce fichier, il faut penser à le recharger dans systemd à l'aide de la commande systemctl daemon-reload
avant de redémarrer ACMEd.
Les clés et certificats générés par ACMEd sont archivés avec git
via un hook.
J'ai copié bêtement de la Krypte, est-ce que ceci est par défaut ou propre à Khaganat ? C'est pushé où ?
ACMEd permet beaucoup de choses, ici un exemple pour qu'un site web basique, servi par nginx, puisse obtenir son certificat.
Modifiez le fichier /etc/acmed/acmed.toml
.
Il faut que je compare avec le fichier par défaut, mais il faut que je réinstalle acmed sur un serveur pour ça…
Créez la section account
où vous renseignerez un nom et un mail pour vous contacter ; si Let's encrypt a un souci, c'est par ce biais qu'ils vous préviendront. Le “nom” va servir plus bas aussi.
[[account]] name = "Mon Pseudo" email = "monmail@mail.net"
Puis dans la section certificate
, indiquez les noms de domaine à servir :
[[certificate]] account = "Mon Pseudo" endpoint = "letsencrypt v2 prod" domains = [ { dns = "monsite.fr", challenge = "http-01"}, { dns = "api.monsite.fr", challenge = "http-01"}, algorithm = "ecdsa_p384" kp_reuse = true hooks = ["http-01-echo", "restart-nginx", "git"]
account
: remettez le contenu du champ précédent “name”. Notez qu'un même serveur pouvant vous servir pour plusieurs comptes, vous pouvez avoir plusieurs “name” et “account”1).endpoint
: Pas la moindre idée de ce que c'est mais ça semble important.domains
: c'est là qu'on va déclarer les domaines. Une ligne par domaine et sous-domaine.algorithm
: selon toute logique, le type de chiffrement utilisé. ecdsa_p384
est probablement très bien vu que c'est ce que notre expert a mis sur nos serveurs. kp_reuse
: faut que je relise le man, la réponse doit être dedans… Mais là j'avance sur le tuto, donc en attendant, je suppose qu'on peut copier bêtement et que c'est important.hooks
: appelle des “hooks” définis par défaut ou avant dans le fichier de conf (voir la section “Hooks”). include = [ "default_hooks.toml" ] [[endpoint]] name = "letsencrypt v2 prod" url = "https://acme-v02.api.letsencrypt.org/directory" tos_agreed = true [[hook]] name = "restart-nginx" type = ["post-operation"] cmd = "service" args = [ "nginx", "restart" ] [[hook]] name = "restart-apache" type = ["post-operation"] cmd = "service" args = [ "apache2", "restart" ] [[account]] name = "Mon Pseudo" email = "monmail@mail.net" [[certificate]] account = "Mon Pseudo" endpoint = "letsencrypt v2 prod" domains = [ { dns = "monsite.fr", challenge = "http-01"}, { dns = "api.monsite.fr", challenge = "http-01"}, algorithm = "ecdsa_p384" kp_reuse = true hooks = ["http-01-echo", "restart-nginx", "git"]
Les “Hooks” sont des petits bouts de configuration à appeler ensuite, ça évite de se répéter et ça permet de gérer plein de situations.
Le fichier /etc/acmed/default_hooks.toml
contient nombre de hooks déjà prêts à être utilisés.
Dans l'exemple de configuration pour nginx, les hooks suivant sont appelés :
http-01-echo
restart-nginx
(définit dans le fichier /etc/acmed/acmed.toml
même)git
Dans /etc/acmed/default_hooks.toml
, le hook http-01-echo
est en fait un groupe : un hook qui appelle un lot de hooks :
[[group]] name = "http-01-echo" hooks = [ "http-01-echo-mkdir", "http-01-echo-echo", "http-01-echo-chmod", "http-01-echo-clean" ]
Et le hook http-01-echo-mkdir
ressemble par exemple à ça :
[[hook]] name = "http-01-echo-mkdir" type = ["challenge-http-01"] cmd = "mkdir" args = [ "-m", "0755", "-p", "{{#if env.HTTP_ROOT}}{{env.HTTP_ROOT}}{{else}}/var/www{{/if}}/{{domain}}/.well-known/acme-challenge" ] allow_failure = true
name
: nom par lequel on appelera le hook ensuitetype
: aucune idée, lire la doc ^^“cmd
: commande bash qui sera appeléeargs
: arguments passés à la commande en question. L'utilisation d'expressions régulières est possible.allow_failure
: aucune idée, lire la doc ^^”La doc d'ACMEd est complète, les pages de manuel sont incluses.
man acmed
? Évidemment on n'a pas installé la manpage sur kanla, je suis bloquée pour tester…