Console and web tier virtual host certificates no longer trusted by Google Chrome 58.0.3029.81 in RSA Authentication Manager 8.x
4 years ago
Originally Published: 2017-07-05
Article Number
000063660
Applies To
RSA Product Set: SecurID
RSA Product/Service Type: Authentication Manager
RSA Version/Condition: 8.x
Issue
With the latest update of Google Chrome 58 (58.0.3029.81), customers report certificate errors from RSA Authentication Manager when accessing the Security Console, Operations Console and Virtual Host Web Tiers. Both internal site RSA self-signed certificates and external or public CA-signed replacement certificates are affected. The error is:
 
Your connection is not private
This server could not prove that it is <FQDN>: its security certificate is from [missing_subjectAltName]
NET::ERR_CERT_COMMON_NAME_INVALID
This may be caused by a misconfiguration or an attacker intercepting your connection
 
Common Name Invalid
Cause
The RSA Authentication Manager Security Console, Operations Console and Virtual Host certificates do not have a Subject Alternative Name (SAN), like the one pictured in the certificate below

SAN field

New versions of Chrome (Chrome 58) and Firefox check the Subject Alternative Name (SAN) field, looking for a DNS name or IP address.  Historically, Authentication Manager has never used this field in our certificates because it was not required and it is sometimes used for a wildcard certificate (i. e., *.company.com), which is not supported by Authentication Manager and would break an Authentication Manager server.  

The Authentication Manager server consoles and web tiers bind a Fully Qualified Domain Name (FQDN) of the Authentication Manager server to the Common Name or CN in the Subject field.
 
CN=FQDN
 
The problem is that Chrome now looks for a DNS name in the SAN field to match the Common Name in the Subject field, but Authentication Manager has not used the SAN field before, even in our replacement certificates.  The Authentication Manager Operations Console generated Certificate Signing Request (CSR) for a replacement console or virtual host certificate currently has no way to enter a SAN.  

Defect AM-31165 (Authentication Manager 8.2 CSRs have empty Subject Alternative Name fields which Chrome/FF no longer trust) has been raised for this issue.
Resolution
There are at least three options for this problem;
  1. Disable the Chrome policy that checks for a SAN, which will not work after 2017.  See the Workaround below.
  2. Use a third party tool or your Certificate Authority to generate a CSR that includes a DNS entry in the SAN field or use the CSR generated in the Authentication Manager Operations Console, but request that your CA sign the reply with a DNS entry in the SAN field.
  3. Upgrade to Authentication Manager 8.3 or higher.  This addresses both self-signed internal RSA console certificates and virtual  host certificates, as well as CSRs.
Workaround
There is a a workaround to disable this check, but is only good for a year or until Chrome 65 comes out.  See The Chromium Projects' Policy List regarding EnableCommonNameFallbackForLocalAnchors

The descriptions is as follows:
When this setting is enabled, Google Chrome will use the commonName 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 certificates.
 
Note that this is not recommended, as this may allow bypassing the nameConstraints extension that restricts the hostnames that a given certificate can be authorized for.
 
If this policy is not set, or is set to false, server certificates that lack a subjectAlternativeName extension containing either a DNS name or IP address will not be trusted.

Related Articles

Trending Articles

Don't see what you're looking for?