Resolving NET::ERR_CERT_COMMON_NAME_INVALID: Complete Guide to Creating Self-Signed Certificates for Domains and Subdomains on Windows

Keywords: Self-Signed Certificate | SSL Error | Chrome Compatibility | Subject Alternative Names | OpenSSL Configuration

Abstract: This technical article provides an in-depth analysis of the NET::ERR_CERT_COMMON_NAME_INVALID error encountered when creating self-signed SSL certificates for domains and subdomains in Windows development environments. The paper examines Chrome's mandatory requirement for Subject Alternative Names (SAN), presents comprehensive solutions using OpenSSL configuration files and third-party tools, and offers step-by-step guidance for configuring openssl.conf, generating certificate key pairs, and importing certificates into system trust stores to resolve HTTPS certificate validation issues in local development setups.

Problem Background and Error Analysis

When configuring HTTPS services in local development environments, developers frequently need to create self-signed SSL certificates for multiple domains and subdomains. According to user reports, when attempting to use wildcard certificates (such as *.myserver.net) to cover both the main domain and all subdomains, Chrome browser returns the NET::ERR_CERT_COMMON_NAME_INVALID error. The error message clearly states: "This server could not prove that it is myserver.net; its security certificate is from *.myserver.net/CN=myserver.net."

Root Cause Analysis

The core issue lies in modern browsers' (particularly Chrome 58 and above) enhanced SSL certificate validation standards. Chrome has deprecated certificate validation that relies solely on the Common Name field, instead mandating that certificates must include Subject Alternative Names extensions. This means that even if the Common Name field is set in wildcard format, the certificate will still be considered invalid if corresponding SAN entries are missing.

Solution 1: Using OpenSSL Configuration File

Create a configuration file named openssl.conf with the following content:

[req]
default_bits = 2048
default_keyfile = oats.key
encrypt_key = no
utf8 = yes
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no

[req_distinguished_name]
C = US
ST = Cary
L = Cary
O = BigCompany
CN = *.myserver.net

[v3_req]
keyUsage = critical, digitalSignature, keyAgreement
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = myserver.net
DNS.2 = *.myserver.net

Generate the certificate using the following command:

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

Solution 2: Using Third-Party Certificate Tools

For developers seeking to simplify the process, professional self-signed certificate generation tools can be utilized:

Visit reliable self-signed certificate websites to generate certificate files
Import the generated root certificate into "Trusted Root Certification Authorities" via Windows Certificate Manager
Additionally import the certificate in Chrome Certificate Manager (this step addresses Chrome-specific issues)

Browser Compatibility Considerations

It's worth noting that Chrome is particularly strict about this type of certificate validation, while browsers like Firefox Developer Edition may behave differently. During development, temporarily switching to alternative browsers for testing presents a viable workaround when time is limited.

Best Practice Recommendations

To ensure certificates work properly across all modern browsers, it is recommended to:

Always include Subject Alternative Names extensions in certificates
Set the main domain in both Common Name and SAN
Use explicit domain name lists rather than relying solely on wildcards
Regularly update certificates and test compatibility across different browsers

Implementation Steps Summary

The complete certificate creation and deployment process encompasses four key phases: configuration file preparation, certificate generation, system import, and browser configuration. By following the guidance above, developers can effectively resolve the NET::ERR_CERT_COMMON_NAME_INVALID error and ensure proper operation of HTTPS services in local development environments.

Copyright Notice: All rights in this article are reserved by the operators of DevGex. Reasonable sharing and citation are welcome; any reproduction, excerpting, or re-publication without prior permission is prohibited.