serveur_hebergement:apache2:let_s_encrypt_certbot_et_ssl_sur_debian

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Prochaine révision		 Révision précédente
serveur_hebergement:apache2:let_s_encrypt_certbot_et_ssl_sur_debian [2022/10/21 16:59] – créée fateserveur_hebergement:apache2:let_s_encrypt_certbot_et_ssl_sur_debian [2024/03/22 13:45] (Version actuelle) – [Création d’un certificat wildcard] fate
Ligne 3: Ligne 3:
 Pour ceux qui ne connaissent pas, Let's Encrypt fourni, gratuitement, des certificats SSL reconnus par les navigateurs (une petite révolution). Pour ceux qui ne connaissent pas, Let's Encrypt fourni, gratuitement, des certificats SSL reconnus par les navigateurs (une petite révolution).
  
-Le SSL, qu'est-ce que c'est ? C'est un protocole permettant de sécuriser les échanges sur internet, que ce soit via les protocoles http, ftp ou encore pop (pour les mail). Ce protocole ne se nomme plus SSL (Secure Sockets Layer) mais TLS (Transport Layer Security) depuis 1999 (merci wikipedia ^^). Le protocole TLS est le successeur du protocole SSL (ce dernier n'étant plus utilisé) mais le terme SSL est resté.+Le SSL, qu'est-ce que c'est ? C'est un protocole permettant de sécuriser les échanges sur internet, que ce soit via les protocoles http, ftp ou encore pop (pour les e-mails). Ce protocole ne se nomme plus SSL (Secure Sockets Layer) mais TLS (Transport Layer Security) depuis 1999 (merci wikipedia ^^). Le protocole TLS est le successeur du protocole SSL (ce dernier n'étant plus utilisé) mais le terme SSL est resté.
  
 Pour expliquer rapidement comment ça fonctionne, le SSL utilise une paire de clé (publique et privée) et une autorité de confiance : Pour expliquer rapidement comment ça fonctionne, le SSL utilise une paire de clé (publique et privée) et une autorité de confiance :
   - Le navigateur se connecte au serveur et demande une connexion SSL   - Le navigateur se connecte au serveur et demande une connexion SSL
   - Le serveur envoi un certificat SSL, contenant sa clé publique et sa signature numérique chiffrée, au navigateur   - Le serveur envoi un certificat SSL, contenant sa clé publique et sa signature numérique chiffrée, au navigateur
-  - Le navigateur essaye de déchiffrer la signature avec les clés publique des autorités de confiance intégrés au navigateur (VeriSign, Visa, etc)+  - Le navigateur essaye de déchiffrer la signature avec les clés publiques des autorités de confiance intégrés au navigateur (VeriSign, Visa, etc)
   - S'il y arrive, ça prouve que le certificat a été émis par une autorité de confiance, tout va bien. S'il n'y arrive pas il va déchiffrer la signature avec la clé publique fournie avec le certificat et va alerter l'utilisateur que ce certificat n'a pas été émis par une autorité de confiance et n'est donc pas sûr (on parle de certficat auto-émis).   - S'il y arrive, ça prouve que le certificat a été émis par une autorité de confiance, tout va bien. S'il n'y arrive pas il va déchiffrer la signature avec la clé publique fournie avec le certificat et va alerter l'utilisateur que ce certificat n'a pas été émis par une autorité de confiance et n'est donc pas sûr (on parle de certficat auto-émis).
   - Une fois le certificat validé, le navigateur va échanger des données chiffrées avec le serveur en utilisant des suites cryptographiques (voir plus de détails [[https://fr.wikipedia.org/wiki/Suite_cryptographique|ici]]).   - Une fois le certificat validé, le navigateur va échanger des données chiffrées avec le serveur en utilisant des suites cryptographiques (voir plus de détails [[https://fr.wikipedia.org/wiki/Suite_cryptographique|ici]]).
Ligne 14: Ligne 14:
 La révolution amenée par Let's Encrypt est qu'il a été reconnu comme une autorité de confiance et que, contrairement aux autres autorités de confiance, il propose des certificats gratuitement. La révolution amenée par Let's Encrypt est qu'il a été reconnu comme une autorité de confiance et que, contrairement aux autres autorités de confiance, il propose des certificats gratuitement.
  
-Toutes les commandes indiquées doivent être lancé avec l'utilisateur root (ou avec sudo)+Toutes les commandes indiquées doivent être lancées avec l'utilisateur root (ou avec sudo)
  
 =====Activez le support SSL===== =====Activez le support SSL=====
Ligne 41: Ligne 41:
 =====Création du certificat SSL sans wildcard ===== =====Création du certificat SSL sans wildcard =====
  
-Si vous avez besoin de créer un certificat wildcard (c'est à dire valide pour tous les sous-domaines également), passez au chapitre suivant.+Si vous avez besoin de créer un certificat wildcard (c’est-à-dire valide pour tous les sous-domaines également), passez au chapitre suivant.
  
 Commencez par créer un fichier lets_encrypt.ini (vous pouvez le nommer comme vous voulez) et mettez-y les lignes suivantes dedans : Commencez par créer un fichier lets_encrypt.ini (vous pouvez le nommer comme vous voulez) et mettez-y les lignes suivantes dedans :
Ligne 58: Ligne 58:
   * agree-tos=true : permet d’accepter les conditions d’utilisation de Certbot   * agree-tos=true : permet d’accepter les conditions d’utilisation de Certbot
   * email : c’est l’adresse sur laquelle seront envoyés les messages de renouvellement. Il vous faut la modifier   * email : c’est l’adresse sur laquelle seront envoyés les messages de renouvellement. Il vous faut la modifier
-  * domains : indique les domaines pour lesquels vous voulez renouveler les certificats. Il vous faudra les modifier pour mettre vos nom de domaine+  * domains : indique les domaines pour lesquels vous voulez renouveler les certificats. Il vous faudra les modifier pour mettre vos noms de domaine
   * rsa-key-size = 4096 : permet de générer un certificat avec une clé RSA de 4096 bits et non pas de 2048 bits comme c’est le cas par défaut.   * rsa-key-size = 4096 : permet de générer un certificat avec une clé RSA de 4096 bits et non pas de 2048 bits comme c’est le cas par défaut.
  
Ligne 87: Ligne 87:
  
 Si vous allez dans le répertoire /etc/letsencrypt/live/domaine.fr/, vous trouverez 4 fichiers : Si vous allez dans le répertoire /etc/letsencrypt/live/domaine.fr/, vous trouverez 4 fichiers :
-          * privkey.pem qui est la clé privé SSL +          * privkey.pem qui est la clé privée SSL 
-          * cert.pem qui est le certificat SSL. (n'est utilisé que par les version d'Apache inférieure à 2.4.8) +          * cert.pem qui est le certificat SSL. (n'est utilisé que par les versions d'Apache inférieure à 2.4.8) 
-          * chain.pem qui contient des certificats intermédiaire (n'est utilisé que par les version d'Apache inférieure à 2.4.8) +          * chain.pem qui contient des certificats intermédiaires (n'est utilisé que par les versions d'Apache inférieure à 2.4.8) 
-          * fullchain.pem qui est une concaténation des fichier cert.pem et chain.pem (n'est utilisé que par les version d'Apache supérieure ou égale à 2.4.8)+          * fullchain.pem qui est une concaténation des fichiers cert.pem et chain.pem (n'est utilisé que par les versions d'Apache supérieure ou égale à 2.4.8)
  
 ===== Création d’un certificat wildcard ===== ===== Création d’un certificat wildcard =====
Ligne 96: Ligne 96:
 Let’s Encrypt permet également de générer des certificats wildcard. Les wildcard sont des certificats qui sont valables pour l’ensemble des sous-domaines. Let’s Encrypt permet également de générer des certificats wildcard. Les wildcard sont des certificats qui sont valables pour l’ensemble des sous-domaines.
  
-Avec la méthode du chapitre précédent, il faut lister tous les sous-domaines lors de la création du certificat SSL. Du coup si on créé un nouveau sous-domaine 3 jours après avoir généré le certificat SSL il faut le regénérer en incluant le nouveau sous-domaine. Avec les certificats wildcard, plus besoin.+Avec la méthode du chapitre précédent, il faut lister tous les sous-domaines lors de la création du certificat SSL. Du coup si on crée un nouveau sous-domaine 3 jours après avoir généré le certificat SSL il faut le regénérer en incluant le nouveau sous-domaine. Avec les certificats wildcard, plus besoin.
  
 Pour vérifier que le nom de domaine pour lequel vous souhaitez générer un certificat vous appartient, Let’s Encrypt propose 2 types de challenges : Pour vérifier que le nom de domaine pour lequel vous souhaitez générer un certificat vous appartient, Let’s Encrypt propose 2 types de challenges :
-      * http-01 : il envoi une requête http+      * http-01 : il envoie une requête http
       * dns-01 : il demande la création d’un enregistrement TXT sur la zone du domaine       * dns-01 : il demande la création d’un enregistrement TXT sur la zone du domaine
  
 Dans le chapitre précédent, on a utilisé le challenge http-01, le plus simple à mettre en place. Mais pour les certificats wildcard, seul le challenge dns-01 est accepté.  Dans le chapitre précédent, on a utilisé le challenge http-01, le plus simple à mettre en place. Mais pour les certificats wildcard, seul le challenge dns-01 est accepté. 
-Je ne traiterai dans ce chapitre que le cas du serveur DNS auto-hébergé, dans mon cas Bind. Certbot possède d’autres plugins permettant de compléter le challenge dns-01 dans le cas où votre dns est gérer par ovh, ghandi, etc, mais je ne les ai jamais testés.+Je ne traiterai dans ce chapitre que le cas du serveur DNS auto-hébergé, dans mon cas Bind. Certbot possède d’autres plugins permettant de compléter le challenge dns-01 dans le cas où votre dns est géré par ovh, ghandi, etc, mais je ne les ai jamais testés.
  
 Il faut donc impérativement que vous ayez suivi la page [[gnu_linux:raspberry:ip_dynamique_et_dns|IP dynamique et DNS]] sur la mise en place de dns dynamique.  Il faut donc impérativement que vous ayez suivi la page [[gnu_linux:raspberry:ip_dynamique_et_dns|IP dynamique et DNS]] sur la mise en place de dns dynamique. 
-Seuls les chapitres 1 et 2 de cet articles, qui traitent de la création de la clé et de la configuration de Bind, sont indispensable. +Seuls les chapitres 1 et 2 de cet article, qui traitent de la création de la clé et de la configuration de Bind, sont indispensables. 
 L’autre partie traite de la mise à jour de l’adresse ip, qui n’est pas utile pour les wildcard. L’autre partie traite de la mise à jour de l’adresse ip, qui n’est pas utile pour les wildcard.
 Par contre, il ne vous faudra pas utiliser “update-policy”comme indiqué au début du chapitre 2, mais “allow-update” comme indiqué à la fin du chapitre 2 (que vous utilisiez ISPConfig ou non). Par contre, il ne vous faudra pas utiliser “update-policy”comme indiqué au début du chapitre 2, mais “allow-update” comme indiqué à la fin du chapitre 2 (que vous utilisiez ISPConfig ou non).
Ligne 160: Ligne 160:
 <code>/etc/letsencrypt/live/nomdedomaine/</code> <code>/etc/letsencrypt/live/nomdedomaine/</code>
  
-=====Configuration de Apache=====+Une chose à savoir, les certificats créés par certbot ne sont accessibles qu'à l'utilisateur root. Les programmes comme Apache2, Postfix, PureFTP, etc sont exécutés par l'utilisateur root et auront donc accès à ces certificats mais il y peut y avoir d'autres programmes exécuté par un autre utilisateur ayant besoin de ces certificats (Collabora Online par exemple). Le meilleur moyen de donner accès à ces programmes aux certficats est d'utiliser [[ACL|https://fr.wikipedia.org/wiki/Access_Control_List]]. 
 +Commencez par installer le paquet acl : 
 +<code bash>sudo aptitude install acl</code> 
 +Ensuite tapez les commandes suivantes (remplacez utilisateur par votre utilisateur devant accéder aux certificats et nomdedomaine.fr par votre nom de domaine) : 
 +<code bash> 
 +sudo setfacl -m u:utilisateur:rX /etc/letsencrypt/{live,archive} 
 +sudo setfacl -R -m u:utilisateur:rX /etc/letsencrypt/{live,archive}/nomdedomaine.fr 
 +</code> 
 +La première commande donne accès à l'utilisateur "utilisateur" aux répertoires /etc/letsencrypt/live/ et /etc/letsencrypt/archive mais pas à leurs sous-dossiers. 
 +La seconde commande donne accès à l'utilisateur "utilisateur" aux fichiers se trouvant dans les répertoire /etc/letsencrypt/live/nomdedomaine.fr et /etc/letsencrypt/archive/nomdedomaine.fr. 
 + 
 +L'attribution des droits se fait en 2 fois car vous pouvez avoir les certificats de plusieurs noms de domaine dans vos dossiers live et archive mais ne vouloir donner l'accès qu'à un en particulier. Cette modification des droits est perdue après un redémarrage, donc pensez à ajouter un cron pour relancer ces commandes à chaque démarrage. 
 + 
 +=====Configuration d’Apache=====
  
 Maintenant, il nous faut modifier les fichiers de config d'Apache pour intégrer le certificat SSL qui se trouve dans le répertoire /etc/letsencrypt/live/www.domaine.fr/. Maintenant, il nous faut modifier les fichiers de config d'Apache pour intégrer le certificat SSL qui se trouve dans le répertoire /etc/letsencrypt/live/www.domaine.fr/.
Ligne 174: Ligne 187:
          
     ErrorLog /var/log/apache2/error.example.com.log     ErrorLog /var/log/apache2/error.example.com.log
- CustomLog /var/log/apache2/access.example.com.log combined+    CustomLog /var/log/apache2/access.example.com.log combined
          
- <Directory /var/www/domaine.fr> +    <Directory /var/www/domaine.fr> 
- Options -Indexes +FollowSymLinks +MultiViews + Options -Indexes +FollowSymLinks +MultiViews 
- AllowOverride none + AllowOverride none 
- Require all granted + Require all granted 
- </Directory>+    </Directory>
    
     SSLEngine on     SSLEngine on
- SSLCertificateFile    /etc/letsencrypt/live/www.domaine.fr/fullchain.pem +    SSLCertificateFile    /etc/letsencrypt/live/www.domaine.fr/fullchain.pem 
- SSLCertificateKeyFile   /etc/letsencrypt/live/www.domaine.fr/privkey.pem+    SSLCertificateKeyFile   /etc/letsencrypt/live/www.domaine.fr/privkey.pem
    
- Header always set Strict-Transport-Security "max-age=15768000"+    Header always set Strict-Transport-Security "max-age=15768000"
    
   
Ligne 209: Ligne 222:
   * SSLCipherSuite : indique les suites cryptographiques qui peuvent être utilisées (des failles de sécurités ont été trouvées sur certaines suites).   * SSLCipherSuite : indique les suites cryptographiques qui peuvent être utilisées (des failles de sécurités ont été trouvées sur certaines suites).
   * SSLHonorCipherOrder : on indique que l'ordre des suites cryptographiques à utiliser est imposé par le client   * SSLHonorCipherOrder : on indique que l'ordre des suites cryptographiques à utiliser est imposé par le client
-  * SSLSessionTickets : on désactive les tickets de session TLS. Si cette fonction est activé sans redémarrer le serveur selon une périodicité appropriée (par exemple quotidiennement), cela compromet le niveau de confidentialité.+  * SSLSessionTickets : on désactive les tickets de session TLS. Si cette fonction est activée sans redémarrer le serveur selon une périodicité appropriée (par exemple quotidiennement), cela compromet le niveau de confidentialité.
   * SSLUseStapling on et SSLStaplingCache : permet de vérifier les certificats SSL plus rapidement.   * SSLUseStapling on et SSLStaplingCache : permet de vérifier les certificats SSL plus rapidement.
                      
Ligne 230: Ligne 243:
 # intermediate configuration # intermediate configuration
         SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1         SSLProtocol             all -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>+        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         SSLHonorCipherOrder     off
         SSLSessionTickets       off         SSLSessionTickets       off
Ligne 292: Ligne 305:
 <code bash>chmod +x /root/script_letsencrypt.sh</code> <code bash>chmod +x /root/script_letsencrypt.sh</code>
  
-Il ne nous reste plus qu’a lancer ce script tous les jours via le crontab de l’utilisateur root. +Il ne nous reste plus qu’à lancer ce script tous les jours via le crontab de l’utilisateur root. 
  
 Editez le crontab du root  Editez le crontab du root 
Ligne 303: Ligne 316:
  
 Le script sera lancé tous les jours à 1h du matin par l’utilisateur root  et votre certificat sera renouvelé automatiquement 24h avant son expiration.  Le script sera lancé tous les jours à 1h du matin par l’utilisateur root  et votre certificat sera renouvelé automatiquement 24h avant son expiration. 
-Les sorties seront stockés dans le fichier /var/log/lets-encrypt.sh, ce qui vous permettra de voir si des erreurs surviennent.+Les sorties seront stockées dans le fichier /var/log/lets-encrypt.sh, ce qui vous permettra de voir si des erreurs surviennent.
  • serveur_hebergement/apache2/let_s_encrypt_certbot_et_ssl_sur_debian.1666371579.txt.gz
  • Dernière modification : 2023/08/08 14:01
  • (modification externe)