000035338 - Console and web tier virtual host certificates no longer trusted by Google Chrome 58.0.3029.81 in RSA Authentication Manager 8.x

Document created by RSA Customer Support Employee on Jul 13, 2017Last modified by RSA Customer Support on May 14, 2019
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000035338
Applies ToRSA Product Set: SecurID
RSA Product/Service Type: Authentication Manager
RSA Version/Condition: 8.x
IssueWith 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
CauseThe 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.
ResolutionThere 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.
WorkaroundThere 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.

Attachments

    Outcomes