It appears that the discussed configuration makes the server incorrectly pick a DH-driven cipher suite even though it does not have a DH certificate. This leads to further errors during SSL key material negotiation and to fatal handshake failure in the end. We have fixed the problem; the fix is undertaking its QA assessment at the moment, and will be included to the future SecureBlackbox update.

In the mean time, please switch off DH- and ECDH-driven cipher suites (SB_SUITE_DH_..., SB_SUITE_ECDH_...) on the server manually to overcome the problem. This won't affect the functionality of the server at all, as those suites can only be used if your server has DH or ECDH certificate installed.

It is also a good idea to switch off SRP and PSK suites if you do not plan to use them explicitly.

Thank you for reporting the problem. We are sorry for the inconvenience it might have caused you.

I'm not sure what is happening now, but I think it is related to this issue:

If I enable the (EC)DHE ciphers and give them a high prioriy (5) a connection is established from the client. So this seems to work now.

This is without requiring a client certificate. But if I require a client certificate (SSLClientAuthentication = True and a CertificateValidate function that Always sets Validate := True) the connection fails on the server with error 75778 ERROR_SSL_BAD_RECORD_MAC.

We use cookies to help provide you with the best possible online experience. By using this site, you agree that we may store and access cookies on your device. You can find out more about and set your own preferences here.