Fix NET::ERR_CERT_COMMON_NAME_INVALID with Hosts File (2026)

NET::ERR_CERT_COMMON_NAME_INVALID occurs when the SSL/TLS certificate presented by your web server does not match the domain name typed into the browser. When you use your hosts file to route a test or staging domain to your local machine, the default certificate returned by your server is rejected by browser security checks.

How to fix NET::ERR_CERT_COMMON_NAME_INVALID with the hosts file

To fix NET::ERR_CERT_COMMON_NAME_INVALID when using the hosts file, install a local certificate authority with mkcert -install, generate a TLS certificate that includes all your test domains and subdomains (using Subject Alternative Names), and configure your local web server (Nginx, Caddy, or Apache) to serve this certificate over port 443.

Why this error happens during hosts file testing

When you add a custom entry to your hosts file:

127.0.0.1  myclient-site.test

Here is what happens during the network request:

1. The browser resolves myclient-site.test to 127.0.0.1 via your hosts file.
2. The browser initiates a secure HTTPS connection on port 443 of 127.0.0.1.
3. The local server returns its active SSL certificate (often issued for localhost or a different vhost).
4. The browser compares myclient-site.test against the allowed names in the certificate's Subject Alternative Name (SAN) field.
5. Because there is no match, Chrome and Safari block the request with NET::ERR_CERT_COMMON_NAME_INVALID.

See also our guide on local HTTPS certificates and fixing mkcert certificate authority errors.

Solution comparison matrix

Recommended fix: Generate SAN certificates with mkcert

Since the deprecation of the legacy Common Name field in favor of Subject Alternative Name (SAN, RFC 2818), modern certificates must explicitly list all domain aliases.

1. Install mkcert

On macOS (via Homebrew):

brew install mkcert
brew install nss # Recommended for Firefox support

On Linux (Ubuntu/Debian):

sudo apt install libnss3-tools
curl -JLO "https://dl.filippo.io/mkcert/latest?for=linux/amd64"
chmod +x mkcert-v*-linux-amd64
sudo cp mkcert-v*-linux-amd64 /usr/local/bin/mkcert

On Windows (PowerShell via Chocolatey):

choco install mkcert

2. Install the local certificate authority

mkcert -install

This registers a custom root CA in your operating system trust store.

3. Generate a certificate covering all hosts file domains

Include all your test hostnames, wildcards, and loopback addresses in one command:

mkcert myproject.test "*.myproject.test" api.myproject.test localhost 127.0.0.1

This produces two files in your current working directory:

• myproject.test+4.pem (the public certificate)
• myproject.test+4-key.pem (the private key)

4. Configure your local web server (Nginx example)

server {
    listen 443 ssl http2;
    server_name myproject.test api.myproject.test;

    ssl_certificate /path/to/myproject.test+4.pem;
    ssl_certificate_key /path/to/myproject.test+4-key.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto https;
    }
}

Reload Nginx (sudo nginx -s reload) and refresh the page. The green lock icon will display without certificate warnings.

Why you should avoid .dev and .app for local testing

Some developers use myproject.dev or myproject.app in their hosts file.

• .dev and .app are real Top-Level Domains owned by Google Registry.
• They are included in the browser HSTS preload list.
• Any connection attempt is converted to strict HTTPS, and browsers strictly block the "Proceed to site" bypass option if the certificate is invalid.

For local development in /etc/hosts, always use reserved TLDs specified by RFC 2606:

• .test (e.g., app.test)
• .example
• .localhost

Read why you should use .test for local development for more details.