I've successfully requested new certs for 6 domains today but one is giving me issues: sunsetbeachva.com
Everything that I know to look for looks good. The error is: https://acme-v02.api.letsencrypt.org/acme/chall-v3/12640051165/Y1f-CQ
It sounds to me like there is an existing challenge? I also see that "addressUsed" is an IPv6 IP and our servers don't respond viz IPv6.
Any feedback is appreciated, thanks!
The more I think about it the more I believe it's the IPv6 issue. I'll remove those and test.
It looks to me like when I connect to sunsetbeachva.com over IPv6 it's working fine, and already has a Let's Encrypt certificate? I think you need to give us a bit more details about your current setup, and why you think IPv6 is a problem. Do you have some sort of load balancing or caching in front of it that's trying to handle the
Funny, because from my endpoint (and Unboundtest) there are no AAAA RRs configured?
Well there aren't now. But there were when this was first posted.
but there are ipv6 answers.
Your configuration looks curious - see https://check-your-website.server-daten.de/?q=sunsetbeachva.com
You have two ipv6:
||184.108.40.206 Jacksonville/Florida/United States (US) - Flexential Colorado Corp. Hostname: w11-03.vizergy.com
||2620:12a:8000::2 San Francisco/California/United States (US) - Fastly
||2620:12a:8001::2 San Francisco/California/United States (US) - Fastly
And it looks that these are different providers.
But the answer checking
Visible Content: check-your-website-dot-server-daten-dot-de.vKGSnNTMm-njyWJQYjhmPuIovGcwxiduMtzbURl4_Yc
That looks that you use a system that answers with a general account key.
Filename + "." + Hash of the account key.
That's the typical error message
The key authorization file from the server did not match this challenge
May be remove your ipv6.
Where do those come from?
ns72.domaincontrol.com. are listed as the authorative NS at the
com. DNS servers and they don't report AAAA RRs.
The site has been using Let's Encrypt for quite some time
The certificate created a month ago is what I saw the server using over IPv6 before.
That was the check result 19:51 (Berlin).
Now, 20:41 - all ipv6 are gone.
It was the IPv6 records causing the issue. I hadn't run into that before. Thanks everyone!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.