Letsencrypt

De Le Wiki du Forum-Debian.fr
Aller à la navigation Aller à la recherche

Salut,

Je l'utilise depuis plus d'un mois maintenant, et je n'ai pas trouvé quoi que ce soit à redire sur ce soft, et les services qu'il offre:
Créer votre certificat SSL, que ce soit pour votre domaine ou votre sous-domaine, simplement et gratuitement... Que demander de plus ?

Ci-dessous, après le chapitre "Installation", vous trouverez des recommandations pour Apache, puis Nginx, puis quelques informations concernant SSL.

Installation

Il y a bien un paquet Debian, mais il m'a posé des problèmes (de sombres histoires de dépendances python que je n'ai pas cherché à résoudre...).


# apt-get install -s python-letsencrypt

Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Certains paquets ne peuvent être installés. Ceci peut signifier
que vous avez demandé l'impossible, ou bien, si vous utilisez
la distribution unstable, que certains paquets n'ont pas encore
été créés ou ne sont pas sortis d'Incoming.
L'information suivante devrait vous aider à résoudre la situation : 

Les paquets suivants contiennent des dépendances non satisfaites :
 python-letsencrypt : Dépend: python-acme (>= 0.4.1) mais ne sera pas installé
                      Dépend: python-cryptography (>= 0.7) mais 0.6.1-1 devra être installé
                      Recommande: letsencrypt mais ne sera pas installé
E: Impossible de corriger les problèmes, des paquets défectueux sont en mode « garder en l'état ».

Sans parler d'un bug dans les dépendances:


# apt-listbugs list python-letsencrypt-apache

Récupération des rapports de bogue… Fait
Analyse des informations Trouvé/Corrigé… Fait
bogues de gravité serious sur python-letsencrypt-apache (→ ) <Résolus dans une version donnée>
 b1 - #818696 - Fails to build twice - clean does not clean enough (Corrigé : python-letsencrypt-apache/0.5.0-1)
Résumé :
 python-letsencrypt-apache(1 bogue)

J'ai donc choisi de l'installer via les sources !


 ATTENTION : Depuis le mois de mai 2016, le client officiel a changé, et se nomme 'certbot' ... Pour plus d'informations, veuillez lire : https://letsencrypt.org/getting-started/ !
En bref, la commande n'est plus 'letsencrypt' et 'letsencrypt-auto', mais 'certbot' et 'certbot-auto'


Prérequis: activer et configurer le serveur web

Si vous fonctionnez avec le mod-proxy d'apache2

# a2enmod proxy proxy_http
$editeur /etc/apache2/mods-enabled/proxy.conf


J'ai choisi le port 9999, libre à vous d'en prendre un autre.

  <IfModule mod_proxy.c>
      ProxyPass "/.well-known/acme-challenge/" "http://127.0.0.1:9999/.well-known/acme-challenge/" retry=1
      ProxyPassReverse "/.well-known/acme-challenge/" "http://127.0.0.1:9999/.well-known/acme-challenge/"
      <Location "/.well-known/acme-challenge/">
          ProxyPreserveHost On
          Order allow,deny
          Allow from all
          Require all granted
      </Location>
  </IfModule>


# apache2ctl restart


Si vous fonctionnez avec Nginx

La première chose à rajouter est l'écriture suivante, dans la section 'server' :

location '/.well-known' {
        allow all;
}
location '/.well-known/acme-challenge' {
        allow all;
}

Puis tester la config nginx et la recharger si ok :


# nginx -t
service nginx reload


Installation:

# apt-get install git
cd /opt && git clone https://github.com/letsencrypt/letsencrypt


Les autres dépendances de letsencrypt seront installées à la génération de votre premier certificat

Premier lancement et création du premier certificat:

 ATTENTION : Un DNS doit être configuré, et renvoyer sur votre serveur Web, sinon ça ne fonctionne pas. Il faut configurer un vhost, et le faire pour chaque domaine et sous-domaine !


La commande magique:


# cd /opt/letsencrypt/ && ./letsencrypt-auto --agree-tos --renew-by-default --standalone --standalone-supported-challenges http-01 --http-01-port 9999 --server https://acme-v01.api.letsencrypt.org/directory certonly -d domaine.tld


Il installera automatiquement les dépendances manquantes :

Bootstrapping dependencies for Debian-based OSes...
...
Les NOUVEAUX paquets suivants seront installés :
  augeas-lenses cpp cpp-4.9 dh-python dialog gcc gcc-4.9 libasan1 libatomic1 libaugeas0 libc-dev-bin libc6-dev libcilkrts5 libcloog-isl4 libexpat1-dev
  libffi-dev libgcc-4.9-dev libisl10 libitm1 liblsan0 libmpc3 libmpdec2 libmpfr4 libpython-dev libpython2.7-dev libpython3-stdlib libpython3.4-minimal
  libpython3.4-stdlib libssl-dev libtsan0 libubsan0 linux-libc-dev python-chardet-whl python-colorama-whl python-dev python-distlib-whl
  python-html5lib-whl python-pip-whl python-pkg-resources python-requests-whl python-setuptools-whl python-six-whl python-urllib3-whl python-virtualenv
  python2.7-dev python3 python3-minimal python3-pkg-resources python3-virtualenv python3.4 python3.4-minimal virtualenv zlib1g-dev
...

Vous demandera un mail de contact Et finalement vous créera un joli certificat!

- Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/domaine.tld/fullchain.pem. Your
   cert will expire on 2016-07-18. To obtain a new version of the
   certificate in the future, simply run Let's Encrypt again.


# ls /etc/letsencrypt/live/domaine.tld
cert.pem chain.pem fullchain.pem privkey.pem


Configuration des certificats

Si vous fonctionnez avec Apache 2 :

Éditez votre VHOST et faites pointer les certificats vers les bons fichiers :

...
<VirtualHost xxx.xxx.xxx.xxx:443>
...
                <IfModule mod_ssl.c>
                SSLEngine on
                SSLProtocol All -SSLv2 -SSLv3
                SSLCertificateFile /etc/letsencrypt/live/votredomaine/fullchain.pem
                SSLCertificateKeyFile /etc/letsencrypt/live/votredomaine/privkey.pem
                SSLCACertificateFile /etc/letsencrypt/live/votredomaine/fullchain.pem
                </IfModule>

Rechargez apache :


# /etc/init.d/apache2 force-reload


Si vous fonctionnez avec Nginx :

=> Il faut modifier le contexte 'server' de votre domaine, pour modifier celui-ci, le mieux étant de le faire dans un fichier de config à part, puis de l'inclure dans votre contexte, tel que 'ssl.cfg' :

include /repertoire_vers_le_fichier_config_ssl/ssl.cfg;


 NOTE : Pensez à virer la déclaration d'écoute sur le port 80 !


Fichier 'ssl.cfg' :

listen 443 ssl spdy;
#listen [::]:443 ssl spdy; # si ipv6 actif, à décommenter !

spdy_headers_comp 9;
ssl on;


 ATTENTION : Si votre version de nginx est >= 1.9.5, ne plus utiliser les déclarations 'spdy', mais 'http2' !


=> Ensuite, on va ajouter les autres déclarations liées à l'usage du protocole SSL :

Fichier 'ssl.cfg' :

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

ssl_certificate /opt/letsencrypt/live/votre_domaine.tld/fullchain.pem;
ssl_certificate_key /opt/letsencrypt/live/votre_domaine.tld/privkey.pem;
ssl_trusted_certificate /opt/letsencrypt/live/votre_domaine.tld/chain.pem;

ssl_dhparam /etc/ssl/private/dhp_4096.pem;

#ssl_ecdh_curve chiffrement_edch_choisi;

ssl_prefer_server_ciphers on;

# Intermediate Mode
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
#ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:$
# Modern Mode
#ssl_protocols TLSv1.2;
#ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:EC$
# More secure Mode
#ssl_ciphers 'ECDH:DH:AES:!aNULL:!eNULL:!NULL:!DES:!3DES:!DSS:!EXPORT:!LOW:!MEDIUM:!PSK:!RC4:!SHA';

ssl_session_cache shared:SSL:10m;

ssl_session_tickets off;
#ssl_session_ticket_key /repertoire_vers_le_fichier_config_ticket_ssl/ticket.key;
ssl_session_timeout 24h;

ssl_stapling on;
ssl_stapling_verify on;

#resolver 127.0.0.1;
# resolvers FDN, OpenNIC
resolver 80.67.169.12 80.67.169.40 142.4.204.111 142.4.205.47 valid=300s;
# resolver ipv6 : FQDN
#resolver 2001:910:800::12 2001:910:800::40 valid=300s;
resolver_timeout 3s;

Un peu d'explication ne fera pas de mal, non ?!

La première déclaration 'add_header' est liée à l'information HTTP STS qui demande au navigateur web de communiquer uniquement sur le protocole HTTPS, durant la période déclarée. La valeur '31536000' correspond à une année ... valeur qui peut, bien-sûr, être changée !

Les trois autres premières déclarations sont liées aux certificats SSL créés ...

ssl_dhparam: Si vous avez créé votre clé Diffie Hellman, c'est là qu'il faut lui indiquer où elle se trouve ... Sinon, un petit code shell, tel que, devrait vous servir :


# openssl dhparam -rand - 4096 -out "/repertoire_ou_vous_voulez/dh_4096.pem"; chmod 0400 /repertoire_ou_vous_voulez/dh_4096.pem


ssl_ecdh_curve: est le chiffrement ECDHE choisi - à n'utiliser que si vous avez choisi de créer des clés ECDSA ... ce qui avec le client officiel ne peut pas être le cas, à ce jour ...

ssl_protocols: On bannit tous les anciens modes SSL, pour n'utiliser QUE les modes TLS. C'est un impératif de sécurité !

ssl_ciphers: choisissez en décommentant l'un des modes en question ...

  • le mode "Intermediate" est à utiliser si vous voulez que d'anciens navigateurs web puissent accéder à votre site en HTTPS.
  • le mode "Modern" est à utiliser rien que pour les versions récentes de navigateurs web ...
  • le mode "secure" refuse ABSOLUMENT certains chiffrements ...
  • le mode le plus sécurisé est à ce jour : 'ECDHE:!aNULL:!eNULL:!NULL:!DES:!3DES:!DSS:!EXPORT:!LOW:!MEDIUM:!PSK:!RC4:!SHA' qui n'utilise que les chiffrements ECDHE !

ssl_session_tickets et ssl_session_ticket_key sont à utiliser, si et seulement si, vous désirez l'usage des tickets SSL ... dans ce cas, il faut générer un ticket de chiffrement de session ssl, tel que :


# openssl rand 48 > /repertoire_ou_vous_voulez/ticket.key; chmod 0400 /repertoire_ou_vous_voulez/ticket.key


ssl_stapling et ssl_stapling_verify sont liés au mode OCSP stapling est un mode particulier qui oblige vos clients navigateurs web à faire la vérification relative à la validité de votre certificat SSL/TLS à partir de votre serveur web. C'est votre serveur web qui interroge le serveur OCSP, mets en cache l'information, et la restitue à vos clients ... à utiliser, de forte préférence ...

resolver: ce sont les serveurs DNS à interroger !


Bon, toutes ces modifications ayant été faites, testez votre config nginx, puis relancez le service !

Renouvellement

Comme précisé dans le message de félicitation, votre certificat n'est valide que pour 3 mois... Il faut donc tout de suite se couvrir et prévoir le renouvellement.
La solution que j'ai choisie : crontab. Si le certificat n'a pas besoin d'être renouvelé, rien ne se passe. Il est donc tout à fait correct d'exécuter le script quotidiennement.


# crontab -e

30 1 * * * cd /opt/letsencrypt/ && ./certbot-auto renew

Les liens symboliques vers les certificats sont automatiquement gérés par certbot, il n'y a rien à mettre à jour.

Voilà! Je repasserais sûrement dans ce T&A au fur et à mesure de vos commentaires sur le forum debian-fr.xyz

Lol (discussion) 20 avril 2016 à 13:29 (CEST)