Installer certbot-auto
Je suis sous Debian 7, et apache 2.2
Obtenir la copie de certbot-auto sur son serveur
$ wget https://dl.eff.org/certbot-auto
Rendre exécutable
$ chmod a+x certbot-auto
Exécutez le script :
$./certbot-auto
Patienter quelques minutes le temps d’installer Python et autre configuration, répondez Yes à la question. Ensuite entrez un email pour recevoir des emails, utile en cas de problème, notification de renouvellement, sécurité.
Ensuite le programme va vous lister les domaines qui sont sur votre serveur dédié, entrez les domaine séparés par une virgule ou espace (les nombres pas les noms de domaine). Le message suivant vous demande de sauvegarder le répertoire où tous les fichiers seront sauvegardés.
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address.
- Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
Créer un certificat SSL pour un domaine
Pour ajouter un certificat SSL tapez la commande suivante:
./certbot-auto certonly --webroot -w /home/domaine/public_html -d www.domaine.com -d domaine.com -w /home/sousdomaine/public_html -d sous.domaine.com -w /home/autredomaine/public_html -d www.autredomaine.fr
Que fait certbot-auto avec cette commande?
Il va d’abord créer des CSR, et ensuite les fichiers pem qui sont les clé SSL proprement dites. Un fichier de configuration à inclure au format .conf est créé qui contient les directives SSL pour Apache. Le fichier httpd.conf doit inclure ce fichier pour comprendre les certificats SSL.
Contenu du fichier options-ssl-apache.conf :
# Baseline setting to Include for SSL sites
SSLEngine on
# Intermediate configuration, tweak to your needs
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLHonorCipherOrder on
SSLCompression off
SSLOptions +StrictRequire
# Add vhost name to log entries:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" vhost_combined
LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common
#CustomLog /var/log/apache2/access.log vhost_combined
#LogLevel warn
#ErrorLog /var/log/apache2/error.log
# Always ensure Cookies have "Secure" set (JAH 2012/1)
#Header edit Set-Cookie (?i)^(.*)(;\s*secure)??((\s*;)?(.*)) "$1; Secure$3$4"
On retrouve les directives qui font fonctionner le SSL :
SSLEngine on
SSLProtocol
SSLCipherSuite
SSLHonorCipherOrder
SSLCompression
SSLOptions
Remarque vous devez avoir activé le module SSL pour Apache avec la commande a2enmod ssl
Les clés au format pem sont dans le sous répertoire live. Il y en a 4, cert.pem, chain.pem (pour Nginx), fullchain.pem (le certificat) et privkey.pem la clé privée (très important à ne pas divulguer). Ces fichiers qu’il ne faut surtout pas déplacer, sont à la base du fonctionnement.
Créer un fichier pour la version https du site
Il faut créer un fichier pour la version SSL (https) de votre site sans quoi ça ne marcherait pas. En gros c’est des lignes de configuration de la même manière que http, mais englobé dans une directive <IfModule mod_ssl.c>
Voici un exemple
<IfModule mod_ssl.c>
<VirtualHost 163.172.63.51:443>
SuexecUserGroup "#1027" "#1025"
ServerName www.domaine.net
FcgidMaxRequestLen 2000000
DocumentRoot /home/domaine/public_html
ErrorLog /home/domaine/logs/ssl_error_log
CustomLog /home/domaine/logs/ssl_access_log combined
<Directory /home/domaine/public_html>
Options -Indexes +IncludesNOEXEC +SymLinksIfOwnerMatch +ExecCGI
allow from all
AllowOverride All Options=ExeCGI,Includes,IncludesNOEXEC,Indexes,Multiviews,SymlinksIfOwnerMatch
AddHandler fcgid-script .php
AddHandler fcgid-script .php5
FCGIWrapper /home/domaine/fcgi-bin/php5.fcgi .php
FCGIWrapper /home/domaine/fcgi-bin/php5.fcgi .php5
AddType application/x-httpd-php .php
Require all granted
</Directory>
SSLCertificateFile /etc/letsencrypt/live/www.domaine.net/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.domaine.net/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/www.domaine.net/chain.pem
</VirtualHost>
</IfModule>
J’ai oublié d’ajouter un sous-domaine comment faire?
Le problème survient lorsque vous vous rendez compte que vous auriez aimé aussi émettre un certificat pour un sous-domaine sub.domaine.com, voire tout simplement domaine.com, en effet Let’s Encrypt n’émet que des certificats pour sous domaine, il n’émet pas un certificat qui gère tous les sous-domaines. Dans le commerce il existe des certificats (wildcard) qui gèrent les sous-domaines, ils sont en général trois fois plus chers que les certificats non wildcards.
Pas de problème, car il suffit d’indiquer les sous-domaines pour lesquels vous voulez un certificat.
Cela se fait avec l’argument expand. (**Voir la nouvelle méthode plus efficace**)
certbot-auto --expand -d existing.com,example.com,newdomain.com
« expand » va dire à certbot de mettre à jour le certificat existant avec un nouveau certificat qui contient les domaines existants et va y ajouter le ou les nouveaux domaines (ou sous domaine). En fait ce que je viens de dire signifie que pour deux domaines distincts, vous pouvez créer deux certificats distincts OU un seul certificat qui va fonctionner pour les deux domaines distinct. Voir la documentation officielle pour ces manipulations.
Vous devez indiquer tous les sous-domaines y compris les sous-domaine déjà pris en compte par le certificat, c’est un peu fastidieux à écrire, sinon vous allez exclure le ou les sous-domaines non énumérés dans la commande.
update : maintenant il y a une meilleure façon de faire plus précise et plus intuitive en utilisant le flag –cert-name
./certbot-auto --cert-name www.domaine.com -d www.domaine.com,blog.domaine.com,support.domaine.com
Vous devez indiquer tous les sous-domaines y compris les sous-domaine déjà pris en compte par le certificat, c’est un peu fastidieux à écrire, sinon vous allez exclure le ou les sous-domaines non énumérés dans la commande.
$ ./certbot-auto --apache certonly --expand -d domaine.com,www.domaine.com
la sortie à l'écran :
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for domaine.com
tls-sni-01 challenge for www.domaine.com
Waiting for verification...
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0003_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0003_csr-certbot.pem
N’oubliez pas de redémarrer Apache en faisant :
service apache2 restart
Comment effacer un certificat?
Effacer un certificat en effaçant simplement les répertoire, mais non en fait ce n’est pas une bonne solution. Il y a une commande exprès pour ça :
certbot-auto delete --cert-name mondomaine.com
La validité des certificats de Lets’Encrypt est seulement de 90 jours, au-delà il vous faut renouveler avec la commande renew. Vous pouvez effacer à la main en utilisant un programme comme WinSCP par exemple.
Nous allons automatiser ce renew pour ne pas l’oublier, avec un crontab.
Le flag -n veut dire qu’on n’est pas en interactif, c’est à dire que le prompt ne va pas vous demander de taper une touche du clavier pour continuer le process, c’est nécessaire quand vous voulez fiare une tache CRON qui va renouveler automatiquement.
Efface un certificat Letsencrypt The Right Way!
Mais avant je vais vous lister une commande pour lister les certificats déjà en place:
Lister les certificats générés
./certbot-auto certificates
Found the following certs:
Certificate Name: www.domaine.fr
Domains: www.domaine.fr
Expiry Date: 2017-12-29 15:11:49+00:00 (VALID: 78 days)
Certificate Path: /etc/letsencrypt/live/www.domaine.fr/fullchain.pem
Private Key Path: /etc/letsencrypt/live/www.domaine.fr/privkey.pem
Certificate Name: www.domaine.com
Domains: www.domaine.com
Expiry Date: 2017-12-23 18:28:00+00:00 (VALID: 72 days)
Certificate Path: /etc/letsencrypt/live/www.domaine.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/www.domaine.com/privkey.pem
Cette commande est très utile, elle vous donne la liste des certificats et les jours avant expiration.
$./certbot-auto delete --cert-name www.domaine.com
-------------------------------------------------------------------------------
Deleted all files relating to certificate www.domaine.com.
-------------------------------------------------------------------------------
Supplément : rediriger les anciennes url vers la version sécurisée:
RedirectMatch permanent ^/(.*) https://www.domaine.fr/$1
Vous pouvez mettre cette directive dans le fichier de configuration du virtual host.
Les pièges du certificat SSL
Toujours considérer la version non www
J’insisterai en particulier sur la création pour le sous-domaines sans www. Par exemple www.domaine.com, www est le sous domaine, en vrai le domaine c’est domaine.com.
Donc si vous avez un site www.domaine.com et que vous vouliez rediriger domaine.com vers www.domaine.com, il vous faut aussi intégrer ce sous-domaine dans le certificat. Parce que si vous ne le faites pas, tout requête de domaine.com va se solder par un avertissement comme quoi le site n’est pas sécurisé et qu’il vous faut confirmer l’exception de sécurité. Cela étant déjà un roblème pour un humaine, imaginez Google !
Non mais j’ai fait une redirection 301 vers le www.domaine.com
Et non ça ne marche pas comme ça ! Quand vous faites une requête HTTP à domaine.com, il doit le résoudre domaine.com avec de faire le redirection, et sans certificat SSL, il ne pourra le résoudre, dans votre redirection 301 tombe à l’eau.
Ok je m’en fiche Google aura une erreur sur ce sous-domaine c’est pas grave
Là encore je suis désolé, dans le cas où vous avez un dédié tournant sous Apache (cas que je connais) avec plusieurs virtual host (donc plusieurs domaines), si le domaine.com est résolu manuellement (forçage SSL), il va pointer sur un autre site, en fait le premier qu’Apache aura trouvé.
