Passage de l’intermédiaire X1 à X3, ce qui a cassé toutes les chaînes de certificats (si vous aviez HSTS actif, ça a signifié l’impossibilité totale pour vos visiteurs de se connecter à votre site, il n’y a plus de bouton « Continuer quand même » sur l’alerte de sécurité dans ce cas).
Pourquoi veux-tu que ça casse quoi que ce soit ? Le protocole ACME, et son implémentation par Let's Encrypt, fournit l'URL certificat intermédiaire lors de l'émission du certificat. Un client ACME bien fichu doit pouvoir l'utiliser, et n'a aucune raison de dépendre d'un certificat intermédiaire donné : s'il change, il récupère le nouveau et tout marche comme sur des roulettes.
Gestion du multi-frontal, par exemple un HA proxy ou de la virtualisation (comment je pousse le même certificat et clef sur tout le parc sans avoir un god-master root en DMZ sur tout mon parc ie le 7ème cercle de l’enfer)
Eh bien tu ne le pousse pas, tu le tires. Sérieusement, c'est un problème qui n'est pas du tout lié à Let's Encrypt : tu as une architecture compliquée, eh bien c'est compliqué à maintenir à la main, et compliqué à automatiser, c'est dur, mais c'est la vie.
Gestion impossible ou extrêmement complexe de HPKP et pire de DANE/TLSA
Pour HPKP, c'est peut-être parce que l'idée même d'épingler un certificat est une belle connerie, qui est vouée à se retourner contre l'administrateur au moindre changement, et pour rappel, des changements, ça arrive de façon systématique et prévue, mais aussi de façon imprévue, hein.
Quant à DANE, je ne vois pas en quoi Let's Encrypt empêche ou complique excessivement quoi que ce soit.
Pas de support de IPv6 jusqu’à très récemment
Génial l'argument : Let's Encrypt c'est nul parce qu'avant ça ne faisait pas telle chose. (Bon, maintenant ça le fait, mais avant ça ne le faisait pas, donc c'est trop nul quand même.)
Impossibilité de récupérer le certificat racine automatiquement
Ça n'a pas été prévu en effet. Mais ça n'est pas pire que la concurrence, qui ne permet même pas de récupérer l'intermédiaire automatiquement.
Et accessoirement, en fait tu peux tout à fait récupérer le certificat racine automatiquement : le certificat intermédiaire est fourni, et une fois que tu l'as, tu peux chercher l'URL de CA Issuers, qui permet de télécharger le certificat racine.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 8.
Pourquoi veux-tu que ça casse quoi que ce soit ? Le protocole ACME, et son implémentation par Let's Encrypt, fournit l'URL certificat intermédiaire lors de l'émission du certificat. Un client ACME bien fichu doit pouvoir l'utiliser, et n'a aucune raison de dépendre d'un certificat intermédiaire donné : s'il change, il récupère le nouveau et tout marche comme sur des roulettes.
Eh bien tu ne le pousse pas, tu le tires. Sérieusement, c'est un problème qui n'est pas du tout lié à Let's Encrypt : tu as une architecture compliquée, eh bien c'est compliqué à maintenir à la main, et compliqué à automatiser, c'est dur, mais c'est la vie.
Pour HPKP, c'est peut-être parce que l'idée même d'épingler un certificat est une belle connerie, qui est vouée à se retourner contre l'administrateur au moindre changement, et pour rappel, des changements, ça arrive de façon systématique et prévue, mais aussi de façon imprévue, hein.
Quant à DANE, je ne vois pas en quoi Let's Encrypt empêche ou complique excessivement quoi que ce soit.
Génial l'argument : Let's Encrypt c'est nul parce qu'avant ça ne faisait pas telle chose. (Bon, maintenant ça le fait, mais avant ça ne le faisait pas, donc c'est trop nul quand même.)
Ça n'a pas été prévu en effet. Mais ça n'est pas pire que la concurrence, qui ne permet même pas de récupérer l'intermédiaire automatiquement.
Et accessoirement, en fait tu peux tout à fait récupérer le certificat racine automatiquement : le certificat intermédiaire est fourni, et une fois que tu l'as, tu peux chercher l'URL de CA Issuers, qui permet de télécharger le certificat racine.