OneView Directory Login Issue since update

[SteveSC]

Hello

Since our OneView was updated from 3.00.05 to 4.00.07.02. we have been unable to login with our AD accounts. Only the local login can be used to access OneView.

When trying to login we get the error message:

"Unable to establish trusted communication with the server. The directory server certificates signature algorithm is not supported by OneView in the current security mode. Refer to OneView and directory server user documentations to know more about the certificate signature algorithms supported by each system in the various security modes. Set up the directory server with a certificate having signature algorithm that is supported by OneView in its current security mode. After setting up the directory server with the certificate as specified, add the directory server certificate into the OneView."

The certificates in use for our directory servers are been used on another OneView server without an issues at the moment so it is odd we have encountered this issue since the upgrade.

I have been able to re-add the certificates using the "Paste Certificate" option but not when using "Add certificate from an IP address or hostname". When I try that option I get

"Secure connection to the device or server failed because the connection could not be negotiated at the desired level of security. 

HANDSHAKE_FAILED_DETAILS

Resolution Check if the device or server is compliant with the appliance cryptography mode."

I had read that the root and intermediate certificates should be present but when using  "Paste Certificate" for these I get 

"Signature algorithm of the certificate is not supported. 

Signature algorithm of the certificate is not in the allowed range.

Resolution provide a certificate that has a valid signature algorithm and try again."

The signature algorithm for the root and intermediate are RSASSA which I have found may be an issue in general looking at "https://pkisolutions.com/pkcs1v2-1rsassa-pss/" but are ticking the "force trust leaf certificate so I would presume the root and intermediate would not matter unless them using RSASSA has caused an issue for the directory certificates.

Any advice anyone can be offered would be greatly appreciated.

[BhaskarV]

 Hi SteveSC - 

Can you share the signature algorithm that is on the certificate (certificate chain) that you are using?
We'll be able to tell if that is a problem.
I would have expected both the Copy/paste versus the "fetch from IP address/hostname" to be consistent with the same error.
If you can open a support case with a support dump that would be helpful for us to figure out what is going on.

[BhaskarV]

Hi SteveSC

Seems like you already shared that the signature algorithm being used is RSASSA-PSS and you had shared the link to 
https://pkisolutions.com/pkcs1v2-1rsassa-pss/
We'll research this on why we fail on this signature at connection handshake time. 
To unblock, at the very least you may need to get the leaf level AD certificate reissued as suggested by the article.
i.e.  If an application rejects an end-entity certificate due to the RSASSA-PSS encoding, then the certificate will need to be reissued. This can be turned off on the template that is being used to issue the certificate.
So the CA template that issued the AD certificate in your case probably has the additional / extra attribute set. 
You may then want to make use of force trust leaf certificate for the moment instead of having to reissue everything all the way from the topmost RootCA down to the leaf level AD certificate.
Do open a support case on this so we can track this.

[BhaskarV]

For now, to unblock yourselves, you may want to move away from using RSASSA-PSS for the Root, intermediate and the leaf level AD server certificate. Do open a support case on this.