Outils pour utilisateurs

Outils du site


technique:x509

Différences

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

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
technique:x509 [2017/09/28 14:16]
lg
technique:x509 [2020/07/05 18:52] (Version actuelle)
ljf
Ligne 13: Ligne 13:
  
 **Les autres sites web de l'asso, comme ceux permettant de piloter les BMC** sont plutôt dédié à un usage interne et ils ne peuvent exécuter un script pour renouveler un certificat Let's Encrypt tous les 3 mois donc ils **utilisent des certs auto-signés**. Amélioration possible : générer une CA propre à l'asso qui signerait les certs pas importants. Cela permet de l'ajouter dans les navigateurs des admins. **Les autres sites web de l'asso, comme ceux permettant de piloter les BMC** sont plutôt dédié à un usage interne et ils ne peuvent exécuter un script pour renouveler un certificat Let's Encrypt tous les 3 mois donc ils **utilisent des certs auto-signés**. Amélioration possible : générer une CA propre à l'asso qui signerait les certs pas importants. Cela permet de l'ajouter dans les navigateurs des admins.
 +
 +===== Note =====
 +Transformer ça en page de doc http://pad.arn-fai.net/p/HJMYft4fWm
 +
 +Je viens arbitrairement de :
 +  - passer les reload en sudo, avec la partie sudoers qui va bien
 +    (tantôt pour apache2, tantôt nginx)
 +  - virer les redirections du cron
 +  - passer le cron à une seule fois le 11 du mois
 +  - fait les reload à la main comme ça on repart à zéro
 +  - fait que le check d'âge du certificat se passe sur +chain vu que
 +    c'est lui qui est utilisé en vrai et qu'il y avait eu un fail entre
 +    le certificat et le +chain :
 +-rw-r--r-- 1 letsencrypt letsencrypt 2147 nov.  27 01:11 netlib.re.crt
 +-rw-r--r-- 1 letsencrypt letsencrypt 3794 sept. 28 13:52netlib.re.crt+chain
 +
 +
 +
 +Meow,
 +
 +Les certificats x509 du wiki et d'adh ont expiré. ljf a réparé ça ce soir.
 +
 +Les certificats x509 de zabbix et listes.arn-fai.net ont expiré, j'ai
 +réparé ça y'a une heure.
 +
 +Ces deux problèmes ont une origine différente.
 +
 +
 +---- ORIGINE DU PROBLÈME SUR WIKI ET ADH
 +
 +Le problème était que, dans CRON, nous demandons l'exécution de la
 +commande « /usr/local/bin/letsencrypt-auto-renew.sh 2>>
 +/var/log/acme_tiny.log » alors que /var/log/acme_tiny.log n'existe pas.
 +L'utilisateur « letsencrypt », avec lequel est lancé la commande,
 +n'ayant pas les droits d'écriture dans /var/log/, forcément, ça échoue.
 +
 +DONE : j'ai crée ce fichier de log sur adh, mail, zabbix et web. Il
 +était déjà créé sur alsace.ttnn.
 +
 +TODO : vérifier que ce fichier existe sur wifi.arn-fai.net aka
 +hub.netlib.re.
 +
 +
 +---- ABSENCE DE MAIL D'ERREUR ?
 +
 +Je me suis demandé pourquoi, nous, admins, n'avons pas reçu de mail
 +d'erreur. Surtout qu'avant, avec le script maison de John, on recevait
 +un mail « certif renew OK » ou « pas besoin de renew » une fois par
 +mois, quand tout se passait bien.
 +
 +CRON envoie un mail (d'échec dans le cas présent) à l'utilisateur avec
 +lequel est exécutée la commande, letsencrypt dans notre cas. ssmtp
 +centralise tous les mails en les envoyant à mail.arn-fai.net [1]. Sauf
 +qu'on l'a configuré pour qu'il ne réécrive pas le « to: ». Donc un mail
 +envoyé par root à root arrive sur mail.arn-fai.net pour root et un alias
 +root = admins nous le délivre. Un mail envoyé par CRON (root) pour
 +letsencrypt arrive sur mail.arn-fai.net pour letsencrypt. Comme aucun
 +alias n'existe et que l'user « letsencrypt » existe localement, les
 +mails sont envoyés à cet user. La commande « mail » affichait 234 mails
 +non-lus pour l'user letsencrypt avant que je les efface.
 +
 +DONE : sur mail et alsace.ttnn, j'ai modifié /etc/aliases pour ajouter
 +un alias letsencrypt = admins. Normalement, vous avez reçu, comme moi,
 +mes 3 mails de test ainsi que les mails des CRON letsencrypt de cette nuit.
 +
 +TODO : je pense que ce serait une bonne chose qu'on vire le « 2>>
 +/var/log/acme_tiny.log » afin de recevoir les erreurs par mail si jamais
 +le renew d'un certificat foire, histoire que nos certifs n'aient pas le
 +temps d'expirer. Qu'en pensez-vous ? Couplé à un CRON qui s'exécute une
 +fois par mois au lieu d'une fois par jour, je pense que ça nous
 +délivrera un bon niveau d'information sur ce qui se trame, non ?
 +
 +
 +---- ORIGINE DU PROBLÈME SUR LISTES ET ZABBIX
 +
 +Il y a deux causes :
 +  * Le fichier /etc/letsencrypt/<quelquechose>/<quelquechose>.crt+chain
 +appartient à root:root, 644. Le script
 +/usr/local/bin/letsencrypt-auto-renew.sh, étant exécuté par
 +l'utilisateur « letsencrypt », il ne peut pas réaliser l'opérations «
 +cat /etc/letsencrypt/<quelquechose>/<quelquechose>.crt
 +/etc/letsencrypt/intermediate.pem >
 +/etc/letsencrypt/<quelquechose>/<quelquechose>.crt+chain » donc,
 +forcément, le serveur web continue de servir le vieux certificat.
 +
 +  * En lisant rapidement le script
 +/usr/local/bin/letsencrypt-auto-renew.sh, je me suis rendu compte qu'il
 +exécute des « /usr/sbin/service $service reload » afin que les serveurs
 +(apache, nginx, etc.) se présentent aux clients avec le nouveau
 +certificat. Comment cette commande peut-elle réussir puisque le script
 +est lancé par CRON sous l'identité de « letsencrypt » qui n'a pas les
 +droits de relancer les services ? Donc, lors d'un renew auto, un nouveau
 +certificat est bien obtenu depuis Let's Encrypt mais nos serveurs ne les
 +utilisent pas.
 +
 +DONE :
 +  * Sur zabbix et mail, j'ai exécuté moi-même le cat
 +/etc/letsencrypt/<quelquechos>/<quelquechose>.crt
 +/etc/letsencrypt/intermediate.pem >
 +/etc/letsencrypt/<quelquechose>/<quelquechose>.crt+chain
 +
 +  * Sur zabbix et mail, j'ai exécuté moi-même « sudo systemctl reload
 +nginx »
 +
 +  * Pour que ce problème ne se reproduise plus, j'ai chown
 +letsencrypt:letsencrypt
 +/etc/letsencrypt/<quelquechose>/<quelquechose>.crt+chain sur web,
 +alsace.ttnn, adh, mail et zabbix.
 +
 +TODO :
 +  * est-ce qu'on exécute /usr/local/bin/letsencrypt-auto-renew.sh en
 +root ou est-ce qu'on modifie « /usr/sbin/service $service reload » en «
 +/usr/bin/sudo /usr/sbin/service $service reload » avec une ligne «
 +NOPASSWD » dans le sudoers (en restreignant les services qui peuvent
 +être reloadés comme ça) ? Qu'est-ce qui vous semble le plus approprié ?
 +
 +  * Vérifier que les droits sont OK sur le crt+chain de wifi.arn-fai.net.
 +
 +
 +---- ABSENCE DE MONITORING
 +
 +John et moi pensions avoir supervisé l'expiration de nos certificats
 +x509 mais, en définitif, il faut croire que non…
 +
 +DONE : j'ai codé un check des certificats x509 dans Picomon. Il
 +surveille désormais tous les certificats listés en
 +<https://wiki.arn-fai.net/technique:x509>, pas un de moins, pas un de
 +plus. Il nous enverra un mail 7 jours avant l'expiration. J'ai màj la
 +doc [3].
 +
 +TODO : John doit relire mon code avant que je le pousse dans notre git
 +public [2].
  
technique/x509.txt · Dernière modification: 2020/07/05 18:52 de ljf