Beaucoup d’entre‐vous s’en sont rendus compte, le certificat X.509 utilisé par LinuxFr.org a expiré ce 3 juin 2018. Retour sur cet incident et sur le renouvellement de ce certificat dans la seconde partie de cette dépêche.
Historique des certificats X.509 sur LinuxFr.org
Jusqu’en 2015, LinuxFr.org était accessible en HTTPS grâce à un certificat X.509 provenant de l’autorité de certification communautaire CAcert. Malgré un fonctionnement communautaire et quelque peu décentralisé plaisant beaucoup à notre équipe, la non‐inclusion de cette autorité de certification dans les navigateurs les plus utilisés devenait un frein à l’accès grand public à LinuxFr.org.
En 2015, le bureau d’enregistrement de noms de domaines (registrar) Gandi a fourni gracieusement à LinuxFr.org un certificat X.509 valable pour tout le domaine linuxfr.org (ce que l’on appelle un wildcard, c.‐à‐d. un certificat dont le sujet est *.linuxfr.org) pour une durée de trois ans. Cette dépêche est d’ailleurs l’occasion de les remercier chaleureusement pour cela.
Trois ans plus tard, nous sommes en 2018. Se pose alors la question de renouveler le certificat.
Chronologie de l’incident
La date d’expiration du certificat offert par Gandi est le 3 juin 2018 à 1 h 59. Le 24 mai, Benoît poste un rappel sur la tribune de modération. Personne n’étant disponible, le certificat expire le 3 juin. Les premières alertes sont données par courriel, en direction de la liste des modérateurs, à partir de 9 h 11. D’autres personnes signalent aussi le problème sur Twitter dans la foulée. Les premiers administrateurs au courant n’ayant pas forcément la possibilité de se connecter immédiatement sur les serveurs pour résoudre la situation, il faudra attendre 10 h avant que quelqu’un puisse le faire.
Deux des administrateurs entrevoient les possibilités :
- commander un nouveau certificat chez Gandi ;
- utiliser l’autorité de certification gratuite et automatisée Let’s Encrypt.
Après quelques tergiversations, d’envois de demandes de signature de certificats (CSR) pas forcément bien ficelées, c’est vers Let’s Encrypt que les administrateurs se tournent. Du fait de dépendances légères et de connaissances sur ce logiciel, c’est le client dehydrated qui est utilisé, d’abord sur le serveur alpha (préproduction) puis sur le serveur prod (qui porte bien son nom). Le certificat est généré sur la production à 11 h 28, la fin de l’incident peut donc être déclarée vers 11 h 35. À ce moment‐là, décision est prise de ne pas activer le renouvellement automatique, afin de décider de la pérennisation de Let’s Encrypt une fois tous les administrateurs disponibles.
Le certificat sur prod sera de nouveau généré en début de soirée (20 h 39) pour ajouter une entrée CN (celle de prod lui‐même).
À noter que la priorité étant donnée au service HTTPS, les services de messagerie SMTP ne sont pas modifiés à ce moment‐là. Les courriels continuant d’arriver, cela n’est pas considéré comme prioritaire. Le sujet est néanmoins abordé sur le canal IRC des administrateurs du site et des actions auront lieu sur le sujet.
Leçons et actions futures
Suite à cet incident, on peut retenir :
- que la communauté autour de LinuxFr.org fait un sacré travail de signalement des incidents :) ;
- qu’il est important d’avoir plusieurs personnes dans l’équipe qui peuvent intervenir ;
- qu’il ne faut pas oublier de vérifier les dates d’expiration de certains services critiques (certificats X.509, noms de domaines…).
Les actions actuellement envisagées :
- un passage permanent à Let’s Encrypt, sur chaque serveur en ayant besoin ;
- pourquoi pas l’installation d’un serveur de supervision pour alerter l’équipe de ce genre de problème (et d’autres ?).
Aller plus loin
- LinuxFr.org : Quoi de neuf côté LinuxFr.org, relatant le changement de certificat en 2015 (177 clics)
- Journal LinuxFr.org hacké (244 clics)
- Les certificats SSL chez Gandi (123 clics)
- Let’s Encrypt (150 clics)
- Wikipédia : X.509 (87 clics)
# Acronymes
Posté par cosmocat . Évalué à 1.
Retour intéressant mais…
CSR? CN? J'ai pas compris…
Après recherche: CSR: https://en.wikipedia.org/wiki/Certificate_signing_request
CN (Common Name) : https://www.ssl.com/faqs/common-name/ ex:linuxfr.org
Lorsqu'on s'adresse à un public qu'on ne connait pas, on évite d'employer des acronymes ou alors on les explique (encore mieux car c'est formateur)…
[^] # Re: Acronymes
Posté par Nils Ratusznik (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 05 juin 2018 à 11:29.
Les corrections ont été faites, merci du signalement.
[^] # Re: Acronymes
Posté par Davy Defaud . Évalué à 7.
Dans un souci didactique, j’ai remplacé le lien vers la page sur la CSR du Wikipédia anglais par son pendant français : demande de signature de certificat X.509.
# Compléments
Posté par Benoît Sibaud (site web personnel) . Évalué à 10. Dernière modification le 05 juin 2018 à 13:39.
La correction du
www.linuxfr.orga été faite le 4 juin à 22:52 (Paris). (Cette conf un peu inutile du www n'existe pas sur le serveur de dev, et il est facile de l'oublier).La correction sur la partie messagerie électronique (postfix/sympa) a été faite le 5 juin à 00:29 (Paris).
Dix certificats sur quatorze (smtp et https pour les différents domaines) sont à jour actuellement, les quatre derniers étant invisibles de l'extérieur. Et il reste encore un peu de taf pour finaliser l'automatisation de l'installation et du renouvellement (crontab, script ansible, mise à jour de la doc, mise à jour de la FAQ, etc.).
[^] # Re: Compléments
Posté par dromadaire35 . Évalué à 3.
J'en conclus que le nouveau certificat n'est pas un wildcard comme le précédent. Pourquoi ne pas avoir refait un wildcard ? Est-ce une volonté de l'équipe, ou juste dû au délai un peu court pour corriger le problème ?
[^] # Re: Compléments
Posté par Benoît Sibaud (site web personnel) . Évalué à 9. Dernière modification le 13 février 2022 à 21:37.
Wildcard ou pas, ça n'aurait rien changé dans ce cas, c'est juste un autre bloc de config pour le
www.pour une redirection, il est caché tout en bas d'un long fichier, et il pointait encore vers l'ancien certificat. Le nouveau certificat était déjà prévu pourlinuxfr.org www.linuxfr.org prod.linuxfr.org img.linuxfr.org. Écraser l'ancien certificat avec le nouveau aurait pu éviter le souci par contre (mais dehydrated préfère sans doute avoir son propre répertoire).Sinon sur la question du wildcard, c'est mieux de ne pas partager un certificat magique entre tous les serveurs (*), et quitte à avoir un certificat différent par serveur, ce n'est pas plus compliqué de préciser les domaines et d'éviter le wildcard.
(*) pour au moins deux raisons, la sécurité, et aussi le fait qu'ils vont tous expirer en même temps, comme un dimanche 3 juin par exemple.
[^] # Re: Compléments
Posté par Yves (site web personnel) . Évalué à 6.
Perso, avec Dehydrated, je laisse l’outil stocker les fichiers dans son répertoire à lui, avec ses droits à lui, etc. tout ceci absolument inaccessible de l’internet d’aucune façon que ce soit.
Puis dans un script « HOOK » de Dehydrated, je fais du déploiement, c’est à dire que je vais placer pour chaque serveur (Exim, HAProxy, Nginx, Prosody…) les fichiers dont il a besoin (privé, publique, mélangé…) de la façon la plus standard possible pour ce serveur (emplacement, nommage), en propriété exclusive de ce serveur et en mode 400.
# Merci Dehydrated
Posté par Yves (site web personnel) . Évalué à 6.
Tiens, moi aussi j’utilise dehydrated !
Ce client ACME a l’avantage d’être complet, souple et efficace, et suffisamment petit pour que j’aie pu me permettre de lire intégralement le code source avant de l’installer. Un client ACME a en effet des droits non négligeables sur la machine…
[^] # Re: Merci Dehydrated
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 8.
C'est très bien de pouvoir lire ce genre de code :) D'ailleurs, c'est le but des clients acme-tiny et de mon fork acme-dns-tiny.
Ce dernier n'a d'ailleurs besoin que de très peu de droits sur la machine locale (en gros, lire la clé ACME et le CSR), mais doit pouvoir gérer les entrées DNS "_acme_challenge.*" sur une machine distante.
# regarder ses emails
Posté par Stibb . Évalué à 4.
à rephraser: "qu'il faut prendre en compte des emails de rappels envoyé automatiquement par la plupars des services commerciaux". Quite à se créer une adresse mail d'équipe avec des crédentials partagés (bitwarden, …).
Ce genre d'erreur est classique et ça aurait pu être pire (vol du domaine, etc).
[^] # Re: regarder ses emails
Posté par fredezic . Évalué à 3.
dans ma boite on gere plusieurs centaine de certificat, il y a 1 personne qui est chargé de suivre tout le cycle de vie de tous les certificats (privée ou publique)
pour mon périmètre j'ai un ptit script qui m'envoie un mail quand un certificats expire moins d'un mois, ca me laisse le temps de le renouveller tranquillement ( en le demandant a celui qui gere tous les certificats)
# Supervision
Posté par Pol' uX (site web personnel) . Évalué à 4.
Otez moi d'un doute … dlfp n'est pas déjà monitoré ?
Adhérer à l'April, ça vous tente ?
[^] # Re: Supervision
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
Le minimum est fait : courbes de charge serveur, mémoire et réseau, plus les vérifications périodiques des conteneurs lxc, des processus, des ports en écoute et des flux TCP/UDP connus/inconnus. Plus la très efficace supervision par les utilisateurs (nous y compris).
[^] # Re: Supervision
Posté par Pol' uX (site web personnel) . Évalué à 4.
Si ça vous intéresse (et en échange d'un email de contact) je peux vous mettre un check_http sur un des icinga que j'administre. Ça peut notamment vérifier la date de validité des certs TLS.
Adhérer à l'April, ça vous tente ?
[^] # Re: Supervision
Posté par ZeroHeure . Évalué à 3.
Let's Encrypt envoie un courriel de rappel 20 jours avant l'expiration.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Supervision
Posté par Pol' uX (site web personnel) . Évalué à 4.
Mouais, sauf que :
[*] Typiquement, tu veux ajouter un domaine à un cert, donc tu le regénères avec tous les domaines inclus, plus le nouveau. LE ne reconnais pas la parenté entre l'ancien et le nouveau et à l'échéance de l'ancien tu te fais spammer.
Adhérer à l'April, ça vous tente ?
[^] # Re: Supervision
Posté par ZeroHeure . Évalué à 3.
Merci des précisions ! Je surveille ça d'un peu trop loin.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Supervision
Posté par Pol' uX (site web personnel) . Évalué à 5.
Beh basiquement, c'est infiniment plus fiable pour détecter une panne de faire une requête proche de celle que ferait un usager lambda. Le script check_http ne fait pas tout, loin de la, mais te permet de tester depuis un bout arbitraire de l'internet si ton serveur répond (tu peux contrôler le code), s'il répond la bonne page (tu peux chercher un string ou une regex), et s'il répond avec un certificat qui n'a pas expiré.
Le courriel de letsencrypt en comparaison c'est pipo.
Adhérer à l'April, ça vous tente ?
[^] # Re: Supervision
Posté par Yves (site web personnel) . Évalué à 4.
Merci pour ces infos. Je me demande : qu’est-ce qu’implique le fait que ce soit du Mailchimp ? Est-ce que cette entité que je ne connais pas (et qui, je le crains, pourrait être source de pubs et spam…) connait ainsi la liste exhaustive de tous les admins utilisateurs de Let’s Encrypt ?
[^] # Re: Supervision
Posté par Pol' uX (site web personnel) . Évalué à 4.
Autant pour moi c'est mandrill.com ; pas mailchimp.
A priori oui. Il faut s'en remettre à leur déontologie.
Adhérer à l'April, ça vous tente ?
[^] # Re: Supervision
Posté par MTux . Évalué à 3.
La supervision est faite par la communauté :)
[^] # Re: Supervision
Posté par Pol' uX (site web personnel) . Évalué à 3.
Beh elle a échoué à prévenir que le certificat échouerait dans 2 semaines. :)
Adhérer à l'April, ça vous tente ?
[^] # Re: Supervision
Posté par MTux . Évalué à 4.
En fait j'avais compris que des gens avaient alerté linuxfr en avance, mais en relisant la phrase effectivement c'est arrivé après.
Je ne vous jette pas la pierre, à chaque expiration de mon certificat j'ai la même chose (toujours des surprises avec le renouvellement auto let's encrypt + flemme).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.