Okay, I see it on all 6 paths / servers. And, unboundtest.com sees it on 4 repeated tries.
Now, press enter and show the result
3 Likes
Press Enter to Continue
The dry run was successful.
1 Like
Okay. Well, that's wonderful.
One thing I noticed is that all these TXT records showed 86400 for the TTL. But, the older 7FRy record had 120 as the TTL from ns2 but 86400 for the others. The TTL does not affect Let's Encrypt as it queries the auth servers directly. It just indicates to me some difference between what you just did manually and earlier efforts.
It is just something to keep in mind.
Now, next step ...
You should try that command without the --dry-run. That does two things. One is you will (should) get a valid production cert. But, it will also update your Certbot renewal profile for that domain to be the manual method. A manual method without matching "hooks" cannot be renewed automatically. We can address that later.
This will be helpful to get a fresh cert since yours expires soon. But, also to further debug what exactly is failing
4 Likes
My bad. You need to add a second name to that command to match your prior cert. So, like this
certonly --manual --preferred-challenge dns-01 -d adopteunmanchot.com -d *.adopteunmanchot.com
You will be prompted to enter 2 TXT values one for each -d
3 Likes
Domains like adopteunmanchot.com or alsace.eu.org are not significant, if you want me to NOT create certificats manually I can live with.
I will renew manually critical domains. For the moment many thanks for your support. And yeah, I wouldn't forget the subdomains 
no worry.
1 Like
I would be interested to know if the Let's Encrypt production system will validate the same as the Staging did. It should but would still be nice to follow the sequence to the end.
3 Likes
To be sure I understand you, I will keep those both domains for testing the certbot renew command. Right?
Certificate received for tic.alsace 
\o/
Using the same domain name is easier to debug so yes. I also wanted to know that the LE production would validate before you tried getting certs with the manual method for important domains.
After getting a production cert for adopteunmanchot.com I was going to have you try getting it with your rfc2136 plugin. That's what we really want to get working again.
It is too hard to debug odd DNS problems when different domain names are used. We want to change just one thing at a time.
4 Likes
Just noting that I see the fresh production cert was issued Jan16 for this root with wildcard (from this). But, your nginx server is still using the cert that expires Jan18.
SSL Labs says the same thing. Your score is A+ but if you look at details the cert is as I describe (link here)
As an aside, I cannot connect to that domain with either IPv6 address. IPv4 works fine for me (with cert soon to expire). Not sure why as IPv6 works well for me usually. SSL Labs works for both your IPv6 so that's good I suppose.
3 Likes
Yes, certificate generated, will be applied tomorrow (23:10 pm here). Thanks for following 
2 Likes
Hi Mike. All our necessaries certificates are deployed, perfect.
I keep 3 of them for tests:
. adopteunmanchot.com and alsace.eu.org which are to be renewed
. swiss-itech.ch for which we never created certificate
What the next step you want me to do ?
Did you use the --manual method or were you able to get your rfc2136 plugin working again?
3 Likes
--manual
1 Like
The --manual method cannot auto-renew (without custom hooks). I only suggested it as a debug tool and to get a cert since your expiration was so soon.
It is not a good method long-term. How many certs are you managing?
We need to get your rfc2136 plugin working.
Let's see what this does. The --dry-run is important to not disturb your production certs.
certbot certonly --dry-run --dns-rfc2136 --dns-rfc2136-credentials /etc/bind/rfc2136/ini --dns-rfc2136-propagation-seconds 600 -d adopteunmanchot.com -d '*.adopteunmanchot.com'
During the 600s wait you should check all your name servers to make sure a new TXT record appears. I think you have enough experience with that now 
3 Likes
No need to wait
root@keewi:~# certbot certonly --dry-run --dns-rfc2136 --preferred-challenge dns-01 --dns-rfc2136-credentials /etc/bind/rfc2136/ini --dns-rfc2136-propagation-seconds 600 -d adopteunmanchot.com -d '*.adopteunmanchot.com'
Saving debug log to /var/log/letsencrypt/letsencrypt.log
An RSA certificate named adopteunmanchot.com already exists. Do you want to
update its key type to ECDSA?
(U)pdate key type/(K)eep existing key type: U
Simulating renewal of an existing certificate for adopteunmanchot.com and *.adopteunmanchot.com
Encountered exception during recovery: certbot.errors.PluginError: Unable to determine base domain for _acme-challenge.adopteunmanchot.com using names: ['_acme-challenge.adopteunmanchot.com', 'adopteunmanchot.com', 'com'].
Unable to determine base domain for _acme-challenge.adopteunmanchot.com using names: ['_acme-challenge.adopteunmanchot.com', 'adopteunmanchot.com', 'com'].
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
unboundtest OK
dnsviz OK
Hmm ...
Your plugin is not able to update your bind servers. I am not really sure how to debug that but perhaps others do. I can only refer you to the docs for that plugin and review all the steps. LIkely related to permissions and keys.
https://certbot-dns-rfc2136.readthedocs.io/en/stable/
Well, unboundtest still sees that older TXT record but there is nothing newer due to the above error
And, we know that was okay from the --manual tests and successful issuance.
1 Like
I could live with this except that I don't know how LE check TXT records, let me explain. If I have
. domain.tld *.domain.tld or
. domain.tld sub1.domain.tld sub2.domain.tld ... subN.domain.tld
. domain.tld otherdomain.tld yetanotherdomain.tld
for what I saw using --non-interactive --manual-auth-hook I will receive as many TXT records as domains. So:
- how to know which is the first domain sended so I could replace the existing _acme-challenge.domain,tld.txt file to delete old records
- value of remaining_challenges is zero for one domain. So eg value is 3 mean I have 4 TXT records? This bring me to question 1: if I had something like total_challenges I would know that if remaining_challenges=total_challenges it's the first record of the renew action and I could delete/replace old file
- seems that each TXT record is tested immediately so named has to be restarted each time as reload doesn't do the job
Am I right ?
I tried my custom hook against adopteunmanchot.com which seems to work but have only one TXT record at the end. Seems logical to me.
Waiting your comments
1 Like
You may wish to visit the github for EFF's Certbot (link here) for such specific questions on its use. We see that often here so can usually help but your latest questions don't come up that often.
I can help with some of them
You can (should) delete the TXT record in a post-hook after the request is complete. Once the cert is issued the TXT record is not looked at anymore (by Let's Encrypt anyway). Yes, it is sometimes helpful to keep them for debug purposes so maybe have a switch in your hook to allow that. Or, some other way to bulk delete all the TXT challenge records. I just wanted to clarify how long the TXT is needed by LE. Be sure not to accumulate too many TXT records in any case.
I am not certain what remaining_challenges means. Let's Encrypt will cache a successful challenge for a domain (per account). So, the next time a challenge is not needed. The cache is currently 30 days. Using --dry-run with Certbot should invalidate these challenges so production is different. That may be better for the Certbot github or maybe another volunteer here.
You should have one TXT record for each -d name. You would have 2 if doing the root and a wildcard in the same request.
Another option instead of doing this custom dev work is to try a different ACME Client. I don't know how many support rfc2135 but acme.sh supports nsupdate which might work too. Switching clients takes some effort, especially if you have a large installation, but you are starting on a custom effort anyway so thought I'd mention it. Acme.sh nsupdate link here
2 Likes
Thanks, will read your links.
remaining_challenges is one of the certbot variables
$CERTBOT_VALIDATION"
$CERTBOT_DOMAIN"
$CERTBOT_REMAINING_CHALLENGES"
$CERTBOT_ALL_DOMAINS"
2 Likes