Certificats SSL TLS Letsencrypt
Aller à la navigation
Aller à la recherche
Le wiki : Accueil - Administrateur - Bureautique - Développeur - Intégrateur - Marketing - Multimédia - Objets numériques - Jeux - We make Hack
Certificats SSL TLS Let's Encrypt
# Le protocole TLS s'est imposé mais on parle toujours de SSL par convention. # Un certificat SSL et un certificat TLS sont une seule et même chose. # Lire cette page pour créer un Certificat SSL TLS Let's Encrypt.
# Les normes de sécurité encouragent à déclarer qu'un site Web est uniquement accessible via une connexion sécurisée (HTTPS). Can i use Strict Transport Security : https://caniuse.com/#feat=stricttransportsecurity
Les caractéristiques du certificat Let’s Encrypt
Le logiciel Certbot propose des plugins et des assistants qui permettent d’installer automatiquement les certificats et de modifier automatiquement les configurations. Certbot est l'outil. Let’s Encrypt est le service.
Il permet de sécuriser un serveur web, un serveur de messagerie, un serveur FTP ainsi que de sécuriser une connexion via le protocole HTTPS. Le certificat Let’s Encrypt est reconnu et compatible avec quasiment tous les navigateurs et toutes les applications. Le certificat est valables 90 jours, il est possible d’automatiser le renouvellement. L’émission du certificat est automatisée et ne prend que 5 minutes. Il est de type X.509 et utilise la fonction de hachage SHA-2. Il est gratuit et délivré par une autorité de certification. Il est uniquement de type validation de domaine (DV).
Déployer Certbot sur Debian
Méthode pour déployer Certbot et Let’s Encrypt
- Installer les prérequis pour le serveur web. - Installer Certbot qui va générer les certificats. - Attention : Cas pour une machine virtuelle. - Générer un certificat TLS Let’s Encrypt. - Configurer le vhost de Apache pour utiliser le certificat. - Vérifier la configuration et la qualité du paramétrage SSL. - Renouveler un certificat. - Renouveler automatiquement un certificat. - Révoquer un certificat.
Installer les prérequis pour le serveur web
Pour un serveur Apache2, les mods SSL et rewrite doivent être activés. Vérifier si les modules sont activés : sudo apachectl -M
Si les deux modules sont affichés, c'est qu'ils sont chargés. Loaded Modules: ... rewrite_module (shared) ssl_module (shared)
Sinon, charger les modules : sudo a2enmod ssl sudo a2enmod rewrite
Redémarrer Apache2 pour prendre en compte les nouveaux modules : sudo systemctl restart apache2
Vérifier également que l'hôte virtuel pour le domaine concerné soit bien renseigné dans le vhost de Apache2.
Installer Certbot qui va générer les certificats
Installer Certbot sur Debian
# Vérifier si le paquet certbot est présent sur le dépôt. apt policy certbot
# Installer Certbot sur Debian Stretch 9.5. sudo apt install certbot
# Fin de l'installation. # Le dossier suivant est maintenant disponible sur le système. cd /etc/letsencrypt/
Installer Certbot Auto depuis les paquets officiels
Télécharger Certbot et le rendre exécutable : wget https://dl.eff.org/certbot-auto chmod a+x certbot-auto
C'est un simple fichier a stocker dans un endroit approprié. Dans /opt par exemple. Exécuter une première fois certbot-auto pour qu’il télécharge ses dépendances et s'installe. ./certbot-auto
Certbot proposera de commencer le travail de création. Vous pouvez quitter pour y revenir plus tard.
Les fichiers principaux sont installés et se trouvent dans /etc/letsencrypt. Trois dossiers de stockage pour les certificats sont présents : 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éer le certificat pour un domaine. ./certbot-auto certonly --webroot --webroot-path /var/www/domain.tld/ --domain domain.tld --domain www.domain.tld --email mon@email.com
# Créer le certificat pour plusieurs domaines, sans spécifier le webroot-path. ./certbot-auto certonly -d www.domain1.fr -d domain1.fr -d domain2.fr -d www.domain2.fr
certonly : Demande uniquement la création du certificat. --webroot : Le plugin webroot se contente d'ajouter des fichiers dans le dossier défini dans --webroot-path. --webroot-path : Le chemin du DocumentRoot de 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.
Cas pour un serveur web local sur une machine virtuelle
Sur une page HTTPS, toute demande de chargement de JavaScript à partir d'une URL HTTP sera bloquée. Si vous développez localement en HTTP, vous pouvez ajouter un script qui fonctionne correctement mais qui ne fonctionnera pas une fois déployé en production HTTPS.
Let's Encrypt ne peut pas fournir de certificats pour «localhost» car personne ne le possède de manière unique, et, il n’est pas ancré dans un domaine de premier niveau comme «.com» ou «.net».
Vous ne pourrez pas émettre un certificat pour ce domaine à partir de la machine virtuelle sans que le domaine ne soit dirigé vers la machine virtuelle. Vous pouvez modifier le domaine pour pointer vers l'adresse IP de la machine virtuelle et vous assurer que le port 80 de cette adresse IP est dirigé vers le client ACME sur la machine virtuelle. Utiliser le type de requête DNS-01.
Pour éviter DNS-01 et utiliser HTTP-01 avec un faux nom de domaine, suivre les instructions pour configurer une instance de développement de Boulder. Pour tester sans avoir un vrai nom de domaine, exécuter votre propre version des serveurs Let's Encrypt avec lesquels vous pouvez utiliser de fausses données DNS. Utiliser Certbot / votre client Acme avec cette instance locale, en définissant le paramètre "FAKE_DNS env. var" correctement pour pointer sur votre machine virtuelle de test avec le client acme.
https://github.com/letsencrypt/boulder#working-with-a-client https://github.com/letsencrypt/boulder#development-setup
Générer un certificat TLS Let’s Encrypt
Arrêter Apache2 systemctl stop apache2
Créer un certificat TLS 4096bits avec Cerbot : certbot certonly --standalone -d domaine.tld --rsa-key-size 4096
Renseigner une adresse mail valide permet de recevoir les notifications de fin de validité du certificat TLS : Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel):
Accepter les termes de la licences : (A)gree/(C)ancel:
Le certificat TLS est créé : Congratulations!
Certbot certonly standalone
# Créer le certificat pour visionduweb.fr
# Le problème avec standalone, c'est qu'il a besoin de stopper apache pour faire la création du certificat à contrario de webroot. # C'est la raison pour laquelle il utile les "pre-hook" (?) en stoppant puis redémarrant apache. # En essayant de simuler un renouvellement de certificat ou une création : "certbot renew --dry-run" ou "certbot certonly --dry-run", la console fait correctement son travail.
# Arrêter Apache2 avant de faire la création du certificat : systemctl stop apache2 sudo certbot certonly --standalone -d visionduweb.fr -d www.visionduweb.fr --rsa-key-size 4096 --email vision.du.web@free.fr
Lire https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf Lire : https://acme-v01.api.letsencrypt.org/directory a pour accept
Seriez-vous prêt à partager votre adresse e-mail avec Electronic Frontier Fondation, partenaire fondateur du projet Let's Encrypt et de l'association à but non lucratif organisation qui développe Certbot? Nous aimerions vous envoyer un email sur EFF et notre travail pour chiffrer le Web, protéger ses utilisateurs et défendre les droits numériques. y pour yes
Obtaining a new certificate Performing the following challenges: http-01 challenge for visionduweb.fr Cleaning up challenges Problem binding to port 80: Could not bind to IPv4 or IPv6.
# Ce message est affiché car utiliser --standalone lance un serveur Web temporaire car aucun serveur n'est en cours d'exécution. # Il faut arrêter Apache2 avant de faire la manipulation.
# Noter qu'il semble nécessaire de monter un Virtualhost pour configurer le nom de domaine localement. # Mon premier essai sur une Machine Virtuelle locale a échoué. # En effet, le nom de domaine principale utilisé ne pouvant pas pointer vers l'adresse IP de la machine virtuelle qui utilise ce même nom de domaine mais de façon virtuelle en utilisant le fichier hosts, la création du certificat ne pourra pas fonctionner et il sera refusé par l'autorité de certification Let's Encrypt. # Il faut s'assurer que votre nom de domaine soit correctement accessible depuis l'extérieur et que les enregistrements DNS A / AAAA pour ce domaine contiennent bien une adresse IP accessible.
Simuler la création de la clé
certbot certonly --non-interactive --email vision.du.web@free.fr \ --preferred-challenges tls-sni-01 --standalone --agree-tos \ --renew-by-default --webroot-path /var/www/html \ -d visionduweb.fr -d www.visionduweb.fr --test-cert
Let's Encrypt ne gérait pas le Wildcard. Il fallait donc déclarer le domaine.ext et le sous-domaine www.domaine.ext. Depuis, il semblerait que Let's Encrypt gère le Wildcard. À suivre.
Si tout se passe correctement, enlever l'option --test-cert pour générer le certificat. Les fichiers générés devraient se trouver dans le répertoire /etc/letsencrypt/live/<domaine>.
Noter que lors de la création des clés, les VirtualHosts n'incluent pas encore les lignes vers le certificat, puisqu'il n'existe pas encore. Les VirtualHosts doivent être en écoute du port 80 pour répondre aux requêtes. Mes VirtualHosts sont peut être mal renseigné : Cette commande avec --standalone n'a pas aboutie lors de mes essais. Il faudra vérifier par la suite si cette commande fonctionne correctement.
Générer le certificat Let's Encrypt certonly standalone
# Il semble conseillé d'arrêter le serveur Apache2 durant la création ou le renouvellement de certificats. # Utiliser la commande suivante pour arrêter Apache2 le temps de la création du certificat, puis, pour redémarrer Apache2 : sudo certbot certonly --authenticator standalone --pre-hook "systemctl stop apache2.service" --post-hook "systemctl start apache2.service" --email email@chepec.se -d git.chepec.se
# Créer le certificat pour mondomaine.com et son sous domaine www.mondomaine.com : sudo certbot certonly --webroot --agree-tos --email votre@email.com -d mondomaine.com -d www.mondomaine.com -w /var/www/html --rsa-key-size 4096
Ajouter d'autres domaines lors de la création du certificat avec l'option -d domaine.tld. Spécifier l'emplacement du site sur le serveur avec l'option --webroot (-w) : /var/www/html/ Utiliser l'option -d mondomaine.com -d www.mondomaine.compour ajouter un site. Le certificat créé sera multi-site. Utiliser l'option --rsa-key-size 4096 pour améliorer le certificat en le passant en 4096 bits (2048 bits par défaut).
Pour une gestion simplifiée des certificats, ne pas intégrer tous vos sous-domaines au même certificat. Créer 2 certificats, pour des sites différents sur des sous-domaines différents, pour blog.domaine.com et forum.domaine.com. En cas de modification, de déplacement ou de suppression de l'un des sites, il n’y aura pas d'impacts sur les autres certificats.
# Créer le certificat pour mes propres domaines : sudo certbot certonly --webroot --agree-tos --email vision.du.web@free.fr -d green-nrj.com -d www.green-nrj.com -d unis-pour-le-climat.com -d www.unis-pour-le-climat.com -d unis-pour-la-planete.com -d www.unis-pour-la-planete.com -w /var/www/html --rsa-key-size 4096
# Après avoir lancé la commande de création de certificat, les éléments suivants sont affichés : Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator webroot, Installer None << Je note que le plugin Authenticator webroot ne semble pas être installé ! Obtaining a new certificate Performing the following challenges: http-01 challenge for www.unis-pour-la-planete.com http-01 challenge for green-nrj.com http-01 challenge for unis-pour-la-planete.com http-01 challenge for unis-pour-le-climat.com http-01 challenge for www.green-nrj.com http-01 challenge for www.unis-pour-le-climat.com Using the webroot path /var/www/html for all unmatched domains. << Attention : Dans mon cas, par la suite, un des domaines se trouve dans /var/www/domaine.tld Waiting for verification... Cleaning up challenges IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/green-nrj.com/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/green-nrj.com/privkey.pem Your cert will expire on 2019-01-21. 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"
Accéder aux logs de la création du certificat : sudo cat /var/log/letsencrypt/letsencrypt.log
Consulter le dossier de Let's Encrypt qui devrait contenir les clés dans un dossier live/ sudo bash cd /etc/letsencrypt/ Contenu du dossier si la génération des clés a échoué : accounts cli.ini csr keys renewal renewal-hooks Contenu du dossier si la génération des clés a fonctionné : accounts archive cli.ini csr keys live renewal renewal-hooks
Note : Que ce soit pour standalone ou webroot, le plugin ne semble pas trouver : Plugins selected: Authenticator webroot, Installer None
Générer le certificat Let's Encrypt avec webroot
# L'avantage est qu'il n'est pas nécessaire de stoper Apache pour renouveller les certificats ! certbot certonly --webroot -w /var/www/lesite -d www.lesite.com -d lesite.com -w /var/www/autresite -d autre.site.net -d autre.site.encore.net
sudo certbot certonly --webroot -w /var/www/domaine.visionduweb.fr -d domaine.visionduweb.fr Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator webroot, Installer None Obtaining a new certificate IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/domaine.visionduweb.fr/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/domaine.visionduweb.fr/privkey.pem Your cert will expire on 2020-09-17. 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" - 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
Source : https://certbot.eff.org/docs/using.html#webroot
Les certificats obtenus
# Les certificats se trouvent dans les dossiers : /etc/letsencrypt/live/domain.tld/ # Pour chaque certificat 4 fichiers ont été créés :
privkey.pem : La clé privée de votre certificat. A garder strictement confidentiel. cert.pem : Le certificat serveur pour les versions d'Apache < 2.4.8. chain.pem : Les certificats intermédiaires pour les versions d'Apache < 2.4.8. fullchain.pem : L'ensemble des certificats, concaténation du cert.pem et du chain.pem, pour les versions d’Apache >= 2.4.8.
Options de configuration pour le renouvellement des certificats
Changer l'emplacement du répertoire de travail pour un site utilisant Let's Encrypt
# Lors de mes essais, j'avais généré un certificat pour plusieurs domaines, pointant tous vers le dossier "/var/www/html". # Par la suite, les répertoires sur le serveur ont évolués, et, certains sites ont eut leur propre répertoire.
# Changer le chemin du site visionduweb.fr qui a changé d'emplacement sur le disque par après que le certificat ait été créé. cd /etc/letsencrypt/renewal sudo nano green-nrj.com.conf
# De green-nrj.com = /var/www/html www.green-nrj.com = /var/www/html visionduweb.fr = /var/www/html www.visionduweb.fr = /var/www/html
# Vers green-nrj.com = /var/www/html www.green-nrj.com = /var/www/html visionduweb.fr = /var/www/visionduweb.fr www.visionduweb.fr = /var/www/visionduweb.fr
# Noter qu'il semble préférable de révoquer le certificat multi-site, pour créer un seul certificat par domaine. # Cela permet de mieux gérer les révocations individuelles, notamment, en cas de modification du nom de dossier contenant le site.
Configurer le vhost de Apache pour utiliser le certificat
# Se placer dans le dossier des sites activés. cd /etc/apache2/sites-available/
# Éditer le fichier du VirtualHost à configurer. # L'outil en ligne suivant permet de générer la configuration du VirtualHost pour obtenir une sécurité optimale : https://ssl-config.mozilla.org
Configuration du VirtualHost de Apache2
Configuration minimaliste présente lors de la création du certificat
# Ajouter les lignes suivante dans le VirtualHost.
<VirtualHost *:80>
ServerName www.green-nrj.com
ServerAlias green-nrj.com
ServerAdmin mail@visionduweb.com
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
Enregistrer la configuration et quitter l'éditeur de texte.
Tester la configuration de Apache2 : sudo apachectl -t
Redémarrer Apache2 pour appliquer la nouvelle configuration : sudo systemctl restart apache2
Configuration avancée pour prendre en compte le certificat qui a été créé
# Ajouter les lignes suivante à la suite des lignes présentes dans le VirtualHost.
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName www.green-nrj.com
ServerAlias green-nrj.com
ServerAdmin mail@visionduweb.com
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
# Quatres lignes pour intégrer le certificat Let's Encrypt.
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/green-nrj.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/green-nrj.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/green-nrj.com/chain.pem
</VirtualHost>
</IfModule>
Enregistrer la configuration et quitter l'éditeur de texte.
Tester la configuration de Apache2 : sudo apachectl -t
Redémarrer Apache2 pour appliquer la nouvelle configuration : sudo systemctl restart apache2
Optimiser la configuration SSL
## Récupérer les infos supplémentaires depuis le fichiers options-ssl-apache.conf ## Je ne trouve pas ce fichier.
Ajouter les directives qui nous intéressent : SSLProtocol SSLHonorCipherOrder SSLCompression SSLOptions SSLCipherSuite
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
Tester la configuration de Apache2 : apachectl -t
Rester à jour avec les montées en version en 2020
# Exclure -TLSv1 -TLSv1.1 et éventuellement inclure +TLSv1.3 SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.3 # Malgré cette configuration, les tests SSL indiquent que le serveur accepte toujours TLSv1 et TLSv1.1. Cela est sûrement du aux Ciphers utilisés.
# Utiliser le générateur de configuration SSL de Mozilla : https://ssl-config.mozilla.org
# Ajouter dans le VirtualHost : # Activer HTTP2 si disponible. # D'après le test en ligne, HTTP2 n'est pas activé pour le site / serveur. A suivre. Protocols h2 http/1.1
# Ajouter / Remplacer : # Configuration intermédiaire tolérante pour les appareils moyennement modernes : # Je rajoute -SSLv2 des fois que ... SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384 SSLHonorCipherOrder off SSLSessionTickets off
# Cette configuration semble être trop restrictive, car, les applications Android n'arrivent plus à monitorer le serveur, même pour simplement savoir si le serveur est en ligne. # Le problème "javax.net.ssl.SSLProtocolException: SSL handshake aborted" est lié aux Cipher configurés sur Apache2. # Avec une configuration prenant en compte les anciens appareils, les logiciels de monitoring Android continueront de fonctionner.
# En autorisant les Ciphers suivant, les outils de monitoring sous Android continuerons de fonctionner : SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA SSLHonorCipherOrder on
# Se renseigner sur cette directive : # Également proposé par le générateur Mozilla mais indique une erreur au redémarrage de Apache2 : # SSLUseStapling On # SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
Rediriger toutes les requêtes http vers https
# Remplacer : ## ## ## Port 80 ## ## ## <VirtualHost *:80> Servername visionduweb.fr Redirect permanent / http://www.visionduweb.fr/ </VirtualHost>
# Par :
## ## ## Port 80 ## ## ##
<VirtualHost visionduweb.fr:80>
ServerName visionduweb.fr
ServerAlias www.visionduweb.fr
# Le vhost du port 80 redirige de http vers https.
# Je souhaite que 100% du trafic passe sur https.
# Les informations complémentaires sont inutiles.
# Pas de documentRoot, pas de logs.
<IfModule mod_rewrite.c>
RewriteEngine on
# Redirection de http vers https.
RewriteCond %{HTTPS} off
# Le dossier .well-know doit être exclu de la réécriture d'URL.
RewriteRule (^|/)\.(?!well-known) - [F]
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]
</IfModule>
</VirtualHost>
Tester la configuration de Apache2 : apachectl -t
Les challenge ACME
Challenge http-01
# Letsencrypt utilise un protocole appelé ACME (Automated Certificate Management Environment) pour déterminer si vous êtes vraiment le propriétaire du domaine pour lequel vous demandez un certificat.
# Informations complémentaires sur le dossier .well-know qui devrait être créé par certbot. # Dans mon cas certbot n'a pas créé de dossier .well-know ! # Le challenge .well-know ne peut donc pas fonctionner.
# Même si le dossier et le token existent : .well-known/acme-challenge/token # Le fait d'être en HSTS preload + sous domaines, ce qui force la redirection de HTTP vers HTTPS sur tous les domaines, semble empêcher la validation du challenge http-01.
# Le problème du challenge HTTP-01 pourrait principalement venir de l'absence du token dans le dossier .well-known/acme-challenge/token
# Vérifier l'existence du dossier .well-known : curl -I https://www.visionduweb.fr/.well-known
# Exclure le dossier .well-know de la réécriture d'URL : RewriteRule (^|/)\.(?!well-known) - [F]
# Configurer le serveur web pour qu'il aille chercher .well-known là où certbot l'a créé. # Il n'est pas obligatoire de placer le dossier .well-known dans le dossier principale du site concerné : - Un /var/www/certbot/ dans lequel certbot peut écrire peut être placé n'importe où et peut servir pour tous les domaines. - Dans la conf du serveur web, créer un alias pour que /.well-known pointe sur /var/www/certbot/ - Appeler certbot en cli en lui précisant `--webroot -w /var/www/certbot`. - L'option webroot-path permet de définir l'emplacement du dossier .well-known
# Le dossier ".well-known" est actuellement utilisé par Let's Encrypt, mais d'autres usages vont arriver. # Une RFC est sortie sur ce dossier : https://tools.ietf.org/html/rfc5785 # Certain l'utilise déjà pour y stocker les favicons, robots.txt, sitemap... https://github.com/fvsch/scripts-and-snippets/blob/master/apache/rewrite-well-known.conf
# Utiliser un dossier commun pour plusieurs les sites avec un unique alias sur l'adresse "/.well-known/acme-challenge".
# Si le serveur web n'est pas accessible par HTTP, on peut utiliser un challenge par DNS. # Un renouvellement par défaut avec un challenge http-01 ne fonctionnera pas : sudo certbot renew Attempting to renew cert (privatebin.visionduweb.fr) from /etc/letsencrypt/renewal/privatebin.visionduweb.fr.conf produced an unexpected error: Failed authorization procedure. privatebin.visionduweb.fr (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://privatebin.visionduweb.fr/403-forbidden.php: Too many redirects. Skipping. All renewal attempts failed. The following certs could not be renewed: /etc/letsencrypt/live/privatebin.visionduweb.fr/fullchain.pem (failure)
# Différents exemples de challenges : https://marcofranssen.nl/use-the-acme-dns-challenge-to-get-a-tls-certificate/
Challenge DNS TXT
# Le challenge par DNS TXT : certbot -d privatebin.visionduweb.fr --manual --preferred-challenges dns certonly
# Accepter que l'adresse IP utilisée soit loguée pour servir de preuve qu'il s'agisse de l'adresse IP de l'administrateur du serveur.
# La commande va alors générer une proposition de DNS TXT à ajouter dans les DNS du domaine concerné : Please deploy a DNS TXT record under the name _acme-challenge.privatebin.visionduweb.fr with the following value: 2JH5sxpMcaex9RBgNUoxhL4ubcL9DzPWFiyNrjgdOG4
# Depuis OVH, le sous domaine est donc : _acme-challenge.privatebin # La valeur est : 2JH5sxpMcaex9RBgNUoxhL4ubcL9DzPWFiyNrjgdOG4
# Après avoir validé la création du DNS TXT depuis le gestionnaire des DNS de votre nom de domaine, patienter quelques minutes puis continuer la validation depuis le serveur :
Before continuing, verify the record is deployed. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Press Enter to Continue Waiting for verification... Cleaning up challenges IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/privatebin.visionduweb.fr/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/privatebin.visionduweb.fr/privkey.pem Your cert will expire on 2020-11-22. 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" - 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
# Tester le déploiement du DNS TXT avec nslookup : nslookup -q=txt _acme-challenge.privatebin.monnaie-libre.fr monnaie-libre.fr Server: monnaie-libre.fr Address: 51.159.57.131#53 ** server can't find _acme-challenge.privatebin.monnaie-libre.fr: NXDOMAIN
# Tester le déploiement du DNS TXT en affichant la valeur de la clé : dig TXT _acme-challenge.privatebin.monnaie-libre.fr +short
# Tester le déploiement du DNS TXT avec un test en boucle et dig : while true; do dig privatebin.monnaie-libre.fr TXT | grep "QZlU7"; sleep 30; done
# Note : # La commande certbot renew ne permet pas le renouvellement du certificat dans le cas d'un challenge DNS TXT. # Il faut soit renouveler le certificat en relançant la commande manuellement pour gérer un nouveau token DNS TXT, soit intégrer de nouveaux outils au serveur pour automatiser le renouvellement.
Challenge TLS-SNI-01
Utilise TLS sur le port 443.
Vérifier son certificat
Vérifier la configuration et la qualité du paramétrage SSL
Tester le score de votre certificat depuis l'outil en ligne proposé par ssllabs : https://www.ssllabs.com/ssltest/index.html Analyser le domaine visionduweb.fr depuis SSLLabs retourne un score A+. Vous devez viser l'obtention d'un A+ pour chacun de vos domaines.
Vérifier les liens suivants pour étudier la qualité de son certificat
# Autres liens à consulter et à trier, pour vérifier son certificat.
Mozilla SSL Configuration Generator : https://mozilla.github.io/server-side-tls/ssl-config-generator/
https://www.ssllabs.com/ssltest/ https://tls.imirhil.fr https://ssldecoder.org https://www.networking4all.com/en/ https://www.htbridge.com/ssl/ https://observatory.mozilla.org https://securityheaders.com
A installer sur sa machine : https://f4fia.wordpress.com/2015/08/16/tuto-installation-du-script-sslcheck/
Sous GNU/Linux pour tester la connexion en présentant un cipher particulier : openssl s_client -cipher 'ECDHE-RSA-AES256-GCM-SHA384 ' -connect www.monsite.com:443
Pour tester la connexion et voir quel cipher est négocié : openssl s_client -connect www.monsite.com:443
Lister tous les ciphers côté client : openssl ciphers -v
Lister les ciphers côté client excepté ceux sans chiffrement (eNULL) ou sans authentification (aNULL) : openssl ciphers -v 'ALL:!aNULL'
Tester le ciphers supportés par votre serveur : https://github.com/drwetter/testssl.sh
Vérifier le temps restant en jours avant expiration de son certificat
Vérifier la date de validité des certificats
sudo certbot certificates
Utiliser cURL pour vérifier le certificat d'un domaine
curl -L -v -s https://www.visionduweb.fr 1>/dev/null
# Retourne :
* found 598 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* server certificate verification OK
* server certificate status verification SKIPPED
* common name: green-nrj.com (matched)
* server certificate expiration date OK
* server certificate activation date OK
* certificate public key: RSA
* certificate version: #3
* subject: CN=green-nrj.com
* start date: Thu, 20 Dec 2018 01:37:02 GMT
* expire date: Wed, 20 Mar 2019 01:37:02 GMT
* issuer: C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
* compression: NULL
* ALPN, server accepted to use http/1.1
> GET / HTTP/1.1
> Host: www.visionduweb.fr
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 25 Feb 2019 03:52:54 GMT
< Server: Apache/2.4.38 (Debian)
< Expires: Wed, 17 Aug 2005 00:00:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Pragma: no-cache
< Set-Cookie: f4e8b27a5048454220760e16fe525d93=js9viovkacg8u0cbq1ebcc8eev; path=/; HttpOnly
< Last-Modified: Mon, 25 Feb 2019 03:52:55 GMT
< Vary: Accept-Encoding
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=utf-8
<
{ [6 bytes data]
* Connection #0 to host www.visionduweb.fr left intact
Utiliser openssl pour vérifier le certificat d'un domaine
# Afficher la date d'expiration d'un certificat : echo | openssl s_client -connect visionduweb.fr:443 2>/dev/null \ | openssl x509 -noout -enddate
# Retourne : notAfter=Mar 20 01:37:02 2019 GMT
# Autre commande pour un certificat :
openssl s_client -showcerts -connect ${HOSTNAME}:443
# Autre commande pour plusieurs certificats sur la même adresse IP - Remplacer l'adresse IP par celle du serveur, et, le HOSTNAME par le HOSTNAME du serveur :
openssl s_client -showcerts -connect ${HOSTIP}:443 -servername ${HOSTNAME}
Monitorer la date d'expiration d'un certificat SSL avec ssl-cert-check
# Installer le paquet. sudo apt-get install ssl-cert-check
# Monitorer un certificat SSL installé sur votre serveur. ssl-cert-check -c /etc/letsencrypt/live/site.net/fullchain.pem
# Monitorer un certificat SSL en ligne. ssl-cert-check -s noobunbox.net -p 443
# Monitorer plusieurs domaines à partir d'une liste. # Créer le fichier pour accueillir la liste. nano ssl-domains # Ajouter les domaines dans la liste. site.net 443 site.deux.net 443 google.com 443 # Vérifier la liste. ssl-cert-check -f ssl-domains # Plus d'informations sur les certificats avec le paramètre -i. ssl-cert-check -i -f ssl-domains
# Envoyer une (-a) alerte par (-e) email si l’un des certificats listés dans le fichier (-f ssl-domains) ssl-domains expire dans (-x 60) 60 jours. ssl-cert-check -a -f ssl-domains -q -x 60 -e adresse-email
Script pour vérifier un certificat et les domaines liés
# Ajouter les lignes suivantes dans un fichier how-much-time-remaining.sh sudo touch how-much-time-remaining.sh sudo nano how-much-time-remaining.sh
cert="/etc/letsencrypt/live/green-nrj.com/cert.pem"
echo " "
echo "############"
if openssl x509 -checkend 86400 -noout -in $cert
then
echo "Le certificat $cert fonctionnera demain !"
today=`date +%D`
expiredate=`openssl x509 -enddate -noout -in $cert | awk -F'=' '{print $2}'`
expdate="date +%D --date='$expiredate'"
ed=`eval $expdate`
daysleft=`echo $(($(($(date -u -d "$ed" "+%s") - $(date -u -d "$today" "+%s"))) / 86400))`
datejourformatfr=`date -d "$today" +%d/%m/%y`
dateexpirationformatfr=`date -d "$ed" +%d/%m/%y`
echo "Date du jour : $datejourformatfr ; Expiration : $dateexpirationformatfr ; $daysleft jours restants avant expiration."
else
echo "Le certificat $cert a expiré ou va expirer d'ici 24 heures !"
echo "(Ou alors, le certificat est invalide ou n'a pas été trouvé.)"
fi
echo "############"
echo " "
# Lancer le script : sudo sh how-much-time-remaining.sh
# Le message suivant sera affiché pour un certificat valide : ############ Certificate will not expire Le certificat /etc/letsencrypt/live/green-nrj.com/cert.pem fonctionnera demain ! Date du jour : 25/02/19 ; Expiration : 20/03/19 ; 23 jours restants avant expiration. ############
Renouveler un certificat
# Le certificat délivré par Let's Encrypt est valable 90 jours. # Il faut renouveler le certificat avant son expiration sinon il devient invalide. # Let's Encrypt ne renouvellera pas le certificat avant les 30 derniers jours de validité du certificat.
# Il est bon de vérifier que cette commande fonctionnera bien le moment venu. # Pour cela on peut lancer une simulation de renouvellement via : certbot-auto renew --dry-run
# 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.
# IMPORTANT : Arrêter Apache2 avant de lancer la commande de renouvellement du certificat ! sudo apache2ctl stop
# Renouveler le certificat : certbot renew # Où pour ne pas afficher les information inutiles : certbot -q renew # Où pour vérifier automatiquement tous les certificats de votre serveur et renouveler ceux qui vont expirer dans moins de 30 jours. certbot-auto renew # Où forcer le renouvellement en ajoutant le flag --force-renewal. # Noter que la modification de la force de la clé RSA peut être demandée lors du renouvellement avec le flag --rsa-key-size 4096. ./certbot-auto renew --rsa-key-size 4096 --force-renewal # Où forcer le renouvellement des certificats ayant expirés en ajoutant le flag --force-renew.
# Redémarrer Apache2. sudo systemctl start apache2
# Dans le cas ou le certificat ne nécessite pas encore un renouvellement, le message suivant sera affiché : sudo certbot renew Saving debug log to /var/log/letsencrypt/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Processing /etc/letsencrypt/renewal/green-nrj.com.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Cert not yet due for renewal - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The following certs are not due for renewal yet: /etc/letsencrypt/live/green-nrj.com/fullchain.pem expires on 2019-01-21 (skipped) No renewals were attempted.
Erreur de renouvellement - The client lacks sufficient authorization
sudo certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/green-nrj.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for visionduweb.fr
http-01 challenge for www.visionduweb.fr
Waiting for verification...
Cleaning up challenges
Attempting to renew cert (green-nrj.com) from /etc/letsencrypt/renewal/green-nrj.com.conf produced an unexpected error: Failed authorization procedure. www.visionduweb.fr (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.visionduweb.fr/.well-known/acme-challenge/euQstJaPGZ3QQ8wm2Akzp5sseWLKKvBvkAo-dW2Qfyk: "<!DOCTYPE html>\n<html xmlns=\"http://www.w3.org/1999/xhtml\" xml:lang=\"fr-fr\" lang=\"fr-fr\" dir=\"ltr\">\n <head>\n <meta htt", visionduweb.fr (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://visionduweb.fr/.well-known/acme-challenge/NqcCUIEySWiT4ATh_-yGJpXuqd2lEF-vFsaa5cYcL1c: "<!DOCTYPE html>\n<html xmlns=\"http://www.w3.org/1999/xhtml\" xml:lang=\"fr-fr\" lang=\"fr-fr\" dir=\"ltr\">\n <head>\n <meta htt". Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/green-nrj.com/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/green-nrj.com/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: www.visionduweb.fr
Type: unauthorized
Detail: Invalid response from
http://www.visionduweb.fr/.well-known/acme-challenge/euQstJaPGZ3QQ8wm2Akzp5sseWLKKvBvkAo-dW2Qfyk:
"<!DOCTYPE html>\n<html xmlns=\"http://www.w3.org/1999/xhtml\"
xml:lang=\"fr-fr\" lang=\"fr-fr\" dir=\"ltr\">\n <head>\n
<meta htt"
Domain: visionduweb.fr
Type: unauthorized
Detail: Invalid response from
http://visionduweb.fr/.well-known/acme-challenge/NqcCUIEySWiT4ATh_-yGJpXuqd2lEF-vFsaa5cYcL1c:
"<!DOCTYPE html>\n<html xmlns=\"http://www.w3.org/1999/xhtml\"
xml:lang=\"fr-fr\" lang=\"fr-fr\" dir=\"ltr\">\n <head>\n
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.
Ici, je suppose que l'erreur est du au fait que j'ai déplacé le site, après avoir créé le certificat. De ce fait, la correspondance avec le dossier .well-known ne correspond plus. Je me rend compte par la suite que le dossier .well-know n'existe pas.
# Proposition de résolution du problème : # - Il faut remettre la redirection de base qui pointe vers /var/www/html cela, depuis les VirtualHosts. # - Il faut renouveler les certificats pour voir si ça fonctionne. # - Il faut révoquer tous les certificats. # - Il faut alors modifier les VirtualHost pour revenir à une configuration http:// # - Il faut recréer les certificats pour les domaines hébergés sur /var/www/html # - Il faut recréer un unique certificat pour visionduweb.fr # - Il faut recréer un unique certificat pour wiki.visionduweb.fr # - Il faut modifier à nouveau les VirtualHost pour prendre en compte les certificats SSL. # - Il faut sauvegarder les certificats.
Pour résoudre ce problème, je n'ai pas eu besoin de réaliser les étapes précédentes que je proposais. 1) J'ai exclu le dossier .well-know de la réécriture d'URL dans le VirtualHost à l'écoute du port 80 : RewriteRule (^|/)\.(?!well-known) - [F] Comme je ne trouve pas ce dossier .well-know ni dans le dossier /var/www/html/ ni dans le dossier du site :/var/www/visionduweb.fr je suppose que ce n'est pas cette configuration qui résolu le problème. Le dossier .well-know n'a pas été trouvé pour le moment.
2) J'ai modifié la configuration depuis le dossier /etc/letsencrypt/renewal/ en éditant le fichier de configuration du certificat : sudo nano green-nrj.com.conf Dans ce fichier, je modifie l'emplacement du site visionduweb.fr qui, depuis son VirtualHost, est configuré pour se trouver dans le dossier /var/html/visionduweb.fr cd /etc/letsencrypt/renewal sudo nano green-nrj.com.conf # De green-nrj.com = /var/www/html www.green-nrj.com = /var/www/html visionduweb.fr = /var/www/html www.visionduweb.fr = /var/www/html # Vers green-nrj.com = /var/www/html www.green-nrj.com = /var/www/html visionduweb.fr = /var/www/visionduweb.fr www.visionduweb.fr = /var/www/visionduweb.fr
Je lance la commande de renouvellement, qui fonctionne maintenant immédiatement. Noter que j'étais en sudo bash (oups). certbot renew Saving debug log to /var/log/letsencrypt/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Processing /etc/letsencrypt/renewal/green-nrj.com.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Cert is due for renewal, auto-renewing... Plugins selected: Authenticator webroot, Installer None Renewing an existing certificate Performing the following challenges: http-01 challenge for visionduweb.fr http-01 challenge for www.visionduweb.fr Waiting for verification... Cleaning up challenges - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - new certificate deployed without reload, fullchain is /etc/letsencrypt/live/green-nrj.com/fullchain.pem - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Congratulations, all renewals succeeded. The following certs have been renewed: /etc/letsencrypt/live/green-nrj.com/fullchain.pem (success) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Si je relance la commande, la date d'expiration a été reconduite pour 90 jours. certbot renew Saving debug log to /var/log/letsencrypt/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Processing /etc/letsencrypt/renewal/green-nrj.com.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Cert not yet due for renewal - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The following certs are not due for renewal yet: /etc/letsencrypt/live/green-nrj.com/fullchain.pem expires on 2019-05-28 (skipped) No renewals were attempted. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Malgré toute, même si le certificat a bien été renouvelé, je rencontre une nouvelle erreur, mes redirections pourtant bien configurées dans les VirtualHost ne fonctionnent plus. Tous les domaines sont redirigés vers /var/www/visionduweb.fr indépendamment de la configuration des VirtualHosts qui fait pointer les autres domaines vers /var/www/html.
# Je modifie à nouveau la configuration du fichier /etc/letsencrypt/renewal/green-nrj.com.conf pour la remettre à son état initial. Tous les domaines pointent à nouveau vers /var/www/html
# Je tente alors de forcer le renouvellement, avec la configuration initiale qui a été éditée dans le fichier /etc/letsencrypt/renewal/green-nrj.com.conf. sudo certbot --force-renewal renew # L'étape aboutie correctement, mais, pas de changement, le domaine visionduweb.fr est bien accessible, mais, tous les autres domaines pointent vers visionduweb.fr
J'ai donc un certificat renouvelé. Un problème de redirection, puisque tous mes domaines pointent vers /var/www/visionduweb.fr Un répertoire .well-know aux abonnés absents.
Finalement, je tente de modifier le VirtualHost du domaine visionduweb.fr, localisé sur le serveur dans le dossier /var/www/visionduweb.fr Je renseigne le DocumentRoot comme étant /var/www/html, ce qui était la situation initiale. (Redémarrer le serveur Apache2.) Je commente la redirection vers le port 443. Je force à nouveau le renouvellement : sudo certbot --force-renewal renew Si je consulte mes domaines multiples, ils pointent maintenant bien sur /var/www/html Si je consulte le domaine visionduweb.fr, il pointe lui aussi vers /var/www/html Le domaine https://visionduweb.fr pointe correctement sur le site hébergé depuis /var/www/visionduweb.fr Résolu / Temporairement seulement.
Si je décommente la redirection vers le port 443 et modifie à nouveau le DocumentRoot du VirtualHost du site visionduweb.fr comme étant DocumentRoot /var/www/visionduweb.fr. (Redémarrer le serveur Apache2.) Tous les domaines pointent à nouveau vers visionduweb.fr bien que le DocumentRoot de leur VirtualHost indique /var/www/html Je n'ai toujours pas de répertoire .well-know.
Je pense pouvoir conclure qu'un certificat Let's Encrypt ne fonctionne que dans le cas ou les domaines pointent vers le même hébergement physique.
J'en reviens à ma proposition de résolution du problème : OK - Il faut remettre la redirection de base qui pointe vers /var/www/html cela, depuis les VirtualHosts. OK - Il faut renouveler les certificats pour voir si ça fonctionne. A faire - Il faut révoquer tous les certificats. A faire - Il faut alors modifier les VirtualHost pour revenir à une configuration http:// A faire - Il faut recréer les certificats pour les domaines hébergés sur /var/www/html A faire - Il faut recréer un unique certificat pour visionduweb.fr A faire - Il faut recréer un unique certificat pour wiki.visionduweb.fr A faire - Il faut modifier à nouveau les VirtualHost pour prendre en compte les nouveaux certificats SSL. A faire - Il faut sauvegarder les certificats.
Renouveler automatiquement un certificat Letsencrypt
# Créer le fichier de log qui va stocker les informations sur le renouvellement. sudo touch /var/log/letsencrypt/letsencrypt-renew.log sudo chown debian:debian /var/log/letsencrypt/letsencrypt-renew.log sudo chmod 644 /var/log/letsencrypt/letsencrypt-renew.log
# Éditer la crontab : crontab -e
# Cette commande ne lancera le renouvellement que si votre certificat est éligible. # Utiliser sudo pour écrire dans les logs, ou, donner les droits en écriture aux 3 éléments notifié ici : Gestion des logs - Letsencrypt.
# Ajouter une tache cron qui va vérifier tous les jours à 2 heures 15 du matin si le certificat doit être renouvelé. 15 2 * * * sudo /usr/bin/certbot renew >> /var/log/letsencrypt/letsencrypt-renew.log
# L'idéal recommandé par certbot serrait d'automatiser une vérification deux fois par jour : 15 2/12 * * * sudo /usr/local/sbin/certbot-auto renew >> /var/log/letsencrypt-renew.log
# Pour que le renouvellement se fasse correctement, il est nécessaire de stopper le serveur Apache2 puis de le relancer pour rendre à nouveau le site disponible : 14 2 * * * sudo service apache2 stop >> /var/log/letsencrypt/letsencrypt-renew.log 15 2 * * * sudo /usr/bin/certbot renew >> /var/log/letsencrypt/letsencrypt-renew.log 16 2 * * * sudo service apache2 restart >> /var/log/letsencrypt/letsencrypt-renew.log
Autre possibilité pour renouveler les certificats
# Le script précédent ne fonctionne pas sur l'un de mes serveurs, et, m'indique que le port 80 n'est pas binding, que Apache2 soit démarré ou stoppé. # Sur mon deuxième serveur, le renouvellement est bien effectué. # Je tente la modification suivante, en utilisant un script.
cd /usr/local/bin/ sudo nano letsencrypt-renew.sh #!/bin/bash # sudo chmod +x letsencrypt-renew.sh /usr/bin/certbot renew >> /var/log/letsencrypt/letsencrypt-renew.log
# Tâche cron depuis la crontab de root : # crontab -e
# Renouvellement des certificats Letsencrypt avec une tâche cron - Tous jours jours à 6h15 -> 6h20 du matin. # 14 06 * * * echo "Début du renouvellement des certificats" >> /var/log/letsencrypt/letsencrypt-renew.log # 14 06 * * * /etc/init.d/apache2 stop >> /var/log/letsencrypt/letsencrypt-renew.log # 16 06 * * * /bin/sh /usr/local/bin/letsencrypt-renew.sh # 18 06 * * * /etc/init.d/apache2 start >> /var/log/letsencrypt/letsencrypt-renew.log # 18 06 * * * echo "Fin du renouvellement des certificats" >> /var/log/letsencrypt/letsencrypt-renew.log
# Même problème, le port 80 n'est pas binding, même si Apache2 est stoppé. # Pourtant, quand je lance le renouvellement manuellement, avec Apache2 stoppé, le renouvellement est bien effectué.
# Modifier le script ainsi : cd /usr/local/bin/ sudo nano letsencrypt-renew.sh # /usr/bin/certbot renew >> /var/log/letsencrypt/letsencrypt-renew.log certbot renew
Révoquer un certificat
Quand on migre 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 par ailleurs.
cd /etc/letsencrypt/live certbot --text revoke --cert-path chemin/vers/cert.pem
Il sera également nécessaire de revenir à une configuration de Apache sans les lignes concernant SSL, le certificat, les ciphers.
Deployer Certbot sur Ubuntu
Ubuntu 18.04 LTS – Installation de certificats SSL/TLS avec Certbot (Let’s Encrypt) : https://howto.wared.fr/ubuntu-certificats-ssl-tls-certbot/ How to Install Let’s Encrypt with Apache on Ubuntu 16.04 : https://linuxhostsupport.com/blog/how-to-install-lets-encrypt-with-apache-on-ubuntu-16-04/
Wildcard
Aux alentours de avril 2018 (Apparemment), Let'Encrypt a intégré le wildcard.
La syntaxe de la commande ne change pas : certbot certonly -d *.domaine.org
Pour un wildcard, le challenge acme est différent. Au lieu du challenge http (Installer un fichier sous .well-known/acme-challenges/), il y a un challenge DNS : ajout d'un enregistrement DNS de type TXT dans la zone DNS.
How to : Use certbot with Let’s Encrypt wildcard certificates : https://www.eigenmagic.com/2018/03/14/howto-use-certbot-with-lets-encrypt-wildcard-certificates/
Notes
Avec systemd ce /etc/cron.d/certbot ne fait rien. Il sort sans rien faire si /run/systemd/system existe. Dans ce cas, c'est /etc/systemd/system/certbot.service qui fait le travail.
StartSSL avant LetsEncrypt
StartSSL était un service qui était largement utilisé avant la démocratisation de Let's Encrypt. StartSSL ne semble plus être reconnu par Google Chrome ainsi que par Firefox. Il faut désormais s’orienter vers Let’s Encrypt.
Créer un certificat SSL autosigné pour le développement en local
Pour le local on peut utiliser un certificat dit auto-signé, ou self-signed, c'est à dire sans certification d'une autorité compétente. Let's Encrypt ou Gandi par exemple. Un certificat auto-signé déclenche une alerte dans la plupart des navigateurs. Ce n'est évidement pas recommandé pour un serveur en production mais cela suffira très bien pour un serveur local.
Créer un certificat SSL / TLS sur Debian : https://howto.biapy.com/fr/debian-gnu-linux/serveurs/http/creer-un-certificat-ssl-sur-debian HTTPS mise en place d’un certificat auto signé : http://webdevpro.net/https-mise-en-place-dun-certicat-auto-signe/ Source : https://kgaut.net/blog/2016/creer-un-certificat-ssl-autosigne-pour-le-developpement-en-local.html Créer un certificat SSL autosigné pour le développement en local : https://kgaut.net/comment/6707
Source : https://blog.moncoindunet.fr/linux/openssl/openssl-creer-un-certificat-auto-signe/
Utiliser un certificat pour son site accessible via Tor
Cloudflare propose un certificat gratuit pour Tor
Cloudflare propose un certificat gratuit pour Tor.
Proton mail sur Tor
Proton mail a fait mettre en place un certificat EV pour son service sur Tor. Un certificat EV a été mis en place pour cette occasion : https://www.sslmarket.fr/ssl/certificats-ev/
Sécurité
Failles SSL
Exploit SSL 3.0 alias POODLE : http://blogmotion.fr/internet/securite/faille-sslv3-cve-2014-3566-12180 Faille Heartbleed - Votre serveur est-il vulnérable : http://blogmotion.fr/internet/securite/exploit-ssl-11140
Bibliographie
Acheter un certificat en ligne
https://www.wistee.fr/certificat-ssl.php
EFF - Let's Encrypt
Le site officiel propose des supports d'installation pour différents systèmes d'exploitation : https://certbot.eff.org
Le site officiel pour devenir membre EFF : https://supporters.eff.org/donate/certbot-welcome
Cacert
Tutoriels complémentaires
Serveur Apache2
Serveur Nginx
SSL
Ciphers
Vidéos
NAVIGATION
PARTICIPER ET PARTAGERBienvenue sur le wiki de Amis SH. De nombreuses pages sont partagées sur ce wiki. Créer un compte utilisateur pour participer sur le wiki. Les pages présentées sur le wiki évoluent tous les jours. Certaines recherches sont peu abouties et incluent des erreurs. Utiliser la recherche interne du wiki pour trouver votre contenu. La page de discussion de Amis SH vous permet de poser vos questions. Consulter le site amis-sh.fr pour installer votre propre serveur web. Améliorer le contenu des pages avec vos retours depuis l'onglet discussion. Ce contenu ne doit pas servir à nuire à autrui ou à un système informatique. Protéger votre système Linux ou Windows avec cette page dédiée à la sécurité. |
SOUTENIR CE WIKISoutenir le wiki avec un don en monnaie numérique : AEON - Bitcoins - Bitcoins Cash - Bitcoins Gold - Bitcore - Blackcoins - Basic Attention Token - Bytecoins - Clams - Dash - Monero - Dogecoins - Ğ1 - Ethereum - Ethereum Classique - Litecoins - Potcoins - Solarcoins - Zcash OBTENIR DE LA MONNAIE NUMERIQUEObtenir gratuitement de la monnaie numérique : Miner de la cryptomonnaie. |