6

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;
    }
}
thomasfedb
  • 455
  • 5
  • 14
  • 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. – Richard Smith Oct 25 '16 at 10:34
  • The Subject is `Subject: C=AU, ST=Western Australia, L=Perth, O=Zephon, CN=*.localhost`. I'll add it to the question. – thomasfedb Oct 25 '16 at 10:38
  • You may find [this link](http://stackoverflow.com/questions/27294589/creating-self-signed-certificate-for-domain-and-subdomains-neterr-cert-commo) interesting. It suggests that Chrome likes the SAN field to be filled in as well as the CN. – Richard Smith Oct 25 '16 at 10:51
  • 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. – Jens Bradler Oct 25 '16 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 Nov 04 '16 at 12:56
  • 5
    Resolved the issue by using `*.dev.localhost` as the CN. – thomasfedb Jan 18 '17 at 17:22
  • 2
    @thomasfedb found explanation of why common browsers do not accept wildcard certificates for TLDs here: https://security.stackexchange.com/a/6874/93805 – Florent Roques Apr 07 '20 at 01:14

2 Answers2

10

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.

thomasfedb
  • 455
  • 5
  • 14
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

MrMesees
  • 127
  • 5
  • 2
    The OP already managed to do all of this, including adding the wildcard to the CN. It didn't work. – Michael Hampton Mar 11 '19 at 02: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 Mar 11 '19 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. – Michael Hampton Mar 11 '19 at 17:02
  • Did you get this working with Chrome? Which version? – thomasfedb Mar 12 '19 at 05:45
  • Chromium. I have a whole doc about installing self-signed SSL's on Chrome (windows) here https://github.com/CODESIGN2/CODESIGN2.github.io/blob/master/jan-2015-free-ssl.pdf it's probably a little out of date, but works. The other day I didn't follow that, I just installed and updated root ca bundle as described in the link regarding linux – MrMesees Mar 12 '19 at 09:51
  • Noticed this got upvoted. Here is a stable link (will never change) https://github.com/CODESIGN2/CODESIGN2.github.io/blob/legacy-hybrid/jan-2015-free-ssl.pdf – MrMesees Feb 18 '21 at 15:09
  • 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 Feb 18 '21 at 15:12