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.
Ce n’était pas le cas de certbot (à l’époque en tout cas) : il ne renouvellait que le certificat, et demandait à l’utilisateur d’embarquer en dur la chaîne intermédiaire (générée au 1er appel de certbot).
Et même pour ceux qui avait automatisé à mort, ils se sont retrouver avec 2 chaînes différentes (les certificats pas encore renouvelés et ceux fraîchement renouvelés), mais un seul chain.pem utilisé pour tous les vhosts via SSLCertificateChainFile (ça a donné pas mal de soucis en pratique en tout cas.)
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.
Tirer, ça pose les problèmes de synchronisation. Il faut tiré pile après avoir renouvelé, et depuis toutes les machines en même temps pour éviter les problèmes de certificats pas identiques entre les machines.
Et mon archi n’est pas compliquée, c’est le b.a-ba d’une infra correcte aujourd’hui (virtualisation, dual stack ipv4 (reverse proxy)-ipv6 (direct access), HA proxy...)
Quant à DANE, je ne vois pas en quoi Let's Encrypt empêche ou complique excessivement quoi que ce soit.
Si tu changes de pin, il faut mettre à jour les entrées TLSA. Ce qui est encore plus compliqué à mettre en place que de tirer les certificats...
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 Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 1. Dernière modification le 22 septembre 2016 à 14:32.
Ce n’était pas le cas de certbot (à l’époque en tout cas) : il ne renouvellait que le certificat, et demandait à l’utilisateur d’embarquer en dur la chaîne intermédiaire (générée au 1er appel de certbot).
Et même pour ceux qui avait automatisé à mort, ils se sont retrouver avec 2 chaînes différentes (les certificats pas encore renouvelés et ceux fraîchement renouvelés), mais un seul chain.pem utilisé pour tous les vhosts via SSLCertificateChainFile (ça a donné pas mal de soucis en pratique en tout cas.)
Tirer, ça pose les problèmes de synchronisation. Il faut tiré pile après avoir renouvelé, et depuis toutes les machines en même temps pour éviter les problèmes de certificats pas identiques entre les machines.
Et mon archi n’est pas compliquée, c’est le b.a-ba d’une infra correcte aujourd’hui (virtualisation, dual stack ipv4 (reverse proxy)-ipv6 (direct access), HA proxy...)
Si tu changes de pin, il faut mettre à jour les entrées TLSA. Ce qui est encore plus compliqué à mettre en place que de tirer les certificats...
Quand ce n’est pas juste totalement buggé chez LE.