Différences

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

--- admin:services:letsencrypt [2020/04/26 00:28] – [Installation] Désactivation du timer et du service systemd david
+++ admin:services:letsencrypt [2020/06/17 18:23] (Version actuelle) – zertrin
@@ Ligne 2: / Ligne 2: @@
 Cette page décrit la mise en place des certificats signés par [[https://letsencrypt.org/|Let's Encrypt]] sur les serveurs de FedeRez.
+<WRAP center round important>
+Quand vous créez un nouveau certificat ou si vous ajoutez des sous-domaines dans un certificat existant, pensez bien à mettre à jour le script de monitoring des certificats SSL : cf [[admin:services:ssl-cert-check]]
+</WRAP>
+<WRAP center round important>
+Pour les tests il faut apposer temporairement ''--dry-run'' à la commande certbot. Il est **obligatoire** de faire des tests jusqu'à ce que ça marche, il y a toujours des oublis ou des problèmes imprévus, et trop d'erreurs sans dry run va conduire à un blocage temporaire du coté de Let's Encrypt.
+</WRAP>
 ===== Mise en place de Let's Encrypt sur les serveurs FedeRez =====
@@ Ligne 29: / Ligne 37: @@
  *  le webroot qui consiste à rediriger les requêtes des serveurs LE dans un dossier différent de celui de l'application web usuelle.
-Nous choisirons ici le deuxième méthode le plus souvent.
+Nous choisirons ici la deuxième méthode.
 Pour un nginx la configuration à placer dans le vhost est la suivante :
@@ Ligne 51: / Ligne 59: @@
-La première fois on vous demandera de dire oui aux TOSS. Pour les test il faut apposer --dry-run. Il est obligatoire de faire des tests jusqu'à ce que ça marche, il y a toujours des oublis.
+La première fois on vous demandera de dire oui aux TOSS.
-Si on veut étendre un certificat existant on peut placer un --extend et il faut mettre le même nom.
+<WRAP center round important>
+Rappel: Pour les tests il faut apposer temporairement ''--dry-run'' à la commande certbot. Il est **obligatoire** de faire des tests jusqu'à ce que ça marche, il y a toujours des oublis ou des problèmes imprévus, et trop d'erreurs sans dry run va conduire à un blocage temporaire du coté de Let's Encrypt.
+</WRAP>
-Pour avoir une idée de quels certificats sont existants un ''certbot certificates'' marche très bien.
+Si on veut étendre un certificat existant on peut placer un ''--extend'' et il faut mettre le même nom.
+Pour avoir une idée de quels certificats sont existants un ''certbot certificates'' marche très bien.
 ==== Vue d'ensemble du système ====
@@ Ligne 71: / Ligne 82: @@
   * Un **script de monitoring des certificats SSL** est en place pour vérifier la durée de validité restante et alerter si le certificat s'approche de son expiration : voir [[admin:services:ssl-cert-check]].
-<WRAP center round alert>
+<WRAP center round info >
-Précédemment, **il fallait absolument éviter de retirer un sous-domaine de la liste des domaines** après que le certificat ait été déjà émis. Lors du renouvellement une nouvelle "lignée" de certificats était créée ne se trouvant pas dans le dossier de destination attendu par les services.
+Précédemment, il fallait absolument éviter de retirer un sous-domaine de la liste des domaines après que le certificat ait été déjà émis. Lors du renouvellement une nouvelle "lignée" de certificats était créée ne se trouvant pas dans le dossier de destination attendu par les services.
 Ceci était du au bug https://github.com/certbot/certbot/issues/2071
@@ Ligne 79: / Ligne 90: @@
 Désormais, il suffit que l'option ''--cert-name'' soit donnée quand on appelle certbot. Cela définit la "lignée" de certificats et donc, si on retire un sous domaine de la liste, il comprendra que c'est bien ce qu'on veut faire.
-</WRAP>
-<WRAP center round important>
-Quand vous ajoutez des sous-domaines dans le certificat, pensez bien à mettre à jour le script de monitoring des certificats SSL : cf [[admin:services:ssl-cert-check]]
 </WRAP>
@@ Ligne 153: / Ligne 159: @@
 mkdir -p /var/www/letsencrypt/.well-known/acme-challenge
 </code>
 Pour éviter de définir pour chaque site un bloc de configuration pour HTTP afin de rediriger les navigateurs vers la version HTTPS de chaque site, on peut créer un fichier '''/etc/apache2/sites-available/000-no-tls.conf''' avec :
 <file apache /etc/apache2/sites-available/000-no-tls.conf>
 <VirtualHost *:80>
@@ Ligne 194: / Ligne 200: @@
 On s'assurera que le module '''mod_rewrite''' est bien chargé :
   a2enmod rewrite
 Ensuite, il faut activer la configuration du site qui gère HTTP avec :
   a2ensite 000-no-tls
-Enfin, on peut supprimer tous les VHOST HTTP pour ne laisser que les blocs qui concernent HTTPS dans les fichiers de configuration d'Apache. Puis on recharge la configuration d'apache :
+Enfin, on peut supprimer tous les VHOST HTTP pour ne laisser que les blocs qui concernent HTTPS dans les fichiers de configuration d'Apache.
+Notamment, s'il n'est pas utilisé pour autre chose, il faut désactiver la config ''000-default.conf'' avec ''a2dissite 000-default.conf''. Sinon il prend précédence sur le ''000-no-tls.conf'' qu'on vient de définir.
+Puis on recharge la configuration d'apache :
   service apache2 reload
@@ Ligne 205: / Ligne 219: @@
   - Créer un fichier de test : ''echo 'This is a test' > /var/www/letsencrypt/.well-known/acme-challenge/test''
   - Depuis une autre machine, utiliser le oneliner suivant pour tester l'accès à ce fichier de test (remplacer ''quigon ldap-ro wiki-backup git'' par les sous-domaines à tester) :
+  - s'assurer de voir ''This is a test'' retourné pour chaque sous domaine (et donc pas une erreur 404).
 <code>
@@ Ligne 224: / Ligne 239: @@
 # ----------------------------------
-#  EXAMPLE POUR QUIGON.FEDEREZ.NET
+#  EXAMPLE POUR EXMAPLE.FEDEREZ.NET
 #  À ADAPTER EN FONCTION DU SERVEUR
 # ----------------------------------
@@ Ligne 233: / Ligne 248: @@
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
-FULLCHAINPATH="/etc/letsencrypt/live/EXAMPLE.federez.net/fullchain.pem"
+# remplacer avec le bon chemin, cf le --cert-name ci-dessous
+FULLCHAINPATH="/etc/letsencrypt/live/EXMAPLE.federez.net/fullchain.pem"
 if [[ -e "$FULLCHAINPATH" ]]
@@ Ligne 244: / Ligne 260: @@
 echo "Renewing federez.net with letsencrypt-auto..."
-# Pour le moment, il faut absolument éviter de retirer un sous-domaine de la liste des domaines
+# Bien s'assurer que le --cert-name est défini, sinon il y aura des problèmes si on veut retirer des domaines.
-# après que le certificat ait été déjà émis. Lors du renouvellement une nouvelle “lignée” de
+# De préférence mettre le meme nom que le premier domaine demandé, qui est de préférence le FQDN du serveur.
-# certificats sera créée ne se trouvant pas dans le dossier de destination attendu par les services.
-#
-# Ceci est du au bug https://github.com/letsencrypt/letsencrypt/issues/2071
-#
-# Il est cependant possible d'ajouter des SAN sans problème.
 /usr/bin/letsencrypt certonly --config /etc/letsencrypt/cli.ini --non-interactive --quiet \
-  -d quigon.federez.net \
+  --cert-name EXMAPLE.federez.net \
+  -d EXMAPLE.federez.net \
   -d ldap-ro.federez.net \
   -d wiki-backup.federez.net \
@@ Ligne 283: / Ligne 295: @@
   echo "Restarting services ..."
   /bin/systemctl reload apache2.service
-  /bin/systemctl reload postfix.service
+  # /bin/systemctl reload postfix.service
   # /bin/systemctl reload proftpd.service
   # /bin/systemctl restart dovecot.service
@@ Ligne 291: / Ligne 303: @@
 === Tester la génération du certificat ===
+<WRAP center round important>
+Rappel: Pour les tests penser à apposer temporairement ''--dry-run'' à la commande certbot dans le script. Il est **obligatoire** de faire des tests jusqu'à ce que ça marche, il y a toujours des oublis ou des problèmes imprévus, et trop d'erreurs sans dry run va conduire à un blocage temporaire du coté de Let's Encrypt.
+</WRAP>
 <code>