Synology : Certificat valide avec Let’s Encrypt

Synology : Certificat valide avec Let's Encrypt

Avoir son site fonctionnant en HTTP c’est bien, mais en HTTPS et sans exception de sécurité du navigateur c’est encore mieux ! Même dans le cas où vous n’avez pas de réel besoin de chiffrer les requêtes, cela a au moins le mérite d’améliorer la note de référencement. En revanche, gardez à l’esprit qu’il n’est pas une bonne pratique de faire fonctionner tout votre site en HTTPS puisque désactivant ainsi le cache. Ce billet résume la démarche à suivre pour générer et importer un certificat valide avec Let’s Encrypt sur un NAS Synology DSM 6 avec Nginx.

Certificat valide avec Let’s Encrypt

Let’s Encrypt est une autorité de certification lancée le 3 décembre 2015 (Bêta Version Publique). Cette autorité fournit des certificats gratuits X.509 pour le protocole cryptographique TLS au moyen d’un processus automatisé destiné à se passer du processus complexe actuel impliquant la création manuelle, la validation, la signature, l’installation et le renouvellement des certificats pour la sécurisation des sites internet.

Source : Wikipedia

Générer le certificat

La génération d’un certificat valide avec Let’s Encrypt se fait grâce à un client, plusieurs sont disponibles. Toutefois, tous ne fonctionnent pas sur notre NAS, à commencer par le client officiel. En effet, vous aurez rapidement le message d’erreur suivant :

Sorry, I don’t know how to bootstrap Let’s Encrypt on your operating system!

Je ne vous cacherai pas que j’ai dans un premier temps tenté via une Debian sous VirtualBox de générer ce certificat via le client officiel, seulement voila : la procédure implique de générer des fichiers devant être immédiatement accessibles depuis le web, alors forcément, ça devient compliqué…

La solution est donc d’utiliser un autre client : Acme-tiny, écrit en Python. Et le Python on aime parce que ça tourne directement sur notre NAS ! Par ailleurs, vous constaterez que le readme est extrêmement bien fait et sera en grande partie repris dans ce tuto, mais en plus détaillé et en couleur svp 🙂

Etape 1 : Récupérer Acme-tiny

whoami
root
mkdir /root/cert && cd /root/cert
git clone https://github.com/diafygi/acme-tiny.git

cd acme-tiny

Etape 2 : Générer les clés privées

Pour cet exemple, le nom de domaine est thorpora.fr, à remplacer donc par votre FQDN. Les noms de fichiers ont simplement une importance sémantique. A contrario de ce qui est présenté sur github, je ne vous conseille pas l’option -subj. Ainsi, toutes les informations vous seront demandées interactivement.

openssl genrsa 4096 > account.key
openssl genrsa 4096 > thorpora.key
openssl req -new -sha256 -key thorpora.key  > thorpora.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
—–
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Paris
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Thorpora
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:thorpora.fr
Email Address []:foo.bar@gmail.com
Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:AnyPasswordLessThan20Char
string is too long, it needs to be less than  20 bytes long
A challenge password []:anyNewPassword
An optional company name []:

Etape 3 : Configurer Nginx

Il faut savoir qu’à la prochaine étape, le client Acme-tiny va générer des fichiers qui vont devoir être accessibles directement depuis votre serveur HTTP. Il faut donc préparer le terrain.

mkdir -p /volume1/web/.well-known/acme-challenge/

Depuis les IHM Syno, il faut donner les droits de lecture au groupe HTTP pour le répertoire .well-known en cochant « Appliquer à ce dossier, ces sous-dossiers et ces fichiers ».

Nous devons à présent customiser notre virtual host thorpora.fr. Dans le fichier de configuration de Nginx /etc/nginx/app.d/server.webstation-vhost.conf dans votre fichier de vhost créer manuellement et se situant dans le répertoire site-enabled (en savoir plus grâce à cet article) il est nécessaire de modifier l’entrée concernant l’url .well-known de cette façon :

Puis recharger la configuration : nginx -s reload

Pour vérifier que la configuration est correcte :

  • Vérifier déjà que le site web est toujours fonctionnel
  • Créer un fichier hello par exemple dans le répertoire /web/.well-known/acme-challenge/, avec les droits http en lecture
  • Le fichier doit être accessible depuis l’url http://thorpora.fr/.well-known/acme-challenge/hello

Etape 4 : Générer le certificat signé

whoami
root
pwd
/root/cert/acme-tiny
python acme_tiny.py –account-key ./account.key –csr ./thorpora.csr –acme-dir /volume1/web/.well-known/acme-challenge > signed.crt
Parsing account key…
Parsing CSR…
Registering account…
Registered!
Verifying thorpora.fr…
thorpora.fr verified!
Signing certificate…
Certificate signed!

Cette étape est la plus délicate… si une erreur survient, il faut très certainement revoir la configuration de Nginx et les droits des répertoires.

Il faut ensuite télécharger le certificat intermédiaire fournit par Let’s Encrypt et générer notre certificat final :

wget -O – https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem > intermediate.pem
cat signed.crt intermediate.pem > chained.pem

Par principe, déplaçons tous nos fichiers générés dans /root/cert pour y avoir plus claire.

pwd
/root/cert
 ls -l
acme-tiny
account.key
chained.pem
intermediate.pem
signed.crt
thorpora.csr
thorpora.key

Nous avons enfin un certificat valide avec Let’s Encrypt : notre fichier chained.pem, au format standard d’OpenSSL !

Mise à jour du vhost avec le certificat

Précédemment dans cet article je préconisais d’utiliser l’IHM DSM pour la mise à jour des certificats. Seulement voila : c’était en partant du principe que nos vhosts avaient été créés depuis l’IHM et consolidés manuellement via le fichier /etc/nginx/app.d/server.webstation-vhost.conf. Cette façon de faire est problématique puisque régulièrement ce fichier est régénéré par Synology, indépendamment de toute action humaine. Finalement, le plus simple est de gérer les virtuals host de façon totalement indépendante des surcouches Synology via le répertoire site-enabled.

Ainsi pour la prise en compte de notre certificat, il suffit de mettre à jour la configuration du vhost en question :

Cet article traitant de l’installation de WordPress présente un vhost complet et créé manuellement, n’hésitez pas à y jeter un coup d’œil. Par ailleurs, ce même article présente aussi la création d’un dossier partagé etc offrant plusieurs avantages.

Renouvellement automatique

Avoir un certificat valide avec Let’s Encrypt c’est bien, le problème c’est que ce certificat n’est valide que 30 jours… Heureusement il est possible d’automatiser la mise à jour du certificat relativement simplement ! Pour cela il suffit d’ajouter une entrée dans /etc/crontab qui se chargera tous les 30 jours d’appeler notre script de renouvellement.

Ce script est disponible sur github : https://github.com/ylacaute/synology/tree/master/ssl. La ligne à ajouter dans le fichier /etc/crontab est indiquée dans le README. Vous pouvez directement exécuter le script pour effectuer un renouvellement immédiatement, en prenant soin de modifier les informations de l’entête !

  • ACME_DIR : représente le répertoire où vous avez téléchargé l’outil acme-tiny
  • CERT_DIR : le répertoire où vos stocker vos certificats
  • WEB_ROOT_DIR : le répertoire racine web de Synology (à modifier si vous utilisez plusieurs certificats en fonction de vos sites web)
  • SENDER : l’adresse envoyant les mails, doit matcher votre nom de domaine (autrement sera considéré comme du spam)
  • DEST : votre email perso, pour recevoir les notifications de renouvellement

En effet, à chaque fois que le script s’exécute, un mail vous sera envoyé, précisant que l’opération de renouvellement à réussi ou non. Cela nécessite d’avoir installé et configuré le package Mail Server sur votre NAS.

Mise à jour du certificat via l’IHM

Attention cette partie est valable uniquement si vous avez utilisé l’IHM pour créer vos vhosts (ce que je ne conseille pas !)

Par précaution, nous ajoutons un nouveau certificat plutôt que d’écraser une quelconque configuration existante de Synology.

Synology DSM : ajouter un certificat valide avec Let's Encrypt

Choisir « Ajouter un nouveau certificat »

 

Synology DSM : importer un certificat valide avec Let's Encrypt

Choisir « importer le certificat »

Synology DSM : importer un certificat valide avec Let's Encrypt

Ajouter les fichiers générés précédemment, Ok. Clic droit sur le certificat puis « configurer »

 

Synology DSM : configurer un certificat valide avec Let's Encrypt

Changer le certificat pour le domaine concerné.

Tester votre certificat

Il est temps de tester notre nouveau certificat, naviguer vers votre site en HTTPS : il ne devrait plus y avoir d’exception !

Vous pouvez également faire un tour sur WhyNoPadLock qui nous donne d’autres infos utiles sur l’affichage correctes (ou pas) des pages HTTPS. En effet, avec WordPress, il est courant de constater des problème d’images chargées en HTTP alors même que l’internaute navigue en HTTPS, résultant la perte du petite cadena vert dans le navigateur.

WhyNoPadLock : vérifier un certificat valide avec Let's Encrypt

Vérifier son domaine avec WhyNoPadLock

 

 

2 réponses

  1. 19 avril 2016

    […] Si vous disposez de vos propres certificats vous pouvez mettre à jour les deux lignes commentées. Cet autre article explique comment générer ces fichiers. […]

  2. 19 avril 2016

    […] Si vous disposez de vos propres certificats vous pouvez mettre à jour les deux lignes commentées. Cet autre article explique comment générer ces fichiers. […]

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *