Symantec ProxySG: Error: NET::ERR_CERT_COMMON_NAME_INVALID when accessing secure web sites via ProxySG or ASG

Affected Products

Chrome browser version 58 and later, and:

• accessing secure websites hosted behind a ProxySG (reverse proxy)
• or accessing other websites through a ProxySG or ASG where redirect-mode authentication is performed over SSL
• or accessing the management console, via any version of the ProxySG or Advanced Secure Gateway (ASG).

Overview

The latest versions of Google’s Chrome browser introduces a much stricter interpretation and implementation of paragraph 3.1 of RFC2818, dealing with Server Identity in the context of HTTP over TLS. This may cause Chrome to present users with a connection-security warning page in a number of situations as noted above.

Although the RFC document doesn’t formally prohibit the use of Common Names in the Subject field of certificates for the purposes of a server’s identification, use of the Subject Alternative Name (subjectAltName or SAN) extension for this purpose is cited as being preferred.

Error Message

When accessing a site noted in the situation above, a user will see an error/warning page such as the one below with error:

NET::ERR_CERT_COMMON_NAME_INVALID

The following solution details steps to create a CSR with the SAN extension using a Microsoft web server and on UNIX or Linux systems.

The management console or CLI currently does not provide an option to generate a CSR that includes the SAN extension.

The steps listed therefore only apply in the following situations:

• Where the ProxySG or ASG acts as a reverse-proxy, and the CSR is generated on the web server behind the ProxySG or ASG.
• If the certificate-signing tool used to sign a CSR provides for the addition of the SubjectAltName extension, where a CSR is submitted on behalf of the ProxySG or ASG. For example, for the purposes of creating a keyring that is used in the HTTPS management-console.

Disclaimer:

If help is needed using Microsoft Server for this task, contact Microsoft Support.

Using a Microsoft Server

1. Since the default web server certificate template populates the Subject Name data in the certificate from the fields included in the CSR, a new certificate template must first be created. To create the new template, right-click the default template in the list from Active Directory Certificate Services console, and click Duplicate. Here is an example of a modified template:
   
2. Once the template has been created and saved, a certificate for the web server must be created using the MMC snap-in. Note that in this instance, the snap-in must be added to the default console under the Local Computer account:
   
3. Once the MMC is loaded, right-click the Personal container, then All Tasks > Request New Certificate > Next > Next, which should present you with the Certificate Enrollment dialog window:
   
4. Select the corresponding box for the new template created earlier, click Details > Properties.  This displays the Certificate Properties dialog window:
   
5. After filling out a name and description, navigate to the Subject tab, select DNS from the Alternative name drop-down, and enter a relevant hostname for the website in the Value field:
   

   

6. Click Apply, and then fill out or select all other relevant options for the certificate in the remaining tabs (your exact requirements may vary). Details on exporting the certificate and associated private-keys are documented.

Using a Linux server with OpenSSL

The following is an example which should work in the majority of configurations:

$ openssl req -new -sha256 -key domain.key -subj “/C=US/ST=CA/O=Acme, Inc./CN=example.com” -reqexts SAN -extensions SAN -config <(cat /etc/ssl/openssl.cnf <(printf “[SAN]\nsubjectAltName=DNS:example.com,DNS:www.example.com”)) -out domain.csr

Note: The above command should be entered as a single line