7

I've attempted to set up a wildcard *.localhost for HTTP and HTTPS with Nginx proxying requests to localhost:3000. DNSmasq is used for resolving *.localhost to 127.0.0.1.

Everything works fine for HTTP, but HTTPS connections receive the following error in Google Chrome:

There are issues with the site's certificate chain (net::ERR_CERT_COMMON_NAME_INVALID).

The certificate is a self-signed certificate that I've added to Chrome via settings, and was generated with the following command:

openssl req -x509 -sha256 -newkey rsa:2048 -keyout localhost.key -out localhost.crt -days 3650 -nodes

The Subject is as follows:

Subject: C=AU, ST=Western Australia, L=Perth, O=Zephon, CN=*.localhost

My Nginx config is as follows:

server {
    listen       80;
    listen       443 ssl; 

    server_name  localhost;

    ssl_certificate /etc/nginx/ssl/localhost.crt;
    ssl_certificate_key /etc/nginx/ssl/localhost.key;

    location / {
        proxy_pass          http://localhost:3000;
        proxy_http_version  1.1;
        proxy_set_header    Host             $host;
        proxy_set_header    Upgrade          $http_upgrade;
        proxy_set_header    Connection       "upgrade";
        proxy_set_header    X-Real-IP        $remote_addr;
        proxy_set_header    X-Forwarded-For  $proxy_add_x_forwarded_for;
        proxy_set_header    X-Client-Verify  SUCCESS;
        proxy_set_header    X-Client-DN      $ssl_client_s_dn;
        proxy_set_header    X-SSL-Subject    $ssl_client_s_dn;
        proxy_set_header    X-SSL-Issuer     $ssl_client_i_dn;
        proxy_read_timeout 1800;
        proxy_connect_timeout 1800;
    }
}
7
  • When you created your self signed certificate, you specified the common name (CN) which is the DNS name of your website. If you use that certificate with another.localhost, you will get that warning. Commented Oct 25, 2016 at 10:34
  • 4
    The problem is that you'd like to create a wildcard SSL certificate for a top level domain. This certificate will be denied by Chrome to avoid wildcard certificates like *.com or *.net or whatever. Commented Oct 25, 2016 at 14:45
  • 1
    @JensBradler is this behaviour documented anywhere? I've been unable to find a list of rules for what Chrome will accept anywhere.
    – thomasfedb
    Commented Nov 4, 2016 at 12:56
  • 5
    Resolved the issue by using *.dev.localhost as the CN.
    – thomasfedb
    Commented Jan 18, 2017 at 17:22
  • 3
    @thomasfedb found explanation of why common browsers do not accept wildcard certificates for TLDs here: security.stackexchange.com/a/6874/93805 Commented Apr 7, 2020 at 1:14

2 Answers 2

11

So ultimately the answer seems to be that you simply can't create a certificate for *.localhost that Chrome will accept.

My solution was to change to using *.dev.localhost instead, which worked a treat.

4
  • 1
    So chrome don't allow *.xyz certificates?
    – user291620
    Commented Jan 31, 2020 at 14:34
  • Hi! Is this answer still valid in 2024?
    – Jono
    Commented Jan 3 at 16:56
  • @Jono Still correct for we can't use *.localhost for the certificate, or any local TLD, like *.local or *.test.
    – bayuah
    Commented May 8 at 14:28
  • Thank you for documenting this! Been tearing my hair out trying to work out why this specific case (I have multiple SAN entries) didn't work. It's not clear why localhost is classified as a registry/unknown TLD, but I guess this is intentional based on Florent's link in the comment on the question above. Commented Jul 7 at 1:17
1

It's actually fully possible. What it's not is particularly well documented.

https://letsencrypt.org/docs/certificates-for-localhost/#making-and-trusting-your-own-certificates shows how to generate your own localhost certificate

openssl req -x509 -out localhost.crt -keyout localhost.key \
  -newkey rsa:2048 -nodes -sha256 \
  -subj '/CN=localhost' -extensions EXT -config <( \
    printf "[dn]\nCN=localhost\n[req]\ndistinguished_name = dn\n[EXT]\nsubjectAltName=DNS:localhost\nkeyUsage=digitalSignature\nextendedKeyUsage=serverAuth")

You can then work out what extras signing a wildcard certificate needs. I believe this is as simple as providing a *. prefix (glob wildcard syntax) source

Installing a self-signed cert is documented elsewhere on stackoverlow regarding linux

Windows IDK, Mac IDC

9
  • 2
    The OP already managed to do all of this, including adding the wildcard to the CN. It didn't work. Commented Mar 11, 2019 at 2:27
  • Did they reload their certs. Assuring me you know what OP did without a link I can't do much with. I'm not sure what the point of the comment was, but it's possible and I posted after having done this for a work skunkworks project yesterday.
    – MrMesees
    Commented Mar 11, 2019 at 15:21
  • 1
    All of this was already in the original question. I posted to let you know that your answer was useless in its current form. Commented Mar 11, 2019 at 17:02
  • Did you get this working with Chrome? Which version?
    – thomasfedb
    Commented Mar 12, 2019 at 5:45
  • 1
    Also, in 2021 I would advise you not to do this. I run several wildcard services on my home network by using LetsEncrypt AWS & DigitalOcean DNS, and having a dedicated domain / sub-domain which is not used online. The benefits are not needing to jump through hoops to get the self-signed CA setup. WARNING. DO NOT EVER USE A LIVE DOMAIN LIKE THIS LOCALLY. It is terrible security practice, and really just works around OS's not shipping with Https localhost by default. Perhaps /etc/selfsigned-root.crt now that all OS's auto-update it could provide further incentive.
    – MrMesees
    Commented Feb 18, 2021 at 15:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .