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.
Je veux dire qu’il faut déjà savoir générer une CSR. Donc comprendre comment la générer proprement (SAN, SHA-2...), faire la danse de la pluie et sacrifier 2 caisses de poulets lors de l’invocation openssl correspondante...
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...)
C’est un peu le sens de ce que je disais. Si tu veux faire les choses proprement, on en revient à restreindre LE à « une CA comme les autres ». Donc on s’attendrait à quand même pouvoir émettre du certificat d’un an...
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
Ça a l’intérêt de justement dégager la notion de CA, qui est bordélique au possible et devrait mourir vu le taux de compromission parmi ces trucs...
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.
Donc de désactiver la gestion de la clef par LE :P
Pas nécessairement. Mon serveur n’a pas les clefs de signature de ma zone DNS.
Je veux dire par là que ton serveur de renouvellement, nécessairement en DMZ par design (ACME challenge) va devoir modifier les entrées TLSA. Donc doit avoir accès à la zone DNS en écriture. Ce qui casse tout l’intérêt de TLSA (séparation forte/physique entre certificat et DNS).
En cas de compromission de ton certificat/clef, il y aura de fortes chances que l’attaquant puisse du coup modifier tes entrées TLSA au passage.
(En théorie, ton serveur DNSSec devrait être un shadow master hors DMZ, faisant les rollovers nécessaires et publiant via AXFR à ton « master » (en fait un slave du coup) DNS public qui lui est en DMZ. Ainsi tes clefs DNSSec sont à l’abri en cas de compromission de la DMZ.)
[^] # Re: 90 jours, et alors?
Posté par Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 1.
Je veux dire qu’il faut déjà savoir générer une CSR. Donc comprendre comment la générer proprement (SAN, SHA-2...), faire la danse de la pluie et sacrifier 2 caisses de poulets lors de l’invocation openssl correspondante...
C’est un peu le sens de ce que je disais. Si tu veux faire les choses proprement, on en revient à restreindre LE à « une CA comme les autres ». Donc on s’attendrait à quand même pouvoir émettre du certificat d’un an...
Ça a l’intérêt de justement dégager la notion de CA, qui est bordélique au possible et devrait mourir vu le taux de compromission parmi ces trucs...
Donc de désactiver la gestion de la clef par LE :P
Je veux dire par là que ton serveur de renouvellement, nécessairement en DMZ par design (ACME challenge) va devoir modifier les entrées TLSA. Donc doit avoir accès à la zone DNS en écriture. Ce qui casse tout l’intérêt de TLSA (séparation forte/physique entre certificat et DNS).
En cas de compromission de ton certificat/clef, il y aura de fortes chances que l’attaquant puisse du coup modifier tes entrées TLSA au passage.
(En théorie, ton serveur DNSSec devrait être un shadow master hors DMZ, faisant les rollovers nécessaires et publiant via AXFR à ton « master » (en fait un slave du coup) DNS public qui lui est en DMZ. Ainsi tes clefs DNSSec sont à l’abri en cas de compromission de la DMZ.)