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

Document created by RSA Customer Support Employee on Jul 13, 2017
Version 1Show 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, customers report certificate errors from Authentication Manager when accessing the Security Console, Operations Console and Virtual Host Web Tiers. Both internal siteRSA 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
 
CauseRSA 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 (v.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 ID 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 SAN, which will not work next year in 2018 - 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. Wait for an RSA bug fix to AM-31165.  This fix should address both self-signed internal RSA console and virtual  host certificates as well as CSRs.
WorkaroundThere is a a work-around 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