Le blog technique de Microlinux

Cet article décrit la mise en place d’un hébergement sécurisé sur un serveur Apache tournant sous CentOS 7. Le protocole HTTP (Hypertext Transfer Protocol) transmet les données entre le serveur et le navigateur « en clair ». Les données personnelles, mots de passe et autres numéros de Carte Bleue sont donc interceptables. Pour résoudre ce problème, on utilisera le protocole HTTPS, qui ajoute une couche de cryptage SSL (Secure Sockets Layer) au protocole HTTP.

Le transfert crypté des données ne constitue qu’un aspect dans l’établissement d’une connexion sécurisé. L’autre aspect tout aussi important, c’est que l’utilisateur doit être sûr de communiquer avec la bonne personne. Autrement dit, votre numéro de Carte Bleue a beau être transmis de façon sécurisée, encore faut-il que la plateforme de paiement ne soit pas située sur un serveur géré par la mafia albanaise.

Pour savoir si l’on a bien affaire au bon interlocuteur, on utilisera un certificat. Cette véritable carte d’identité électronique contient non seulement la clé publique du serveur pour crypter les transmissions, mais également des renseignements sur le site ainsi que la signature de l’autorité de certification.

La génération d’un certificat électronique fait l’objet d’un article à part. Pour nos essais, nous utiliserons un certificat SSL/TLS fourni par le client Certbot. Si l’on décide de partir sur un certificat auto-signé, la configuration devra être adaptée en conséquence.

Dans l’exemple ci-dessous, nous allons configurer un hébergement public https://www.slackbox.fr.

• Prérequis
• Installation
• Configurer Apache et SSL
• Améliorer la sécurité de notre hébergement
• La politique HSTS
• Héberger plusieurs sites sécurisés

Prérequis

Le protocole HTTPS utilise le port 443. Il faut donc songer avant toute chose à ouvrir ce port dans le pare-feu.

Installation

Le chiffrement SSL/TLS pour Apache est fourni par le paquet mod_ssl.

# yum install mod_ssl

On notera l’apparition d’un fichier de configuration ssl.conf dans /etc/httpd/conf.d.

Configurer Apache et SSL

Avant de continuer, effectuer une copie de sauvegarde du fichier de configuration par défaut.

# cd /etc/httpd/conf.d
# cp ssl.conf ssl.conf.orig

Partant d’un répertoire /var/www/html vide, on peut récupérer un peu de contenu statique pour avoir quelque chose à nous mettre sous la dent.

# cd /var/www/html/
# cp -R /usr/share/httpd/noindex/* .

Régler les permissions de l’arborescence de fichiers téléchargés.

# chown -R microlinux:microlinux *
# find . -type d -exec chmod 0755 \{} \;
# find . -type f -exec chmod 0644 \{} \;

Ensuite, éditer /etc/httpd/conf.d/ssl.conf en renseignant les directives DocumentRoot et ServerName ainsi que l’emplacement du certificat SSL et de la clé privée.

##
## SSL Virtual Host Context
##
<VirtualHost _default_:443>
DocumentRoot "/var/www/html"
ServerName www.slackbox.fr:443
...
SSLCertificateFile /chemin/vers/cert.pem
SSLCertificateKeyFile /chemin/vers/privkey.pem
SSLCertificateChainFile /chemin/vers/fullchain.pem
...
</VirtualHost>

Redémarrer Apache.

# systemctl restart httpd

Ouvrir le site avec Firefox. On notera la présence du petit cadenas vert en haut à gauche dans la barre d’adresses pour indiquer l’établissement d’une connexion sécurisée.

Améliorer la sécurité de notre hébergement

Rendons-nous sur la page SSL Server Test du portail Qualys SSL Labs pour effectuer un audit de la sécurité de notre hébergement.

Pour l’heure, la résultat est plutôt médiocre et comporte une série de vulnérabilités, que nous allons éliminer l’une après l’autre en suivant les suggestions affichées.

La vulnérabilité à l’attaque POODLE se résoud en désactivant SSLv3 dans ssl.conf. L’option SSLProtocol se situe dans la configuration de l’hôte virtuel. Il faut la déplacer au début du fichier dans les options globales, en ajoutant -SSLv3, comme ceci.

#
# When we also provide SSL we have to listen to the 
# the HTTPS port in addition.
#
Listen 443 https

##
##  SSL Global Context
##
##  All SSL configuration in this context applies both to
##  the main server and all SSL-enabled virtual hosts.
##

#   SSL Protocol support:
# List the enable protocol levels with which clients will be able 
# to connect.  Disable SSLv2 access by default:
SSLProtocol all -SSLv2 -SSLv3

Prendre en compte les modifications et relancer un test sur le site de Qualys Labs en cliquant sur Clear cache.

C’est déjà un peu mieux. La prochaine suggestion concerne la désactivation du chiffrement RC4. Cette fois-ci, il faut récupérer l’option SSLCipherSuite dans la configuration de l’hôte virtuel et la placer en tête du fichier dans les options globales, en ajoutant !RC4.

#   SSL Protocol support:
# List the enable protocol levels with which clients will be able to
# connect.  Disable SSLv2 access by default:
SSLProtocol all -SSLv2 -SSLv3

#   SSL Cipher Suite:
#   List the ciphers that the client is permitted to negotiate.
#   See the mod_ssl documentation for a complete list.
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA:!RC4

Recharger la configuration d’Apache et relancer un test.

On avance petit à petit. Pour nous débarrasser de la vulnérabilité restante, repérer l’option commentée SSLHonorCipherOrder et l’insérer juste après SSLCipherSuite en la décommentant.

#   SSL Cipher Suite:
#   List the ciphers that the client is permitted to negotiate.
#   See the mod_ssl documentation for a complete list.
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA:!RC4
SSLHonorCipherOrder on

Cette fois-ci, nous avons bel et bien éliminé l’ensemble des failles de sécurité connues concernant le chiffrement.

La politique HSTS

HSTS (HTTP Strict Transport Security) est un mécanisme de politique de sécurité proposé pour HTTP, permettant à un serveur web de déclarer à un agent utilisateur (navigateur web) compatible qu’il doit interagir avec lui en utilisant une connexion sécurisée (comme HTTPS). La politique est donc communiquée à l’agent utilisateur par le serveur via la réponse HTTP, dans le champ d’en-tête nommé Strict-Transport-Security. La politique spécifie une période de temps durant laquelle l’agent utilisateur doit accéder au serveur uniquement de façon sécurisée.

Pour activer cette politique dans la configuration d’Apache, il suffit d’ajouter la ligne suivante dans la définition de l’hôte virtuel.

<VirtualHost _default_:443>
# HSTS
Header always set Strict-Transport-Security \
  "max-age=63072000; includeSubDomains"
...
</VirtualHost>

L’audit de sécurité nous montre qu’on est assez proche de la perfection.

Héberger plusieurs sites sécurisés

Si l’on souhaite héberger plusieurs sites sécurisés sous forme d’hôtes virtuels Apache, la solution la plus propre consiste à éditer /etc/httpd/conf.d/ssl.conf pour ne garder que les options globales, comme ceci par exemple.

# /etc/httpd/conf.d/ssl.conf
Listen 443 https
SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog
SSLSessionCache         shmcb:/run/httpd/sslcache(512000)
SSLSessionCacheTimeout  300
SSLRandomSeed startup file:/dev/urandom  256
SSLRandomSeed connect builtin
SSLCryptoDevice builtin
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA:!RC4
SSLHonorCipherOrder on

Ensuite, chaque hôte virtuel disposera de son propre fichier de configuration dans /etc/httpd/conf.d. Voici un exemple.

# /etc/httpd/conf.d/www.slackbox.fr.conf

# http://www.slackbox.fr -> https://www.slackbox.fr
<VirtualHost *:80>
  ServerName www.slackbox.fr
  ServerAlias slackbox.fr
  Redirect / https://www.slackbox.fr
</VirtualHost>

# https://www.slackbox.fr
<VirtualHost _default_:443>
  Header always set Strict-Transport-Security \
    "max-age=63072000; includeSubDomains"
  ServerAdmin info@microlinux.fr
  DocumentRoot "/var/www/html/slackbox-site/html"
  ServerName www.slackbox.fr:443
  ServerAlias slackbox.fr
  SSLEngine on
  SSLCertificateFile /etc/letsencrypt/.../cert.pem
  SSLCertificateKeyFile /etc/letsencrypt/.../privkey.pem
  SSLCertificateChainFile /etc/letsencrypt/.../fullchain.pem
  BrowserMatch "MSIE [2-5]" \
    nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0
  ErrorLog logs/www.slackbox.fr-error_log
  CustomLog logs/www.slackbox.fr-access_log common
</VirtualHost>

Cet article décrit la gestion des certificats SSL/TLS gratuits sur un serveur dédié tournant sous CentOS 7. Un certificat électronique peut être vu comme une carte d’identité numérique. Il est utilisé principalement pour identifier et authentifier une personne physique ou morale, ou pour chiffrer des échanges. Il est signé par un tiers de confiance qui atteste du lien entre l’identité physique et l’entité numérique. Le standard le plus utilisé pour la création des certificats numériques est le X.509.

Les prix des certificats électroniques sont extrêmement variables, et certaines entreprises comme par exemple Verisign les font payer très cher. En revanche, il est tout à fait possible de les avoir gratuitement…

• en utilisant Certbot, le client Let’s Encrypt ;
• en générant un certificat auto-signé.

Let’s Encrypt est une autorité de certification lancée le 3 décembre 2015 en version bêta publique. Elle fournit des certificats SSL/TLS gratuits grâce au client Certbot installé sur le serveur qui automatise la plupart des tâches. On n’est donc plus obligé de payer une fortune et/ou de sauter à travers des cerceaux en feu pour créer et renouveler les certificats.

Les certificats générés avec Certbot sont reconnus par l’ensemble des navigateurs Web modernes. Cette technologie repose sur le protocole ACME (Automated Certificate Management Environment).

• Installation
• Plug-ins
• Tester Certbot et générer un certificat
• Utiliser et tester le certificat
• Renouveler un certificat
• Révoquer un certificat
• Certificats et permissions
• Automatiser la procédure
• Certificat SAN multi-domaines
• Le cas de figure domaine-0001
• Téléchargement

Installation

Certbot est fourni par le dépôt EPEL.

# yum install certbot

On notera au passage que le paquet dépend d’une quantité importante de modules Python.

Plug-ins

Le client Certbot supporte une série de plug-ins pour Apache et Nginx. L’option plugins permet d’afficher les plug-ins installés.

# certbot plugins
Saving debug log to /var/log/letsencrypt/letsencrypt.log
* standalone
Description: Spin up a temporary webserver
Interfaces: IAuthenticator, IPlugin
Entry point: standalone = certbot.plugins.standalone:Authenticator

* webroot
Description: Place files in webroot directory
Interfaces: IAuthenticator, IPlugin
Entry point: webroot = certbot.plugins.webroot:Authenticator

Notre installation dispose des plug-ins standalone et webroot.

Tester Certbot et générer un certificat

Pour commencer, nous allons générer un certificat pour le domaine slackbox.fr. Étant donné que la requête utilise le port 443, il faut d’abord arrêter le serveur Web. En passant, il faudra éventuellement vérifier si le port 443 est bien ouvert dans le pare-feu.

# systemctl stop httpd

Pour nos tests, nous allons partir d’une installation par défaut d’Apache.

• Vider le répertoire /var/www/html
• Supprimer les hôtes virtuels dans /etc/httpd/conf.d

Dans un premier temps, nous allons tester la génération du certificat comme ceci.

# certbot certonly --non-interactive --email info@microlinux.fr \
  --preferred-challenges tls-sni-01 --standalone --agree-tos \
  --renew-by-default --webroot-path /var/www/html \
  -d slackbox.fr -d www.slackbox.fr --test-cert

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Starting new HTTPS connection (1): acme-staging.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for slackbox.fr
tls-sni-01 challenge for www.slackbox.fr
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
 /etc/letsencrypt/live/slackbox.fr/fullchain.pem. Your cert will
 expire on 2017-10-03. To obtain a new or tweaked version of this
 certificate in the future, simply run certbot again. To
 non-interactively renew *all* of your certificates, run "certbot
 renew"

Pour en savoir un peu plus sur les options utilisées, on peut afficher l’aide de certbot comme ceci.

# certbot --help all | less

Si tout s’est passé comme prévu, on peut réitérer la commande ci-dessus en omettant l’option --test-cert pour générer le certificat pour de vrai.

Les fichiers générés se trouvent tous dans le répertoire /etc/letsencrypt/live/<domaine>. On va donc jeter un oeil.

# ls -1 /etc/letsencrypt/live/slackbox.fr/
cert.pem  
chain.pem  
fullchain.pem  
privkey.pem

À quoi correspondent ces fichiers ?

• privkey.pem : c’est la clé privée pour le certificat. Ce fichier ne doit surtout pas être divulgué. Le serveur doit pouvoir y accéder pour que SSL/TLS fonctionne. C’est ce qu’Apache utilisera comme fichier SSLCertificateKeyFile.
• cert.pem : le certificat du serveur. C’est ce qui correspond au SSLCertificateFile d’Apache.
• chain.pem : les certificats requis par le navigateur hormis le certificat du serveur. Requis par Apache < 2.4.8 pour le SSLCertificateChainFile.
• fullchain.pem : tous les certificats, y compris celui du serveur. Il s’agit là de la concaténation de chain.pem et de cert.pem. C’est requis par Apache >= 2.4.8 pour le SSLCertificateFile.

On pourrait théoriquement tenter de créer un certificat propre au FQDN de la Dedibox.

# certbot certonly --non-interactive --email info@microlinux.fr \
  --preferred-challenges tls-sni-01 --standalone \
  --renew-by-default --agree-tos \
  --webroot-path /var/www/html -d sd-100246.dedibox.fr 

Avec un peu de chance, ça passe. Dans le cas contraire, on est gratifié d’un message d’erreur de dépassement de quota en raison d’un nombre de sous-domaines trop élevé pour le domaine dedibox.fr. Cela dépend des jours.

Utiliser et tester le certificat

Pour commencer, on peut mettre en place un hébergement sécurisé avec le serveur Web Apache. La procédure détaillée fait l’objet d’un article à part. Voici la stance correspondante dans la configuration d’Apache.

...
SSLCertificateFile "/chemin/vers/cert.pem"
SSLCertificateKeyFile "/chemin/vers/privkey.pem"
SSLCertificateChainFile "/chemin/vers/fullchain.pem"
...

Renouveler un certificat

La durée de vie d’un certificat est de 90 jours, ce qui n’est pas beaucoup. Pour prolonger la validité d’un certificat, il suffit de le renouveler en réinvoquant exactement la même commande utilisée pour le générer initialement.

Révoquer un certificat

Dans certains cas de figure – par exemple lorsqu’on déménage un hébergement vers une autre machine avec une adresse IP différente – il peut être nécessaire de révoquer un certificat avant de le générer ailleurs. On peut le faire comme ceci.

# cd /etc/letsencrypt/live
# certbot --text revoke --cert-path chemin/vers/cert.pem

Certificats et permissions

Si l’on souhaite utiliser plusieurs applications sécurisées pour un même domaine (Web, courrier, messagerie XMPP), on se retrouve confronté à un problème de permissions. Concrètement, si le serveur Web ainsi que le serveur de messagerie Prosody doivent accéder en lecture au certificat et à la clé privée, on peut utiliser la solution qui suit.

On crée un groupe système certs, on ajoute les utilisateurs système respectifs à ce groupe et on règle les permissions des fichiers en fonction, c’est-à-dire root:certs. Concrètement :

# groupadd -g 240 certs
# chgrp -R certs /etc/letsencrypt
# chmod -R g=rx /etc/letsencrypt

Si l’on souhaite qu’une application accède au certificat et à la clé privée, il suffit qu’on ajoute l’utilisateur correspondant au groupe système certs. Exemple pour la messagerie XMPP Prosody :

# usermod -a -G certs prosody

Notez que ce n’est pas la peine d’ajouter l’utilisateur apache au groupe certs. Au démarrage, le serveur Apache s’exécute avec les droits root, puis lance une série de processus enfants avec des droits restreints :

# ps aux | grep httpd | grep -v grep
root   3168 0.0 0.2 ... /usr/sbin/httpd -DFOREGROUND
apache 3169 0.0 0.2 ... /usr/sbin/httpd -DFOREGROUND
apache 3170 0.0 0.3 ... /usr/sbin/httpd -DFOREGROUND
apache 3171 0.0 0.3 ... /usr/sbin/httpd -DFOREGROUND
apache 3254 0.0 0.3 ... /usr/sbin/httpd -DFOREGROUND

Automatiser la procédure

La procédure de génération et de renouvellement peut être automatisée à l’aide d’un petit script. Voici un exemple.

#!/bin/bash
#
# mkcert.sh
#
# Create/renew SSL/TLS certificate

# Create certs group with GID 240
if ! grep -q "^certs:" /etc/group ; then
  groupadd -g 240 certs
  echo ":: Added certs group."
  sleep 3
fi

# Stop Apache
if ps ax | grep -v grep | grep httpd > /dev/null ; then
  echo ":: Stopping Apache."
  systemctl stop httpd 1 > /dev/null 2>&1
  sleep 5
fi

# Generate SSL/TLS certificate
certbot certonly \
  --non-interactive \
  --email info@microlinux.fr \
  --preferred-challenges tls-sni-01 \
  --standalone \
  --agree-tos \
  --renew-by-default \
  --webroot-path /var/www/html \
  -d slackbox.fr -d www.slackbox.fr

# Fix permissions
echo ":: Setting permissions."
chgrp -R certs /etc/letsencrypt
chmod -R g=rx /etc/letsencrypt

# Start Apache
echo ":: Starting Apache."
systemctl start httpd

À partir de là, on peut définir une tâche automatique (cronjob) pour renouveler le certificat tous les débuts de mois, comme ceci par exemple.

# crontab -l
# Renouveler le certificat SSL le 1er du mois à 4h30
30 4 1 * * /usr/local/sbin/mkcert.sh 1> /dev/null

Certificat SAN multi-domaines

Dans certains cas de figure, notamment lorsqu’on met en place le serveur de messagerie Postfix, on peut avoir besoin de regrouper les certificats pour plusieurs domaines dans un seul certificat SAN (Subject Alternative Names). Pour générer un certificat SAN multi-domaine, on pourra adapter le script ci-dessus.

Voici un exemple pour un certificat SAN pour les domaines slackbox.fr et unixbox.fr et les sous-domaines mail.slackbox.fr et mail.unixbox.fr.

# Generate SSL/TLS certificate
certbot certonly \
  --non-interactive \
  --email info@microlinux.fr \
  --preferred-challenges tls-sni-01 \
  --standalone \
  --agree-tos \
  --renew-by-default \
  --webroot-path /var/www/html/slackbox-site/html \
  -d slackbox.fr -d www.slackbox.fr \
  --webroot-path /var/www/html/slackbox-mail/html \
  -d mail.slackbox.fr \
  --webroot-path /var/www/html/unixbox-site/html \
  -d www.unixbox.fr -d unixbox.fr \
  --webroot-path /var/www/html/unixbox-mail \
  -d mail.unixbox.fr

Le cas de figure domaine-0001

Il peut arriver qu’on soit confronté à la création d’un répertoire domaine-0001 dans /etc/letsencrypt/live, par exemple suite à la suppression d’un sous-domaine pour un certificat SAN. Du coup les chemins vers les certificats ne sont plus valides, et c’est une belle pagaille.

La manière la plus simple de rectifier le tir pour récupérer une configuration consiste à faire le ménage « à la louche ».

1. Révoquer tous les certificats.
2. Supprimer le contenu de l’arborescence.
3. Relancer le script pour générer les certificats.

Téléchargement

Un modèle de script mkcert.sh est disponible au téléchargement dans mon dépôt Github centos, dans le répertoire el7/certbot.

$ git clone https://github.com/kikinovak/centos