Internationalized Domain Names (IDNs) and ssl configuration

I have a Internationalized Domain Name (IDNs): wó

I would like to configure it to have http and certified ssl version available.
Would you be so kind and try to step by step make the configuration with me?

You might ask why I do not try to do it by myself? To be honest I tried but I am not sure if I did it correctly. My knowledge cannot even compare to your knowledge and I would like to see how experts would do it.

As before my web server is:
Server version: Apache/2.4.57 (Debian)
Server built: 2023-04-13T03:26:51

System Debian: Debian GNU/Linux 12 (bookworm)

DNS records:

I have root access to my machine, firewall and routing is set up correctly because I have ssl configuration for "regular" domains.

Currently domain http://wó is showing default website of Apache because Virtual Host is not there yet.

Would you be able to help me with preparing ideal configuration for that IDNs domain, please?

I need to add that when I made configuration by myself, I realized that there is one "effect" I do not like. I mean when I enter IDN domain name wó in my browser, I see for a second ascii domain name

I believe I have never seen that for IDN domains in internet, just for my configuration :frowning: So I am assuming I did something wrong.

Yeah, puny code (xn--) is used for internationalized names.

This thread has good detail


Perhaps your site is just a bit slower than the other sites you have visited.
Giving you just enough time for your eyes to see what should be there [for all such names].


Mhhh, it is just blank website :frowning: nothing there :frowning:
How Virtual Host should looks like for wó domain? Would somebody present, please?

1 Like

pretend unicode doesn't exist and use punycode string


As would any other vhost in your system.
Just use:


Something like this?

<VirtualHost *:80>
        # The ServerName directive sets the request scheme, hostname and port that
        # the server uses to identify itself. This is used when creating
        # redirection URLs. In the context of virtual hosts, the ServerName
        # specifies what hostname must appear in the request's Host: header to
        # match this virtual host. For the default virtual host (this file) this
        # value is not decisive as it is used as a last resort host regardless.
        # However, you must set it for any further virtual host explicitly.


        # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
        # error, crit, alert, emerg.
        # It is also possible to configure the loglevel for particular
        # modules, e.g.
        #LogLevel info ssl:warn

        ErrorLog /var/www/html/wó
        CustomLog /var/www/html/wó combined

        # For most configuration files from conf-available/, which are
        # enabled or disabled at a global level, it is possible to
        # include a line for only one particular virtual host. For example the
        # following line enables the CGI configuration for this host only
        # after it has been globally disabled with "a2disconf".
        #Include conf-available/serve-cgi-bin.conf
RewriteEngine on
RewriteCond %{SERVER_NAME} [OR]
RewriteCond %{SERVER_NAME}
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

In the ErrorLog and CustomLog should it be or wó ?

In RewriteRule:
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]


RewriteRule ^ https://wó{REQUEST_URI} [END,NE,R=permanent]


I suggest not using any non-ASCII characters in your web server configuration file. You can leave it as

I see that too, but I don't see it when clicking on a link to your domain (e.g. http://wó If you're able to publicize/get people to interact with your site in such a way that they're usually clicking a link to it rather than pasting the URL, perhaps this won't be a problem?

I don't think that the appearance of the ASCII-encoded form in the browser user interface is a result of your server configuration in any way. I tried this with a different IDN domain and I saw exactly the same behavior (ASCII-encoded form is very briefly visible if pasting the URL, not if following a link).


I would stay away from using that ["ó"] in the nginx coding.


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