|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]
This may be caused by a misconfiguration or an attacker intercepting your connection
|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|
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.
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;|
|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.