My domain is: virtualinux.co.uk
I ran this command: certbot --manual --preferred-challenges dns-01 -d… -d…
It produced this output: It all worked fine!
hiya, this is a general question - my DNS provider (123-reg) does’nt support dynamic DNS or the RFC, so I created my wildcard and base domain name cert using the manual DNS method. I’d created a couple first before I got it right but I was surprised that on subsequent occasions I wasn’t asked to change the TXT record with a new verification key, and that all subsequent requests after the first one succeeded.
Should I now manually delete that TXT to prevent anyone requesting certs for my domain or does that mean renewals will fail? Do I need to manually update the TXT record quarterly in order for renewals to work?
PS I just tried a dry run renewal which failed saying I needed to add a script with --manual-auth-hook, so I’m assuming I need to mcgyver something to bypass the fact that my ISP don’t support DDNS? Need to get this stable before I use it in anger - any help appreciated:)
a confirmed challenge is 30 days valid. So you (your account) can create new certificates without a new token.
But it's only your account.
Yes, that's the limitation of using
PS: Your chain is wrong:
Chain - duplicate certificates
3 CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US
Every time you validate the name, Let’s Encrypt will give you a different
TXT record value. You can delete the DNS record immediately after validation is done.
The trick is that Let’s Encrypt doesn’t always require you to validate again. Currently, an ACME account can reuse the same authorization for up to 30 days. This is subject to change – Let’s Encrypt even recently turned off authorization reuse entirely on the staging environment for a while.
On top of this, there was a problem: Before version 0.31.0, Certbot did not notice when the CA was reusing an authorization, so it would ask you to set the
TXT record and ask the CA to validate it again without realizing that it was unnecessary and nothing would happen. You would have to watch
letsencrypt.log to see when that was happening.
It would be best if you can use HTTP validation (and stop using wildcards) or switch to a DNS setup that allows automation.
By the way, you should use Certbot’s
--dry-run options when testing. Don’t issue too many certificates using Let’s Encrypt’s production environment.
Thanks for your reply @JuergenAuer. WRT the chain not sure how that happened, or how to fix it? Looks like I may need to bin the wildcard and use HTTP auth anyway so may be moot but anything to do to avoid when I create my named certs?
Thanks @mnordhoff, I only created a second wildcard because I’d stupidly put in *.virtualinux instead of *virtualinux so the base domain wasn’t included. I’ll have a look at the HTTP auth as it seems the path of least resistance - hopefully I can use SANs to save managing multiple certs for this box.
Thanks to both respondents, for speedy and useful help - much appreciated:)
Looks like you use cert.pem and chain.pem (or fullchain.pem). But chain.pem (or fullchain.pem) may contain the content of cert.pem.
Share the vHost - configuration. To see, if it works, recheck the domain.
PS: That has nothing to do with the question wildcard / not wildcard or other things.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.