Nginx on Jesuisadmin

WordOps - Déployer WordPress avec Nginx simplement

Sat, 18 May 2019 12:03:24 +0000

Pour automatiser le déploiement de mes serveurs avec Nginx, PHP, MariaDB et pour créer les vhosts Nginx, j’utilisais précédemment EasyEngine v3 - qui avait d’ailleurs fait l’objet d’un article. Le problème, c’est qu’EasyEngine n’était plus vraiment à jour. Et pour cause, ses développeurs (rtCamp) travaillaient sur une nouvelle mouture qui a été publiée fin novembre 2018, EasyEngine v4.

Malheureusement, cette nouvelle version développée en PHP qui utilise WP-CLI et Docker ne réponds pas vraiment à mes besoins, et ne laisse (à l’heure actuelle) que très peu de place à la customisation, aussi bien au niveau des configurations Nginx, que des paquets/containers utilisés.

N’y voyez pas un reproche à l’encontre de ses créateurs, puisque je comprends tout à fait le choix fait par l’équipe de rtCamp, et il me semble tout à fait normal que l’outil qu’ils développent soit avant tout adapté à leurs besoins. Il me paraît d’ailleurs important de souligner qu’ils mettent à disposition, gratuitement, avec une simple licence MIT, une application très complète et documentée, et ceux depuis déjà plusieurs années (la première version d’EasyEngine a été publiée en 2014).

Finalement, c’est en parcourant les articles du blog d’EasyEngine fin Décembre, que j’ai découvert qu’un fork de la version 3 d’EasyEngine baptisé WordOps était actuellement en développement et qu’une première pre-release était disponible sur Github.

Ayant contribué de mon mieux au projet EasyEngine v3 en publiant un certain nombre de scripts ainsi que la majorité de mes configurations Nginx, j’ai été contacté par l’équipe de WordOps que j’ai finalement intégré début Février.

Nous avons publié la première version “stable” de l’application début Mai et il était donc temps de rédiger un article pour vous présenter WordOps.

WordOps qu’est ce que c’est ?

C’est un outil en ligne de commande qui facilite l’administration d’un serveur et le déploiement de sites avec Nginx (notamment WordPress) en utilisant des commandes simples - faciles à mémoriser.

Quels sont les pré-requis pour installer WordOps ?

Du côté hardware, il n’y a pas vraiment de pré-requis, puisque l’application est développée en Python avec le framework Cement et ne nécessite que quelques mégaoctets d’espace disque pour le stockage des librairies.

Pour une utilisation en production, les services installés et configurés par WordOps tel que Nginx, PHP-FPM ou MariaDB, nécessitent un minimum de ressources pour fonctionner. Ce minimum peut varier en fonction du trafic des sites hébergés. C’est pourquoi nous conseillons d’installer WordOps sur un serveur disposant d’au moins 2Go de RAM et si possible d’un processeur multi-core (qu’ils soient virtuels ou non) pour garantir le bon fonctionnement des différents services déployés avec WordOps et donc la disponibilité des sites hébergés.

Par contre, si vous comptez utiliser WordOps pour du développement, il devrait normalement fonctionner sur n’importe qu’elle machine/VM disposant de 512mo de RAM ou plus.

Nous avons d’ailleurs ajouté depuis peu le support de la distribution Raspbian 9, qui permet donc l’installation sur Raspberry Pi (nos tests ont été réalisés sur le modèle 3B+).

Du côté software, les distributions linux supportées sont :

Ubuntu 16.04 LTS (Xenial)
Ubuntu 18.04 LTS (Bionic)
Ubuntu 19.04 (Disco)
Debian 8 (Jessie)
Debian 9 (Stretch)
Raspbian 9 (Stretch)

Quelles sont ses fonctionnalités ?

WordOps réalise non seulement l’installation et la configuration des paquets nécessaires au déploiement d’un site (Nginx, PHP, MariaDB) mais il s’occupe également de la création des vhosts Nginx, de la base de données, d’installer WordPress et même d’obtenir un certificat SSL Let’s Encrypt, le tout réalisable en une seule ligne de commande.

Dans le cas d’un site WordPress, vous disposez de plusieurs solutions de cache (optionelles) : Nginx fastcgi_cache, Redis (full page cache + object cache) ou WP-Super-Cache.

Enfin WordOps dispose d’un tableau de bord (que j’ai réalisé depuis un template bootstrap de Creative Tim et avec la suite de monitoring Netdata) qui permet à la fois de monitorer le serveur mais également d’accéder à des outils tel que PhpMyAdmin, Adminer, eXtplorer, phpRedisAdmin etc.. Une démo est disponible à l’adresse suivante : demo.wordops.eu.

Qu’est ce qu’il y a sous le capot ?

Nginx stable v1.16.1 (custom) avec le support du HTTP/2 HPACK de Cloudflare, de la compression avec Brotli, et des modules tiers tel que ngx_cache_purge ou ngx_vts
PHP 7.2 & PHP 7.3
MariaDB server 10.3
Redis 5.0
Netdata pour le monitoring
Acme.sh pour la gestion des certificats SSL Let’s Encrypt
WP-CLI pour le déploiement des sites WordPress

Et bien sûr, un ensemble de templates de configuration Nginx, qui ont pour objectif de délivrer les meilleures performances possibles ainsi qu’un niveau de sécurité optimale. Pour cela, WordOps utilise par exemple Nginx en tant que load-balancer pour répartir la charge sur les pools php-fpm en utilisant plusieurs unix sockets. On retrouve également un certain nombre de directives limitant l’accès et/ou l’exécution et le téléchargement de certains fichiers afin de bloquer les tentatives d’attaques régulièrement utilisées.

Installer WordOps

Un script pour automatiser l’installation de WordOps est bien sûr disponible, il s’exécute avec la commande suivante :

wget -qO wo wops.cc && sudo bash wo

Si vous souhaitez installer manuellement WordOps, un guide est disponible dans la documentation

Durant l’installation, WordOps vous demandera un nom d’utilisateur et une adresse email. Ces informations sont uniquement utilisées pour générer le fichier .gitconfig nécessaire au fonctionnement de git, qui est utilisé pour enregistrer les différentes configurations du serveur.

Commencer avec WordOps

Après avoir installé WordOps, la première étape est d’activer la complétion des commandes, il suffit pour cela d’utiliser la commande :

source /etc/bash_completion.d/wo_auto.rc

Nous pouvons donc commencer à utiliser les commandes WordOps, dont la structure est la suivante :

wo <commande> [options]

Vous souhaitez obtenir la liste des commandes disponibles ? Rien de plus simple, utilisez la commande :

wo

Vous pouvez également obtenir des informations sur chacune des sous-commandes en ajoutant les arguments -h ou --help.

Exemple :

wo site create -h

Installer les services (optionnel)

WordOps peut installer les services Nginx, PHP ou MySQL via la commande wo stack ou n’installer que les services nécessaires lors de la création d’un site avec la commande wo site create.

Si vous comptez utiliser WordOps pour héberger vos sites WordPress, il peut être intéressant de commencer par déployqer les services (Nginx, PHP 7.2, MariaDB) ainsi que les outils additionnels (phpMyAdmin, Adminer, OpcacheGui) qui seront disponibles dans le backend accessible via le port 22222 (exemple : https://IP.DU.SERVEUR:22222 ou https://serveur.hostname:22222).

Pour déployer les services, la commande à utiliser est :

wo stack install

Créer votre premier site

Que vous ayez suivi ou non l’étape précédente, vous pouvez créer votre premier site. La création de site se fait via la commande wo site create avec la structure suivante :

wo site create [<nom_de_domaine>] [type_de_site] [options] <options>

Pour vous donner un exemple relativement simple, nous allons créer un site WordPress, configuré avec PHP 7.3 et le système de cache nginx fastcgi_cache, sécurisé avec un certificat SSL Let’s Encrypt :

wo site create site.tld --wpfc --php73 --letsencrypt

Quelques points à retenir

par défaut et en l’absence de l’argument --php73, WordOps utilisera PHP 7.2
l’argument --wpfc définit le type de site, ici un site WordPress avec le système de cache Nginx fastcgi_cache. Vous pouvez découvrir tous les autres types de sites dans la documentation.
l’argument --letsencrypt est optionel et peut être utilisé avec n’importe quel type de site. Si le site que vous souhaitez créer est un sous-domaine, utilisez alors l’argument --letsencrypt=subdomain pour que WordOps n’essaye pas de générer un certificat SSL pour l’alias www.site.tld.

Voici un exemple qui présente le fonctionnement général de WordOps :

Contribuer

Comme pour la majorité des projets open-source, toute contribution est la bienvenue. Et il n’est pas nécessaire d’être un développeur ou un administrateur système pour contribuer.

Le simple fait de faire un signalement détaillé d’un bug dans l’application est une contribution au projet. Vous pouvez également participer à l’amélioration de la documentation de WordOps, qui peut facilement être éditée car elle est rédigée en markdown et hébergée dans un dépôt Github.

Si vous souhaitez contribuer directement au développement de WordOps, sachez que la rédaction d’un guide est en cours, avec un présentation détaillée des librairies utilisées et les règles à suivre notamment pour le style à appliquer au code (PEP8). Je mettrais à jour cet article dès que le guide sera publié sur le dépôt Github.

Les liens utiles

le site du projet : https://wordops.net
le dépôt Github : https://github.com/WordOps/WordOps
le forum : https://community.wordops.net/
la documentation : https://docs.wordops.net/
le compte twitter : https://twitter.com/WordOps_
le compte mastodon : https://mastodon.top/@WordOps

Installer Rocket.chat sur Ubuntu 18.04 LTS

Wed, 01 May 2019 16:21:00 +0000

Rocket.Chat est une plateforme de chat open-source et particulièrement complète. Vous pouvez aussi bien l’utiliser pour créer une chat-room, avec une gestion des utilisateurs et des permissions, que pour proposer un live chat via un widget sur votre site web.Cette plateforme est d’autant plus intéressante que vous pouvez la déployer en utilisant les “snaps” sur Ubuntu. Ainsi vous n’aurez pas besoin d’installer/configurer NodeJS ou MongoDB.

Installer Rocket.chat avec un snap

L’installation se fait via une seule ligne de commande :

sudo snap install rocketchat-server

Votre instance Rocket.Chat sera alors accessible à l’adresse : http://IP-de-VOTRE-SERVEUR:3000.

Mettre en place un reverse-proxy avec Nginx

Il est préférable de mettre en place un reverse-proxy pour accéder à l’interface de Rocket.Chat via un port standard et d’utiliser un certificat SSL pour sécuriser les échanges. Nous allons pour cela installer Nginx et générer un certificat SSL via Let’s Encrypt.

Commençons par installer Nginx :

apt update && apt install nginx

On créer ensuite notre vhost dans /etc/nginx/sites-available/ :

nano /etc/nginx/sites-available/chat.votredomaine.tld

Dont voici le contenu :

# redirection http vers https
server {
 listen 80;
 listen [::]:80;
 server_name chat.votredomaine.tld;
 return 301 https://chat.votredomaine.tld;
}

# Upstream
upstream backend {
 server 127.0.0.1:3000;
}

# HTTPS Server
server {
 server_name chat.votredomaine.tld;

 error_log /var/log/nginx/rocketchat.access.log;

 location / {
 proxy_pass http://backend/;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection "upgrade";
 proxy_set_header Host $http_host;

 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forward-Proto http;
 proxy_set_header X-Nginx-Proxy true;

 proxy_redirect off;
 }
 # permet de stocker la configuration ssl dans le répertoire du site
 include /var/www/votredomaine.tld/conf/nginx/*conf;
}

Pour activer ce vhost, on créer un lien symbolique vers le répertoire /etc/nginx/sites-enabled avec la commande :

ln -s /etc/nginx/sites-available/chat.votredomaine.tld /etc/nginx/sites-enabled/

Puis on relance Nginx :

service nginx reload

Obtenir un certificat SSL Let’s Encrypt avec acme.sh

Il ne nous reste plus qu’à générer le certificat via Let’s Encrypt, on installe donc acme.sh :

wget -O - https://get.acme.sh | sh
sudo source ~/.bashrc

Puis on génère le certificat pour notre sous-domaine.

acme.sh --issue -d chat.votredomaine.tld --pre-hook "systemctl stop nginx" --standalone --post-hook "systemctl start nginx" --ecc -k ec-384

On créer un répertoire pour stocker notre certificat :

mkdir -p /etc/letsencrypt/live/chat.votredomaine.tld

Puis on installe le certificat dans ce répertoire :

acme.sh --install-cert -d chat.votredomaine.tld --ecc \
--cert-file /etc/letsencrypt/live/chat.votredomaine.tld/cert.pem \
--key-file /etc/letsencrypt/live/chat.votredomaine.tld/key.pem \
--fullchain-file /etc/letsencrypt/live/chat.votredomaine.tld/fullchain.pem \
--ca-file /etc/letsencrypt/live/chat.votredomaine.tld/ca.pem \
--reloadcmd "systemctl restart nginx.service"

On termine en ajoutant le certificat SSL à notre configuration Nginx, pour cela nous allons créer le fichier /var/www/chat.votredomaine.tld/conf/nginx/ssl.conf qui sera automatiquement ajouté dans notre vhost grâce à la directive include /var/www/chat.votredomaine.tld/conf/nginx/*conf;. Voici son contenu:

 listen 443 ssl http2;
 listen [::]:443 ssl http2;
 ssl_certificate /etc/letsencrypt/live/chat.votredomaine.tld/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/chat.votredomaine.tld/key.pem;
 ssl_trusted_certificate /etc/letsencrypt/live/chat.votredomaine.tld/ca.pem;

La dernière étape pour pouvoir accéder à l’instance Rocket.Chat est d’appliquer la configuration avec la commande :

service nginx reload

Vous pourrez alors accéder à votre instance via l’adresse https://chat.votredomaine.tld. Pour accéder au panel d’administration de Rocket.chat, il vous faudra créer un premier compte utilisateur qui sera automatiquement définit en tant qu’administrateur.

Release Bell : ne ratez plus aucune publication de release sur Github

Wed, 24 Oct 2018 04:42:09 +0000

Lorsqu’on héberge un certain nombre d’applications “open-source”, il ~~est~~ était parfois difficile de suivre le flux de mises à jour des applications. Il s’agit heureusement d’une époque révolue, grâce à l’application Release Bell developpée par l’équipe de cloudron.io

Release-Bell est une application qui permet de recevoir une notification lorsqu’une nouvelle release est publiée sur Github parmi la liste des dépôts que vous avez “étoilé”. Elle est disponible via la plateforme de self-hosting cloudron que j’ai précédement présenté dans un article, mais elle peut également être installée manuellement sur n’importe quel serveur linux disposant de Nodejs et d’un serveur MySQL.

Les notifications sont envoyées par email, mais il n’est absolument pas obligatoire d’activer cette fonctionnalité. Dans mon cas, visualiser la liste des dépôts Github qui m’intéresse, sous la forme d’un flux chronologique suivant la date de publication des releases est largement suffisant.

Dans ce tutoriel, nous allons voir comment installer l’application Release-Bell sur un serveur Debian(8/9) ou Ubuntu (16.04 LTS/18.04 LTS).

Les prérequis

Comme je l’ai dis précédemment, pour installer Release-Bell, vous aurez besoin d’un reverse-proxy (Nginx dans ce tutoriel), de NodeJS (dont la version LTS actuelle est 8.x) et d’un serveur MySQL (ou MariaDB).

Nginx

Pour l’installation d’Nginx, rien de plus simple, sur Ubuntu ou Debian suffit d’utiliser :

sudo apt-get update && sudo apt-get install nginx -y

NodeJS

Pour NodeJS, c’est également relativement simple, puisqu’il suffit d’utiliser les commandes :

curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash
sudo apt-get install -y nodejs

MariaDB

Enfin pour le serveur MySQL (MariaDB server 10.3 dans ce tutoriel) :

# ajout du dépôt APT de MariaDB
sudo bash <(wget -qO - https://downloads.mariadb.com/MariaDB/mariadb_repo_setup) --mariadb-server-version=10.3 --skip-maxscale -y

# installation de MariaDB
sudo apt-get update && sudo apt-get install mariadb-server -y

Je vous recommande de placer les identifiants root du serveur MariaDB dans un fichier .my.cnf placé dans votre home pour pouvoir vous connecter via la commande mysql, sans avoir à copier/coller le mot de passe à chaque opération. Vous trouverez plus d’informations sur le sujet dans cet article de la KnowledgeBase de VirtuBox.

Il vous faudra créer une base de données avant de commencer l’installation de Release-Bell. Pour cela connecter vous en tant que root à votre serveur MariaDB :

mysql

puis créez une nouvelle base de données :

CREATE DATABASE releasebell;

Ajouter ensuite un utilisateur avec les permissions nécessaires pour utiliser cette base de données :

GRANT ALL ON releasebell.* TO 'utilisateur_releasebell'@'localhost' IDENTIFIED BY 'motdepasse';

Terminez en flushant les privilèges pour appliquer les modifications

FLUSH PRIVILEGES;

Puis quittez l’interface en ligne de commande de MySQL :

EXIT;

Installer Release-Bell

Certaines étapes de l’installation de Release-Bell sont peut-être incomplètes ou différentes de la méthode utilisée par Cloudron. La documentation disponible sur le dépôt de l’application étant minimaliste, j’ai utilisé les mêmes étapes d’installation que d’autres applications NodeJS.

Pour installer Release-Bell, créer un nouvel utilisateur, de préférence sans mot de passe ou login afin d’éviter un éventuel accès non désiré via cet utilisateur :

Mise en place de l’application NodeJS

adduser --disabled-password --disabled-login releasebell

Puis connecter vous en tant que cet utilisateur :

sudo su - releasebell

Créez un répertoire pour héberger l’application :

mkdir releasebell

Puis téléchargez l’application avant de extraire de son archive :

curl -L https://git.cloudron.io/cloudron/releasebell/-/archive/v1.1.0/releasebell-v1.1.0.tar.gz \
| tar zxf - --strip-components 1 -C ./releasebell

Allez dans le répertoire de l’application :

cd releasebell

Et installer des dépendances NodeJS :

npm install

Importation de la structure de la base de données

Le structure de la base de donnéees de releasebell est stockée dans le dossier migrations de l’application. Pour l’importer il suffit donc d’utiliser :

mysql -u utilisateur_releasebell -p releasebell < migrations/initial-schema.sql

Configurer Release-Bell

La configuration de l’application repose sur deux fichiers, il s’agit de database.json utilisé pour la configuration de la base de données MySQL, et users.json pour les identifiants des utilisateurs de l’application.

Il faut tout d’abord définir les paramètres d’accès à la base de données dans le fichier database.json, qui doit ressembler à l’exemple suivant :

{
 "defaultEnv": "local",
 "local": {
 "host": "localhost",
 "user": "utilisateur_releasebell",
 "password": "motdepasse",
 "database": "releasebell",
 "driver": "mysql",
 "multipleStatements": true
 }
 }

S’il n’existe pas encore, créez le fichier users.json dont le contenu doit ressembler à l’exemple suivant :

[
 {
 "username": "votre_nom_dutilisateur",
 "password": "motdepasse",
 "email": "test@example.com"
 }
]

La configuration de l’application est désormais terminée, l’application peut-être lancée avec la commande :

node index.js

Ajouter un service systemd pour Release-Bell

Vous souhaitez peut-être pouvoir utiliser l’application sans avoir à laisser un terminal ouvert indéfiniment. Pour cela le plus simple sur Debian/Ubuntu est d’ajouter un service systemd pour notre application. On y définira notamment certaines variables nécessaires à la configuration de l’application.

Pour ajouter un service, nous allons créer un ficher .service dans la répertoire /lib/systemd/system/

sudo nano /lib/systemd/system/release_bell.service

Le contenu de ce ficher de configuration doit ressembler à ceci (il vous faudra l’adapter avec vos informations) :

[Unit]
Description=ReleaseBell

[Service]
Type=simple
WorkingDirectory=/home/utilisateur_releasebell/releasebell
User=utilisateur_releasebell
Environment="NODE_ENV=production"
Environment="MAIL_SMTP_SERVER=smtp.example.com"
Environment="MAIL_SMTP_PORT=25"
Environment="MAIL_SMTP_USERNAME=releasebell@example.com"
Environment="MAIL_SMTP_PASSWORD=MotdepasseSMTP"
Environment="MAIL_FROM=releasebell@example.com"
Environment="MAIL_DOMAIN=example.com"
Environment="APP_ORIGIN=example.com"
ExecStart=/usr/bin/node index.js
Restart=always

[Install]
WantedBy=multi-user.target

Activez le service release_bell avec la commande :

sudo systemctl enable release_bell.service

Vous pouvez enfin démarrer le service avec la commande :

sudo service release_bell start

Configurer Nginx

Pour terminer ce tutoriel, voici un exemple de configuration pour utiliser Nginx en tant que reverse-proxy pour notre application :

server {


 server_name release.yourdomain.tld


 access_log /var/log/nginx/release.yourdomain.tld.access.log rt_cache;
 error_log /var/log/nginx/release.yourdomain.tld.error.log;


 location / {
 proxy_pass http://127.0.0.1:3000;
 proxy_redirect off;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 }

}

Je ne vais pas m’étendre sur cette partie de la configuration, mais je vous invite à jeter un oeil à mon article Installer un certificat SSL Let’s Encrypt avec acme.sh si vous souhaitez générer un certificat SSL pour sécuriser l’accès à l’application Release-Bell.

Comment avoir une excellente configuration HTTPS en 2017 ?

Fri, 13 Oct 2017 00:05:47 +0000

Article écrit par Wonderfall. Suite à la fermeture de son blog, j’ai souhaité (avec son accord) remettre en ligne ce dernier pour que son contenu reste accessible.

Cet article est adressé principalement aux administrateurs système, ou devrais-je plutôt dire aux administrateurs de système puisque parmi vous il y a non seulement des personnes qui en ont fait leur métier, et d’autres personnes qui en font leur passion (comme moi, peut-être…). Par manque de temps et surtout parce que je parlerai des outils sur lesquels j’ai mis la main, j’utiliserai un seul serveur web au cours de cet article, le bien connu nginx. Cet article reprendra en partie un ancien article de mon précédent blog : Des certificats ECDSA avec Let’s Encrypt.

1. Mettons les choses en ordre…

Jetez un coup d’oeil à l’image d’en-tête de l’article. Vous vous y reconnaitrez peut-être. Ou peut-être pas. Certains parmi vous sont complètement perdus, et ces noms ne leurs évoqueront rien. D’autres sont déjà à l’aise, savent grossièrement à quoi cela correspond. Eh bien, j’en fais moi-même partie. Dans un esprit d’humilité, je reconnais ne pas avoir les capacités nécessaires pour comprendre à 100% les notions conceptuelles, mathématiques, et toutes les subtilités derrière les technologies que je mentionnerai. Cela dit, ça ne m’empêchera pas de tenter, au moins, de vulgariser et de montrer des exemples. Ma vulgarisation sera approximative, elle comportera peut-être des erreurs, je l’admets. Mais tant que j’estime ne pas mettre en danger la sécurité des personnes (au contraire…), et tant que vous avez compris ce que je voulais dire dans ce paragraphe, je me sens libre de continuer à écrire cet article.

Ce qui m’a poussé à le faire, c’est que le nombre de demandes d’aide à propos de la configuration HTTPS est devenu croissant. Vous vous souvenez de Mastodon ? Aujourd’hui le nombre d’instances est bien plus important, et plus d’instances, ça veut dire aussi plus de configurations. Le principal site qui recense les différentes instances classe désormais les instances en fonction de leur configuration HTTPS, à travers Cryptcheck et depuis peu l’Observatoire Mozilla (qui comprend Cryptcheck également puisqu’il fait appel à des tests tiers). Évidemment, c’est la folie : tout le monde veut absolument avoir son instance le plus haut possible dans la liste, donc il faut à tout prix mieux sécuriser… si seulement c’était le cas pour les banques aussi, mais passons.

Et puis, certains iraient bien se masturber un coup sur un A+ de Cryptcheck/Qualys. Mais, pourquoi pas ? Ces questions ne me concernent pas. On atteindra cette finalité si c’est ce que vous voulez, vos motivations sont les vôtres. Quand je parle d’une excellente configuration, c’est effectivement une configuration qui vous donnera une note maximale sur ces outils. Dans le titre, je n’ai pas parlé de “comment configurer HTTPS”, nuance. Mais il ne faut pas non plus suivre mon tutoriel n’importe comment, parce que premièrement, la compatibilité des clients en prend forcément un coup, et deuxièmement, certains mécanismes tels que HPKP peuvent vous casser la gueule si vous les utilisez n’importe comment. Lisez, puis faites. Pas l’inverse…

D’avance, j’annonce que je ne me prendrai pas la tête avec la compatibilité. Donc ne venez pas me dire que votre site ne fonctionne pas sur X ou Y, parce que je vous aurais prévenu.

2. Choix de la bibliothèque SSL/TLS

Les bibliothèques SSL/TLS fournissent une implémentation d’algorithmes cryptographiques et de protocoles de communication sécurisés (les différentes versions de SSL et TLS : SSLv2, SSLv3, TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3..). Aujourd’hui, 3 bibliothèques sont compatibles avec nginx :

OpenSSL : la plus connue, et la plus présente.
LibreSSL : fork d’OpenSSL par OpenBSD.
BoringSSL : fork d’OpenSSL par Google.

Il faut dire que Heartbleed a porté en 2014 un coup à la popularité d’OpenSSL. Non pas que ce fut la première faille découverte, loin de là, mais il y a eu une prise de conscience sur la qualité du code d’OpenSSL et des implémentations trop anciennes qui y sont présentes. OpenBSD fidèle à sa réputation, créa son fork LibreSSL dans le but de littéralement nettoyer OpenSSL et de le débarrasser d’algorithmes dépassés et dangereux d’utilisation. Aujourd’hui, il n’y a pas seulement OpenBSD qui utilise LibreSSL à la place d’OpenSSL en tant que bibliothèque par défaut du système. En effet, d’autres distributions ont sauté le pas, y compris macOS.

Quant à Google, ce n’est pas vraiment la même raison qui a conduit à créer BoringSSL. En effet, ils maintenaient déjà une version d’OpenSSL interne avec de nombreux patchs, Heartbleed a seulement été l’élément déclencheur pour repartir d’une page blanche, et c’est bien ce travail qui a été mené. Peu importe si les mises à jour cassent la compatibilité API/ABI avec d’autres logiciels comme nginx, Google met de toute façon en garde :

EN : Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don’t recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.

FR : Bien que BoringSSL soit un projet open-source, il n’est pas destiné à un usage général, comme OpenSSL l’est. Nous ne recommandons pas que les tierces parties dépendent dessus. Faire ainsi sera probablement source de frustrations puisqu’il n’y aucune garantie de la stabilité de l’API/ABI.

En pratique, BoringSSL fonctionne avec nginx et les développeurs ont accepté de faire quelques efforts pour satisfaire les quelques curieux qui souhaitent l’utiliser de cette façon. En revanche, pas de support de OCSP stapling.

En pratique, qu’est-ce que je dois choisir ?

Utiliser la bibliothèque de son système est une bonne chose car les mises à jour sont simples, donc il n’est pas nécessaire de recompiler nginx à chaque fois. Sur Debian, ça reste pour le moment OpenSSL. La version de Jessie est maintenue, mais elle est figée du point de vue technologique, donc en pratique, on aura pas quelques algorithmes récents (même si on peut s’en passer) et quelques features intéressantes compatibles avec nginx, mais nécessitant une version d’OpenSSL supérieure. La version d’OpenSSL fournie par Stretch (1.1.0) est aujourd’hui la version la plus récente d’OpenSSL.

Si vous êtes prêts à ne pas utiliser une bibliothèque système, je vous recommande sans hésiter LibreSSL, pour les raisons que j’ai énoncées plus haut. OpenBSD est une équipe de confiance, vraiment (et même un peu trop) perfectionniste. BoringSSL est celui qui vous proposera le plus de nouveautés, dont l’utilisation des versions drafts de TLS 1.3, des expérimentations d’algorithmes quantum proofs qui peuvent être retirées du jour au lendemain par Google (comme CECPQ1), etc. mais de mon point de vue, ce n’est vraiment pas quelque chose à utiliser sur une machine en production, il n’y a même pas de versioning, à utiliser plus pour la curiosité donc.

Si vous avez fait le choix d’utiliser une autre bibliothèque que la bibliothèque utilisée par défaut par le système, vous allez devoir recompiler nginx. Inutile que je passe mon temps à faire un tutoriel, il y en a… plein : ici (2015) pour LibreSSL, là (2016) pour BoringSSL (je me fais un peu de publicité, je sais). Mais si vous ne voulez pas vous prendre la tête, je vous propose des scripts voire des images Docker :

Angristan/nginx-autoinstall : compile nginx sur Debian, avec le choix entre OpenSSL et LibreSSL et d’autres modules !
wonderfall/boring-nginx : une image Docker basée sur Alpine Linux, avec nginx compilé depuis les sources avec BoringSSL.
xataz/nginx : une image Docker basée sur Alpine Linux qui installe simplement nginx, mais Alpine Linux utilise LibreSSL par défaut.
ajhaydock/BoringNginx : des scripts pour Debian/CentOS et une image Docker basée sur CentOS pour utiliser nginx avec BoringSSL.

3. D’abord, les certificats !

a. Savoir (un peu) de quoi on parle

Inutile de s’attaquer à la configuration d’HTTPS sans passer par la génération de certificats. Mais d’abord, pourquoi parle-t-on de certificats ? Deux mots pour décrire les buts d’HTTPS : chiffrement et authenticité. Ce dernier point repose sur la certification de la clé publique avec un certificat (d’un certain format nommé X.509) signé par une autorité connue (CA pour Certificate Authority). L’ensemble des composantes visant à gérer le cycle de vie des certificats porte le nom de Public Key Infrastructure (PKI). Les certificats définissent les informations d’appartenance de la clé publique, et définissent également les hostnames pour lesquels le certificat est valide. Par exemple, le certificat que j’utilise pour psychedeli.cat est aussi valable pour isso.psychedeli.cat (un sous-domaine). Ces informations, vous pouvez les obtenir très simplement depuis votre navigateur qui lit ces informations depuis le certificat fourni par le serveur web.

Voyez l’illustration comme un arbre, on part de la racine (= root), on passe par les branches ramifiées (certificats intermédiaires) et enfin on atteint les feuilles (= leaf)

Nous allons ici utiliser Let’s Encrypt, qui est comme je vous l’ai dit une autorité de certification. Le principe est celui d’une chaîne de confiance : le certificat root (fourni ici par ISRG) est le certificat originel, qui peut signer des certificats intermédiaires (ceux de Let’s Encrypt). Ces certificats intermédiaires permettront de signer les certificats que nous utilisons tous les jours, qu’on appelle aussi leaf certificate, ils permettront de signer des clés temporaires dérivées de la paire clé publique/privée qui sera utilisée pour sécuriser une session. Ces certificats sont en fin de chaîne et ce sont eux que nous allons obtenir.

b. Générer des certificats ECDSA (P-384)

Plus précisément, on va le faire d’une façon un peu plus manuelle mais loin d’être difficile. Cela nous permettra :

De gérer nous-même le renouvellement de la paire de clés, ce qui nous permet d’utiliser plus sereinement et efficacement HPKP.
D’utiliser une autre approche d’algorithme asymétrique que RSA, ECDSA qui repose donc sur la cryptographie sur les courbes elliptiques (ECC).

Les algorithmes de la famille des courbes elliptiques proposent d’utiliser des clés bien plus courtes, pour une sécurité comparable à celle offerte par RSA, et ils permettent également d’économiser des ressources. Voici des tests de performance que j’ai réalisés avec ma machine :

$ openssl speed rsa
 sign verify sign/s verify/s
rsa 2048 bits 0.000549s 0.000025s 1821.4 39636.0
rsa 3072 bits 0.002579s 0.000051s 387.7 19471.4
rsa 4096 bits 0.005829s 0.000089s 171.5 11270.1

$ openssl speed ecdsa
 sign verify sign/s verify/s
 256 bit ecdsa (nistp256) 0.0000s 0.0001s 25425.7 10819.8
 384 bit ecdsa (nistp384) 0.0002s 0.0007s 5749.2 1340.1
 521 bit ecdsa (nistp521) 0.0003s 0.0006s 3007.0 1659.5

ECDSA en soit n’est pas directement comparable à RSA, il doit être associé à des courbes elliptiques, et ici, ce sont les courbes NIST P-256, P-384, et P-521, qui sont utilisées. Le nombre de signatures/secondes est tout simplement bien meilleur avec ECDSA. Quid de la sécurité ? Selon la NSA elle-même, une clé ECC de taille 384 bits offrirait une sécurité équivalente à une clé RSA de taille 7680 bits.

Depuis Février 2016, Let’s Encrypt peut émettre des certificats ECDSA (les choix sont P-256 et P-384). Malheureusement, le client officiel certbot ne le permet pas. Alors soit on peut utiliser d’autres clients comme lego qui vont mâcher le travail, soit on peut toujours utiliser certbot mais se débrouiller nous-même pour générer notre clé privée et notre demande de signature de certificat (dans un fichier CSR).

Commençons par générer une clé privée P-384 :

openssl ecparam -genkey -name secp384r1 > privkey.pem

On peut maintenant créer un fichier CSR, qui contient toutes les informations relatives à une demande de certificat. Comme moi, vous aurez peut-être envie de générer un seul certificat pour plusieurs domaines, ceci peut se faire avec l’extension SAN de X.509. Vous devez tout d’abord copier le fichier /etc/ssl/openssl.cnf dans votre répertoire de travail. Par exemple :

cp /etc/ssl/openssl.cnf custom.cnf

On va modifier ce custom.cnf pour bénéficier de SAN et donc d’un certificat valable, en gros, pour plusieurs domaines. Voici comment. Dans la section [ req ], décommettez req_extensions = v3_req. Dans la section [ v3_req ], ajoutez une nouvelle ligne : subjectAltName = @alt_names. Enfin, tout se passe dans [ alt_names ] pour ajouter vos domaines. Cette section n’existe pas, il faut la créer, par exemple tout à la fin du fichier.

# custom.cnf

...

[ req ]
...
req_extensions = v3_req

...

[ v3_req ]
...
subjectAltName = @alt_names
### OCSP Must-Staple, cf. plus loin
#tlsfeature = status_request # OpenSSL >=1.1.0
#1.3.6.1.5.5.7.1.24 = DER:30:03:02:01:05 # OpenSSL <=1.0

...

[ alt_names ]
DNS.1 = domain.tld
DNS.2 = sub1.domain.tld
DNS.3 = sub2.domain.tld
...
DNS.n = subn.domain.tld

Pour chaque domaine souhaité, on l’associe à la directive DNS.k où k, allant de 1 à n, est incrémenté sur chaque nouvelle ligne. Le SAN que peut signer Let’s Encrypt peut atteindre 100 (autrement dit, 100 domaines différents dans un seul certificat X.509), donc n <= 100.

Enregistrez toutes ces modifications. Vous pouvez désormais générer votre CSR avec la commande suivante :

openssl req -new -sha256 -key privkey.pem -out csr.der -config custom.cnf

Rentrez des informations, mais laissez Common Name vide, et ne protégez pas avec un mot de passe. Vous devez, à ce stade, avoir en votre possession un privkey.pem et un csr.der.

Pour demander à Let’s Encrypt de nous émettre un certificat à partir de notre demande, il suffit d’utiliser certbot de cette façon, avec l’argument --csr pour fournir le CSR :

certbot certonly --standalone --agree-tos -m admin@domain.tld \
 --csr /path/to/csr.der \
 --cert-path /path/to/cert.pem \
 --chain-path /path/to/chain.pem \
 --fullchain-path /path/to/fullchain.pem

Congrats! Vous avez ainsi obtenu :

cert.pem : leaf certificate, contient entre autres la clé publique
chain.pem : certificat de la chaîne Let’s Encrypt
fullchain.pem : concaténation des deux fichiers ci-dessus
privkey.pem : clé privée qu’on avait générée tout à l’heure

DNS CAA : N’oubliez pas d’ajouter des enregistrements CAA dans votre zone DNS, ils permettent de définir quel CA est autorisé à émettre un certificat pour le domaine domain.tld. Exemple pour ce domaine avec Let’s Encrypt :

domain.tld. CAA 0 issue "letsencrypt.org"
domain.tld. CAA 0 iodef "mailto:admin@domain.tld"

4. Le protocole SSL/TLS

Je vous recommande la lecture de cet article : CryptCheck, vérifiez vos implémentations de TLS.

TLS et son ancêtre SSL sont des protocoles qui sont utilisés pour sécuriser des échanges sur Internet. Par exemple conjointement avec HTTP pour donner HTTPS, le joli cadenas vert que vous avez dans votre barre d’adresse et qui ne veut pas dire grand chose parfois. Ils sont utilisés pour l’intégrité, l’authentification, la confidentialité (chiffrement), etc.

Aujourd’hui, la compatibilité de TLS 1.2 est répandue et il s’agit de la dernière version datant de 2008. TLS 1.0 (quoique…) et 1.1 peuvent être activés en cas de besoin de compatibilité. Pour cet article je ne vais garder que TLS 1.2. Il est par contre hors de question d’utiliser SSL. SSLv3 c’est poubelle (POODLE), SSLv2 c’est poubelle aussi (DROWN). D’ailleurs j’en profite : arrêtez de véhiculer cet abus de langage comme quoi SSL/TLS = SSL. J’aurais d’ailleurs trouvé ça appréciable si LibreSSL s’appelait plutôt LibreTLS, bref.

Donc on configure nginx pour n’accepter que TLS 1.2 :

ssl_protocols TLSv1.2;

TLS 1.3 arrivera incessamment sous peu, à l’heure où j’écrit cet article la 19e draft est encore très récente. OpenSSL 1.1.0 aura droit à TLS 1.3, tout comme LibreSSL qui devrait suivre. BoringSSL propose déjà TLS 1.3, j’ai testé et ça fonctionne même s’il faut l’activer de force. Cela dit je ne peux pas vraiment recommander d’utiliser un protocole au stade de brouillon et dont l’implémentation est encore trop jeune.

Histoire de faire une transition avec la partie suivante : avec TLS, tout commence par un handshake entre le client et le serveur. Le client envoie au serveur un message ClientHello avec une liste de suites cryptographiques supportées et de protocoles (par exemple pour HTTP/2). Le serveur renvoie à son tour un ServerHello avec entre autres, le choix de la suite cryptographique pour la session.

5. La suite cryptographique

Vous auriez déjà dû entendre parler du terme cipher. Cela désigne pour ceux qui ne le savent pas un algorithme qui chiffre et déchiffre, c’est une notion simple et cela existe depuis l’antiquité en fait, puisque ce sont les débuts même de la cryptographie. Mais avant que les 2 parties (ici, le serveur et le client) ne puissent chiffrer/déchiffrer leurs communications (par exemple du chiffrement par bloc avec un algorithme de cryptographie symétrique comme AES), il faut que les deux s’échangent une clé temporaire qui a été dérivée de la paire de clés du certificat, pour une session. Donc la question est de le faire d’une façon sécurisée à travers Internet, et éviter à tout prix les attaques MiTM.

a. L’échange de clés

Pour cela, on préfère l’échange de clés Diffie-Hellman (DH) car il y a la propriété de confidentialité persistante (Forward Secrecy FS ou Perfect Forward Secrecy PFS) : si la clé privée à partir de laquelle les clés de session ont été dérivés est compromise dans le futur, les clés de session utilisées précédemment pour des communications passées ne seront pas compromises. On pourrait en parler mathématiquement, mais là n’est pas vraiment le sujet, des personnes plus compétentes en parleront mieux que moi.

Avec TLS, on utilise DHE (Diffie-Hellman Exchange) ou ECDHE (Elliptic Curve Diffie-Hellman Exchange), ECDHE étant une variante de DHE. Sans rentrer dans les détails, la différence est dans la génération des clés : pour ce faire, DHE repose sur de l’algorithmique modulaire (simple), tandis que ECDHE repose sur le problème mathématique des courbes elliptiques (algébriques). Ces courbes (NIST, Brainpool, X25519…) ont les bénéfices que nous avons en partie évoqué plus haut.

De mon côté, je vous recommande carrément de n’utiliser que ECDHE pour l’échange de clés. Si vous voulez continuer à utiliser DHE, générez au moins une bonne clé de taille 4096 bits. Souvenez-vous des conséquences d’une clé trop petite, je parle bien sûr de Logjam. DHE souffre également d’un autre problème qui consiste en une MiTM assez violente : il est possible de downgrade vers une suite EXPORT dès que le serveur la supporte, et même si le client ne la supporte pas (merci @aeris pour cette remarque). Je persiste, utilisez donc seulement ECDHE, c’est très bien et dans la continuité de cet article. Et il n’y a rien de plus simple pour nginx puisqu’il suffit de jouer avec la directive ssl_ecdh_curve.

On peut ne pas renseigner cette directive, c’est possible, et dans ce cas le client et le serveur se mettront d’accord comme des grands sur la courbe à utiliser. Avec des versions de nginx relativement récentes (1.11+) et OpenSSL 1.1.0+ / LibreSSL / BoringSSL, il est possible de définir, côté serveur, un ordre de préférence. De mon côté, je préfère le faire (et si vous ne pouvez pas préciser plusieurs courbes, ne pas renseigner la directive est plus sage, sinon vous pouvez utiliser P-384 seulement) :

ssl_ecdh_curve X25519:P-521:P-384;
# ssl_ecdh_curve secp521r1:secp384r1; # Autres noms
# ssl_ecdh_curve secp384r1; # Si nginx pas récent

Petite aparté sur X25519 : cette courbe elliptique est le fruit des recherches du Dr. Bernstein. Comme indiqué sur ce site, la sécurité offerte par les courbes NIST n’est pas parfaite et mathématiquement douteuse. X25519 est “meilleur”, et en plus, il ne vient pas d’une agence proche de la NSA qui a tout intérêt à rendre la cryptanalyse des courbes NIST plus avantageuse pour elle.

X25519 n’étant disponible que sur des versions récentes de Chromium, il faut accepter d’autres courbes pour supporter par exemple Firefox et d’autres plateformes : P-521 et P-384, c’est très bien aussi. Ajoutez P-256 si la compatibilité est vraiment un problème.

b. Le chiffrement des données

Maintenant que la clé temporaire de session a été communiquée de façon sécurisée grâce à ECDH au client, ce dernier et le serveur peuvent échanger dans un canal chiffré dans une configuration symétrique, d’où l’utilisation d’algorithmes symétriques comme AES. C’est aujourd’hui le plus éprouvé. RC4, DES, 3DES… sont à bannir. Des chatons meurent à chaque fois que ces algorithmes sont utilisées. En 2017, on utilise normalement AES.

AES faisant du chiffrement par bloc, on introduit deux notions :

Le mode d’opération des blocs : CCM, CBC, GCM…
La taille des clés utilisées : 128, 256…

TLS 1.2 standardise notamment des suites cryptographiques qui reposent sur AES-CBC et AES-GCM, avec des clés 128 et 256 bits. Le mode GCM est nettement préférable à CBC. Pourquoi ? Dans le mode CBC, on utilise la fonction XOR (disjonction exclusive) avec un bloc de données en clair et un vecteur d’initialisation (IV), ensuite la sortie de XOR est chiffrée avec notre clé symétrique. Le mode GCM diffère de par son fonctionnement : un compteur pour chaque bloc est chiffré par la clé symétrique (dans le Corps de Galois), puis on utilise la fonction XOR avec la sortie obtenue et le bloc de données en clair : le bloc chiffré est formé ainsi. Pour ne pas aller plus loin dans les détails même si ce sont de grands mots qui peuvent faire peur, le fonctionnement inhérent de GCM est plus sécurisé que celui de CBC. Il est aussi très rapide. CBC est vulnérable aux attaques padding oracle.

Ne faites pas une erreur tentante : Qualys ne vous mettra pas du 100/100 partout si vous avez le malheur d’utiliser AES avec une clé 128 bits, même AES GCM. Donc certains vont forcer AES avec une clé 256 bits, mode GCM et CBC, parce que AES-256-GCM n’est pas forcément très bien supporté partout encore. C’est une fausse bonne idée ! AES-128-GCM est très bien, et quoiqu’il arrive, il faut privilégier GCM à CBC. C’est le comportement de la suite EECDH+AES par défaut, inutile d’en préciser plus. Pour utiliser GCM seulement, ce que je fais, vous pouvez utiliser EECDH+AESGCM.

ChaCha20 est un autre algorithme symétrique, qui a un fonctionnement intrinsèquement différent puisqu’il fonctionne par flot et non par blocs (comme RC4). C’est une alternative à AES proposée par le Dr. Bernstein encore une fois. Bien que la cryptanalyse faite sur ChaCha20 ne soit pas aussi importante qu’avec AES, on le considère comme sûr, et de toute façon, avoir une alternative est toujours une bonne chose (et le monopole cryptographique n’étant pas idéal de toute façon…). Il est moins rapide que AES sur des CPU qui disposent des instructions AES-NI, c’est-à-dire presque tous les CPU x86_64 actuels si je ne me trompe pas. Mais ChaCha20 offre des performances remarquables et se défend bien, si bien qu’il est préféré à AES quand on est sur des SoC ARM par exemple.

ChaCha20 est combiné à Poly1305, un type de code d’authentification de message (MAC) assurant l’intégrité des données, alors qu’on combine AES-GCM à HMAC-SHA2 par exemple. La qualité du HMAC dépendant de la fonction de hashage utilisée, je préfère ne pas utiliser SHA1 (et il est hors de question d’utiliser MD5), mais s’en séparer convient de faire une croix sur la compatibilité avec certains clients encore une fois. Pour continuer l’analogie entre ChaCha20 et AES, est-ce que Poly1305 est mieux que HMAC-SHA2 ? C’est différent, et c’est bien d’avoir le choix. Il y a certainement des subtilités qui feront pencher les cryptographes d’un côté plus que l’autre… De mon côté, je préfère même mettre ChaCha20+Poly1305 en tête de liste parce que je préfère Docteur Bernstein. Mais il ne faut pas basher AES non plus : bien qu’il ait vu le jour lors du concours NIST au début des années 2000, les critères autour de sa création sont rigoureusement transparents. Tout ce dont on peut être sûr c’est que la NSA par exemple a eu le temps de faire sa cryptanalyse.

Donc la configuration que je propose est la suivante :

ssl_ciphers EECDH+CHACHA20:EECDH+AESGCM;

Restrictive, certes. Mais il ne devrait pas y avoir de soucis avec des clients modernes. Chrome et Firefox supportent déjà ChaCha20+Poly1305. AES-GCM fera l’affaire pour Edge, Safari (jusqu’à la version incluse dans Yosemite, mais n’oubliez pas que Mavericks a le droit à des updates majeures de Safari par exemple), et Android jusqu’à KitKat.

Bonus si vous utilisez BoringSSL : vous pouvez définir des groupes de suites cryptographiques équivalentes. Au sein d’un même groupe, vous laissez le client choisir selon son ordre à lui. Cela peut-être utile si vous voulez utiliser AES sur votre PC, mais ChaCha20 sur votre smartphone ARM, par exemple. Le groupe est défini entre crochets [] et avec une barre verticale pipe | entre chaque ciphersuite, ça donnerait ceci :

ssl_ciphers [EECDH+CHACHA20|EECDH+AESGCM];

6. HTTP Strict Transport Security

HSTS est un mécanisme de sécurité qui consiste à indiquer par un header envoyé au client qu’il doit communiquer, pour un domaine donné, avec le serveur web par une connexion sécurisée HTTPS uniquement. L’intérêt est évident, car si HSTS est actif, le client est protégé de diverses attaques réseau et d’une MiTM. Mais je n’ai pas mis le précédent “si” en gras pour rien, en effet si HSTS n’a jamais été actif ou ne l’est plus, HSTS ne peut plus plus offrir cette sécurité. C’est pour cela qu’a été inventé le mécanisme de HSTS Preloading, qui consiste en des listes préchargées et intégrées aux navigateurs pour indiquer la politique HSTS utilisée pour un domaine ; en quelque sorte, HSTS est déjà actif avant même que vous n’ayez visité le site.

Pour utiliser HSTS, il faut utiliser :

Le header Strict-Transport-Security.
max-age : durée d’activité une fois actif (recommandé : 6 mois+)
includeSubDomains : protéger tous les sous-domaines.
preload : activer HSTS preloading.

De mon côté, je vais mettre max-age à 1 an soit 31536000 secondes. J’activerai HSTS preloading, et j’indiquerai de protéger tous les sous-domaines, soyez sûr que vous souhaitez faire de même :

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";

Pour s’inscrire à la liste préchargée, il faut aller inscrire son domaine ici. La propagation peut prendre plusieurs semaines. Attention, HSTS Preload n’est pas là pour remplacer la redirection 301 vers HTTPS depuis HTTP.

7. OCSP Stapling et OCSP Must-Staple

OCSP Stapling est une alternative au protocole OCSP qui consiste à vérifier auprès de l’autorité de certification la validité du certificat. Avec OCSP, c’est le client lui-même qui fait cette démarche de vérification auprès du CA ; tandis qu’avec OCSP Stapling, c’est le serveur qui fait cette tâche et qui envoie la réponse OCSP au début de l’échange TLS. Bien que ce soit discuté d’un point de vue sécurité, les gains apportés par OCSP Stapling pour la vie privée sont non-négligeables, il est donc préférable de l’activer. Voyons comment cela se configure avec nginx, d’abord les paramètres OCSP Stapling à proprement parler :

ssl_stapling on;
ssl_stapling_verify on;
resolver 213.133.98.98 213.133.99.99 valid=300s;
resolver_timeout 5s;

Les deux premières lignes activeront OCSP Stapling. Mais il faut fournir un résolveur DNS à stapling pour qu’il puisse fonctionner. On peut fournir plusieurs IPs ou des FQDN pour pointer vers des résolveurs DNS, IPv4 et IPv6. Il faut également fournir à nginx le certificat de la chaîne Let’s Encrypt chain.pem dans chaque configuration :

ssl_trusted_certificate /path/to/chain.pem;

Une fois que c’est fait et nginx redémarré, vous pouvez tester vos paramètres OCSP Stapling sur Qualys SSL. Si OCSP Stapling s’affiche en vert avec Yes, c’est que logiquement ça fonctionne bien.

Quant à OCSP Must-Staple, imaginez tout simplement la même problématique qu’avec HSTS : au départ, le client n’a aucune idée si le serveur supporte HSTS, ou OCSP Stapling. OCSP Must-Staple est la solution pour OCSP Stapling qui a été proposée pour résoudre ce problème. C’est une extension à activer dans le certificat, qui indique au client qu’il doit être livré en même temps qu’une réponse OCSP du serveur, sinon c’est niet (donc vérifiez bien, et régulièrement, que vos paramètres fonctionnent…). Comment faire ? J’en ai déjà parlé plus haut, lors de la génération du certificat, quand vous modifiez custom.cnf dans la section [ v3_req ].

Si vous êtes sur OpenSSL 1.1.0 ou supérieur :

tlsfeature = status_request

Si vous êtes sur OpenSSL 1.0 et inférieur (moins sexy) :

1.3.6.1.5.5.7.1.24 = DER:30:03:02:01:05

Encore une fois vous pouvez vérifier que le flag est bien présent dans votre certificat après un petit tour sur Qualys SSL, ou en regardant les détails du certificat depuis votre navigateur.

Remarque : Firefox est ici le bon élève puisqu’apparemment il supporte bien OCSP Must-Staple. Cependant il se peut que dès le démarrage du serveur web et lors de la première tentative de connexion, Firefox vous colle une belle erreur OCSP : c’est normal. En fait, il faut que nginx remplisse son cache OCSP, et c’est ce que vous avez fait lors de la première connexion. Une idée toute bête pour contourner ce problème est de faire un script qui va faire la connexion. Vous pouvez même l’ajouter dans une entrée cron pour être sûr qu’il n’y ait aucun problème de ce genre sur le long terme.

Problème : le cache OCSP ne se remplit pas automatiquement lors du démarrage d’nginx et il a besoin de se remplir de temps en temps. “Oui, et ?” me diriez-vous. Le problème c’est que quand le cache doit se remplir sur demande d’un client, le client balancera une erreur. Si on rafraîchit la page, hop, l’erreur part. C’est donc une limitation de OCSP stapling que l’on peut contourner avec un script (merci @href pour la piste) à mettre en cron où $domain est le domaine concerné, voici un bout de code pour vous montrer :

/bin/echo "Q" | /usr/bin/openssl s_client -connect $domain:443 -status > /dev/null 2>&1

pm## 8. HTTP Public Key Pinning (HPKP) HPKP est un autre mécanisme de sécurité, basé sur un header HTTP, qui vise à faire mémoriser au client une liste sûre de clés. Si le CA est compromis et se met à faire de faux certificats pour votre domaine, HPKP s’il est bien configuré vous protégera d’une MiTM. Vu qu’on utilise Let’s Encrypt, et avec la méthode que je vous ai fournie pour gérer vos certificats, nous pouvons directement pin la clé publique du leaf certificate. Pourquoi ? Parce que comme je vous l’ai dit, on peut désormais utiliser nos propres clés privées donc on peut se passer de la régénération automatique de Let’s Encrypt qui rend l’usage de HPKP très délicat.

Prudence. Le problème avec HPKP, c’est qu’une fois actif chez le client, il le reste pendant la durée max-age fournie dans le header. Si par malheur la clé privée est compromise mais que vous avez pin un seul certificat, pardonnez-moi le terme, mais vous êtes littéralement baisé (et plus concrètement votre site sera inaccessible chez ceux qui auront l’ancienne version du header active chez eux). Voilà pourquoi il faut pin plusieurs clés :

Si la clé privée est compromise, on peut changer de clé.
Par mesure de bon sens, il faut parfois rouler les clés.
Si l’algo est pété, on peut changer sur une autré clé d’un autre type d’algo.

Concrètement, moi, ce que je vous recommande, c’est de générer 2 clés P-384 et une clé RSA 4096, et de faire le tutoriel pour créer le certificat ECDSA à partir d’une clé P-384 générée.

# Génération des 3 clés : 2x P-384, 1x RSA-4096
openssl ecparam -genkey -name secp384r1 > privkey_ec_1.pem
openssl ecparam -genkey -name secp384r1 > privkey_ec_2.pem
openssl genrsa -out privkey_rsa.pem 4096

# Configurez comme indiqué plus haut le custom.cnf
cp /etc/ssl/openssl.cnf custom.cnf

# Les 3 CSR à générer
openssl req -new -sha256 -key privkey_ec_1.pem -out csr_ec_1.der -config custom.cnf
openssl req -new -sha256 -key privkey_ec_2.pem -out csr_ec_2.der -config custom.cnf
openssl req -new -sha256 -key privkey_rsa.pem -out csr_rsa.der -config custom.cnf

# Récupérer les empreintes
openssl req -pubkey < csr_ec_1.der | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64
openssl req -pubkey < csr_ec_2.der | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64
openssl req -pubkey < csr_rsa.der | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64

# Génération d'un certificat à partir de la première clé
letsencrypt certonly --standalone --agree-tos -m admin@domain.tld \
 --csr /path/to/csr_ec_1.der \
 --cert-path /path/to/cert.pem \
 --chain-path /path/to/chain.pem \
 --fullchain-path /path/to/fullchain.pem

Le header Public-Key-Pins est à renseigner avec les 3 empreintes obtenues et un max-age. Pour l’instant, et pour commencer, je le mettrais à 2 mois (de toute façon, Chrome limite la validité du header à 60 jours…) ; libre à vous de monter plus haut ensuite. Il est également possible d’appliquer HPKP à tous les sous-domaines une fois actif sur un domaine.

add_header Public-Key-Pins 'pin-sha256="empreinte_ec_1"; pin-sha256="empreinte ec_2"; pin-sha256="empreinte_rsa"; max-age=5184000; includeSubdomains';

Il va de soit que les clés ne doivent pas être idéalement sur la même machine, car si celle-ci est compromise, ce n’est pas une mais les trois clés privées que vous allez perdre. N’hésitez pas à rouler les clés, c’est-à-dire passer sur la deuxième clé privée puis en générer une nouvelle et l’ajouter à HPKP, en virant la première et en laissant la deuxième.

9. DANE, une alternative à HPKP ?

DANE pour DNS-based Authentication of Named Entities est un autre mécanisme sécurité, qui a la même finalité que HPKP mais qui repose sur des entrées DNS (des enregistrements TLSA). La condition pour son utilisation est l’activation de DNSSEC, sans quoi DANE n’a aucun intérêt. Je vais éviter la redite parce que mon ami Hardware a rédigé un billet sur le sujet, n’hésitez pas à le consulter.

Les entrées TLSA se présentent sous cette forme :

Pour extraire l’empreinte SHA-256 du fullchain.pem, voici comment :

openssl x509 -noout -in fullchain.pem -fingerprint -sha256 | cut -c 20- | sed s/://g | awk '{print tolower($0)}'

Puis il “suffit” d’ajouter une entrée TLSA dans votre zone DNS :

_443._tcp.domain.tld. IN TLSA 3 0 1 EMPREINTE
# À faire pour chaque sous-domaine.

Du coup si on met le fullchain.pem, il convient de mettre à jour l’entrée TLSA à chaque fois qu’on crée un nouveau certificat. Personnellement j’ai automatisé ça à coups de sed dans mon script de renouvellement, et ça marche bien.

Malheureusement DANE n’est pas présent dans la plupart des clients modernes (même pas Chrome et Firefox), c’est pour cela qu’il vaut mieux garder HPKP à côté. Pour tester si DANE fonctionne correctement, je vous recommande l’utilisation du plugin DNSSEC/TLSA Validator. Vous devriez voir cela :

10. Certificate Transparency

Certificate Transparency (CT) est en passe de devenir un standard. L’objectif derrière est de rendre public et transparent par les CAs toutes les informations autour de la génération d’un certificat. Ainsi, c’est une façon de lutter contre l’apparition de certificats frauduleux.

Lors de la création du certificat, le CA envoie des informations au log server qui répond avec un SCT (signed certificate timestamp). Ce SCT est soit intégré au certificat, soit présenté au travers d’autres moyens : une extension TLS, ou OCSP Stapling. Let’s Encrypt est déjà compatible avec certificate transparency, mais il ne présente pas encore de SCT (il est prévu que OCSP Stapling s’en occupe d’ici la fin d’année). Pour le moment on peut donc utiliser une extension TLS, il faudra compiler nginx avec le module nginx-ct. Il ne fonctionnera qu’avec une version d’OpenSSL assez récente.

Pour obtenir le SCT de fullchain.pem il nous faut utiliser ct-submit.

git clone https://github.com/grahamedgecombe/ct-submit --depth=1
cd ct-submit && go build
./ct-submit ct.googleapis.com/pilot <fullchain.pem>fullchain.sct
xxd fullchain.sct # Pour tester

00000000: 00a4 b909 90b4 1858 1487 bb13 a2cc 6770 .......X......gp
00000010: 0a3c 3598 04f9 1bdf b8e3 77cd 0ec8 0ddc .<5.......w.....
00000020: 1000 0001 4bc7 e617 c800 0004 0300 4830 ....K.........H0
00000030: 4602 2100 b9fe e206 f0f5 f600 93d5 e04c F.!............L
00000040: d2fd 75c9 e1fc a5c8 4812 a8b7 bc2c eb0c ..u.....H....,..
00000050: ee16 1fe9 0221 008a 5974 e1b6 a0e0 281a .....!..Yt....(.
00000060: 61e8 3447 895f 7ad4 2f70 f528 6133 a445 a.4G._z./p.(a3.E
00000070: 4fd4 ab60 ba36 db O..`.6.

Je vous suggère ici de créer un fichier ct_domain.tld.conf où l’on mettra les paramètres nginx pour servir le SCT.

ssl_ct on;
ssl_ct_static_scts /path/to/sct/dir;

Normalement nginx devrait servir les SCTs qui sont dans ce dossier. Si jamais ça ne marche pas, il est possible que ce soit dû à une limitation pour laquelle le serveur par défaut doit impérativement servir des SCTs (ajoutez default_server aux directives listen d’un vhost d’un domaine qui utilise CT). Pour vérifier si Certificate Transparency est opérationnel, Chrome et Qualys SSL feront l’affaire.

A ce fichier de configuration on peut aussi ajouter un header, Expect-CT. Il indique au browser que l’on attend l’utilisation de Certificate Transparency. Au jour d’aujourd’hui aucun browser ne l’utilise mais ce sera bientôt le cas. Surtout vérifiez bien que Certificate Transparency fonctionne et que les SCTs sont bien servis.

add_header Expect-CT "enforce; max-age=86400";

Dans ce cas-ci le browser devrait forcer l’utilisation de Certificate Transparency (erreur si pas possible) pendant un jour.

11. On récapitule ?

Et c’est après, je l’espère, vous avoir expliqué en quoi consistent les mécanismes utilisés, que je vais vous fournir les exemples de configuration. À chaque fois qu’il y a un domain.tld, c’est bien sûr à remplacer par votre domaine. Créons peut-être un dossier /etc/nginx/conf dans lequel on mettra des fichiers de configuration personnalisés, histoire d’éviter la redondance plus tard et de pouvoir maintenir plus facilement.

Créons un fichier tls.conf où l’on mettra les paramètres TLS :

ssl_protocols TLSv1.2;
ssl_ecdh_curve X25519:P-521:P-384;
ssl_ciphers EECDH+CHACHA20:EECDH+AESGCM;
ssl_prefer_server_ciphers on;

ssl_session_cache shared:SSL:20m;
ssl_session_timeout 15m;
ssl_session_tickets off;

On désactive les tickets TLS car leur mauvaise implémentation nuit au principe de confidentialité persistance (FS). Les autres directives modifient le cache alloué aux sessions et le timeout d’une session, elles sont à adapter selon les capacités de votre serveur et l’affluence des connexions.

Un fichier hsts.conf pour HSTS :

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";

Un fichier hpkp_domain.tld.conf pour HPKP d’un domaine :

add_header Public-Key-Pins 'pin-sha256="empreinte_ec_1"; pin-sha256="empreinte ec_2"; pin-sha256="empreinte_rsa"; max-age=5184000; includeSubdomains';

Un fichier ocsp.conf avec les paramètres OCSP :

ssl_stapling on;
ssl_stapling_verify on;
resolver 213.133.98.98 213.133.99.99 valid=300s;
resolver_timeout 5s;

Un fichier headers.conf qui peut être ajouté si l’application n’ajoute pas déjà ces headers :

add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";

Dans sites-enabled/, on aura notre fichier lambda.conf ainsi construit :

server {
 listen 80;
 listen [::]:80;
 server_name domain.tld;
 return 301 https://$host$request_uri;
}

server {
 listen 443 ssl http2;
 listen [::]:443 ssl http2;
 server_name domain.tld;

 ssl_certificate /path/to/fullchain.pem;
 ssl_certificate_key /path/to/privkey.pem;
 ssl_trusted_certificate /path/to/chain.pem;

 include /etc/nginx/conf/tls.conf;
 include /etc/nginx/conf/hsts.conf;
 include /etc/nginx/conf/headers.conf;
 include /etc/nginx/conf/ocsp.conf;
 include /etc/nginx/conf/hpkp_domain.tld.conf;
 #include /etc/nginx/conf/ct_domain.tld.conf;

 ...
}

N’oubliez pas de redémarrer nginx une fois les paramètres appliqués, sans oublier un nginx -t avant pour éviter les mauvaises surprises.

Les tests pour voir si vous avez tout bon :

Qualys SSL (SSL/TLS) : https://www.ssllabs.com/ssltest/
Cryptcheck (SSL/TLS): https://tls.imirhil.fr/ (v2 bientôt)
Observatoire Mozilla (SSL/TLS + headers) : https://observatory.mozilla.org
DNSSEC Analyzer (DNS) : https://dnssec-debugger.verisignlabs.com/
DANE Checker (DNS) : https://www.huque.com/bin/danecheck
Si vous en avez d’autres, proposez !

Ce n’est pas difficile, et je ne pense pas avoir menti sur la marchandise, il s’agit d’une excellente configuration HTTPS, peut-être même un peu trop extrémiste. Si la compatibilité est un trop gros problème, appliquez les conseils que j’ai disséminés le long de l’article.

Article rédigé par Wonderfall, vous pouvez le suivre sur Mastodon ou Twitter

Ghost 1.0 - Installer Ghost avec ghost-cli et Nginx - Migrer depuis wordpress

Mon, 28 Aug 2017 14:24:14 +0000

Ghost à publié sa nouvelle release 1.0, qui introduit également l’outil ghost-cli permettant d’installer ghost, de le mettre à jour et d’intéragir plus facilement avec la plateforme.

Le thème de base “casper” a également été mis à jour, et je trouve le nouveau design absolument génial, bien que j’ai effectué certaines modifications dans les styles, notamment concernant la dimensions des images.

Je n’ai donc pas hésité trop longtemps, car je trouvais déjà que Ghost était une solution très intéressante pour écrire des articles, sans avoir pour autant à ajouter des dizaines de plugins comme sur wordpress.

Je vais donc expliquer dans cet article comment installer Ghost via l’outil ghost-cli, et comment réaliser la migration depuis WordPress.

Pour résumer les fonctionnalités principales de Ghost :

Articles en markdown
Organisation des articles par tags
Support natif des meta datas
Support natif de l’AMP
Application Desktop

De quoi avons nous besoin ?

Un VPS avec Ubuntu 16.04 LTS
Un serveur MySQL
NGINX
Node v6
Un utilisateur avec sudo

Installation des pré-requis

On commence par créer un utilisateur et lui donner les droits sudo, puis on se connecte via cet utilisateur. Cet utilisateur ne doit pas s’appeller ghost, car l’utilisateur ghost sera automatiquement ajouté par ghost-cli

adduser --disabled-password --disabled-login monghost
usermod -aG sudo monghost
su - monghost

On met à jour la liste des paquets et le serveur

sudo apt-get update
sudo apt-get upgrade

On installe la dernière release de nginx

wget -O - https://nginx.org/keys/nginx_signing.key | sudo apt-key add -
sudo echo "deb http://nginx.org/packages/ubuntu/ $(lsb_release -sc) nginx" > /etc/apt/sources.list.d/nginx.list
sudo apt update
sudo apt install nginx

On installe MariaDB 10.3

curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup \
| sudo bash -s -- --mariadb-server-version=10.3 --skip-maxscale

sudo apt update && sudo apt install mariadb-server

On installe nodejs v8 LTS

curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash
sudo apt-get install -y nodejs

Installation de Ghost

On commence par installer ghost-cli

sudo npm i -g ghost-cli

Puis on créer le répertoire pour notre blog

sudo mkdir -p /var/www/ghost
sudo chown monghost:monghost /var/www/ghost
cd /var/www/ghost

Et on peut enfin lancer l’installation de Ghost, qui est totalement interactive et qui va :

Configurer la base de donnée
Installer la dernière version de Ghost
Configurer Ghost
Configurer Nginx et installer un certificat SSL avec Let’s Encrypt
Déclarer Ghost en tant que service via systemd

Vous avez le choix pour chacune des étapes, de le faire via ghost-cli ou manuellement. Dans le cas de Nginx par exemple, si vous utiliser une configuration particulière, il sera préférable d’ajouter votre vhost manuellement.

On lance donc l’installation avec :

ghost install

configuration de nginx

Pour la configuration de Nginx, pour des performances optimales, j’utilise personnellement la fonctionnalité proxy-cache d’Nginx pour mettre en cache les pages du blog, cette technique est également appelée micro-caching puisque le délai d’expiration du cache est relative court mais autorise par contre Nginx à utiliser les fichiers en cache dans le cas ou l’upstream (le serveur nodejs Ghost dans ce cas) est indisponible.

Pour cela je commence par créer un répertoire pour stocker le cache nginx :

sudo mkdir -p /var/cache/nginx/static
sudo chown -R www-data:www-data /var/cache/nginx

Je peux ensuite créer mon vhost et définir le stockage du cache dans ce répertoire

proxy_cache_path /var/cache/nginx/static levels=1:2 keys_zone=GHOST:75m inactive=24h max_size=512m;
server {
# redirection du http vers https
 listen 80;
 listen [::]:80;
 server_name votredomain.tld www.votredomain.tld;

 return 301 https://votredomain.tld$request_uri;
}
server {
# redirection du www vers non-www
 server_name www.votredomain.tld

 listen 443 ssl http2;
 listen [::]:443 ssl http2;
 ssl on;
 ssl_certificate /etc/letsencrypt/live/votredomaine.tld/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/votredomaine.tld/key.pem;
 ssl_trusted_certificate /etc/letsencrypt/live/votredomaine.tld/cert.pem;

 return 301 https://votredomain.tld$request_uri;

}
server {

 server_name votredomain.tld;

 root /var/www/votredomain.tld/system/nginx-root;

 listen 443 ssl http2;
 listen [::]:443 ssl http2;
 ssl on;
 ssl_certificate /etc/letsencrypt/live/votredomaine.tld/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/votredomaine.tld/key.pem;
 ssl_trusted_certificate /etc/letsencrypt/live/votredomaine.tld/cert.pem;

 access_log /var/log/nginx/votredomaine.tld.access.log;
 error_log /var/log/nginx/votredomaine.tld.error.log;

 location / {
 proxy_cache STATIC;
 proxy_cache_valid 200 5m;
 proxy_cache_valid 404 1m;
 proxy_cache_key "$scheme$request_method$host$request_uri";
 proxy_cache_use_stale http_500 http_502 http_503 http_504 http_403 http_404 updating;
 proxy_cache_background_update on;

 proxy_ignore_headers X-Accel-Expires Expires Cache-Control;
 proxy_ignore_headers Set-Cookie;
 proxy_hide_header Set-Cookie;
 proxy_hide_header X-powered-by;

 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header Host $http_host;
 proxy_pass http://127.0.0.1:2368;
 }
 location ~ ^/(?:ghost|signout) {
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_pass http://127.0.0.1:2368;
 add_header Cache-Control "no-cache, private, no-store, must-revalidate, max-stale=0, post-check=0, pre-check=0";
 }
 location /content/images {
 alias /var/wwww/votredomaine.tld/content/images;
 access_log off;
 expires max;
 }
 location /assets {
 alias /var/wwww/votredomaine.tld/content/themes/casper/assets;
 access_log off;
 expires 30d;
 }
 client_max_body_size 50m;
}

Pour installer le certificat SSL, j’utilise actuellement acme.sh, un client Acme écrit en bash que je trouve plus facile à utiliser que certbot, notamment pour la mise en place des renouvellement automatique.

Je vous met le lien de mon article qui explique comment installer acme.sh et comment générer un certificat SSL : Installer un certificat SSL Let’s Encrypt avec Acme.sh

Mettre à jour Ghost

Là aussi, la nouvelle CLI de Ghost facilite vraiment le processus de mise à jour, puisqu’il suffit de se rendre dans le dossier de votre blog en tant que l’utilisateur définit pour utiliser la CLI puis d’utiliser ghost update

su - monghost
cd /var/www/ghost
ghost update

Migrer depuis WordPress

Pour migrer depuis WordPress, il faut tout d’abord extraire votre contenu au format .json en utilisant le plugin officiel publié par Ghost. Il est disponible dans l’annuaire de plugins WordPress

Après avoir extrait votre contenu, vous pourrez l’importer dans Ghost, il est restera cependant quelques tâches à réaliser manuellement :

Les images devront être importées manuellement ou hébergées sur un hébergeur externe
Les commentaires devront être importés sur une plateforme comme Disqus ou sur une solution self-hosted comme Isso
Les méta-data de vos articles devront être ajoutées manuellement, l’importateur Ghost ne traite que le contenu des articles et les tags

Je vais traiter dans un prochain article comment installer Isso pour héberger l’ensemble de vos commentaires et ne pas avoir à utiliser une solution comme disqus.

Installer un certificat SSL Cloudflare Origin avec Nginx

Thu, 20 Apr 2017 22:15:57 +0000

Il s’agit peut-être de la fonctionnalité la plus intéressante avec Cloudflare, la possibilité d’installer un certificat SSL fournit par Cloudflare sur votre serveur web. Cela permet de chiffrer les connexions entre votre serveur et les serveurs de Cloudflare, et vous pouvez générer un certificat valide pour 15 ans, soit largement plus que les 90 jours d’un certificat Let’s Encrypt.

Générer un certificat ainsi qu’une clé privée avec Cloudflare

Pour commencer, vous devez vous rendre dans la partie “Crypto” du domaine pour lequel vous souhaitez générer un certificat. Vous trouverez alors la section Origin Certificates dans laquelle nous allons pouvoir générer notre certificat SSL ainsi que notre clé privée.

Vous pouvez donc cliquer comme dans l’exemple ci-dessous sur le bouton Create Certificate.

Vous pouvez si vous le souhaitez générer une requête de Certificat nommé CSR (Certificate Signing Request) ainsi qu’une clé privée, ou laisser Cloudflare le faire pour vous. Par contre il préférable de choisir un certificat de type ECDSA plutôt que RSA, aussi bien pour les performances, que pour la sécurité.

Vous allez alors obtenir votre certificat ainsi que votre clé privée.

Copiez tout d’abord la clé dans un fichier votredomaine-key.pem, à conserver précieusement car vous ne pourrez pas la télécharger à nouveau depuis Cloudflare.

Copiez ensuite le certificat SSL dans un deuxième fichier que nous allons nommer votredomaine-crt.pem. Et placez les deux fichiers dans un dossier votre choix, par exemple un dossier nommé ssl dans /etc/nginx.

Cependant avant de pouvoir ajouter le certificat dans la configuration Nginx, il faut ajouter la signature de l’autorité de certification dans le même fichier que notre certificat. Pour cela nous allons télécharger le certificat root de Cloudflare et le fusionner avec notre certificat :

wget wget https://support.cloudflare.com/hc/en-us/article_attachments/206709098/cloudflare_origin_ecc.pem
cat votredomaine-crt.pem cloudflare_origin_ecc.pem > votredomaine-fullchain.pem

Installer le certificat avec nginx

Pour utiliser ce certificat dans votre configuration nginx, il vous suffit d’ajouter les lignes suivantes à votre bloc server :

listen 443 ssl http2;
listen [::]:443 ssl http2;
ssl on;
ssl_certificate /etc/nginx/ssl/votredomaine-fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/votredomaine-key.pem;

Vous pouvez vérifier que tout est correct avant t d’appliquer la configuration en utilisant nginx -t. Si il n’y a aucune erreur, vous pouvez alors utiliser service nginx reload

Vous pouvez alors changer le niveau SSL de votre domaine en Full (strict) via l’interface Cloudflare :

Allez plus loin avec les Authenticated Origin Pulls

Nous pouvons même aller plus loin et mettre en place un certificat pour authentifié notre serveur. Ce service est nommé “Authenticated Origin Pulls” dans le panel Cloudflare et permet d’éviter que des requêtes soient faites à votre serveur sans passer par le proxy Cloudflare.

Pour le mettre en place il nous suffit de télécharger le certificat suivant :

wget -O /etc/nginx/ssl/origin-pull-ca.pem https://support.cloudflare.com/hc/en-us/article_attachments/201243967/origin-pull-ca.pem

Et de l’inclure dans notre configuration nginx :

ssl_client_certificate /etc/nginx/ssl/origin-pull-ca.pem;
ssl_verify_client on;

Nous pouvons alors activer depuis l’interface Cloudflare la fonctionnalité Authenticated Origin Pulls.

Migration d'une instance Mastodon

Thu, 13 Apr 2017 13:40:33 +0000

Pourquoi migrer mon instance Mastodon ?

Une semaine après l’installation de ma première instance Mastodon, il est déjà temps de migrer. Mais la raison n’est pas le besoin de plus de ressources pour l’instance.

Non, c’est plutôt que je n’était pas totalement satisfait de ma première installation, et que je rencontrais certains bugs récurrents dont je ne trouvais pas la source. Donc je me suis dit, autant refaire une installation propre maintenant que je connais bien l’outil. Premier point, je suis passé de Ubuntu 16.04 LTS à Debian 8.7, principalement pour bénéficier des packages de dotdeb.org dont notamment redis-server en v3.2.8 contre v3.0.6 sur Ubuntu. Et pour simplifier un petit peu l’installation, j’ai utilisé EasyEngine pour mettre en place nginx et redis. Le principal avantage de EasyEngine est qu’il permet d’organiser très proprement les fichiers de configuration de Nginx avec une nomenclature claire et simple. Je suis également passer de Cloudflare à Let’s Encrypt notamment pour bénéficier d’un meilleur chiffrement et de plus d’options sur les headers Nginx.

Préparer le nouveau serveur

Pour la migration il vous faut exporter la base de donnée postgresql et faire une copie du dossier /home/mastodon. Pour cela il faudra arrêter tous les services de mastodon et avoir préalablement préparé le nouveau serveur. Pour cela commençons par réinstaller ce qui est nécessaire pour Mastodon.

Installation des dépendances

echo "deb http://ftp.debian.org/debian jessie-backports main" >> /etc/apt/sources.list
apt-get update
apt-get install imagemagick ffmpeg libpq-dev libxml2-dev libxslt1-dev nodejs file git curl

Installation de NodeJS

curl -sL https://deb.nodesource.com/setup_4.x | bash -
apt-get install nodejs
npm install -g yarn

Installation de PostgreSQL (en v9.6 via les backports) et création de l’utilisateur mastodon, avec un mot de passe et de la base de donnée mastodon_production

apt-get -t jessie-backports install postgresql postgresql-contrib
su - postgre
psql
CREATE USER mastodon CREATEDB;
ALTER USER "mastodon" WITH PASSWORD 'new_password';
CREATE DATABASE mastodon_production OWNER mastodon;
\q
exit

Pour l’installation de Nginx et Redis, comme dit précédemment, j’ai utilisé EasyEngine, on installe donc d’abord EE :

wget -qO ee rt.cx/ee && bash ee

Et on installe Nginx et Redis :

ee stack install --nginx --redis

Installation des dépendances pour Ruby :

apt-get install autoconf bison build-essential libssl-dev libyaml-dev libreadline6-dev zlib1g-dev libncurses5-dev libffi-dev libgdbm3 libgdbm-dev

adduser --disabled-password --disabled-login mastodon
git clone https://github.com/rbenv/rbenv.git ~/.rbenv
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init -)"' >> ~/.bashrc
source ~/.bashrc

Il faut alors se déconnecter puis se reconnecter en tant que mastodon pour appliquer les modifications faites au bash

exit
su - mastodon

On installe ruby-build

git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build

Puis on installe Ruby, en version 2.4.1 désormais

rbenv install 2.4.1
rbenv global 2.4.1

On peut désormais remettre en place la configuration de Nginx avant de commencer la migration. Mise en place des services :

wget https://git.virtubox.net/virtubox/mastodon/raw/master/services/mastodon-web.service -O /etc/systemd/system/mastodon-web.service
wget https://git.virtubox.net/virtubox/mastodon/raw/master/services/mastodon-streaming.service -O /etc/systemd/system/mastodon-streaming.service
wget https://git.virtubox.net/virtubox/mastodon/raw/master/services/mastodon-sidekiq.service -O /etc/systemd/system/mastodon-sidekiq.service

Pour créer le virtualhost avec EasyEngine :

ee site create votredomaine.com

Vous pouvez ensuite editer /etc/nginx/sites-availables/votredomaine.com, en se basant sur le modèle d’Angristan

map $http_upgrade $connection_upgrade {
 default upgrade;
 '' close;
}
# redirection http vers https
server {
 listen 80;
 listen [::]:80;
 server_name www.votredomaine.com votredomaine.com;
 return 301 https://votredomaine.com$request_uri;

 access_log /dev/null;
 error_log /dev/null;
}

# block https
server {
 listen 443 ssl http2;
 listen [::]:443 ssl http2;
 server_name www.votredomaine.com votredomaine.com;

if ($host = www.votredomaine.com) {
 return 301 https://votredomaine.com$request_uri;
 }


 access_log /var/log/nginx/votredomaine.com-access.log;
 error_log /var/log/nginx/votredomaine.com-error.log;

# configuration ssl avec letsencrypt
 ssl_certificate /etc/letsencrypt/live/votredomaine.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/votredomaine.com/privkey.pem;;
 ssl_protocols TLSv1.2;
 ssl_ciphers EECDH+AESGCM:EECDH+CHACHA20:EECDH+AES;
 ssl_prefer_server_ciphers on;

# ajout des headers pour le HSTS, CSP et Referrer-Policy
 add_header Strict-Transport-Security "max-age=15552000; includeSubDomains; preload";
 add_header Content-Security-Policy "default-src 'self'; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline'; img-src 'self' data:; connect-src 'self' wss://votredomaine.com;";
 add_header Referrer-Policy "strict-origin-when-cross-origin";

 keepalive_timeout 70;
 sendfile on;
 client_max_body_size 0;
 gzip off;

 root /home/mastodon/live/public;

 location / {
 try_files $uri @proxy;
 }

 location @proxy {
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto https;
 proxy_pass_header Server;
 proxy_pass http://127.0.0.1:3000;
 proxy_buffering off;
 proxy_redirect off;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection $connection_upgrade;
 tcp_nodelay on;
 }

 location /api/v1/streaming {
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto https;
 proxy_pass http://127.0.0.1:4000;
 proxy_buffering off;
 proxy_redirect off;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection $connection_upgrade;
 tcp_nodelay on;
 }

 error_page 500 501 502 503 504 /500.html;

}

Transfert des données depuis l’ancien serveur

A partir de là, cette fois on ne clone pas le dépôt Github puisque l’on veut réutiliser l’installation précédente. Pour réaliser la copie depuis le serveur précédent, il faut tout d’abord arrêter les services de mastodon sur l’ancien serveur:

systemctl stop mastodon* redis

On dump ensuite l’ancienne base de donnée :

pg_dump mastodon_production > fichier_de_sortie

Pour les fichier, j’ai simplement zippé le dossier /home/mastodon avant de le transférer sur le nouveau serveur avec scp.

zip backupmaston -r /home/mastodon

Pourquoi ne pas utiliser rsync ? Car lors de l’extraction du zip, il est facile de ne pas écraser les fichiers déjà présent, notamment pour rbenv et rbenv-build en utilisant “N” lorsque le programme unzip nous demande ce que l’on souhaite faire. Pour importer la base de donnée après le transfert sur le nouveau serveur :

su - postgre
psql mastodon_production < fichier_d_entree
exit

Ne pas oublier après le transfert de vérifier les propriétaires des fichiers dans /home/mastodon, ne pas hésiter à faire :

chown -R mastodon:mastodon /home/mastodon

Il faut également penser à copier votre certificat Let’s Encrypt

Relancer mastodon après le transfert

Ne pas oublier de modifier le fichier .env.production avec le mot de passe postgreSQL notamment. Pour relancer mastodon, cela se déroule comme une mise à jour si ce n’est que l’on installe bundler

su - mastodon
cd live
gem install bundler --no-ri
git fetch
git pull
git checkout $(git tag | tail -n 1)
bundle install --deployment --without development test
NODE_ENV=production npm upgrade --global yarn
yarn install
RAILS_ENV=production bundle exec rails assets:clean
RAILS_ENV=production bundle exec rails assets:precompile
RAILS_ENV=production bundle exec rails db:migrate
exit

Puis activer et démarrer les services :

systemctl enable /etc/systemd/system/mastodon-*.service
systemctl start mastodon-web.service mastodon-sidekiq.service mastodon-streaming.service

Mise en place des crons

crontab -e -u mastodon

Et ajouter les lignes

RAILS_ENV=production
@daily cd /home/mastodon/live && /home/mastodon/.rbenv/shims/bundle exec rake mastodon:daily

Voilà ! Vous pouvez désormais changer vos DNS pour pointer votre domaine vers le nouveau serveur. N’hésitez pas à me signaler d’éventuelles erreurs en commentaire ou à proposer des améliorations.

Si vous souhaitez mettre en place une architecture basée sur plusieurs serveurs, je vous recommande l’article matuni.xyz.

Installer une instance Mastodon sur Ubuntu 16.04 LTS

Wed, 05 Apr 2017 20:17:58 +0000

Alors que ce nouveau réseau social fait actuellement beaucoup parler de lui, je me suis décidé à créer ma propre instance Mastodon pour contribuer à ce projet.

J’en ai donc profiter pour faire un tutorial listant les étapes à suivre pour lancer vous aussi votre instance dès aujourd’hui. Je suis parti sur un VPS tournant avec Ubuntu 16.04 LTS et du côté ressources 8 vCores, 8Go de RAM et 50Go de SSD. Je verrais à l’usage si l’instance nécessite plus de ressources.

Pour suivre les étapes de ce tutorial, un utilisateur avec les droits sudo est suffisant, vous n’avez pas besoin de vous connecter en tant que root.

Installer les pré-requis

sudo apt-get update

Installation de nodejs

curl -sL https://deb.nodesource.com/setup_4.x | sudo bash -
sudo apt-get install imagemagick ffmpeg libpq-dev libxml2-dev libxslt1-dev nodejs
sudo npm install -g yarn

Installation de redis-server

sudo apt-get install redis-server redis-tools

Installation de postgresql

sudo apt-get install postgresql postgresql-contrib
sudo su - postgres
psql
CREATE USER mastodon CREATEDB;
\q

Il nous faut également activer le daemon d’authentification pour que les utilisateurs puissent se connecter dans mot de passe :

sudo sed -i '/^local.*postgres.*peer$/a host all all 127.0.0.1/32 ident' /etc/postgresql/9.?/main/pg_hba.conf
sudo apt-get install pidentd
sudo systemctl enable pidentd
sudo systemctl start pidentd
sudo systemctl restart postgresql

Installation de Ruby

On installe les dépendances pour Ruby.

sudo apt-get install autoconf bison build-essential libssl-dev libyaml-dev libreadline6-dev zlib1g-dev libncurses5-dev libffi-dev libgdbm3 libgdbm-dev

On créer un utilisateur mastodon :

adduser --disabled-password --disabled-login mastodon

Puis on s’identifie avec cet utilisateur

su - mastodon

On installe rbenv et rbenv-build :

adduser --disabled-password --disabled-login mastodon
git clone https://github.com/rbenv/rbenv.git ~/.rbenv
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init -)"' >> ~/.bashrc
source ~/.bashrc

On se déconnecte pour appliquer la modification au bash, puis on installe ruby-build.

exit
su - mastodon
git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build

Puis on installe Ruby v2.4.1 pour Mastodon :

rbenv install 2.4.1
rbenv global 2.4.1

On vérifie la version de ruby installé via la commande :

ruby -v

Installation de Mastodon

Nous allons pouvoir passer à l’installation de Mastodon et pour cela on commence par cloner le dépôt Github, puis on utilise git checkout pour sélectionner la dernière release plutôt que de rester sur la branche master :

cd ~
git clone https://github.com/tootsuite/mastodon.git live
cd live
git checkout $(git tag | tail -n 1)

On installe bundler pout gérer l’installation des dépendances et on désactive la documentation pour chaque gem.

echo "gem: --no-document" > ~/.gemrc
gem install bundler --no-ri

Puis on passe à l’installation

bundle install --deployment --without development test
yarn install

On peut désormais copier le fichier de configuration d’exemple et l’éditer avec nos informations :

cp .env.production.sample .env.production
nano .env.production

Les informations à remplir sont :

# Service dependencies
REDIS_HOST=localhost
REDIS_PORT=6379
DB_HOST=/var/run/postgresql
DB_USER=mastodon
DB_NAME=mastodon_production
DB_PASS=
DB_PORT=5432

# Federation
LOCAL_DOMAIN=votredomaine.com
LOCAL_HTTPS=true

Ainsi que la partie SMTP qui permettra aux utilisateurs de confirmer leur inscription :

# E-mail configuration
SMTP_SERVER=mail.votredomaine.com
SMTP_PORT=587
SMTP_LOGIN=noreply@votredomaine.com
SMTP_PASSWORD=VotreMotdePasse
SMTP_FROM_ADDRESS=noreply@votredomaine.com

Pour la partie application secret, utilisez la commande bundle exec rake secret pour générer 3 clés et vous n’avez plus qu’à les copier dans le fichier de configuration.

Pour mettre en place l’instance du côté base de donnée et assets :

RAILS_ENV=production bundle exec rails db:setup
RAILS_ENV=production bundle exec rails assets:precompile

Création des services systemd

Pour le processus web

nano /etc/systemd/system/mastodon-web.service

[Unit]
 Description=mastodon-web
 After=network.target

[Service]
 Type=simple
 User=mastodon
 WorkingDirectory=/home/mastodon/live
 Environment="RAILS_ENV=production"
 Environment="PORT=3000"
 ExecStart=/home/mastodon/.rbenv/shims/bundle exec puma -C config/puma.rb
 TimeoutSec=15
 Restart=always

[Install]
 WantedBy=multi-user.target

**Pour le processus en arrière-plan **

nano /etc/systemd/system/mastodon-sidekiq.service

[Unit]
 Description=mastodon-sidekiq
 After=network.target

[Service]
 Type=simple
 User=mastodon
 WorkingDirectory=/home/mastodon/live
 Environment="RAILS_ENV=production"
 Environment="DB_POOL=5"
 ExecStart=/home/mastodon/.rbenv/shims/bundle exec sidekiq -c 5 -q default -q mailers -q pull -q push
 TimeoutSec=15
 Restart=always

[Install]
 WantedBy=multi-user.target

Pour le processus de l’API

nano /etc/systemd/system/mastodon-streaming.service

[Unit]
 Description=mastodon-streaming
 After=network.target

[Service]
 Type=simple
 User=mastodon
 WorkingDirectory=/home/mastodon/live
 Environment="NODE_ENV=production"
 Environment="PORT=4000"
 ExecStart=/usr/bin/npm run start
 TimeoutSec=15
 Restart=always

[Install]
 WantedBy=multi-user.target

On peut alors activer les services :

systemctl enable /etc/systemd/system/mastodon-*.service

Et enfin démarrer l’instance Mastodon :

sudo systemctl start mastodon-web.service mastodon-sidekiq.service mastodon-streaming.service

On ajoute alors les crons nécessaire pour Mastodon :

crontab -u mastodon -e

RAILS_ENV=production
@daily cd /home/mastodon/live && /home/mastodon/.rbenv/shims/bundle exec rake mastodon:daily

Mise en place du reverse-proxy Nginx :

Nous avons désormais une instance mastodon qui fonctionne, mais nous allons devoir mettre en place un reverse-proxy avec Nginx afin de pouvoir utiliser directement notre domaine pour y accéder.

On commence par installer nginx :

wget -O - https://nginx.org/keys/nginx_signing.key | sudo apt-key add -
sudo echo "deb http://nginx.org/packages/ubuntu/ $(lsb_release -sc) nginx" > /etc/apt/sources.list.d/nginx.list
sudo apt update
sudo apt install nginx

On créer un fichier de configuration en se basant sur le modèle d’Angristan :

nano /etc/nginx/sites-enabled/votredomaine.com

map $http_upgrade $connection_upgrade {
 default upgrade;
 '' close;
}
# redirection http vers https
server {
 listen 80;
 listen [::]:80;
 server_name www.votredomaine.com votredomaine.com;
 return 301 https://votredomaine.com$request_uri;

 access_log /dev/null;
 error_log /dev/null;
}

# block https
server {
 listen 443 ssl http2;
 listen [::]:443 ssl http2;
 server_name www.votredomaine.com votredomaine.com;

if ($host = www.votredomaine.com) {
 return 301 https://votredomaine.com$request_uri;
 }


 access_log /var/log/nginx/votredomaine.com-access.log;
 error_log /var/log/nginx/votredomaine.com-error.log;

# configuration ssl avec letsencrypt
 ssl_certificate /etc/letsencrypt/live/votredomaine.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/votredomaine.com/privkey.pem;;
 ssl_protocols TLSv1.2;
 ssl_ciphers EECDH+AESGCM:EECDH+CHACHA20:EECDH+AES;
 ssl_prefer_server_ciphers on;

# ajout des headers pour le HSTS, CSP et Referrer-Policy
 add_header Strict-Transport-Security "max-age=15552000; includeSubDomains; preload";
 add_header Content-Security-Policy "default-src 'self'; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline'; img-src 'self' data:; connect-src 'self' wss://votredomaine.com;";
 add_header Referrer-Policy "strict-origin-when-cross-origin";

 keepalive_timeout 70;
 sendfile on;
 client_max_body_size 0;
 gzip off;

 root /home/mastodon/live/public;

 location / {
 try_files $uri @proxy;
 }

 location @proxy {
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto https;
 proxy_pass_header Server;
 proxy_pass http://127.0.0.1:3000;
 proxy_buffering off;
 proxy_redirect off;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection $connection_upgrade;
 tcp_nodelay on;
 }

 location /api/v1/streaming {
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto https;
 proxy_pass http://127.0.0.1:4000;
 proxy_buffering off;
 proxy_redirect off;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection $connection_upgrade;
 tcp_nodelay on;
 }

 error_page 500 501 502 503 504 /500.html;

}

Puis on installe Let’s Encrypt pour générer notre certificat SSL :

cd /opt
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto certonly --webroot -w /home/mastodon/live -d www.votredomaine.com -d votredomaine.com --email vous@votredomaine.com --text --rsa-key-size 4096

Mettre à jour Mastodon

Mastodon est très régulièrement mis à jour, cependant pour des raisons de stabilité, il est préférable d’attendre des releases pour mettre à jour son instance. Il ne sera donc pas nécessaire de lancer 10 fois par jour la commande git pull, et il vous suffit après une release d’utiliser les commandes suivantes sans oublier de remplacer tags/vX.X.X par l’identifiant de la release.

su - mastodon
cd live
git fetch
git checkout vX.X.X
bundle install --deployment --without development test
NODE_ENV=production npm upgrade --global yarn
yarn install
RAILS_ENV=production bundle exec rails assets:clean
RAILS_ENV=production bundle exec rails assets:precompile
RAILS_ENV=production bundle exec rails db:migrate
exit

Si une mise à jour de Ruby est nécessaire pour l’installation d’une release, il vous faudra faire :

rbenv install 2.4.1
gem install bundler --no-ri

Note pour la release v1.1.2, pour utiliser la nouvelle fonctionnalitée des avatars GIF, utilisez la commande suivante pour générer une version statiques sur des avatars mis en ligne précédemmment. Sinon vos utilisateurs devront ré-uploader l’avatar pour en bénéficier.

RAILS_ENV=production bundle exec rake mastodon:maintenance:add_static_avatars

Il ne reste plus qu’à redémarrer l’instance :

sudo systemctl restart mastodon-web.service mastodon-sidekiq.service mastodon-streaming.service

Création du compte administrateur

Votre instance est désormais fonctionnelle, il vous suffit donc de vous inscrire et de valider votre adresse mail pour créer votre compte. Ensuite, pour définir ce compte en tant qu’administrateur de l’instance utiliser la commande suivante :

RAILS_ENV=production bundle exec rails mastodon:make_admin USERNAME=votre-utilisateur

Mon instance Mastodon.top

Ayant des ressources à disposition, j’ai lancé mon instance Mastodon, que vous pouvez rejoindre à l’adresse mastodon.top. Nous sommes déjà 90 utilisateurs et vu l’utilisation des ressources, cela ne devrait pas être un problème d’héberger plus de monde. Vous pouvez visualiser les statistiques de l’instance sur la page about ainsi que le monitoring en temps-réel à l’adresse status.mastodon.top.

N’hésitez pas à donner votre avis sur ce tutoriel, à corriger d’éventuelles erreurs ou à demander de l’aide pour mettre en place votre instance !

Vous pouvez aussi me suivre sur Mastodon : thomas_virtubox@mastodon.top

Installer Ghost avec Nginx proxy-cache et Let'sEncrypt

Wed, 29 Mar 2017 21:17:02 +0000

Cet article est ancien et il peut contenir des instructions qui ne sont plus d’actualité.

Si vous aussi, il vous arrive de vous plaindre à propos de WordPress, pourquoi ne pas essayer une autre solution pour votre blog ? C’est ce que j’ai fait pour mon blog anystack.xyz en passant de WordPress à Ghost. Après plusieurs mois d’utilisation, je suis plutôt satisfait de cette plateforme. Il manque effectivement quelques fonctionnalités et l’écosystème de plugins et de thèmes que l’on peut retrouver sur WordPress, mais sa simplicité d’utilisation et son orientation vers ce qui est vraiment important – le contenu – est plutôt agréable.

Je vais donc dans ce tutorial expliquer comment installer Ghost, puis mettre en place un reverse-proxy avec Nginx et Let’s Encrypt, en utilisant le module proxy-cache de Nginx pour rendre Ghost encore plus rapide.

1) Installer NodeJs v4 LTS

wget https://deb.nodesource.com/setup_4.x
chmod +x setup_4.x
./setup_4.x
apt-get install nodejs -y

2) Installer Ghost

mkdir /var/www/ghost
cd /var/www/ghost
curl -L https://ghost.org/zip/ghost-latest.zip -o ghost.zip
unzip ghost.zip
npm install --production

Lancer Ghost :

npm start --production

Votre instance Ghost est donc désormais lancée, et vous pouvez y accéder à l’adresse http://IP-De-Votre-Serveur:2368. Cependant, si vous fermez votre console SSH, l’instance Ghost s’arrêtera. Pour lancer Ghost de façon définitive :

npm install forever -g
## démarrer ghost
NODE_ENV=production forever start index.js

## arrêter ghost
forever stop index.js

3) Configurer Nginx en tant que reverse-proxy

Nous allons donc passer à la partie configuration de Nginx. Si vous utilisez EasyEngine, vous pouvez créer votre sous domaine en une seule commande :

ee site create votredomaine.com --proxy=127.0.0.1:2368

Ensuite modifiez le fichier de configuration de votre domaine en suivant le modèle ci-dessous.

upstream ghost_upstream {
 server 127.0.0.1:2368;
 keepalive 64;
}

proxy_cache_path /var/run/cache levels=1:2 keys_zone=STATIC:75m inactive=24h max_size=512m;

server {
 server_name votredomaine.com wwww.votredomaine.com;
 add_header X-Cache $upstream_cache_status;
 location / {
 proxy_cache STATIC;
 proxy_cache_valid 200 30m;
 proxy_cache_valid 404 1m;
 proxy_pass http://ghost_upstream;
 proxy_ignore_headers X-Accel-Expires Expires Cache-Control;
 proxy_ignore_headers Set-Cookie;
 proxy_hide_header Set-Cookie;
 proxy_hide_header X-powered-by;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header Host $http_host;
 expires 10m;
 }
 location /content/images {
 alias /path/to/ghost/content/images;
 access_log off;
 expires max;
 }
 location /assets {
 alias /path/to/ghost/content/themes/uno-master/assets;
 access_log off;
 expires max;
 }
 location /public {
 alias /path/to/ghost/core/built/public;
 access_log off;
 expires max;
 }
 location /ghost/scripts {
 alias /path/to/ghost/core/built/scripts;
 access_log off;
 expires max;
 }
 location ~ ^/(?:ghost|signout) {
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header Host $http_host;
 proxy_pass http://ghost_upstream;
 add_header Cache-Control "no-cache, private, no-store, must-revalidate, max-stale=0, post-check=0, pre-check=0";
 }
location /.well-known {
 alias /var/www/html/.well-known;
 }
}

Pour appliquer la configuration, on utilise la commande service nginx reload. Cependant il faut également penser à éditer le fichier config.js, situé dans le dossier d’installation de Ghost, et y changer la variable url en la remplaçant par votre nom de domaine :

url: 'http://votredomaine.com'

4) Installer Let’s Encrypt

On peut désormais passer à l’installation de Let’s Encrypt si ce n’est pas déjà fait.

cd /opt
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt

Il ne nous reste plus qu’à générer le certificat via la commande :

./letsencrypt-auto certonly --webroot -w /var/www/html -d votredomaine.com --email votreemail@votredomaine.com --text --agree-tos

Pour utiliser le certificat, ajouter les lignes suivantes après server_name dans votre configuration nginx :

 listen 443 ssl http2;
 ssl on;
 ssl_certificate /etc/letsencrypt/live/votredomaine.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/votredomaine.com/privkey.pem;
 ```

Pour terminer, il ne vous reste plus qu’à modifier à nouveau l’url de votre blog dans le fichier config.js et à ajouter un block server pour faire la redirection http vers https :

server {
listen 80;
server_name votredomaine.com www.votredomaine.com;
return 301 https://votredomaine.com$request_uri;

}

Configurer Nginx en reverse-proxy avec Let's Encrypt pour Proxmox 4

Wed, 22 Mar 2017 18:33:31 +0000

Il y a plusieurs solutions pour sécuriser l’accès à l’interface Proxmox, mais si vous avez l’habitude tout comme moi de nginx, elle est la plus intéressante car elle permet non seulement d’utiliser le domaine de votre choix pour accéder à l’interface sur le port standard 443, mais également de ne pas vous retrouver bloqué par le firewall en cas de mauvaise configuration.

Dans ce tutorial, nous allons donc voir comment installer nginx et comment le configurer pour obtenir un certificat Let’sEncrypt et sécuriser ainsi l’interface de Proxmox.

==La méthode détaillée dans cet article n’est pas compatible avec Proxmox VE 5==

On commence par installer nginx :

apt-get install nginx

Puis on créer un fichier /etc/nginx/conf.d/proxmox.conf :

upstream proxmox {
 server "votre.serveur.hostname";
}

server {
 server_name proxmox.votredomaine.com;
 rewrite ^(.*) https://$host$1 permanent;
location /.well-known {
 alias /var/www/html/.well-known;
 }

}

Pour appliquer la configuration, on utilise la commande service nginx reload. On peut désormais passer à l’installation de Let’s Encrypt si ce n’est pas déjà fait.

cd /opt
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt

Il ne nous reste plus qu’à générer le certificat via la commande :

./letsencrypt-auto certonly --webroot -w /var/www/html -d proxmox.votredomaine.com --email votreemail@votredomaine.com --text --agree-tos

Let’s Encrypt va alors effectuer l’opération de vérification en créer un dossier .well-known dans /var/www/html puis générer votre certificat. Nous pouvons donc désormais ajouter les lignes suivantes à notre fichier /etc/nginx/conf.d/proxmox.conf afin d’utiliser le certificat :

server {
 listen 443;
 server_name proxmox.votredomaine.com;
 ssl on;
 ssl_certificate /etc/letsencrypt/live/proxmox.votredomaine.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/proxmox.votredomaine.com/privkey.pem;
 proxy_redirect off;
 location / {
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection "upgrade";
 proxy_pass https://localhost:8006;
 proxy_buffering off;
 client_max_body_size 0;
 proxy_connect_timeout 3600s;
 proxy_read_timeout 3600s;
 proxy_send_timeout 3600s;
 send_timeout 3600s;
 }
}

On utilise à nouveau la commande service nginx reload pour appliquer la configuration et nous pouvons désormais accéder à l’interface proxmox via l’adresse : https://proxmox.votredomaine.com. Vous pouvez ajouter un cron pour renouveler automatiquement votre certificat letsencrypt tous les 30 jours :

0 0 1 * * /opt/letsencrypt-auto certonly --webroot -w /var/www/html -d proxmox.votredomaine.com --email votreemail@votredomaine.com --text --agree-tos

EasyEngine - Nginx et WordPress en quelques minutes

Sun, 05 Feb 2017 00:45:11 +0000

J’utilise un certain nombre d’outils au quotidien pour installer des serveurs, et EasyEngine est sans aucun doute dans le top 3. Je vais donc vous présenter se petit outil à utiliser en ligne de commande sur votre serveur debian/ubuntu pour installer Nginx avec/sans WordPress en quelques minutes.

EasyEngine doit être installé sur un nouveau serveur, n’ayant déjà Apache ou MySQL.

Pour installer EasyEngine, utilisez la commande :

wget -qO ee rt.cx/ee && sudo bash ee

Il vous sera uniquement demandé un nom d’utilisateur et votre adresse mail. Une fois l’installation terminée, pour vérifier son fonctionnement, utilisez simplement la commande :

ee

Vous aurez alors la liste des arguments disponibles. Pour installer WordPress sur un domaine par example :

ee site create votredomaine.fr --wp

Lors du premier lancement de cette commande, EasyEngine va installer Nginx, php et MariaDB puis WordPress. Vous pouvez ajoutez des arguments supplémentaires après “–wp” afin d’ajouter une solution de cache, choisir php7 plutôt que php5 ou utiliser letsencrypt pour générer un certificat SSL.

Dans le cas du blog, j’ai utilisé la commande :

ee site create jesuisadmin.fr --wpredis --php7 --letsencrypt

–wpredis afin d’installer WordPress avec Redis-server et le plugin Redis-object-cache
–php7 pour installer php7
–letsencrypt pour générer et installer un certificat letsencrypt.

Vous pouvez retrouvez cette liste des commandes disponibles sur le site d’EasyEngine.