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 par ljf