8

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. Commented Nov 4, 2016 at 12:56
  • 5
    Resolved the issue by using *.dev.localhost as the CN. Commented Jan 18, 2017 at 17:22
  • 4
    @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

13

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
  • 2
    So chrome don't allow *.xyz certificates? Commented Jan 31, 2020 at 14:34
  • Hi! Is this answer still valid in 2024? Commented Jan 3, 2024 at 16:56
  • 1
    @Jono Still correct for we can't use *.localhost for the certificate, or any local TLD, like *.local or *.test. Commented May 8, 2024 at 14:28
  • 2
    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, 2024 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
  • 3
    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. 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? 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. Commented Feb 18, 2021 at 15:12

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.