====== Certificats x509 ====== L'asso utilise **l'autorité de certification Let's Encrypt** pour ses sites web suivants : * arn-fai.net et www.arn-fai.net * wiki.arn-fai.net * adherents.arn-fai.net * listes.arn-fai.net * netlib.re et www.netlib.re * wifi.arn-fai.net * zabbix.arn-fai.net **Ces certificats servent uniquement pour les sites web** de l'asso, pas pour le mail ou autre. **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//.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//.crt /etc/letsencrypt/intermediate.pem > /etc/letsencrypt//.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//.crt /etc/letsencrypt/intermediate.pem > /etc/letsencrypt//.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//.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 , 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].