Bravo, c'est une très bonne idée. Juste une remarque, dans la page principale d'explications (Howto use), tu pourrais mentionner que ce que Let's Encrypt va demander de mettre comme enregistrement DNS, c'est le nom de domaine à certifier, préfixé de _acme-challenge, par exemple _acme-challenge.example.com. Ça permet de définir une autorisation de mise à jour dynamique plus stricte que ce que tu suggères, qui en pratique n'autoriserait la mise à jour que d'enregistrements de type TXT pour ce seul nom :
key "_acme-challenge.example.com" {
...
};
zone "example.com" {
type master;
file "example.com.zone";
update-policy {
grant _acme-challenge.example.com self * TXT;
};
};
À noter que, plutôt que d'authentifier la mise à jour dynamique par un secret partagé, il est possible d'utiliser une signature asymétrique pour cela, avec une paire de clefs SIG(0). C'est un peu plus compliqué, la clef publique devant être publiée dans la zone si je me souviens bien.
# Excellent, une remarque
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Créer des certificats avec ACME/Let's Encrypt et des vérifications DNS. Évalué à 7.
Bravo, c'est une très bonne idée. Juste une remarque, dans la page principale d'explications (Howto use), tu pourrais mentionner que ce que Let's Encrypt va demander de mettre comme enregistrement DNS, c'est le nom de domaine à certifier, préfixé de
_acme-challenge, par exemple_acme-challenge.example.com. Ça permet de définir une autorisation de mise à jour dynamique plus stricte que ce que tu suggères, qui en pratique n'autoriserait la mise à jour que d'enregistrements de type TXT pour ce seul nom :À noter que, plutôt que d'authentifier la mise à jour dynamique par un secret partagé, il est possible d'utiliser une signature asymétrique pour cela, avec une paire de clefs SIG(0). C'est un peu plus compliqué, la clef publique devant être publiée dans la zone si je me souviens bien.