There's probably a bug in certbot. I run an IPv6-only server with Arch linux. From the Let's Encrypt docs, I found that certbot renew prefers IPv6 and only falls back to IPv4 when IPv6 is not available. My server only has an AAAA DNS record and does not need an A record. Certbot fails during the challenge check. As soon as I add an A record, the renewal works flawlessly without any other changes. This can't be right.
Please note: there's no problem with port 80 already in use or any firewall issues, it's just that an AAAA record is obviously not enough for certbot to run the check, even if it still only uses IPv6 in the end.
I had an ipv6-only server a few years back and it worked. (Not only it did work, it had an
A record on which I was not listening on port 80 -- I just had 20 ports on a shared ipv4)
I sense there is more to the story. What do the logs say? Is the
AAAA record pointing to the right IP? Does your server know that IP belongs to them?
Yeah, Let's Encrypt supports IPv6 just fine. Ensure that the server is actually accessible to the world on port 80 via that AAAA record, and you should be all set.
The thing is: certbot fails without an A record, even when it is not used at all. There is no way to do a renew purely with IPv6 and only an AAAA record. I do not want or use IPv4 anymore, neither on my server nor in my DNS entries. This is obviously not possible with certbot atm.
It has nothing to do with wrong addresses, my services are reachable at all times with my AAAA record pointing to my IEEE EUI-64 based Global Unicast IPv6 address.
Then post your domain name, IP, and the error you're getting, and perhaps we can help you figure out what's going on. Plenty of people use IPv6-only just fine with Let's Encrypt.
I agree with prior posts that certbot and LE work fine with IPv6. I even tried removing the A record just now on my test server and it worked fine.
You should ensure your IPv6-only server can make outbound requests with IPv6. Use this curl command which will return your public IPv6 addr to confirm.
curl -6 http://ifconfig.co
If the curl works fine please provide the info requested by @petercooperjr
If it does not then you know what needs fixing
Thanks for your answers, I do not want to expose the FQDN. And I see your point, Certbot works with IPv6 only, I can confirm that. But does it work without an A record? I think this is the crucial difference. AAAA record only (which should be enough, resolution works fine) = error in renewal check. Adding an unnecessary and not-even-used A record = renewal check works.
Yes, Let's Encrypt works fine without an A record. If your DNS and host only support IPv6, Let's Encrypt will just use that and not try IPv4 at all.
But it's going to be hard for people to help you without the domain name. If you're willing to enter it into some online tools, you could try looking up your domain name on DNSViz or UnboundTest to see if your DNS server is returning some error or something when you don't have an A record set? I don't know as Let's Encrypt would even be requesting the A record if there's an AAAA record that works, though.
Yes, but even the actual error from the log or certbot display might be enough of a clue. Just saying it fails is not descriptive enough.
Certbot makes outbound requests to the Let's Encrypt server to tell it how to validate control of the domain name. The Let's Encrypt server uses the DNS records to ensure it satisfies the http challenge (with the IP it finds) or DNS challenge (with TXT record). You did not describe which you used.
As I noted just before your latest response, I tried just now removing the A record and certbot worked fine. Have you confirmed your outbound IPv6 since you said your server was IPv6-only so certbot will need to use IPv6 to inform Let's Encrypt server.
Also try using letsdebug.net for possible debug aid
Hard to be specific without more details from you
Thank you all for your support. Good to know that it definitely works without an A record, that really helps. I'm using the http challenge. Unfortunately, I just ran into a rate limit for renewals on the Let's Encrypt servers, so I will have to postpone further testing to next week. Have a nice weekend!
You can use (and should've used) the staging environment.
certbot --dry-run [rest of your command])
The only Rate Limit that involves waiting a week is for duplicate certs which can only happen when you SUCCESSFULLY get a cert (actually, get too many).
There are other rate limits but the wait period is less. What was the exact error message with the rate limit?
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.