Keywords: Self-Signed SSL Certificate | Subject Alternative Name | Chrome Compatibility | OpenSSL Configuration | SAN Extension
Abstract: This article provides an in-depth analysis of the NET::ERR_CERT_COMMON_NAME_INVALID error caused by missing Subject Alternative Name extensions in self-signed SSL certificates. Through OpenSSL configuration examples and step-by-step instructions, it demonstrates how to properly generate self-signed certificates with SAN extensions to ensure compatibility with modern browsers. The discussion covers RFC 2818 deprecation of CN fields and recommends practical scripting tools.
Problem Background
Starting with Chrome version 58, browsers began enforcing the requirement for SSL certificates to include Subject Alternative Name (SAN) extensions, no longer falling back to Common Name (CN) field matching. When self-signed certificates lack SAN extensions, Chrome displays "Subject Alternative Name Missing" warnings and throws NET::ERR_CERT_COMMON_NAME_INVALID errors, marking websites as insecure.
Technical Principles
According to RFC 2818 standards, reliance on CN fields for domain validation has been deprecated since May 2000. SAN extensions provide a more flexible domain identification mechanism, supporting multiple DNS names and IP addresses. OpenSSL uses x509v3 configuration files to add these extension properties, with the subjectAltName field specifying valid domain names for the certificate.
Solution Approach
When generating certificates with OpenSSL, the -extfile parameter must be added to specify extension configuration files. Create a file named v3.ext with the following content:
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = %%DOMAIN%%Replace %%DOMAIN%% with the actual domain name, typically matching the CN field. Certificate generation command example:
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout server.key -out server.crt -sha256 -extfile v3.extComplete Configuration Example
An alternative approach uses comprehensive OpenSSL configuration files, integrating certificate parameters and extension settings in a single file:
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = US
ST = State
L = City
O = Organization
OU = Department
CN = www.example.com
[v3_req]
keyUsage = critical, digitalSignature, keyAgreement
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = www.example.com
DNS.2 = example.comGenerate certificates using this configuration:
openssl req -x509 -nodes -days 730 -newkey rsa:2048 -keyout cert.key -out cert.pem -config req.cnf -sha256Practical Tool Recommendations
For developers requiring frequent self-signed certificate generation, specialized tools can streamline the process:
- self-signed-ssl script: Provides interactive command-line interface with automatic SAN field configuration
- cfssl: Certificate generation tool developed by Cloudflare, supporting complex certificate policies
- mkcert: Tool specifically designed for local development, automatically generating trusted local certificates
Important Considerations
After generating new certificates, Chrome browser must be restarted for changes to take effect. Quick restart can be achieved by visiting chrome://restart. While command-line parameters can disable SSL error checking, this reduces security and is not recommended for production environments.