Tu dois toujours avoir un épinglage d’avance : si tu utilises actuellement la clef N, tu dois publier l’épinglage N et N+1.
Voire même N (clef actuellement en service, sur le serveur), N+1 (future clef, à l’abri hors-ligne), et clef de secours (stockée dans une grotte gardée par des orques, d’où tu ne la sors qu’en cas de pépin).
Le 1er point fait que tu dois avoir une clef prête à l’avance que tu peux déjà publier dans ton épinglage et que tu utiliseras pour la génération de certificat suivante. Très complexe avec la plupart des clients Let’s Encrypt
Je ne peux pas parler pour tous les clients, mais je réfute que ce soit « très complexe » avec le client Certbot. Il suffit de générer soi-même la clef et la requête de certificat (ce que tu devais faire de toute façon avec une CA plus traditionnelle), et d’utiliser l’option --csr de Certbot.
et ça demande dans tous les cas une bonne maîtrise de X.509
Pas plus que pour travailler avec une CA traditionnelle — avec laquelle tu dois déjà générer toi-même la CSR (si tu utilises une CA qui te génère la clef pour toi et te la donne en même temps que le certificat, euh comment dire...)
Et donc se passer totalement du renouvelement de la clef de Let’s Encrypt :)
Complètement d’accord là-dessus, je n’ai d’ailleurs pas dit autre chose, que ce soit dans ma réponse ci-dessus ou dans mon dernier journal sur Let’s Encrypt.
donc que la phase de renouvelement du certificat ou de la clef devrait impliquer le renouvelement des entrées DNS correspondantes...
Le renouvellement du certificat (pas de la clef) n’implique le renouvellement des enregistrements TLSA que si tu épingles le certificat lui-même (selector à 0) au lieu de la clef publique (selector à 1)... ce qui est déconseillé (même si pas très fortement) par le RFC 7671 : dans le cas où tu épingles au niveau terminal (DANE-EE au lieu de DANE-TA), il est conseillé d’épingler la clef publique plutôt que le certificat entier. (Et si tu épingles à un niveau intermédiaire, la question des renouvellements échappe totalement à ton contrôle de toute façon.)
donc votre serveur web ayant un contrôle root sur votre zone DNSSec...
Pas nécessairement. Mon serveur n’a pas les clefs de signature de ma zone DNS.
[^] # Re: 90 jours, et alors?
Posté par gouttegd . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 4.
Voire même N (clef actuellement en service, sur le serveur), N+1 (future clef, à l’abri hors-ligne), et clef de secours (stockée dans une grotte gardée par des orques, d’où tu ne la sors qu’en cas de pépin).
Je ne peux pas parler pour tous les clients, mais je réfute que ce soit « très complexe » avec le client Certbot. Il suffit de générer soi-même la clef et la requête de certificat (ce que tu devais faire de toute façon avec une CA plus traditionnelle), et d’utiliser l’option
--csrde Certbot.Pas plus que pour travailler avec une CA traditionnelle — avec laquelle tu dois déjà générer toi-même la CSR (si tu utilises une CA qui te génère la clef pour toi et te la donne en même temps que le certificat, euh comment dire...)
Complètement d’accord là-dessus, je n’ai d’ailleurs pas dit autre chose, que ce soit dans ma réponse ci-dessus ou dans mon dernier journal sur Let’s Encrypt.
Le renouvellement du certificat (pas de la clef) n’implique le renouvellement des enregistrements TLSA que si tu épingles le certificat lui-même (selector à 0) au lieu de la clef publique (selector à 1)... ce qui est déconseillé (même si pas très fortement) par le RFC 7671 : dans le cas où tu épingles au niveau terminal (DANE-EE au lieu de DANE-TA), il est conseillé d’épingler la clef publique plutôt que le certificat entier. (Et si tu épingles à un niveau intermédiaire, la question des renouvellements échappe totalement à ton contrôle de toute façon.)
Pas nécessairement. Mon serveur n’a pas les clefs de signature de ma zone DNS.