Yunohost - Équiper son serveur d'un certificat TLS commercial
Rédigé par Frédéric Dumas
Aucun commentaire
Classé dans : Administration système
Yunohost est une distribution GNU/Linux basée sur Debian, et spécifiquement conçue pour automatiser l'installation et la mise à jour régulière ultérieure d'une large collection d'applications web, à la place de l'administrateur système. Elle décharge l'utilisateur de la préoccupation de sécuriser son serveur, ce travail étant délégué aux mainteneurs de la distribution et de son catalogue d'applications, au bénéfice de milliers d'utilisateurs finaux.
Conséquence de cette automatisation, depuis son interface d'administration graphique, Yunohost facilite l'installation des certificats X.509 gratuits émis par Let's Encrypt, indispensables pour sécuriser la connexion des visiteurs sur le serveur en https. Cependant, si on dispose d'un certificat X.509 TLS émis par une autre autorité de certification, il sera nécessaire de l'installer sur le serveur à la main, en ligne de commande.
Ce billet explique comment y parvenir, en respectant la logique des auteurs de Yunohost, pour permettre à son serveur web Nginx d'utiliser d'emblée ce certificat, sans qu'il soit nécessaire d'adapter manuellement ses fichiers de configuration. Il est ainsi possible de profiter d'un certificat X.509 d'une autre autorité de certification que Let's Encrypt, en conservant une parfaite compatibilité avec les mises à jours futures de Yunohost.
L'interface graphique d'administration de Yunohost permet facilement de déclarer un nouveau domaine sur le serveur, sur lequel seront accessibles depuis l'Internet les applications web qu'elle permet également d'installer. Nous partons du principe que l'utilisateur:
- a déclaré ce domaine dans l'interface d'administration;
- a obtenu un certificat X.509 émis par une autorité de certification pour ce même domaine (on pourra se référer à cet autre billet pour ce faire);
- est connecté en ligne de commande à son serveur Yunohost, et est passé
rootpar la commandesudo -i; - dispose dans un dossier (1) de la clé privée et (2) du certificat X.509 chainé avec le certificat intermédiaire de l'autorité de certification, comme expliqué dans le billet sus-cité.
Création des sous-répertoires
Sur Yunohost, les certificats TLS sont rangés dans le répertoire:
/etc/yunohost/certs/Pour accueillir la clé privée et le certificat X.509 destinés à sécuriser l'accès au domaine choisi, un sous-répertoire du même nom devra être créé. Par convention, son nom se compose:
- d'un préfixe (le nom de domaine en entier, incluant le tld);
- d'un suffixe ('
-history').
yunohost.e2li.org, le sous-répertoire sera créé ainsi sur le serveur:# mkdir /etc/yunohost/certs/yunohost.e2li.org-historyPour chaque installation d'un nouveau certificat X.509, un sous-répertoire dédié sera encore créé, dont le nom portera par convention:
- la date du jour
- l'heure
- le nom de l'autorité de certification émettrice
Ces informations sont indifférentes au serveur web Nginx lui-même, un autre nom pourrait avoir été choisi pour le sous-répertoire, ne respectant pas cette convention. Le but de cette architecture voulue par les auteurs de Yunohost est de permettre à l'administrateur du serveur de distinguer facilement, au fil du temps, le certificat actuel des certificats précédemment installés, et d'en suivre en quelque sorte l'historique, simplement en affichant le contenu du répertoire. Prenons un exemple, où le certificat aurait été émis par l'autorité de certification Certum; par convention, on pourra ainsi donner comme nom au sous-répertoire:
# mkdir /etc/yunohost/certs/yunohost.e2li.org-history/20260217.111800-certum
Les puristes simplifieront les deux écritures en une seule:
# mkdir -p /etc/yunohost/certs/yunohost.e2li.org-history/20260217.111800-certum
où l'option
-p de la commande mkdir procède à la création du sous-répertoire intermédiaire (ici yunohost.e2li.org-history), s'il n'existait pas encore.À propos des propriétaires, droits d'accès, et formats de fichiers
À ce stade, les sous-répertoires créés appartiennent à l'utilisateur et au groupe
root. Ce n'est pas la configuration souhaitée pour permettre de protéger la clé privée tout en garantissant à Nginx d'y avoir accès. Cependant, nous remettrons d'équerre les propriétaires des dossiers et leurs droits d'accès après les avoir peuplé de la clé privée et du certificat, afin que ces corrections s'appliquent aussi aux fichiers eux-mêmes.PEM est la forme "textuelle" d'encodage des clés et certificats (leur contenu utile est encodé en base64, affichable dans un terminal par un simple
cat), par contraste avec DER, qui est la forme binaire des mêmes clés et certificats. Tant openssl que l'autorité de certification auront générés au format PEM, pour le premier une clé privée, pour la seconde un certificat X.509. Il ne devrait donc pas être nécessaire de procéder à une conversion de format.Pour vérifier qu'un certificat est bien enregistré au format PEM, il suffit d'utiliser
cat pour l'afficher:# cat /etc/yunohost/certs/yunohost.org/crt.pem
-----BEGIN CERTIFICATE-----MIIDlDCCAnygAwIBAgITb9fxoK+erj9kCMbdfmyNaOurbjANBgkqhkiG9w0BAQsF
ADAqMRUwEwYDVQQDEwx5dW5vaG9zdC5vcmcxETAPBgNVBAoTCHl1bm9ob3N0MB4X
[SNIP]
oXEIE1MGWlSIcYD8AVyQRWkeNeHRVwho98Lm0rpneq8i4c+fH9JUAXnWBLK0pNrs
SvdY15ipCX3HAUvnHvHmnNNE3rlcGkersV8Jnoqb4b9dlMG8W5K6LsZzW0YzPn5ERP+1P3ZHjNQ=
-----END CERTIFICATE-----Pour vérifier qu'une clé privée est bien enregistrée au format PEM, on pourra vouloir éviter de la faire apparaitre à l'écran. On se contentera alors de ne faire apparaitre que ses délimiteurs:
# head -n1 /etc/yunohost/certs/yunohost.org/key.pem
-----BEGIN PRIVATE KEY-----ou encore:
# tail -n1 /etc/yunohost/certs/yunohost.org/key.pem
-----END PRIVATE KEY-----Enfin, si une conversion du format de DER à PEM était nécessaire, on y parviendrait à l'aide d'
openssl.Copie de la clé et du certificat
Partons du principe que l'administrateur aura réuni dans un
sous-répertoire appartenant à
root la clé privée et les certificats
chainés au format PEM. Il les déplacera donc vers le répertoire nouvellement créé:# mv /root/certum/* /etc/yunohost/certs/yunohost.e2li.org-history/20260217.111800-certum/
Dans l'affichage ci-dessous, on observe la présence de quatre fichiers (leurs noms sont arbitraires):
# ls -laht /etc/yunohost/certs/yunohost.e2li.org-history/20260217.111800-certum/
total 28K
drwxr-xr-x 2 root root 4,0K 27 févr. 12:12 .
drwxr-xr-x 5 root root 4,0K 27 févr. 11:21 ..
-rw-r--r-- 1 root root 2,9K 26 févr. 22:23 ynh_ecc_chained_2026-02-26.pem
-rw-r--r-- 1 root root 1,7K 26 févr. 20:54 ynh_ecc_2026-02-26.pem
-rw-r--r-- 1 root root 477 26 févr. 13:45 ynh_ecc_2026-02-26.csr
-rw------- 1 root root 302 26 févr. 13:42 ynh_ecc_private_2026-02-26.key
Par ordre d'apparition:
- le premier des deux fichiers nécessaires à Ngnix, on trouve en tête le certificat X.509 signé par l'autorité de certification, et chainé avec le certificat intermédiaire de cette autorité, dans le même fichier;
- vient ensuite le certificat X.509 seul, signé par l'autorité de certification; c'est le même fichier que le précédant, à cette différence que le certificat intermédiaire ne lui avait pas encore été ajouté; en l'état, ce fichier est inutile à Ngnix; cependant, sa présence dans le répertoire ne gêne pas;
- le certificat CSR (Certificate Signing Request — Requête de Signature de Certificat), contenant la clé publique, et qui fut nécessaire pour soumettre la demande de signature à l'autorité de certification; ce fichier lui aussi est inutile à Ngnix; cependant, sa présence dans le répertoire ne gêne pas;
- la clé privée enfin; c'est le second des fichiers nécessaires à Ngnix; il est resté inchangé depuis sa génération initiale par
openssl.
Remarquons qu'à ce stade, le groupe propriétaire des dossiers et fichiers, ainsi que les droits d'accès applicables, n'ont pas encore été rectifiés.
Création des liens symboliques
Pour permettre au serveur web Ngnix de trouver la clé privée et les certificats chainés par les noms sous lesquels il les connait, il suffit d'ajouter dans ce même répertoire des liens symboliques:
# cd /etc/yunohost/certs/yunohost.e2li.org-history/20260217.111800-certum/
# ln -s ynh_ecc_private_2026-02-26.key key.pem
# ln -s ynh_ecc_chained_2026-02-26.pem crt.pemNotre sous-répertoire est désormais ainsi peuplé:
# ls -laht /etc/yunohost/certs/yunohost.e2li.org-history/20260217.111800-certum/
total 24K
drw-r-xr-x 2 root root 4,0K 27 févr. 13:44 .
lrwxrwxrwx 1 root root 30 27 févr. 13:28 crt.pem -> ynh_ecc_chained_2026-02-26.pem
lrwxrwxrwx 1 root root 30 27 févr. 13:27 key.pem -> ynh_ecc_private_2026-02-26.key
drwxr-xr-x 5 root root 4,0K 27 févr. 11:21 ..-rw-r--r-- 1 root root 2,9K 26 févr. 22:23 ynh_ecc_chained_2026-02-26.pem
-rw-r--r-- 1 root root 1,7K 26 févr. 20:54 ynh_ecc_2026-02-26.pem
-rw-r--r-- 1 root root 477 26 févr. 13:45 ynh_ecc_2026-02-26.csr
-rw------- 1 root root 302 26 févr. 13:42 ynh_ecc_private_2026-02-26.key
La logique des auteurs de Yunohost est de conserver dans le répertoire propre à l'historique du domaine (dans notre exemple fictif,
yunohost.e2li.org-history) autant de sous-répertoires (ici 20260217.111800-certum) qu'il y eu de certificats renouvelés et installés. Il faut donc maintenant donner le moyen à Ngnix de savoir lequel de ces sous-répertoires (et des clés et certificats qu'il contient) est pertinent au moment présent. On y parvient à l'aide d'un lien symbolique vers ce sous-répertoire, qui le désignera comme comme celui étant actif:# cd /etc/yunohost/certs/
# ln -s /etc/yunohost/certs/yunohost.e2li.org-history/20260217.111800-certum/ yunohost.e2li.orgAinsi, le sous-répertoire dans lequel Ngnix cherche la clé privée et le certificat X.509 porte toujours le nom du domaine lui-même, auquel cette clé et ce certificat sont dédiés. Le lien symbolique sert à dissimuler à Ngnix la petite complexité apportée par la gestion d'un historique.
Correction du groupe et des droits
À présent, nous avons tous les sous-répertoires, fichiers, liens symboliques en place. Il ne reste qu'à transférer l'ensemble au groupe
ssl-cert, grâce à quoi Ngnix pourra accéder à la clé privée et au certificat, et à configurer aussi les droits d'accès en conséquence. L'utilisateur root restera propriétaire.# chown -R root:ssl-cert /etc/yunohost/certs/Sur les répertoires, on réservera le droit d'écriture au seul propriétaire (
root), de lecture et de traversée au groupe (ssl-cert), et on interdira l'accès aux autres:# find /etc/yunohost/certs/ -type d -exec chmod 750 {} ;Enfin, on appliquera une politique similaire sur les fichiers; le propriétaire aura les droits de lecture et d'écriture, le groupe aura le droit de lecture seule, et les autres n'auront aucun accès:
# find /etc/yunohost/certs/ -type f -exec chmod 640 {} ;Au final, le sous-répertoire dans lequel auront été réunis la clé et le certificat devrait ressembler à ceci:
# ls -laht /etc/yunohost/certs/yunohost.e2li.org-history/20260217.111800-certum
total 24K
drw-r-x--- 2 root ssl-cert 4,0K 27 févr. 13:44 .
lrwxrwxrwx 1 root ssl-cert 30 27 févr. 13:28 crt.pem ->ynh_ecc_chained_2026-02-26.pem
lrwxrwxrwx 1 root ssl-cert 30 27 févr. 13:27 key.pem ->ynh_ecc_private_2026-02-26.key
drwxr-x--- 5 root ssl-cert 4,0K 27 févr. 11:21 ..
-rw-r----- 1 root ssl-cert 2,9K 26 févr. 22:23ynh_ecc_chained_2026-02-26.pem
-rw-r----- 1 root ssl-cert 1,7K 26 févr. 20:54ynh_ecc_2026-02-26.pem
-rw-r----- 1 root ssl-cert 477 26 févr. 13:45ynh_ecc_2026-02-26.csr
-rw-r----- 1 root ssl-cert 302 26 févr. 13:42ynh_ecc_private_2026-02-26.key
Vérification
Il reste à vérifier dans l'interface graphique d'administration de Yunohost que notre nouveau certificat X.509 est bien reconnu pour ce domaine.
Bravo ! Les applications installées sur le serveur Yunohost sous ce domaine sont désormais accessibles en https.
