Créer et installer un certificat SSL Let’s Encrypt pour Apache

Installer Let's Encrypt sur Apache

Dans ce tutoriel nous allons voir comment créer, installer et gérer un certificat SSL Let’s Encrypt, et configurer le serveur web Apache en fonction afin de proposer un site web sécurisé par https aux internautes.

A propos de Let’s Encrypt

Let’s encrypt est une initiative Open Source de l’ISRG qui a pour objectifs résumés de proposer à tous, gratuitement, des certificats SSL permettant de sécuriser un site web via https.
Il faut bien avouer que Let’s Encrypt est la petite révolution de ces 2 dernières années. Tout le monde s’y met. Et ce pour 2 raisons principales : Le fait que ce soit simple ET gratuit, et surtout depuis que Google pousse pour un web sécurisé.
Pour exemple, l’évolution de la recherche de « Let’s Encrypt » sur les 5 dernières années :

Evolution recherche Let's Encrypt

Contexte

Nous allons donc voir comment déployer Let’s Encrypt sur notre serveur Apache, mais d’une façon particulière.
En effet, le logiciel Certbot que nous allons utiliser propose divers plugins et assistants, dont pour Apache, qui permettent d’installer automatiquement les certificats, de modifier les configurations d’Apache, etc… Tout cela automatiquement.
Cela conviendra parfaitement au plus grand nombre, il faut bien le dire.
Mais personnellement, j’aime bien : 1/ savoir ce qu’il se passe, 2/ savoir comment cela fonctionne, 3/ garder la main sur le paramétrage.
Et par dessus tout je déteste qu’un logiciel quel qu’il soit, fasse sa vit seul, modifie mes configurations, redémarre les services, etc… D’autant plus sur un serveur en production.
En le faisant manuellement, au moins, en cas de problème, je sais où chercher et où intervenir.

Pour ce tuto je pars du principe que nous avons une configuration Apache classique, et qu’il n’y pas de cas particuliers.
Je suppose aussi que nous avons plusieurs sites hébergés sur notre serveur et qu’un ou plusieurs d’entre eux vont passer du http au https.

Enfin, notez que ce tutoriel est réalisé sur une Debian 7 et Apache 2.2. Cela fonctionne exactement de la même façon sur une Debian 8 et Apache 2.4.

Prérequis

Avoir installé un serveur Apache 2 et qu’il soit fonctionnel avec les mods SSL et rewrite activés.
Pour vérifier s’ils sont actifs exécutez :

root@g:~# apachectl -M
Loaded Modules:
 ...
 rewrite_module (shared)
 ssl_module (shared)
 ...
Syntax OK

Vous voyez en gras les 2 modules chargés.
Si ce n’est pas le cas, exécutez en fonction :

root@g:~# a2enmod ssl 
Enabling module ssl.
See /usr/share/doc/apache2.2-common/README.Debian.gz on how to configure SSL and create self-signed certificates.
To activate the new configuration, you need to run:
  service apache2 restart

root@g:~# a2enmod rewrite 
Enabling module rewrite.
To activate the new configuration, you need to run:
  service apache2 restart

root@g:~# service apache2 restart 
[ ok ] Restarting web server: apache2 ... waiting .

N’oubliez pas de redémarrer Apache une fois que les modules sont mis à jour.

Méthodologie

La mise en place va se faire en 6 grandes étapes :

  1. Installer le programme Certbot qui va générer les certificats
  2. Créer un premier certificat Let’s Encrypt
  3. Modifier la configuration d’un vhost Apache pour y intégrer les certificats
  4. Vérifier la configuration ainsi que la qualité du paramétrage SSL
  5. Apprendre à renouveler un certificat
  6. Apprendre à révoquer un certificat

Installation de Certbot

Pour commencer, on télécharge Certbot et on le rend exécutable :

wget https://dl.eff.org/certbot-auto
chmod a+x certbot-auto

C’est un simple fichier, stockez le à un endroit approprié. Dans /opt par exemple.
Exécutez-le une première fois « à blanc » pour qu’il télécharge ses dépendances et s’installe.

./certbot-auto

Lorsque ce sera terminé, il vous proposera de commencer le travail de création. Quittez. Nous y reviendrons plus tard.

Les fichiers principaux sont installés. Tout se trouve dans /etc/letsencrypt.
Dans se dossier on trouvera 3 dossiers de stockage pour les certificats :
archive : dossier de base ou sont stockés les certificats
live : dossier des certificats actifs. Des liens symboliques vers le dossier archive.
renewal : dossier qui contient les informations de renouvellement des certificats.

Création du certificat Let’s Encrypt

Lancez la commande suivante en veillant à remplacer les valeurs par les bonnes informations :

./certbot-auto certonly --webroot --webroot-path /srv/www/domain.tld/ --domain domain.tld --domain www.domain.tld --email mon@email.com

Explications :

certonly : on demande la création du certificat uniquement.
--webroot : on utilise le plugin webroot qui se contente d’ajouter des fichiers dans le dossier défini via --webroot-path.
--webroot-path : le chemin de votre « DocumentRoot » Apache. Certbot placera ses fichiers dans $DocumentRoot/.well-known/ pour les tests et vérifications
--domain : le nom de domaine à certifier.
--email : l’adresse qui recevra les notifications de Let’s Encrypt. Principalement pour rappeler de renouveler le certificat le moment venu.

Options de création

Au niveau des paramètres de création, l’essentiel est là. Je vous invite à consulter la doc pour voir les autres options disponibles.
On pourrait éventuellement durcir le certificat en le passant en 4096 bits (2048 bits par défaut) en ajoutant le flag --rsa-key-size 4096 mais c’est un peu disproportionné. C’est vous qui voyez.

Pour revenir sur le flag --domain, attention ! Let’s encrypt ne gère pas à ce jour le Wildcard. Il faut donc penser impérativement à déclarer le domaine ET le sous-domaine « www ». Si vous êtes dans une configuration classique évidemment où votre site est accessible depuis http://domain.tld et http://www.domain.tld.

Les certificats obtenus

Si vous cherchez vos certificats, ils se trouvent dans les dossiers : /etc/letsencrypt/live/domain.tld/
Vous avez pour chaque certificat 4 fichiers :

privkey.pem : La clé privée de votre certificat. A garder confidentielle en toutes circonstances et à ne communiquer à personne quel que soit le prétexte. Vous êtes prévenus !
cert.pem : Le certificat serveur et à préciser pour les versions d’Apache < 2.4.8. Ce qui est notre cas ici.
chain.pem : Les autres certificats, SAUF le certificat serveur. Par exemple les certificats intermédiaires. Là encore pour les versions d’Apache < 2.4.8.
fullchain.pem : Logiquement, l’ensemble des certificats. La concaténation du cert.pem et du chain.pem. A utiliser cette fois-ci pour les versions d’Apache >= 2.4.8.

Le cas des certificats pour différents sous-domaines

Pour une gestion simplifiée de vos certificats, je vous conseille de ne pas intégrer tous vos sous-domaines au même certificat.
Si vous gérez plusieurs sites différents sur des sous-domaines différents, et donc sur des vhost différents : par exemple blog.domain.com et forum.domain.com, à ce moment là vous créer 2 certificats distincts. Comme cela, en cas de modification, déplacement ou suppression de l’un de vos sites, tout est cloisonné et il n’y a pas d’impacts sur les autres certificats.

Intégrer le certificat Let’s Encrypt à Apache

Maintenant que nous avons le certificat, il ne reste plus qu’à l’intégrer au vhost Apache et ainsi servir du contenu en https.
Tout d’abord il faut éditer le vhost afin de déclarer tout le paramétrage nécessaire.
Je suppose ici que nous sommes dans un cas classique où notre site est accessible à la fois depuis domain.com et www.domain.com. Le grand classique.

Modification du vhost

Pour l’instant le vhost ressemble à quelque chose comme ceci :

<VirtualHost *:80>

    ServerName domain.tld
    ServerAlias www.domain.tld
    DocumentRoot /path/to/files

    LogLevel warn
    ErrorLog ${APACHE_LOG_DIR}/domain.tld-error.log
    CustomLog ${APACHE_LOG_DIR}/domain.tld-access.log combined

    RewriteEngine On
    RewriteCond %{HTTP_HOST} !^www\. [NC]
    RewriteRule ^(.*)$ http://www.%{HTTP_HOST}$1 [R=301,L]

    <Directory /path/to/files>
        Options -Indexes -MultiViews
        AllowOverride all
        Order allow,deny
        allow from all
    </Directory>

</VirtualHost>

Ici, le détail de cette configuration importe peu. L’important est de voir que le site est accessible à la fois depuis domain.tld et www.domain.tld, et que si quelqu’un demande http://domain.tld : il y aura une redirection 301 automatique vers le sous-domaine http://www.domain.com.
Nous allons reproduire la même chose en version https. Je vous propose la nouvelle configuration suivante :

<VirtualHost *:80>

    ServerName domain.tld
    ServerAlias www.domain.tld

    RewriteEngine on
    RewriteCond %{HTTPS} !on
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

</VirtualHost>

<VirtualHost *:443>

    ServerName domain.tld
    ServerAlias www.domain.tld

    DocumentRoot /path/to/files/www.domain.tld

    <Directory /path/to/files>
        Options -Indexes
        AllowOverride all
        Order allow,deny
        allow from all
    </Directory>

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/domain.tld/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/domain.tld/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/domain.tld/chain.pem
    SSLProtocol all -SSLv2 -SSLv3
    SSLHonorCipherOrder on
    SSLCompression off
    SSLOptions +StrictRequire
    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
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

    LogLevel warn
    ErrorLog ${APACHE_LOG_DIR}/www.domain.tld-error.log
    CustomLog ${APACHE_LOG_DIR}/www.domain.tld-access.log combined

</VirtualHost>

On voit maintenant que l’on a 2 vhost dans un vhost ! Un pour le port 80 et le http (<VirtualHost *:80>) et un autre pour le port 443 et le https (<VirtualHost *:443>).
Le premier vhost du port 80 ne fait rien d’autre qu’une redirection automatique de l’http vers le https. SI jamais quelqu’un le demandait.
Mis à part cela, il n’y a rien. Pas de documentRoot, pas de logs, etc… C’est un choix. Etant donné que je souhaite que 100% du trafic passe sur https, toutes les informations complémentaires sont inutiles, à commencer pour les logs.

Ensuite il y a la déclaration du vhost https. Comme vous pouvez le voir, la première partie est identique à la configuration initiale, et il n’y a pas de raison qu’elle soit différente. Par contre, en deuxième partie, il y a toutes les déclarations SSL :

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/domain.tld/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/domain.tld/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/domain.tld/chain.pem
    SSLProtocol all -SSLv2 -SSLv3
    SSLHonorCipherOrder on
    SSLCompression off
    SSLOptions +StrictRequire
    SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256 [...]
    # Note: It’s also recommended to enable HTTP Strict Transport Security (HSTS)
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Explications :

SSLEngine on : Activation du module SSL
SSLCertificateFile : chemin vers le fichier cert.pem
SSLCertificateKeyFile : chemin vers le fichier privkey.pem
SSLCertificateChainFile : chemin vers le fichier chain.pem
SSLProtocol : Active le support de toutes les versions SSL mais SAUF SSLv2 et v3 qui ne sont plus suffisamment sécurisées.
SSLHonorCipherOrder : Quand activé, le serveur force ses préférences de protocoles et non le navigateur du client.
SSLCompression : Active la compression SSL
SSLOptions +StrictRequire : Exige une connexion SSL stricte
SSLCipherSuite : Liste des algorithmes de chiffrement disponibles
Header always set Strict-Transport-Security : ou HSTS. Indique aux navigateurs que seul le https est supporté et le force en définissant une durée d’application (longue). Objectif : éviter les attaques « Man in the middle ».

Vérification de la configuration du vhost

Reste maintenant à tester notre configuration :

apachectl configtest

Logiquement devrait vous retourner un « Syntax OK ». Si c’est le cas, il faut reload/restart Apache pour qu’il prenne en compte les modifications.

service apache2 restart

Et là, vous pouvez avoir l’erreur suivante :

[....] Reloading web server config: apache2[Sat Oct 08 11:17:49 2016] [warn] _default_ VirtualHost overlap on port 443, the first has precedence.
... waiting [Sat Oct 08 11:17:49 2016] [warn] _default_ VirtualHost overlap on port 443, the first has precedence
ok

Nous venons d’ajouter un nouveau vhost écoutant sur le port 443 mais nous avons aussi le vhost « default-ssl » qui est déjà présent. Donc 2 vhost, 2 sites pour le même port ça ne va pas. Il faut donner des précisions à Apache pour qu’il sache quoi servir.
Etant dans un contexte de serveurs basés sur le nom, il faut ajouter cette instruction au fichier ports.conf, qui ressemble à ceci par défaut :

<IfModule mod_ssl.c>
    # If you add NameVirtualHost *:443 here, you will also have to change
    # the VirtualHost statement in /etc/apache2/sites-available/default-ssl
    # to <VirtualHost *:443>
    # Server Name Indication for SSL named virtual hosts is currently not
    # supported by MSIE on Windows XP.
    Listen 443
</IfModule>

On va lui ajouter l’instruction NameVirtualHost *:443 ce qui nous donnera :

<IfModule mod_ssl.c>
    # If you add NameVirtualHost *:443 here, you will also have to change
    # the VirtualHost statement in /etc/apache2/sites-available/default-ssl
    # to <VirtualHost *:443>
    # Server Name Indication for SSL named virtual hosts is currently not
    # supported by MSIE on Windows XP.
    Listen 443
    NameVirtualHost *:443
</IfModule>

Vous noterez que les choses sont biens faites, regardez les commentaires, on nous indique que si on ajoute NameVirtualHost *:443 ici il faut également modifier le vhost default-ssl pour remplacer <VirtualHost _default_:443> par <VirtualHost *:443>.

On édite le fichier /etc/apache2/sites-available/default-ssl sur les 2 premières lignes qui sont :

IfModule mod_ssl.c>
<VirtualHost _default_:443>
...

Et qui deviennent alors :

IfModule mod_ssl.c>
<VirtualHost *:443>
...

On restart Apache une dernière fois et il ne devrait plus y avoir de soucis. Rendez-vous sur votre site, et vous pourrez vérifier que tout fonctionne bien avec https activé et fonctionnel. Et surtout sans alerte.

Vérification de la sécurité

Dernier point à voir sur la configuration : la qualité de sécurisation de notre connexion SSL.
En effet, en fonction des paramètres définis dans notre vhost, entre autre, il se peut que la sécurisation ne soit pas optimale. Il y a donc potentiellement un risque d’usurpation d’identité ou encore d’attaque de type « Man in the middle ».
Avec les paramètres définis plus haut, il n’y a pas de soucis. Vous devriez obtenir la note « A+ ». Il s’agit des paramètres par défaut de Let’s Encrypt. Mais cette note n’est pas sans contrepartie.

Commencez par tester votre site sur SSL Server Test : https://www.ssllabs.com/ssltest/

Si vous avez bien suivi ce tuto, vous devriez avoir le fameux « A+ » :

Note A+ SSL server test

Maintenant tout est affaire de compromis.
Plus vous durcirez vos règles, plus vous obtiendrez une meilleure note, plus vous perdrez en compatibilité avec les anciens navigateurs. IE8 sur XP par exemple.
Donc regardez bien vos stats de visites au préalable pour connaitre les configurations de vos visiteurs et adaptez en fonction.
La sécurité c’est bien, mais si vous perdez vos visiteurs ce n’est pas une solution non plus.

Renouveler un certificat Let’s Encrypt

A ce stade nous avons un certificat Let’s Encrypt installé et notre serveur bien configuré.
Il faut savoir que la durée de vie du certificat Let’s Encrypt n’est que de 90 jours, 3 mois donc.
Nous allons voir les commandes pour le renouveler manuellement et automatiquement.

Pour renouveler votre certificat manuellement il suffit de lancer la commande :

./certbot-auto renew

Cette commande interroge les serveurs Let’s encrypt et ces derniers vont déterminer si votre certificat a besoin d’être renouvelé ou non.
Notez que tant que vous ne serez pas dans les 30 derniers jours avant la date d’expiration, Let’s encrypt ne le renouvellera pas. Mais si besoin vous pouvez forcer malgré tout le renouvellement en ajoutant le flag --force-renewal.
Lors du renouvellement vous pouvez également demander la modification de la force de la clé RSA. Si vous avez créé votre certificat en 2048 bits, vous pouvez le passer en 4096, et inversement. Pour cela vous ajouterez le flag --rsa-key-size 4096.
La commande serait alors :

./certbot-auto renew --rsa-key-size 4096 --force-renewal

Ce sont là les options principales. Il y en a d’autres disponibles en fonction de vos besoins, là encore je vous invite à consulter la documentation.

Pour terminer sur le renouvellement il est important de signaler que la commande ./certbot-auto renew renouvelle l’ensemble des certificats Let’s Encrypt disponibles sur la machine.
Pour le moment il n’est pas possible de renouveler un domaine en particulier. Cela sera probablement disponible dans le futur.

Renouveler automatiquement le certificat

Maintenant nous allons voir comment automatiser le renouvellement de notre certificat avec CRON.
Personnellement je me créé un petit script que je vais placer dans le dossier cron.monthly. Basique. Et « monthly » car comme vu précédemment le certificat ne sera renouvelé que dans les 30 derniers jours. Inutile donc de faire la demande toutes les semaines et encore moins tous les jours.
Exemple de fichier renew-certificate.sh :

#!/bin/bash

/chemin/vers/certbot-auto renew

Vous pouvez ajouter le flag --quiet si vous ne souhaitez pas avoir de retour sur la commande.
Dans tous les cas, pas de panique, comme nous avons ajouté notre adresse mail lors de la création du certificat, s’il y a le moindre problème, vous serez prévenu par email.

Révoquer un certificat Let’s Encrypt

Dernier sujet : la suppression, la révocation d’un certificat. Si vous n’en n’avez plus besoin.

Nous allons utiliser la commande certbot-auto revoke en lui passant un certain nombre de paramètres : le certificat à révoquer, le chemin vers la clé privée et le chemin vers le certificat :

./certbot-auto revoke --domain domain.tld --cert-path /etc/letsencrypt/live/domain.tld --key-path /etc/letsencrypt/live/domain.tld

Votre certificat est révoqué. Mais ce n’est pas suffisant.
Si vous regardez vos dossiers /etc/letsencrypt/live/, /archive/ et /renewal/, vous trouverez encore les dossiers/fichiers à l’intérieur.
Pour faire propre, nous allons tout supprimer avec la commande suivante :

rm -rf /etc/letsencrypt/live/domain.tld/ && rm -rf /etc/letsencrypt/archive/domain.tld/ && rm /etc/letsencrypt/renewal/domain.tld.conf

Restaurer la configuration Apache

Dernière modification, restaurer la configuration du vhost Apache dans sa configuration initiale et surtout supprimer toutes les références au SSL et aux certificats.
Pour celaiIl suffit de se référer à la configuration de base plus haut dans cette page. Je vous laisse faire.

Conclusion
J’espère que ce tuto vous sera utile et que vous en aurez appris un peu plus sur le fonctionnement de Let’s Encrypt et globalement l’intégration d’un certificat SSL pour Apache. Car pour cette dernière partie, Let’s Encrypt ou autre, c’est exactement la même chose.
Si vous avez des remarques ou questions, n’hésitez pas à poster un commentaire.

43 commentairesLaisser un commentaire

  • Bonjour,

    Sauf erreur de ma part, il faudrait aussi rajouter en pré-requis la présence du module apache « headers » pour que la déclararation « Header always set Strict-Transport-Security » fonctionne.

    #a2enmod headers puis #systemctl restart apache2 si besoin

    A part ça, bravo pour l’article.

  • Bonjour,

    j’ai bien installé un certificat il y a 3 mois, mais maintenant au renouvellement il me dit :

    Creating virtual environment…
    Traceback (most recent call last):
    File « /usr/bin/virtualenv », line 5, in
    from pkg_resources import load_entry_point
    File « /usr/local/lib/python3.4/dist-packages/pkg_resources/__init__.py », line 72, in
    import packaging.requirements
    File « /usr/local/lib/python3.4/dist-packages/packaging/requirements.py », line 9, in
    from pyparsing import stringStart, stringEnd, originalTextFor, ParseException
    ImportError: No module named ‘pyparsing’

    Une idée ?

    Merci par avance

  • Bonsoir guigeek,

    Je pencherai pour des versions de programmes pas à jour. Soit let’s encrypt / certbot, soit pyton.
    Faites les mises à jour de tout et retentez.

    Bon courage.

  • Bonjour,
    Merci pour ce tuto complet.
    Concernant certbot-auto, est-ce qu’il y a un intérêt à utiliser l’option –apache avec Apache ?
    Merci !

  • Bonsoir Nicolas,

    L’option -apache va créer automatiquement les entrées dans le VHOST si ma mémoire est bonne.
    Je n’ai pas trop testé cette option. Comme je l’expliquais en début d’article, je n’aime pas trop quand les script font des choses sans que je sache ce que c’est 🙂
    Mais sinon pas d’apriori. Cela doit marcher sans problème et simplifier l’installation.

  • Super article ! très complet et détaillé.
    Juste une précision : pour la révocation des certificats, il faut rajouter le nom des fichiers *.pem, sinon, ça ne fonctionne pas (chez moi) :
    ./certbot-auto revoke –domain domain.tld –cert-path /etc/letsencrypt/live/domain.tld/cert.pem –key-path /etc/letsencrypt/live/domain.tld/privkey.pem

    Merci !

  • Merci Benjamin.

    C’était bon au moment où j’ai écris cet article.
    Il y a dû avoir une légère modif avec les dernières versions.

  • Merci Pol pour la première réponse, et meilleurs vœux pour 2018 🙂
    Je viens tout juste de m’y repencher et j’ai une question sur les options : –webroot –webroot-path /srv/www/domain.tld/
    Est-ce qu’elles sont obligatoires ? Quels sont les droits à appliquer au répertoire /srv/www/domain.tld/ s’il y a des droits particuliers ?
    Merci !

  • Bonsoir Nicolas,

    Meilleurs voeux également 😉

    l’option –webroot est obligatoire dans notre cas. Cela correspond au plugin utilisé par certbot pour l’installation.
    Soit on utilise –webroot dans notre cas pour une installation « nature », soit on utilise un autre plugin d’installation automatique à la place comme –apache ou –nginx etc…

    Quant à webroot-path c’est simplement pour indiquer le chemin dans lequel créer les fichiers. C’est donc obligatoire également.

    A bientôt

  • Bonjour

    AU lancement de la commande ./certbot-auto certonly –webroot –webroot-path /srv/www/domain.tld/ –domain domain.tld –domain http://www.domain.tld –email mon@email.com (j’ai bien sur adapté a ma situation

    j’ai cette erreur pour mon domaine : « 403 Forbidden Forbidden »

  • Bonjour, merci pour le tutoriel,

    je viens de renouveler un certificat sur un serveur (sans redémarrer apache), mais quand je regarde la date de validité dans firefox c’est toujours l’ancienne date qui apparait..
    Quand est-ce que le nouveau certificat prend le relais ?
    Suis-je obligé de relancer apache à chaque fois ?

    Merci
    Sullyvan

  • @Marv1 : désolé mais je ne vois pas d’où cela peut venir. Cela fait penser à une erreur apache mais qui est hors contexte lorsque l’on lance la commande certbot… Mystère…

    @Sullyvan : il faut redémarrer apache pour que les nouveaux fichiers soient pris en compte.

  • Bonjour,

    Un grand bravo pour ce travail et ces explications !
    J’avais deja installe la Lets encrypt automatiquement.
    Je vais maintenant m’entrainer a le refaire manuellement.

    A l’issue du test je n’ai pas A+ mais A mais avec les memes notes que dans votre exemple A+.
    Pourquoi ? Un chiffrement a 4096 donnerait-il ce fameux A+ ?

    Cordialement

  • Bonjour Roger,

    Merci pour votre retour 🙂
    Il faudrait voir le détail de votre notation pour voir pour vous avez perdu des points. Mais effectivement si vous avez créé votre certificat en 1024 ou 2048 à la place de 4096, cela peut venir de là.

  • Bonsoir Pol,

    Merci pour vos precisions. Je vais rfaire les tests et vous informer.

    Par ailleurs, a la relecture de votre tutoriel, je lis que vous utilisez cerbot-auto :
    wget https://dl.eff.org/certbot-auto

    Or avant d vous lire, j’avais deja installe cerbot-apache sur Ubuntu 14.04 LTS 64 bits :
    sudo apt-get install python-certbot-apache

    De ce fait les commandes sont pour moi du type :
    sudo certbot –apache -d mondomaine.com

    et non :
    ./certbot-auto xxx

    Ceci explique pourquoi j’ai une erreur quand je tente de revoquer un certificat avec votre commande :
    ./certbot-auto revoke –-domain mondomaine.pw –-cert-path /etc/letsencrypt/live/mondomaine.pw/cert.pem –-key-path /etc/letsencrypt/live/mondomaine.pw/privkey.pem

    Ma question : puis-je melanger les deux versions car je souhaite revoque un certificat ?

    Merci pour votre reactivite.

    Roger

  • Bonsoir Roger,

    Je n’ai pas testé mais a priori je dirai pas de problème pour avvoir les 2 versions.
    Testez-le et dites-nous.

    A bientôt

  • Bonsoir Pol,
    La plupart des instructions d’une version ne fonctionne pas avec l’utre mais visiblement les deux peuvent cohabiter.
    Par contre impossible pour moi de revoquer un certificat.
    Bien a vous.
    Roger

  • Bonsoir Roger,

    Essayez avec : certbot revoke –cert-path /PATH/TO/cert.pem –key-path /PATH/TO/key.pem
    sinon je ne vois pas…

  • Merci beaucoup pour le tutoriel, j’ai galéré longtemps pour avoir HTTPS j’ai commandé l’option SSL Gateway de chez OVH, attendu 3 jours pour l’activation du service et changé les DNS, tant dis que la solution est simple, c’est d’installer Let’s Encrypt directement sur le VPS
    Bravo !

  • Bonsoir Toan,

    Merci pour le retour 🙂

    Pour le ftp, malheureusement je ne saurais pas répondre.
    On peut évidement utiliser des certificats pour le ftp, et j’imagine que ca doit fonctionner aussi avec let’s encrypt. Mais je n’ai jamais fait.
    Sinon, plan B, plutôt que de faire du ftp toujours un peu pénible, pourquoi ne pas passer en sftp qui est déjà présent à priori ?
    J’avais fais un tuto sur openSSH à l’époque. Tu peux regarder.

    A+

  • Merci pour ce tuto!
    J’ai voulu installer un certificat pour l’un de mes site sur mon serveur de preprod, l’installation de Certbot s’est bien déroulée, mais impossible de me reconnecter au site. J’obtiens un « Ce site est inaccessible ERR_TIMED_OUT » sur mon navigateur. En plus le navigateur informe que le site n’est pas sécurisé. Aussi, lorsque je rentre l’url du site dans mon navigateur il est automatiquement redirigé sur HTTPS.
    Une idéé d’où ça pourrait venir?

  • Bonjour François,
    A mon avis vu l’erreur je pense que ca se joue plus côté apache que côté certificat.
    Il doit y avoir une coquille quelque part. Mais difficile d’en dire plus comme ça de loin.

  • Bonjour,

    Un redémarrage des services (apache, postfix, etc…) étant obligatoire, il serait utile de l’intégrer dans le renew-certificate.sh ?

  • Effectivement Hervé, ca peut tout à fait se faire. Après chacun avisera de son contexte pour voir si c’est la meilleure option.
    Mais c’est une bonne idée oui

  • Depuis que je lis des tutos sur LE (ça fait des mois que j’essaye en vain de comprendre la doc officielle de certbot), celui-ci est enfin à ma portée, en bon noob qui aime comprendre ce que font les softs dans mon serveur.
    Je vais tenter un de ces quatre, merci beaucoup.

    Puis-je demander ce qu’on doit ajouter comme commande dans le script pour redémarrer apache ? Simplement un service apache2 restart sur une ligne ?

    PS : c’est où le répertoire /opt sur une debian ? Je sais, je suis un noob 😛

  • Bonsoir Darkblue,

    Content que ca serve, c’est justement dans ce sens que je construit mes tutos 🙂

    pour redémarrer apache dans le script, oui c’est l’idée. Mais il vaut mieux mettre le chemin complet vers l’executable. par exemple : « /usr/sbin/apachectl restart ».
    c’est plus « propre » si on peut dire.

    Quant au répertoire « /opt », la réponse est dans la question 🙂 c’est « /opt » à la racine

  • Bonsoir, je reviens pour dire que c’est passé comme une lettre à la poste, je suis réjoui ! (Debian 9, Apache 2.4)

    J’ai préféré un Redirect permanent / https://site.tld/ dans le vhost 80 à mod_rewrite, que j’ai réservé à la partie https (www vers non-www).

    Pour la partie cron, /opt/certbot-auto renew && service apache2 restart fera l’affaire, car le chemin absolu ne marche pas (j’ai vérifié la présence du fichier pourtant)… Peut-être que ça marche aussi avec systemctl apache2 mais bon, c’est pas critique comme serveur alors ça fera l’affaire !

    Quand au vhost par défaut, il ne m’a pas dérangé. Je n’ai pas rajouté NameVirtualHost *:443 dans ports.conf et gardé le Listen 443 du . Comme ça, il me sert de piège pour les accès directs sur l’adresse IP, au lieu de laisser le premier vhost prendre les visiteurs indésirables. J’ai laissé le certificat snakeoil auto-signé présent par défaut qui lui est nécessaire, même s’il montre le nomd’hote@domaine du serveur, mais bon…

    Enfin voilà mon retour, merci encore, sans cela mes petits sites seraient restés ad vitam sans chiffrement 😀

  • Correction, le vhost ssl par défaut n’a pas tenu au reboot, je l’ai désactivé. A étudier de plus près !

  • Bonjour Pol,

    J’ai ce message d’erreur au moment de la création d’un nouveau certificat :

    root@ns3091367:/opt# ./certbot-auto certonly –webroot –webroot-path /home/usersite/www/web –domain mondomain.com –domain mondomain.com –email mon-email@ndd.com
    Saving debug log to /var/log/letsencrypt/letsencrypt.log
    Plugins selected: Authenticator webroot, Installer None
    Obtaining a new certificate
    Performing the following challenges:
    http-01 challenge for mondomain.com
    Using the webroot path /home/usersite/www/web for all unmatched domains.
    Waiting for verification…
    Cleaning up challenges
    Failed authorization procedure. mondomain.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://mondomain.com/.well-known/acme-challenge/OqYfhoRLnvcud52DddaI3Jd4nQVWDrM_zypB89dRZ7Q:  »

    404 Not Found

    Not Found

    IMPORTANT NOTES:
    – The following errors were reported by the server:

    Domain: mondomain.com
    Type: unauthorized
    Detail: Invalid response from
    http://rmondomain.com/.well-known/acme-challenge/OqYfhoRLnvcud52DddaI3Jd4nQVWDrM_xxxx

    404 Not Found
    Not Found

    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.
    ———————
    ça te parle?

    Tu peux m'aider?

    Encore merci.

    Cordialement

  • Bonjour Vo,

    Vous avez suivi les infos du tuto sans remplacer les informations de nom de domaine par le votre :

    Domain: mondomain.com
    Detail: Invalid response from
    http://rmondomain.com/.well-known/acme-challenge/OqYfhoRLnvcud52DddaI3Jd4nQVWDrM_xxxx

    Le robot va faire une vérification du nom de domaine « mondomain.com » à l’adresse indiquée ci-dessus.
    comme ce n’est pas votre nom de domaine, il est normal que le fichier ne soit pas accessible. Le robot ne le trouvant pas il retourne une erreur.

    Il suffit de mettre votre nom de domaine correctement enregistré et pointant bien sur votre serveur et tout fonctionnera.

  • Bonjour Pol,

    Merci pour ce tuto, très bien fait bravo.
    J’ose ajouter que le wildcard est pris en compte dorénavant.

    Bien à vous.

  • bonjour,
    urgent j’ai suivie le tuto j’ai une redirection en boucle, que faut t-il fait pour tout remettre sans https ?

  • Bonjour, super tuto 😉 merci pour ton travail. J’ai un problème…
    je suis sous Debian 9 apache 2.4…
    j’ai trois sites, je génère correctement les certifs, le premier site fonctionne parfaitement en https. les deux autres, la redirection http -> https est ok mais le certificat ne semble pas ok. (non sécurisé est affiché dans le navigateur)
    au secours je deviens fou 🙂

    merci

  • Bonjour Alex,

    Il faut en dire un peu plus, fouiller les logs pour savoir d’où cela vient car là c’est vague.
    Est-ce que vous avez 3 vhost bien distincts ? Avec les logs activés ? Est-ce qu’il n’y a pas d’erreurs lors de la génération des certificats ?

  • bonsoir merci pour le réponse rapide, oui j’ai trois vhosts distincts,

        ServerName alex-info.fr
        ServerAlias www.alex-info.fr
    
        RewriteEngine on
        RewriteCond %{HTTPS} !on
        RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
    
        ServerName alex-info.fr
        ServerAlias www.alex-info.fr
    
        DocumentRoot /var/www/html/www.alex-info.fr
        
            Options -Indexes
            AllowOverride all
            Order allow,deny
            allow from all
        
        SSLEngine on
        SSLCertificateFile /etc/letsencrypt/live/alex-info.fr/cert.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/alex-info.fr/privkey.pem
        SSLCertificateChainFile /etc/letsencrypt/live/alex-info.fr/chain.pem
        SSLProtocol all -SSLv2 -SSLv3
        SSLHonorCipherOrder on
        SSLCompression off
        SSLOptions +StrictRequire
        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
        Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
    
        LogLevel warn
        ErrorLog ${APACHE_LOG_DIR}/www.alex-info.fr-error.log
        CustomLog ${APACHE_LOG_DIR}/www.alex-info.fr-access.log combined
    

    celui là est celui qui fonctionne.

    celui là fait exactement de la même façon ne fonctionne pas.

        ServerName emilie-castellano.fr
        ServerAlias www.emilie-castellano.fr
    
        RewriteEngine on
        RewriteCond %{HTTPS} !on
        RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
    
        ServerName emilie-castellano.fr
        ServerAlias www.emilie-castellano.fr
    
        DocumentRoot /var/www/html/www.emilie-castellano.fr
        
            Options -Indexes
            AllowOverride all
            Order allow,deny
            allow from all
        
        SSLEngine on
        SSLCertificateFile /etc/letsencrypt/live/emilie-castellano.fr/cert.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/emilie-castellano.fr/privkey.pem
        SSLCertificateChainFile /etc/letsencrypt/live/emilie-castellano.fr/chain.pem
        SSLProtocol all -SSLv2 -SSLv3
        SSLHonorCipherOrder on
        SSLCompression off
        SSLOptions +StrictRequire
        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
        Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
    
        LogLevel warn
        ErrorLog ${APACHE_LOG_DIR}/emilie-castellano.fr-error.log
        CustomLog ${APACHE_LOG_DIR}/emilie-castellano.fr-access.log combined
    

    et oui j’ai les log (cf ci-dessus)
    et j’ai aucune erreur lors de la création des certifs :

    MPORTANT NOTES:
     - Congratulations! Your certificate and chain have been saved at:
       /etc/letsencrypt/live/alex-info.fr-0001/fullchain.pem
       Your key file has been saved at:
       /etc/letsencrypt/live/alex-info.fr-0001/privkey.pem
       Your cert will expire on 2019-01-02. To obtain a new or tweaked
       version of this certificate in the future, simply run certbot-auto
       again. To non-interactively renew *all* of your certificates, run
       "certbot-auto renew"
     - If you like Certbot, please consider supporting our work by:
    
       Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
       Donating to EFF:                    https://eff.org/donate-le
    
    
    IMPORTANT NOTES:
     - Congratulations! Your certificate and chain have been saved at:
       /etc/letsencrypt/live/emilie-castellano.fr/fullchain.pem
       Your key file has been saved at:
       /etc/letsencrypt/live/emilie-castellano.fr/privkey.pem
       Your cert will expire on 2019-01-02. To obtain a new or tweaked
       version of this certificate in the future, simply run certbot-auto
       again. To non-interactively renew *all* of your certificates, run
       "certbot-auto renew"
     - If you like Certbot, please consider supporting our work by:
    
       Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
       Donating to EFF:                    https://eff.org/donate-le
    
    

    merci pour votre aide.

  • Bonjour Alex,

    je viens de regarder et je pense que la configuration apache / let’s encypt est bonne.
    D’ailleurs le meilleur moyen de tester et de le passer sur SSLlabs : https://www.ssllabs.com/ssltest/analyze.html?d=www.emilie-castellano.fr
    Et vous obtenez le fameux « A+ ».

    Le problème, vient du « mixed content ». C’est à dire que votre site est bien en https mais vous continuez d’appeler des ressources en http. C’est le cas sur le site d’emilie.
    Pour cela il suffit de regarder la console de votre navigateur et vous verrez :

    « Mixed Content: The page at ‘‘ was loaded over HTTPS, but requested an insecure image ‘‘. This content should also be served over HTTPS. »

    En gros vous avez 26 liens (images essentiellement) appelés en http au lieu d’https.
    Je pense que vous n’avez pas modifié les url de votre site dans votre backoffice wordpress.

    Dans les paramètres, modifiez les 2 champs suivants pour remplacer http par https et vous allez régler 90% de votre problème :
    Adresse web de WordPress (URL)
    Adresse web du site (URL)

    S’il reste encore des traces d’erreurs il faut continuer de traquer les liens http et modifier soit votre contenu, soit votre thème.

    Bon courage !

Vous avez aimé cet article ? Réagissez !

Votre email ne sera pas publié. Les champs requis sont marqués d'une astérisque *