Hi,
My customer has try to use SAN certificate on AM to replace standard one. Importation was ok but the activation step lead to the following issue.
Their SAN certificate is composed of 3 DNS références including the real name of the host himself but it doesn't work
AM is it compliant with SAN certfificates ?
Thanks in advance for your help.
Have a nice day.
Anthony
Thank you Jeff,
Next time, I will post my question in the right topic.
Sorry.
RSA Auth Manager console certs must be one name, the FQDN of the RSA server. No cnames, no alternates, no wildcards. It is not that we do not accept SAN certs per se, but SAN information won't work. The RSA Auth Manager Server can only be identified, or identify itself, by one name. When you change those certificates, internal components will restart and look at the cert, and it if doesn't match the RSA server name in any way, it won't start up correctly.
The Subject Alternative Name field lets you specify additional host names (sites, IP addresses, common names, etc.) to be protected by a single SSL Certificate, such as a Multi-Domain (SAN) or Extend Validation Multi-Domain Certificate.
The default RSA signed Certs do not have anything in this SAN field, basically for the reasons Ed explained, but
New versions of Chrome (v.58) and FireFox check the Subject Alternate Name field, and if blank (as RSA has in AM) the browser now considers this an un-trusted site.* Details below.
There's an RFE in JIRA, AM-31165 - AM 8.2 Cert Signing Requests, CSRs have empty Subject Alternate Name fields, which Chrome/FF no longer trust,
asking if we Can we add FQDN to the Subject Alternate Name, SAN field in our CSRs.
One option would be to replace RSA self-signed Cert with CA signed, and tell CA to include just the FQDN in the SAN field, same as in the Subject field. This would not help quick setup.
* DETAILS: There is a a work-around to disable this check, but is only good for a year or until Chrome v.65 comes out
https://www.chromium.org/administrators/policy-list-3#EnableCommonNameFallbackForLocalAnchors
Description:
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.
Thank you Jay, so if I well understood the SAN fields are only used for browser expectations and not for unique SSL certificate.
I think so. My first experience with SAN was what Ed described, it was used to add alternate and wildcard names to a Cert, which is common in our new SID Access Identity Router, IDR, which will host multiple web servicers with different names under one domain, e.g. https://concur.rsalab.com, https://sfrsalab.com, https://ibot.rsalab.com - but the Authentication Manager world always shunned wildcard certs, because we were a security device and consider sharing the certificate as insecure. So we never bothered to put anything in the SAN field.
Now 20 years later it is considered unsafe to accept a Certificate where the SAN does not match to the FQDN, so of course our empty SAN field does not match any FQDN. So I think you are correct, the SAN is used for browser expectations, but those expectations are now becoming a security standard.
Thanks Jay, it's crystal clear !
Many Thanks Edward for your explanations.
Hi Anthony,
I have moved this thread to the RSA SecurID Access so that you can get an answer to your question.
You can post future questions and discussions directly to that community by clicking on the Ask a Question or Start a Discussion button on the RSA SecurID Access page.
Thanks,
Jeff