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.
Here at Ibmi Media, as part of our Server Management Services, we regularly help our Customers to fix SSL Certificate related errors.
In this context, we shall look into the causes and fixes to this error.
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.
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.
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.
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.
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 do that we can use the Certificates MMC when we have an internal Certification Authority (CA).
i. From the webserver, open MMC and add the Certificates snap-in, managing the Computer account.
ii. Then expand Certificates (Local Computer) > Personal > (right-click) Certificates > All Tasks > Request New Certificate.
iii. Then choose Active Directory Enrollment Policy to use the existing internal CA.
iv. Select the Web Server certificate template and click the link below it to enter more information.
v. Add the Common Name for the Subject Name, and the DNS name for the Alternative Name.
vi. Enter a Friendly Name on the General tab.
vii. Optionally, make the private key exportable on the Private Key tab and click OK.
viii. Then click Enroll to generate the new cert from the CA and install it on the webserver.
ix. The certificate will be installed. Click Details to view the new certificate.
x. On the Details tab, we see the Subject Alternative Name is on the new cert.
xi. Now we configure IIS to use the new certificate or reconfigure Exchange web services using the Enable-ExchangeCertificate cmdlet.
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.
This article will guide you on steps to fix #Security certificate does not specify subject alternative names.
Basically, the #error, Security certificate does not specify subject alternative names trigger if the certificate does not have the correct SubjectAlternativeName extension.
Subject Alternative Names or SANs allow you to secure multiple domains from one SAN SSL certificate. SANs are additional domain names added to an SSL certificate.
To add a Subject Alternative Name to a certificate:
1. If you want to add #SAN, most CAs allow you to reissue a certificate with new details, though this will usually revoke your old certificate.
2. You don't need the old CSR to reissue a certificate, you can instead create a new CSR with the updated details using a new or existing private key.
The Subject Alternative Name (#SAN) is an extension to the X. 509 specification that allows users to specify additional host names for a single SSL certificate. The use of the SAN extension is standard practice for #SSL #certificates, and it's on its way to replacing the use of the common name.