Effectivement tu as un problème d'auth ou de config acl sur bind. Tu peux vérifier que tu utilises la bonne clef, le bon secret et que l'acl est correcte avec nsupdate.
nsupdate -y KEYNAME:secret
un fois dans l'invite, tu tappes:
server un.de.tes.ns
update add _acme-challenge.subdomain.domain.tld. 600 in txt blabla
show
send
Et tu verras directement si ça marche. Fais bien le test depuis la machine qui fait tourner certbot dans le cas où l'acl vérifier le réseau/addresse source, nsupdate se trouve dans un paquet bind9-tools (au pif).
Deuxième point, vu que tu as plusieurs NS (dig tondoamin.tld ns), il se peut que tu aie une config master/slave, dans quel cas il faudra t'assurer que tu communiques bien avec le server maître. Je suppose qu'il y a un moyen de force certbot à utiliser un NS au lieu d'auto-détecter la SOA/NS.
[^] # Re: regarder comme ca se passe
Posté par benja . En réponse au message Génération certificats avec bind9 via RFC2136. Évalué à 1. Dernière modification le 23 juin 2022 à 14:40.
Effectivement tu as un problème d'auth ou de config acl sur bind. Tu peux vérifier que tu utilises la bonne clef, le bon secret et que l'acl est correcte avec nsupdate.
nsupdate -y KEYNAME:secret
un fois dans l'invite, tu tappes:
server un.de.tes.ns
update add _acme-challenge.subdomain.domain.tld. 600 in txt blabla
show
send
Et tu verras directement si ça marche. Fais bien le test depuis la machine qui fait tourner certbot dans le cas où l'acl vérifier le réseau/addresse source, nsupdate se trouve dans un paquet bind9-tools (au pif).
Deuxième point, vu que tu as plusieurs NS (dig tondoamin.tld ns), il se peut que tu aie une config master/slave, dans quel cas il faudra t'assurer que tu communiques bien avec le server maître. Je suppose qu'il y a un moyen de force certbot à utiliser un NS au lieu d'auto-détecter la SOA/NS.