# Requesting certs for Non-ASCII-Domain (IDN) via certbot causes trouble **URL:** \ **Category:** Help\ **Created:** [April 23, 2017, 7:38pm UTC](https://community.letsencrypt.org/t/requesting-certs-for-non-ascii-domain-idn-via-certbot-causes-trouble/32637 "2017-04-23T19:38:56Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![hotcore](https://avatars.discourse-cdn.com/v4/letter/h/5f9b8f/32.png) [@hotcore](https://community.letsencrypt.org/u/hotcore)\ **Post date:** [April 23, 2017, 7:38pm UTC](https://community.letsencrypt.org/t/requesting-certs-for-non-ascii-domain-idn-via-certbot-causes-trouble/32637/1 "2017-04-23T19:38:56Z")
hey there, I run Apache2 on my Debian 8 (Jessie) server, where I host two websites using two virtual-hosts. Because I want to enable HTTPS-access to them, I installed certbot via ``` git clone git://github.com/certbot/certbot.git ``` and performed it using ``` root@myserver:~/certbot# ./certbot-auto ``` After inserting my domain as punycode (because my domain nürnberg.rocks is a Internationalized Domain Name and not ASCII-comaptible), the following error occurs: ``` An unexpected error occurred: UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 5: ordinal not in range(128). ``` I’m using the certbot version 0.13.0 and I thought, punycode-domains should be supported in this version…? Can someone help me solving this problem or explain, how I can request certs for ounycode-domains? Thanks! ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [April 23, 2017, 8:13pm UTC](https://community.letsencrypt.org/t/requesting-certs-for-non-ascii-domain-idn-via-certbot-causes-trouble/32637/2 "2017-04-23T20:13:38Z")
> [@hotcore](#): > > Can someone help me solving this problem or explain (…) Well, the error is quite clear IMO: on the fifth position, it encounters a non-ASCII character. So it appears your punycode isn't punycoded enough? What _exactly_ did you enter into `certbot`? Edit: My `certbot` works perfectly with the punycoded hostname `xn--nrnberg-n2a.rocks`? ---
**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\ **Post date:** [April 23, 2017, 8:17pm UTC](https://community.letsencrypt.org/t/requesting-certs-for-non-ascii-domain-idn-via-certbot-causes-trouble/32637/3 "2017-04-23T20:17:26Z")
Could you post the log from `/var/log/letsencrypt`, which should include a full traceback showing where the error came from? ---
**Author:** ![sahsanu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/sahsanu/32/89984_2.png) [@sahsanu](https://community.letsencrypt.org/u/sahsanu)\ **Post date:** [April 23, 2017, 8:19pm UTC](https://community.letsencrypt.org/t/requesting-certs-for-non-ascii-domain-idn-via-certbot-causes-trouble/32637/4 "2017-04-23T20:19:10Z")
Hi @hotcore, As @Osiris commented, I suppose you are trying to issue the cert using your domain in unicode `nürnberg.rocks` but you should issue it using punycode `xn--nrnberg-n2a.rocks`. Cheers, sahsanu ---
**Author:** ![leader](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/leader/32/7569_2.png) [@leader](https://community.letsencrypt.org/u/leader)\ **Post date:** [April 23, 2017, 9:14pm UTC](https://community.letsencrypt.org/t/requesting-certs-for-non-ascii-domain-idn-via-certbot-causes-trouble/32637/5 "2017-04-23T21:14:50Z")
> [@hotcore](#): > > I run Apache2 on my Debian 8 (Jessie) server As others correctly mentioned above, you're probably entering those names as-is, rather than in "punycode" form (in which case it would work with most clients). Out of interest, could you please provide the output of the `locale` command (either in this thread or privately) - this weekend I was actually adding a way to handle exactly this case to my LE client and would be interested in reproducing the problem 🙂 ---
**Author:** ![hotcore](https://avatars.discourse-cdn.com/v4/letter/h/5f9b8f/32.png) [@hotcore](https://community.letsencrypt.org/u/hotcore)\ **Post date:** [April 24, 2017, 10:39am UTC](https://community.letsencrypt.org/t/requesting-certs-for-non-ascii-domain-idn-via-certbot-causes-trouble/32637/6 "2017-04-24T10:39:09Z")
Hey guys, thanks for your answers so far! > [@Osiris](#): > > Well, the error is quite clear IMO: on the fifth position, it encounters a non-ASCII character. > > So it appears your punycode isn't punycoded enough? What exactly did you enter into certbot? As certbot asked for the domain names, i entered "xn--nrnberg-n2a.rocks" (should be punycode...), while the real domain is nürnberg.rocks. And this "xn--nrnberg-n2a.rocks" seems to produces the error, the fifth position is an "n", which is IMO an ASCII-character, isn't it? I will post the entire log that evening, as well as answering leader[quote="leader, post:5, topic:32637"] Out of interest, could you please provide the output of the locale command (either in this thread or privately) [/quote] ---
**Author:** ![leader](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/leader/32/7569_2.png) [@leader](https://community.letsencrypt.org/u/leader)\ **Post date:** [April 24, 2017, 6:21pm UTC](https://community.letsencrypt.org/t/requesting-certs-for-non-ascii-domain-idn-via-certbot-causes-trouble/32637/7 "2017-04-24T18:21:39Z")
Considering that you are entering already punycoded (if there is such a word) domain name and it is encoded correctly and the error points to exactly that letter (ü), I would imagine that your input is not a problem, but decoding punycode somewhere down the pipeline is. I had a quick look at the python code and I believe the problem lies around line 187 of certbot\_apache/tls\_sni\_01.py (similar one exists in tls-sni for Nginx): ``` return self.VHOST_TEMPLATE.format( vhost=ips, server_name=achall.response(achall.account_key).z_domain.decode('ascii'), ssl_options_conf_path=self.configurator.mod_ssl_conf, cert_path=self.get_cert_path(achall), key_path=self.get_key_path(achall), document_root=document_root).replace("\n", os.linesep) ``` I would imagine that using some other challenge type instead of tls-sni or using a standalone mode should solve this for you (also make sure the domain name in the Apache config is encoded too). NB: Please note that I’m not a certbot developer and I usually prefer Perl to Python, so the above is just a theory, but I believe a plausible one. @schoen can probably say whether that theory holds any water. 🙂 ---
**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\ **Post date:** [April 24, 2017, 6:44pm UTC](https://community.letsencrypt.org/t/requesting-certs-for-non-ascii-domain-idn-via-certbot-causes-trouble/32637/8 "2017-04-24T18:44:31Z")
I would also like to see the log. Differently from @leader, I suspect the problem is with some other Unicode character on your system (e.g. in a filename or as part of an Apache configuration file). Is it possible that you have a ü character in a filename or Apache configuration file that Certbot would be processing? If so, and if that causes this crash, that is a but in Certbot that we’ll need to fix. ---
**Author:** ![hotcore](https://avatars.discourse-cdn.com/v4/letter/h/5f9b8f/32.png) [@hotcore](https://community.letsencrypt.org/u/hotcore)\ **Post date:** [April 24, 2017, 8:45pm UTC](https://community.letsencrypt.org/t/requesting-certs-for-non-ascii-domain-idn-via-certbot-causes-trouble/32637/9 "2017-04-24T20:45:00Z")
First at all, here is the logfile from /var/log/letsencrypt/letsencrypt.log [code] 2017-04-24 20:33:30,603:DEBUG:certbot.log:Root logging level set at 20 2017-04-24 20:33:30,604:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log 2017-04-24 20:33:30,605:DEBUG:certbot.main:certbot version: 0.13.0 2017-04-24 20:33:30,605:DEBUG:certbot.main:Arguments: ['--apache'] 2017-04-24 20:33:30,606:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#nginx,PluginEntryPoint#standalone,PluginEntryPoint#manual,PluginEntryPoint#webroot,PluginEntryPoin$ 2017-04-24 20:33:30,607:DEBUG:certbot.plugins.selection:Requested authenticator apache and installer apache 2017-04-24 20:33:31,495:DEBUG:certbot\_apache.configurator:Apache version is 2.4.10 2017-04-24 20:33:32,005:DEBUG:certbot.plugins.selection:Single candidate plugin: \* apache Description: Apache Web Server plugin - Beta Interfaces: IAuthenticator, IInstaller, IPlugin Entry point: apache = certbot\_apache.configurator:ApacheConfigurator Initialized: \ Prep: True 2017-04-24 20:33:32,007:DEBUG:certbot.plugins.selection:Selected authenticator \ and installer \ 2017-04-24 20:33:32,022:DEBUG:acme.client:Sending GET request to [https://acme-v01.api.letsencrypt.org/directory](https://acme-v01.api.letsencrypt.org/directory). 2017-04-24 20:33:32,084:DEBUG:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): [acme-v01.api.letsencrypt.org](http://acme-v01.api.letsencrypt.org) 2017-04-24 20:35:02,839:DEBUG:requests.packages.urllib3.connectionpool:[https://acme-v01.api.letsencrypt.org:443](https://acme-v01.api.letsencrypt.org:443) "GET /directory HTTP/1.1" 200 352 2017-04-24 20:35:02,844:DEBUG:acme.client:Received response: HTTP 200 Server: nginx Content-Type: application/json Content-Length: 352 Boulder-Request-Id: amQr9aw-5cgv1Kfh9iJXCEv29M8-V5PEOk5QA8dRcgA Replay-Nonce: WXL\_NhRovns\_Yhu5uoDc8WwjP3IQ7nShmRqMWYKYvlI X-Frame-Options: DENY Strict-Transport-Security: max-age=604800 Expires: Mon, 24 Apr 2017 20:35:06 GMT Cache-Control: max-age=0, no-cache, no-store Pragma: no-cache Date: Mon, 24 Apr 2017 20:35:06 GMT Connection: keep-alive { "key-change": "[https://acme-v01.api.letsencrypt.org/acme/key-change](https://acme-v01.api.letsencrypt.org/acme/key-change)", "new-authz": "[https://acme-v01.api.letsencrypt.org/acme/new-authz](https://acme-v01.api.letsencrypt.org/acme/new-authz)", "new-cert": "[https://acme-v01.api.letsencrypt.org/acme/new-cert](https://acme-v01.api.letsencrypt.org/acme/new-cert)", "new-reg": "[https://acme-v01.api.letsencrypt.org/acme/new-reg](https://acme-v01.api.letsencrypt.org/acme/new-reg)", "revoke-cert": "[https://acme-v01.api.letsencrypt.org/acme/revoke-cert](https://acme-v01.api.letsencrypt.org/acme/revoke-cert)" } 2017-04-24 20:35:02,846:DEBUG:certbot.util:Not suggesting name "www.nürnberg.rocks" 2017-04-24 20:35:02,849:DEBUG:certbot.util:Non-ASCII domain names not supported. To issue for an Internationalized Domain Name, use Punycode. 2017-04-24 20:35:02,850:DEBUG:certbot.util:Not suggesting name "gwsan.nürnberg.rocks" 2017-04-24 20:35:02,850:DEBUG:certbot.util:Non-ASCII domain names not supported. To issue for an Internationalized Domain Name, use Punycode. 2017-04-24 20:35:09,424:INFO:certbot.main:Obtaining a new certificate 2017-04-24 20:35:09,426:DEBUG:acme.client:Requesting fresh nonce 2017-04-24 20:35:09,426:DEBUG:acme.client:Sending HEAD request to [https://acme-v01.api.letsencrypt.org/acme/new-authz](https://acme-v01.api.letsencrypt.org/acme/new-authz). 2017-04-24 20:35:09,626:DEBUG:requests.packages.urllib3.connectionpool:[https://acme-v01.api.letsencrypt.org:443](https://acme-v01.api.letsencrypt.org:443) "HEAD /acme/new-authz HTTP/1.1" 405 0 2017-04-24 20:35:09,629:DEBUG:acme.client:Received response: HTTP 405 Server: nginx Content-Type: application/problem+json Content-Length: 91 Allow: POST Boulder-Request-Id: rk9nzhuCJ6xZxiS9ucj6JRT69vVHy1iFQzXbZkb2Y8k Replay-Nonce: dfoF4bMa-srCC34vk7ZayGE\_Z6vdYAmVN3fz0ZwkEss Expires: Mon, 24 Apr 2017 20:35:13 GMT Cache-Control: max-age=0, no-cache, no-store Pragma: no-cache Date: Mon, 24 Apr 2017 20:35:13 GMT Connection: keep-alive 2017-04-24 20:35:09,629:DEBUG:acme.client:Storing nonce: dfoF4bMa-srCC34vk7ZayGE\_Z6vdYAmVN3fz0ZwkEss 2017-04-24 20:35:09,630:DEBUG:acme.client:JWS payload: { "identifier": { "type": "dns", "value": "xn--nrnberg-n2a.rocks" }, "resource": "new-authz" } 2017-04-24 20:35:09,636:DEBUG:acme.client:Sending POST request to [https://acme-v01.api.letsencrypt.org/acme/new-authz:](https://acme-v01.api.letsencrypt.org/acme/new-authz:) { "header": { "alg": "RS256", "jwk": { "e": "AQAB", "kty": "RSA", "n": "pUTd9HzSRfumd5I9YDkmETzpYqRjosi4KvfeAavhTJaJaAvRhNdoGx6h4TmMI3lcf0SvyG7jtF5g5BX7cgm3qZo18RsLaDzjjLN41GfrIOW5z03pjJHx0LCZ8a0N7jh1ghobL2DNwgkenQyn-SQbQ80bvRle15lNqjq\_2PRFmzqUy4\_tNU6sBf$ } }, "protected": "eyJub25jZSI6ICJkZm9GNGJNYS1zckNDMzR2azdaYXlHRV9aNnZkWUFtVk4zZnowWndrRXNzIn0", "payload": "ewogICJpZGVudGlmaWVyIjogewogICAgInR5cGUiOiAiZG5zIiwgCiAgICAidmFsdWUiOiAieG4tLW5ybmJlcmctbjJhLnJvY2tzIgogIH0sIAogICJyZXNvdXJjZSI6ICJuZXctYXV0aHoiCn0", "signature": "hHRATgMMKjC60rTyHHqFoNXhAtvCeQSJLk3pB5KoWS8C-RQ7ZRTiOcGCOimWenX5HM2BsTxb43ScpN-1bgzXIioaAB\_TEIp05OZQsFEFdSScFtMw5QCLieO-kZj7BFNJ0I7bcz1qhykfJ9EAspiAAZdBZiEN3yehy\_df9186dkCnrI7Qp9$ } 2017-04-24 20:35:09,855:DEBUG:requests.packages.urllib3.connectionpool:[https://acme-v01.api.letsencrypt.org:443](https://acme-v01.api.letsencrypt.org:443) "POST /acme/new-authz HTTP/1.1" 201 1009 2017-04-24 20:35:09,857:DEBUG:acme.client:Received response: HTTP 201 Server: nginx Content-Type: application/json Content-Length: 1009 Boulder-Request-Id: u7GV-7knyFYg1OBe-TuSf81Hs4Gd0K3uPi27e9Tp2KY Boulder-Requester: 13159593 Link: [https://acme-v01.api.letsencrypt.org/acme/new-cert](https://acme-v01.api.letsencrypt.org/acme/new-cert);rel="next" Location: [https://acme-v01.api.letsencrypt.org/acme/authz/z7\_DJyqHTCX0a8ubk3eHzwCXJoxyubCw1jeWy1KvvE8](https://acme-v01.api.letsencrypt.org/acme/authz/z7_DJyqHTCX0a8ubk3eHzwCXJoxyubCw1jeWy1KvvE8) Replay-Nonce: pIbJkWZ3IMwGRvBGuKJlRZX16xVxALGTKoaBtZaJxTk X-Frame-Options: DENY Strict-Transport-Security: max-age=604800 Expires: Mon, 24 Apr 2017 20:35:13 GMT Cache-Control: max-age=0, no-cache, no-store Pragma: no-cache Date: Mon, 24 Apr 2017 20:35:13 GMT Connection: keep-alive { "identifier": { "type": "dns", "value": "xn--nrnberg-n2a.rocks" }, "status": "pending", "expires": "2017-05-01T20:35:13.184024764Z", "challenges": [ { "type": "http-01", "status": "pending", "uri": "[https://acme-v01.api.letsencrypt.org/acme/challenge/z7\_DJyqHTCX0a8ubk3eHzwCXJoxyubCw1jeWy1KvvE8/1078291794](https://acme-v01.api.letsencrypt.org/acme/challenge/z7_DJyqHTCX0a8ubk3eHzwCXJoxyubCw1jeWy1KvvE8/1078291794)", "token": "OurzFgq8UXRkcQzixp1hmpfynwybFhT5PUu4eXoKDx8" }, { "type": "dns-01", "status": "pending", "uri": "[https://acme-v01.api.letsencrypt.org/acme/challenge/z7\_DJyqHTCX0a8ubk3eHzwCXJoxyubCw1jeWy1KvvE8/1078291795](https://acme-v01.api.letsencrypt.org/acme/challenge/z7_DJyqHTCX0a8ubk3eHzwCXJoxyubCw1jeWy1KvvE8/1078291795)", "token": "tgKpc-ul4sR6bPOmKhS4QRAGmPqHB7qCv\_Va\_tS\_m6E" }, { "type": "tls-sni-01", "status": "pending", "uri": "[https://acme-v01.api.letsencrypt.org/acme/challenge/z7\_DJyqHTCX0a8ubk3eHzwCXJoxyubCw1jeWy1KvvE8/1078291796](https://acme-v01.api.letsencrypt.org/acme/challenge/z7_DJyqHTCX0a8ubk3eHzwCXJoxyubCw1jeWy1KvvE8/1078291796)", "token": "vIgeIZWo02c2mdOfo1Nq17U7X5vujwmbkbYGRK4R-hA" } ], "combinations": [ [ 0 ], [ 2 ], [ 1 ] ] } 2017-04-24 20:35:09,857:DEBUG:acme.client:Storing nonce: pIbJkWZ3IMwGRvBGuKJlRZX16xVxALGTKoaBtZaJxTk 2017-04-24 20:35:09,859:INFO:certbot.auth\_handler:Performing the following challenges: 2017-04-24 20:35:09,860:INFO:certbot.auth\_handler:tls-sni-01 challenge for xn--nrnberg-n2a.rocks 2017-04-24 20:35:10,110:INFO:certbot\_apache.configurator:Enabled Apache socache\_shmcb module 2017-04-24 20:35:10,423:INFO:certbot\_apache.configurator:Enabled Apache ssl module 2017-04-24 20:35:10,911:DEBUG:certbot.error\_handler:Encountered exception: Traceback (most recent call last): File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/auth\_handler.py", line 115, in \_solve\_challenges resp = self.auth.perform(self.achalls) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot\_apache/configurator.py", line 1762, in perform sni\_response = chall\_doer.perform() File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot\_apache/tls\_sni\_01.py", line 79, in perform addrs = self.\_mod\_config() File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot\_apache/tls\_sni\_01.py", line 101, in \_mod\_config achall\_addrs = self.\_get\_addrs(achall) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot\_apache/tls\_sni\_01.py", line 126, in \_get\_addrs vhost = self.configurator.choose\_vhost(achall.domain, temp=True) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot\_apache/configurator.py", line 331, in choose\_vhost return self.\_choose\_vhost\_from\_list(target\_name, temp) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot\_apache/configurator.py", line 335, in \_choose\_vhost\_from\_list vhost = display\_ops.select\_vhost(target\_name, self.vhosts) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot\_apache/display\_ops.py", line 29, in select\_vhost code, tag = \_vhost\_menu(domain, vhosts) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot\_apache/display\_ops.py", line 79, in \_vhost\_menu name\_size=disp\_name\_size) UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 5: ordinal not in range(128) 2017-04-24 20:35:10,911:DEBUG:certbot.error\_handler:Calling registered functions 2017-04-24 20:35:10,911:INFO:certbot.auth\_handler:Cleaning up challenges 2017-04-24 20:35:11,549:DEBUG:certbot.log:Exiting abnormally: Traceback (most recent call last): File "/root/.local/share/letsencrypt/bin/letsencrypt", line 11, in sys.exit(main()) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/main.py", line 755, in main return config.func(config, plugins) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/main.py", line 597, in run certname, lineage) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/main.py", line 82, in \_get\_and\_save\_cert lineage = le\_client.obtain\_and\_enroll\_certificate(domains, certname) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/client.py", line 316, in obtain\_and\_enroll\_certificate certr, chain, key, \_ = self.obtain\_certificate(domains) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/client.py", line 285, in obtain\_certificate self.config.allow\_subset\_of\_names) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/auth\_handler.py", line 74, in get\_authorizations resp = self.\_solve\_challenges() File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/auth\_handler.py", line 115, in \_solve\_challenges resp = self.auth.perform(self.achalls) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot\_apache/configurator.py", line 1762, in perform sni\_response = chall\_doer.perform() File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot\_apache/tls\_sni\_01.py", line 79, in perform addrs = self.\_mod\_config() File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot\_apache/tls\_sni\_01.py", line 101, in \_mod\_config achall\_addrs = self.\_get\_addrs(achall) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot\_apache/tls\_sni\_01.py", line 126, in \_get\_addrs File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot\_apache/configurator.py", line 331, in choose\_vhost return self.\_choose\_vhost\_from\_list(target\_name, temp) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot\_apache/configurator.py", line 335, in \_choose\_vhost\_from\_list vhost = display\_ops.select\_vhost(target\_name, self.vhosts) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot\_apache/display\_ops.py", line 29, in select\_vhost code, tag = \_vhost\_menu(domain, vhosts) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot\_apache/display\_ops.py", line 79, in \_vhost\_menu name\_size=disp\_name\_size) UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 5: ordinal not in range(128) [/code] > [@schoen](#): > > Differently from @leader, I suspect the problem is with some other Unicode character on your system (e.g. in a filename or as part of an Apache configuration file). Is it possible that you have a ü character in a filename or Apache configuration file that Certbot would be processing? I have edited none of the apache-config-files, so I am quite shure, there is nowhere an ü-character in there, exept from the virtual-host-config file. At /etc/apache2/sites-available/myvhost.conf the domain written as-is (with ü) is set as ServerName-Directive. Is certbot processing the vhost-file while creating the certs? If so, this might be the problem. ---
**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\ **Post date:** [April 24, 2017, 8:47pm UTC](https://community.letsencrypt.org/t/requesting-certs-for-non-ascii-domain-idn-via-certbot-causes-trouble/32637/10 "2017-04-24T20:47:29Z")
> [@hotcore](#): > > Is certbot processing the vhost-file while creating the certs? If so, this might be the problem. Yes, I'm almost positive that's the problem. I'll file a bug about this. ---
**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\ **Post date:** [April 24, 2017, 8:53pm UTC](https://community.letsencrypt.org/t/requesting-certs-for-non-ascii-domain-idn-via-certbot-causes-trouble/32637/11 "2017-04-24T20:53:39Z")
Submitted as > Thanks for letting us know about the problem and providing a log. Unfortunately, the best workaround until the problem is fixed in Certbot might be to represent your domain name with Punycode even within your Apache configuration file. ---
**Author:** ![leader](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/leader/32/7569_2.png) [@leader](https://community.letsencrypt.org/u/leader)\ **Post date:** [April 24, 2017, 10:25pm UTC](https://community.letsencrypt.org/t/requesting-certs-for-non-ascii-domain-idn-via-certbot-causes-trouble/32637/12 "2017-04-24T22:25:06Z")
Interesting, before the first edit I put there a question in bold if you have a domain name as is rather in punicode form in the Apache config, though considering that it might be not very likely with what you said about using punycode, I then re-phrased it to “make sure it’s encoded in Apache config” 🙂 Anyways, it would be interesting to see what happens if you run it in standalone mode - technically there is no need for certbot to check configs then I guess? ---
**Author:** ![hotcore](https://avatars.discourse-cdn.com/v4/letter/h/5f9b8f/32.png) [@hotcore](https://community.letsencrypt.org/u/hotcore)\ **Post date:** [April 25, 2017, 7:14pm UTC](https://community.letsencrypt.org/t/requesting-certs-for-non-ascii-domain-idn-via-certbot-causes-trouble/32637/13 "2017-04-25T19:14:39Z")
> [@schoen](#): > > Yes, I'm almost positive that's the problem. I'll file a bug about this. Indded, this was nearly fixing the problem. I changed the ServerName-Directive in the vhost-config-file into the punycode domain, an ran again `/root/certbot/certbot-auto --apache` Afterwards I was asked to choose the domain, I want to request certificates for, and the only one shown was the "root"-domain "xn--nrnberg-n2a.rocks". HTPPS-acces to that page works well now, but the only website I am hosting at the moment should be accessed via a subdomain "gwsan.xn--nrnberg-n2a.rocks". The cert doesn't seem to work for the subdomain as well automatically, but creating a cert for that subdomain seems not to be easyly done by running ``` cd /root/certbot ./certbot-auto --domains gwsan.xn--nrnberg-n2a.rocks ``` Feedback: ``` Obtaining a new certificate Performing the following challenges: tls-sni-01 challenge for gwsan.xn--nrnberg-n2a.rocks Cleaning up challenges An unexpected error occurred: UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 5: ordinal not in range(128) ``` The ServerName at the only enabled vhost-config at the moment (responsible for this website) is gwsan.xn--nrnberg-n2a.rocks. How do i get certs for that subdomain, if creating one for the root-domain works now? ---
**Author:** ![hotcore](https://avatars.discourse-cdn.com/v4/letter/h/5f9b8f/32.png) [@hotcore](https://community.letsencrypt.org/u/hotcore)\ **Post date:** [April 25, 2017, 7:17pm UTC](https://community.letsencrypt.org/t/requesting-certs-for-non-ascii-domain-idn-via-certbot-causes-trouble/32637/14 "2017-04-25T19:17:26Z")
> [@leader](#): > > Interesting, before the first edit I put there a question in bold if you have a domain name as is rather in punicode form in the Apache config, though considering that it might be not very likely with what you said about using punycode, I then re-phrased it to "make sure it's encoded in Apache config" Sorry leader, I was not aware that you could also have ment a vhsot-file in the apache-configuration. Thats why I didn't thought about that at first 😉 > [@leader](#): > > Anyways, it would be interesting to see what happens if you run it in standalone mode - technically there is no need for certbot to check configs then I guess? How do I start that standalone-mode? ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [May 25, 2017, 7:24pm UTC](https://community.letsencrypt.org/t/requesting-certs-for-non-ascii-domain-idn-via-certbot-causes-trouble/32637/15 "2017-05-25T19:24:45Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.