The newest version of Google Chrome 58 requires that certificates specify the hostname(s) to which they apply in the SubjectAltName field. The error, Security certificate does not specify subject alternative names trigger if the certificate does not have the correct SubjectAlternativeName extension.

As part of our Server Management Services, we assist our customers with several such errors.

Today, let us see an effective way to fix this error.

Subject Alternative Name

The Subject Alternative Name field helps to specify additional hostnames to be protected by a single SSL Certificate.

This extension was a part of the X509 certificate standard before 1999. However, it wasn’t in use until the launch of Microsoft Exchange Server 2007.

Now Subject Alternative Names are widely in use for environments or platforms that need to secure multiple sites across different domains/subdomains.

We can find Subject Alternative Names in the address bar. Click the padlock in the browser to examine the SSL Certificate. In the certificate details, we will find a Subject Alternative Name extension.

What to do with Subject Alternative Names?

• Secure Host Names on Different Base Domains in One SSL Certificate:

A Wildcard Certificate can protect all first-level subdomains on an entire domain. Whereas Subject Alternative Names can protect both www.example.com and www.example.net.

• Virtual Host Multiple SSL Sites on a Single IP Address:

Hosting multiple SSL-enabled sites on a single server typically requires a unique IP address per site. However, a Multi-Domain (SAN) Certificate with Subject Alternative Names solves this problem.

• Greatly Simplify Your Server’s SSL Configuration:

A Multi-Domain (SAN) Certificate saves us the hassle and time involved in configuring multiple IP addresses on the server, binding each IP address to a different certificate, and trying to piece it all together.

Solution for Security certificate does not specify subject alternative names

• In order to solve the SubjectAltNames issue, we edit the file:

C:\wamp64\bin\apache\apache2.4.27\conf\openssl.cnf

Under [ Req ] section
uncommented: req_extensions = v3_req

Under [ v3_req ] section
Added: extendedKeyUsage = serverAuth
Added: subjectAltName = @alt_names

Under [ v3_ca ] section
Added: subjectAltName = @alt_names

Added new section [ alt_names ] at the bottom of the file
[ alt_names ]
DNS.1 = %domain%

Then we reload the new certificate into the Trusted Root Certification Authorities Store.

• Supply an extra parameter to openssl when we create the cert,

-sha256 -extfile v3.ext

Here, v3.ext is a file with %%DOMAIN%% replaced with the same name we use as the Common Name.

Typically we will set the Common Name and %%DOMAIN%% to the domain we are trying to generate a cert for. So if it was www.example.com, then we have to use that for both.

v3.ext

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = %%DOMAIN%%

• Regenerate the certificate to include a Subject Alternative Name.

To fix the error for Chrome users, we have to regenerate the certificate. To do that we can use the Certificates MMC when we have an internal Certification Authority (CA).

1. From the webserver, open MMC and add the Certificates snap-in, managing the Computer account.
2. Then expand Certificates (Local Computer) > Personal > (right-click) Certificates > All Tasks > Request New Certificate.
3. Then choose Active Directory Enrollment Policy to use the existing internal CA.
4. Select the Web Server certificate template and click the link below it to enter more information.
5. Add the Common Name for the Subject Name, and the DNS name for the Alternative Name.
6. Enter a Friendly Name on the General tab.
7. Optionally, make the private key exportable on the Private Key tab and click OK.
8. Then click Enroll to generate the new cert from the CA and install it on the webserver.
9. The certificate will be installed. Click Details to view the new certificate.
10. On the Details tab, we see the Subject Alternative Name is on the new cert.

Now we configure IIS to use the new certificate or reconfigure Exchange web services using the Enable-ExchangeCertificate cmdlet.

• Disable the checking of SubjectAlternativeName in Chrome.

This is a work-around that will not function beyond version 65 of Google Chrome. Our Support Techs recommend using this method as a temporary fix.

By adding the following setting, Chrome can force to allow certificates that are missing the SubjectAlternativeName extension:

Windows registry (REG_DWORD):
Software\Policies\Google\Chrome\EnableCommonNameFallbackForLocalAnchors

We can add a registry key to Windows by entering the following at the Command Prompt:

reg add HKLM\Software\Policies\Google\Chrome /v EnableCommonNameFallbackForLocalAnchors /t REG_DWORD /d 1

When we enable this setting, Google Chrome will use the Common Name of a server certificate to match a hostname if the certificate is missing a SubjectAlternativeName extension, as long as it successfully validates and chains to a locally-installed CA certificate.

[The error continues to prevail? We can help you]

Conclusion

To conclude, the error, Security certificate does not specify subject alternative names trigger if the certificate does not have the correct SubjectAlternativeName extension. Today we saw how our Support Techs fix this.