my webserver runs Nginx. Obtaining certificates for the other domains that I run there also works fine with Certbot.
I have one German .de Domain with an Umlaut (ä, ö, ü, ß).
This one is also configured correctly, with the punycode name in the Nginx config, DNS works, I can access it over HTTP in the browser without problems, both with the Punycode and the umlaut in the URL via IPV4 and IPV6.
However Certbot fails to obtain a certificate for it. From what it shows me, entering the punycode URL should be correct.
It looks like this (replaced with an example domain name):
certbot --nginx -d xn--exampledomainwithan-obc.de -d www.xn--exampledomainwithan-obc.de
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Requesting a certificate for xn--exampledomainwithan-obc.de and www.xn--exampledomainwithan-obc.de
Performing the following challenges:
http-01 challenge for www.xn--exampledomainwithan-obc.de
http-01 challenge for xn--exampledomainwithan-obc.de
Waiting for verification...
Challenge failed for domain www.xn--exampledomainwithan-obc.de
Challenge failed for domain xn--exampledomainwithan-obc.de
http-01 challenge for www.xn--exampledomainwithan-obc.de
http-01 challenge for xn--exampledomainwithan-obc.de
Cleaning up challenges
Some challenges have failed.
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: www.xn--exampledomainwithan-obc.de
Type: unauthorized
Detail: IPV6-here Invalid response from
http://www.xn--exampledomainwithan-obc.de/.well-known/acme-challenge/...
404
Domain: xn--exampledomainwithan-obc.de
Type: unauthorized
Detail: IPV6-here Invalid response from
http://xn--exampledomainwithan-obc.de/.well-known/acme-challenge/...
404
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address.
I see in the Nginx access.log that the requests for the .well-known/acme-challenge/... happen, so DNS and the webserver are definitely configured correctly, the challenge is just not served there.
So it looks like Certbot does not find the server root and could not write the file in .well-known/acme-challenge/. If it would have Can I supply it manually?
I believe Certbot checks to ensure the file is served before continuing, and it cleans up afterwards.
I think the issue is due to LetsEncrypt not being able to hit the domain via IPv6 routing. A lot of things could cause that. I would try dropping the host to IPv4 during setup if possible.
The first "fix" i would try, is just to ensure it's not an IPv6 issue by dropping that down to IPv4. Some ways to do that are in this thread:
If that doesn't work, the easiest way to handle this is to deal with 2 minutes of downtime and shutdown nginx, then run Certbot in "--standalone" mode on port 80. Certbot will bind to 80, run it's own server, and you can just copy the configuration from a working domain to this one -- referencing the correct domains.
You'll still need to address the cause of this (which i do think is ipv6 related; many people have similar issues) before renewal time - but dropping to ipv4 or running certbot in standalone mode should get your site secured in the interim.
I see the request incoming via IPV6 in the Nginx access.log and error.log. It ends in a 404 because the files are not served. So IPV6 works.
Also it works fine with other domain names that run with pretty much the same config on the server.
First, that resource is not entirely correct and misleading.
The OP shared the punycode encoding of an Internationalized Domain Name (IDNA), which is slightly related to Emoji Domains. Domain names are locked to the ASCII character set by RFC. To support Unicode and non-english usage (where Unicode is necessary), the IDNA algorithm is implemented which uses an "xn--" prefix, followed by the punycode ascii encoding of the unicode text. The double-dashes are allowed, because the "xn--" prefix is considered special and indicates a new set of RFCs should be used on the domain.
Certbot does have a --manual flag, which will prompt you to manually enter the challenge file. You could do that to bugtest your setup against the staging server and see if there is some filesystem path error.
I stress doing this against the staging server, because aside from rate limits it is a pain to upgrade a manual renewal into an automatic one. Once you get this working against staging, you can delete that certificate and then make a normal request against the production server that will auto-renew.
