|Applies To||RSA Product Set: SecurID Access|
RSA Product/Service Type: Identity Router
RSA Version/Condition: All
|Issue||A website scanning tool used to check site security, may report "Certificate cannot be trusted" for the Portal even though all of the following are true:|
|Cause||The Certificate Chain uploaded to the Company Settings page of the Cloud Administration Console, does not include the intermediate CA certificate(s).|
A trace of a web browser accessing the Portal login page will show that the Portal's server certificate is being downloaded during the TLS handshake without the intermediate CA(s). Even though, strictly speaking, this is incorrect according to the TLS standard (for example, TLS 1.2), modern browsers tend to be a bit tolerant of such errors, provided they have the signing intermediate CA's certificate in their trust store. Therefore, most web browsers will be able to access the Portal without warning, even when intermediate CA certificates are not included in the Certificate Chain configuration, under Company Settings on the Cloud Administration Console.
However, as this is incorrect according to the TLS standard, a website security scanner that applies strict TLS requirements will report the server certificate as untrusted.
For example, using Chrome to access the Portal login screen will show no warnings, if it is able to find the first Intermediate CA of the chain, in its local trust store. To confirm, you can disable that intermediate CA certificate in the trust store and Chrome will then report the error: NET::ERR_CERT_INVALID when you access the Portal login page. Enable the certificate again, and the error will no longer occur.
|Resolution||Upload the full intermediate CA chain to the Company Information page of the Cloud Administration Console.|
Instructions for uploading the Certificate Chain for the Portal are in the online help on page Configure Company Information and Certificates. To fix this issue, you do not need to also upload the server certificate and private key files however, as they would be unchanged. The new Certificate Chain must include all intermediate CA certificates, in the correct chain order. The root CA certificate should be last.
If you do not already have the full certificate chain available in a file, the intermediate CA cert(s) can be easily added to the existing CA root certificate, using Windows Notepad, or a similar text editor. The certificates must all be in PEM format, which is a block of ASCII Base64 characters, prefixed by a -----BEGIN CERTIFICATE----- line and followed by an -----END CERTIFICATE----- line. You can check that by opening the certificate files with a text editor such as Notepad. You must insert the intermediate CA certificate(s) in the correct chain order, immediately before the root CA's certificate in the file. The certificate blocks must appear one after the other, with no blank lines between each certificate's -----END CERTIFICATE----- line, and the next certificate's -----BEGIN CERTIFICATE----- line.
Once you have done that, on Microsoft Windows you can check there were no errors introduced during editing, by renaming the file to have a .cer suffix (if it doesn't have that suffix already), then double-clicking it in Windows File Explorer. If the format is correct, Windows will open a properties-style window that shows the first intermediate CA certificates' details, and the Certification path tab will allow you to switch to checking any other intermediate CA's in the chain, and the root CA certificate's details as well.
If you don't already have the intermediate CAs' certificates, you can get it/them from the Portal website using a browser. The steps in Google Chrome (as of version 63) are:
|Notes||For example, the PEM chain file for a certificate signed by a CA using two intermediate certificates would look something like:|
If in doubt as to the order in which certificates were signed, the certificates can be examined (ensure they have a .cer suffix then double click in Windows) and the subject and issuing fields inspected. The issuing field of the certificate will match the subject field of the certificate which signed it. Root CA certificates will be self-signed, meaning the issuing and subject fields will match. As stated by the TLS standard,
Each following certificate MUST directly certify the one preceding it. (IETF RFC 5246 on TLS 1.2).