Certificats x509

L'asso utilise l'autorité de certification Let's Encrypt pour ses sites web suivants :

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 :

  1. passer les reload en sudo, avec la partie sudoers qui va bien

(tantôt pour apache2, tantôt nginx)

  1. virer les redirections du cron
  2. passer le cron à une seule fois le 11 du mois
  3. fait les reload à la main comme ça on repart à zéro
  4. 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 :

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.

/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 :

/etc/letsencrypt/<quelquechos>/<quelquechose>.crt /etc/letsencrypt/intermediate.pem > /etc/letsencrypt/<quelquechose>/<quelquechose>.crt+chain

nginx »

letsencrypt:letsencrypt /etc/letsencrypt/<quelquechose>/<quelquechose>.crt+chain sur web, alsace.ttnn, adh, mail et zabbix.

TODO :

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é ?

—- 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].