Let’s Encrypt, comment passer au HTTPS avec Nginx ?

Let’s Encrypt est une nouvelle autorité de certification (CA) qui fournit un moyen facile d’obtenir et d’installer des certificats TLS/SSL gratuits, ce qui permet de crypter HTTPS sur les serveurs Web. Il simplifie le processus en fournissant un logiciel client, letsencrypt , qui tente d’automatiser la plupart (sinon la totalité) des étapes nécessaires. Actuellement, le processus complet d’obtention et d’installation d’un certificat est entièrement automatisé uniquement sur les serveurs Web Apache. Toutefois, Let’s Encrypt peut être utilisé pour obtenir facilement un certificat SSL gratuit, qui peut être installé manuellement, indépendamment de votre choix de logiciel de serveur Web.

Dans ce tutoriel, nous allons vous montrer comment utiliser Let’s Encrypt pour obtenir un certificat SSL gratuit et l’utiliser avec Nginx sur Ubuntu 16.04. Nous vous montrerons également comment renouveler automatiquement votre certificat SSL. Si vous utilisez un serveur Web différent, suivez simplement la documentation de votre serveur Web pour savoir comment utiliser le certificat avec votre configuration.

Conditions préalables avec Let’s Encrypt

Avant de suivre ce didacticiel, vous aurez besoin de quelques choses.

Vous devez avoir un serveur Ubuntu 16.04 avec un utilisateur non-root qui a des privilèges sudo . Vous pouvez apprendre comment mettre en place un tel compte d’utilisateur en suivant ce guide configuration initiale du serveur pour Ubuntu 16.04.

Vous devez posséder ou contrôler le nom de domaine enregistré avec lequel vous souhaitez utiliser le certificat.

Si vous ne l’avez pas déjà, assurez-vous de créer un enregistrement A qui pointe votre domaine à l’adresse IP publique de votre serveur. Cela est nécessaire en raison de la façon dont Let’s Encrypt valide le domaine pour lequel il émet un certificat. Par exemple, si vous voulez obtenir un certificat pour example.com , ce domaine doit pointer sur votre serveur pour le processus de validation fonctionne. Notre configuration utilisera example.com et www.example.com comme les noms de domaine.

Une fois que vous avez toutes les conditions préalables, passons à l’installation du logiciel client Let’s Encrypt.

Étape 1: Installation du client

La première étape pour Let’s Encrypt pour obtenir un certificat SSL est d’installer le client letsencrypt sur votre serveur. Bien que le projet Let’s Encrypt ai rebaptisé leur client certbot , le client inclus dans les dépôts Ubuntu 16.04  est simplement appelé letsencrypt . Cette version est tout à fait adéquate pour nos fins.

Mettre à jour les packages Ubuntu et installer letsencrypt avec apt:

sudo apt-get update
sudo apt-get install letsencrypt

Le client letsencrypt doit maintenant être prêt à être utiliser.

Étape 2: Obtenir un certificat SSL

Let’s Encrypt fournit une variété de façons d’obtenir des certificats SSL, à travers différents plugins. Contrairement au plugin Apache, qui est couvert dans un tutoriel différent , la plupart des plugins serviront seulement à vous aider à obtenir un certificat que vous devez ensuite configurer manuellement sur votre serveur Web. Les plugins qui n’obtiennent que des certificats et ne les installent pas sont appelés «Authentificateurs» car ils servent à vérifier si un serveur peut recevoir un certificat.

Nous allons vous montrer comment utiliser le plugin Webroot pour obtenir un certificat SSL.

Comment utiliser le plugin Webroot

Le plugin Webroot fonctionne en plaçant un fichier spécial dans un répertoire /.well-known dans le document root de votre serveur. Le serveur doit avoir un droit d’écriture dans ce répertoire. Si vous n’avez pas encore installé Nginx, faites-le en suivant ce tutoriel

Pour s’assurer que le répertoire est accessible par Let’s Encrypt, modifions rapidement notre configuration Nginx. Par défaut, il est situé à
/etc/nginx/sites-available/default

sudo nano /etc/nginx/sites-available/default

À l’intérieur du bloc serveur, ajoutez ce bloc d’emplacement:

location ~ /.well-known {
    allow all;
}

Vous devez aussi vérifier l’emplacement de votre document root

ce chemin est nécessaire pour utiliser le plugin Webroot. Si vous utilisez le fichier de configuration par défaut, la racine sera
/var/www/html Sauvegarder et quitter. Vérifiez les erreurs de syntaxe:

sudo nginx -t

Si aucune erreur n’est trouvée, redémarrez Nginx avec cette commande:

sudo systemctl restart nginx

Maintenant que nous connaissons notre webroot-path , nous pouvons utiliser le plugin Webroot pour demander un certificat SSL avec ces commandes. Ici, nous  spécifions nos noms de domaine avec l’option -d . Si vous voulez un seul certificat à utiliser avec plusieurs noms de domaine (par exemple , example.com et www.example.com ), assurez-vous de les inclure tous. Assurez-vous également que vous remplacez les parties en surbrillance par le chemin webroot et les noms de domaine appropriés :

sudo letsencrypt certonly -a webroot --webroot-path = / var / www / html -d example.com -d www.example.com

À l’invite, entrez une adresse email qui sera utilisée pour les avis et la récupération des clés perdues:

Ensuite, vous devez accepter l’accord Let’s Encrypt. Sélectionnez Agree :

Si tout a réussi, vous devriez voir un message de sortie qui ressemble à ceci:

IMPORTANT NOTES:
 - If you lose your account credentials, you can recover through
   e-mails sent to sammy@digitalocean.com
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/example.com/fullchain.pem. Your
   cert will expire on 2016-03-15. To obtain a new version of the
   certificate in the future, simply run Let's Encrypt again.
 - Your account credentials have been saved in your Let's Encrypt
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Let's
   Encrypt so making regular backups of this folder is ideal.
 - If like Let's Encrypt, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Vous devez noter le chemin et la date d’expiration de votre certificat.

Fichiers de certificats

Après avoir obtenu le cert, vous aurez les fichiers PEM suivants encodés:

• cert.pem: certificat de votre domaine
• chain.pem: certificat de chaîne Let’s Encrypt
• fullchain.pem: cert.pem et chain.pem combinés
• privkey.pem: clé privée de votre certificat

Il est important de connaître l’emplacement des fichiers de certificats qui viennent d’être créés, afin que vous puissiez les utiliser dans la configuration de votre serveur Web. Les fichiers eux-mêmes sont placés dans un sous-répertoire dans /etc/letsencrypt/archive. Cependant, Let’s Encrypt crée des liens symboliques vers les fichiers de certificats les plus récents dans le
/etc/letsencrypt/live/your_domain_name en /etc/letsencrypt/live/your_domain_name. Étant donné que les liens pointent toujours vers les fichiers de certificat les plus récents, il s’agit du chemin que vous devez utiliser pour faire référence à vos fichiers de certificat.

Vous pouvez vérifier que les fichiers existent en exécutant cette commande (en remplaçant votre nom de domaine):

 sudo ls -l /etc/letsencrypt/live/your_domain_name

vous devez voir les 4 fichiers cités précédemment. Dans un moment, vous allez configurer votre serveur Web pour utiliser fullchain.pem comme le fichier de certificat et privkey.pem  comme fichier de clé de certificat.

Générer un solide groupe Diffie-Hellman

Pour augmenter davantage la sécurité, vous devriez également générer un groupe Diffie-Hellman solide. Pour générer un groupe de 2048 bits, utilisez cette commande:

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Cela peut prendre quelques minutes , mais quand c’est  fait , vous aurez un groupe DH fort à /etc/ssl/certs/dhparam.pem .

Étape 3: Configurer TLS/SSL sur le serveur Web (Nginx)

Maintenant que vous avez un certificat SSL, vous devez configurer votre serveur Web Nginx pour l’utiliser.

Nous apporterons quelques ajustements à notre configuration:

1. Nous créerons un extrait de configuration contenant nos emplacements de clé SSL et de fichier de certificat.
2. Nous créerons un extrait de configuration contenant des paramètres SSL solides qui pourront être utilisés avec tous les certificats à l’avenir.
3. Nous allons ajuster les blocs de serveur Nginx pour traiter les requêtes SSL et utiliser les deux extraits ci-dessus.

Cette méthode de configuration de Nginx nous permettra de conserver des blocs de serveurs propres et de mettre des segments de configuration courants dans des modules réutilisables.

Créer un fragment de configuration pointant vers la clé SSL et le certificat

Tout d’ abord, nous allons créer une nouvelle configuration Nginx dans le répertoire /etc/nginx/snippets. Pour bien distinguer le but de ce fichier, nous les appellerons ssl- suivie par notre nom de domaine, suivi par .conf:

sudo nano /etc/nginx/snippets/ssl-example.com.conf

Dans ce dossier, nous avons juste besoin de renseigner la directive  ssl_certificate  à notre fichier de certificat et le ssl_certificate_key à la clé associée. Dans notre cas, cela ressemblera à ceci:

ssl_certificate /etc/letsencrypt/live/example.com /fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Lorsque vous avez ajouté ces lignes, enregistrez et fermez le fichier.

Créer un fragment de configuration avec des paramètres de chiffrement fort

Ensuite, nous allons créer un autre extrait qui définira certains paramètres SSL. Cela configurera Nginx avec une solide suite de chiffrement SSL et activera certaines fonctionnalités avancées qui aideront à maintenir notre serveur sécurisé.

Les paramètres que nous définirons peuvent être réutilisés dans les configurations futures de Nginx, nous allons donner au fichier un nom générique :

sudo nano /etc/nginx/snippets/ssl-params.conf

Pour configurer Nginx avec SSL en toute sécurité, nous allons utiliser les recommandations de Remy van Elst sur le Cipherli.st site. Ce site est conçu pour fournir des paramètres de chiffrement faciles à consommer pour les logiciels populaires. Vous pouvez en savoir plus sur ses décisions concernant les choix Nginx ici .

Remarque: La valeur par défaut suggéré dans les paramètres sur Cipherli.st offrent une sécurité forte. Parfois, cela se fait au prix d’une plus grande compatibilité client. Si vous avez besoin de prendre en charge les clients plus vieux, il existe une liste alternative accessible en cliquant sur le lien «Oui, donnez-moi une suite de chiffrement qui fonctionne avec les anciens logiciels».

La liste de compatibilité peut être utilisée à la place des suggestions par défaut dans la configuration ci-dessous. Le choix de la configuration que vous utilisez dépendra en grande partie de ce que vous devez prendre en charge.

Pour nos besoins, nous pouvons copier les paramètres fournis dans leur intégralité. Il suffit de faire quelques petites modifications.

Tout d’abord, nous ajouterons notre résolveur DNS préféré pour les demandes en amont. Nous utiliserons Google dans ce guide. Nous allons également aller de l’avant et régler le paramètre ssl_dhparam  pour pointer vers le fichier Diffie-Hellman que  nous avons généré plus haut.

Enfin, vous devez prendre un moment pour lire  HTTP Strict Transport Security, ou HSTS et plus particulièrement au sujet de la fonctionnalité « de pré-chargement » . Le préchargement HSTS offre une sécurité accrue, mais peut avoir des conséquences de grande envergure s’il est activé accidentellement ou activé de manière incorrecte. Dans ce guide, nous ne préchargerons pas les paramètres, mais vous pouvez le modifier si vous êtes sûr que vous comprenez les implications :

# from https://cipherli.st/
# and https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
# Disable preloading HSTS for now.  You can use the commented out header line that includes
# the "preload" directive if you understand the implications.
#add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;

ssl_dhparam /etc/ssl/certs/dhparam.pem;

Enregistrez et fermez le fichier lorsque vous avez terminé.

Ajuster la configuration de Nginx à SSL

Maintenant que nous avons nos extraits, nous pouvons ajuster notre configuration Nginx pour activer SSL.

Nous supposerons dans ce guide que vous utilisez le default fichier de bloc de serveur dans le /etc/nginx/sites-available répertoire. Si vous utilisez un fichier de bloc de serveur différent, remplacez-le dans les commandes ci-dessous.

Avant d’aller plus loin, nous allons sauvegarder notre fichier de bloc serveur actuel:

sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/default.bak

Maintenant, ouvrez le fichier de bloc du serveur pour faire les ajustements:

sudo nano /etc/nginx/sites-available/default

À l’intérieur, votre bloc de serveur commence probablement comme ceci:

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    # SSL configuration

    # listen 443 ssl default_server;
    # listen [::]:443 ssl default_server;

    . . .

Nous allons modifier cette configuration afin que les demandes HTTP non chiffrées soient automatiquement redirigées vers HTTPS cryptés. Cela offre la meilleure sécurité pour nos sites. Si vous souhaitez autoriser le trafic HTTP et HTTPS, utilisez la configuration alternative qui suit.

Nous diviseront la configuration en deux blocs séparés. Après les deux premières listen directives, nous allons ajouter une server_name directive, défini sur le nom de domaine de votre serveur. Nous allons ensuite configurer une redirection vers le deuxième bloc serveur que nous allons créer. Ensuite, nous fermons ce court bloc:

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name example.com www.example.com;
    return 301 https://$server_name$request_uri;
}

    # SSL configuration

    # listen 443 ssl default_server;
    # listen [::]:443 ssl default_server;

    . . .

Ensuite, nous devons démarrer un nouveau bloc de serveur directement ci-dessous pour contenir la configuration restante. Nous pouvons dé-commenter les deux directives listen  qui utilisent le port 443. Nous pouvons ajouter http2 à ces lignes afin de permettre HTTP/2 dans ce bloc. Ensuite, il suffit d’inclure les deux fichiers d’extraits que nous avons mis en place:

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name example.com www.example.com;
    return 301 https://$server_name$request_uri;
}

server {

    # SSL configuration

    listen 443 ssl http2 default_server;
    listen [::]:443 ssl http2 default_server;
    include snippets/ssl-example.com.conf;
    include snippets/ssl-params.conf;

    . . .

Enregistrez et fermez le fichier lorsque vous avez terminé.

(Configuration alternative) Autoriser le trafic HTTP et HTTPS

Si vous voulez ou avez besoin d’autoriser à la fois le contenu chiffré et non chiffré, vous devez configurer Nginx un peu différemment. Ce n’est généralement pas recommandé si elle peut être évitée, mais dans certaines situations, il peut être nécessaire.

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    listen 443 ssl http2 default_server;
    listen [::]:443 ssl http2 default_server;

    server_name example.com www.example.com;
    include snippets/ssl-example.com.conf;
    include snippets/ssl-params.conf;

    . . .

Enregistrez et fermez le fichier lorsque vous avez terminé.

Étape 4: ajustez le pare-feu

HTTPS transitant par défaut sur le port 443 vous devez l’autoriser dans le pare-feu. si vous utilisez ufw, voici la démarche à suivre

sudo ufw allow 443

Étape 5: Activation des modifications de Nginx

Maintenant que nous avons apporté nos modifications et adapté notre pare-feu, nous pouvons redémarrer Nginx pour mettre en œuvre nos nouvelles modifications.

Tout d’abord, nous devrions vérifier pour s’assurer qu’il n’y a pas d’erreurs de syntaxe dans nos fichiers.Nous pouvons le faire en tapant:

sudo nginx -t

Si tout est réussi, vous obtiendrez un résultat qui ressemble à ceci:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Si votre résultat correspond à ce qui précède, votre fichier de configuration n’a aucune erreur de syntaxe.Nous pouvons redémarrer en toute sécurité Nginx pour mettre en œuvre nos modifications:

sudo systemctl restart nginx

Le certificat Let’s Encrypt TLS/SSL est maintenant en place et le pare-feu permet désormais le trafic vers le port 80 et 443. À ce stade, vous devez tester que le certificat TLS/SSL fonctionne en visitant votre domaine via HTTPS dans un navigateur Web.

Vous pouvez utiliser le rapport Qualys SSL Labs pour voir vos scores de configuration de serveur à l’adresse :

https://www.ssllabs.com/ssltest/analyze.html?d=example.com

Cette configuration SSL doit rapporter une note A +.

sudo letsencrypt renew

Processing /etc/letsencrypt/renewal/example.com.conf

The following certs are not due for renewal yet:
  /etc/letsencrypt/live/example.com/fullchain.pem (skipped)
No renewals were attempted.

sudo crontab -e

30 2 * * 1 /usr/bin/letsencrypt renew >> /var/log/le-renew.log
35 2 * * 1 /bin/systemctl reload nginx

Cet article est un traduction et adaptation d’un article paru sur DigitalOcean