Certbot with Nginx and IDN domain


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.

 - The following errors were reported by the server:

   Domain: www.xn--exampledomainwithan-obc.de
   Type:   unauthorized
   Detail: IPV6-here Invalid response from

   Domain: xn--exampledomainwithan-obc.de
   Type:   unauthorized
   Detail: IPV6-here Invalid response from

   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.


You might want to check the syntax of the domain name itself

1 Like

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.

And from here What are the valid characters for a domain name and how long can a domain name be? - Knowledgebase - Save On Hosting and here as well .SL Domain Name Registration - Sierra Leone
"The only symbol character domain names can include is a hyphen (-) although the domain name cannot start or end with a hyphen nor have consecutive hyphens."

Your example is showing consecutive hyphens.

That's just an example encoded with punycode, as Certbot requests it. This domain would not even have a hyphen.

xn--exampledomainwithan-obc.de = exampledomainwithanü.de

It's encoding the Ü.


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.

For reading:



Thanks @jvanasco :slight_smile:


Are you sure the IP is external?

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.


NP. Themoreyouknow Star GIF - Themoreyouknow Star Rainbowstreak - Discover & Share GIFs

I got tripped up on the same things too the first time I hosted a punycode domain. "WTF? Two Dashes? AM I HACKED? THIS IS IMPOSSIBLE!"


Kind of seems like ASCII - Wikipedia already had the concept of shifting In and Out of character set.

000 1110 016 14 0E SO ^N Shift Out
000 1111 017 15 0F SI ^O Shift In
001 1011 033 27 1B S3 ESC ^[ \e Escape
1 Like

IPv6 may be "working".
But that is only proof of the networking part of the equation.

The appearance in the logs may be misleading.
If the expected server block is NOT correctly configured, the default server block will respond instead.


Thanks, that solved it. I had to put it in the server block in the Nginx config.

I had
listen 80;
set, but not
listen [::]:80;

So yes, the log and that ping6 worked misled me.

Also thanks to jvanasco for leading in the direction of a IPv6 problem.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.