Last month I updated a clients site to be secure as standard. No problems whatsoever however this week (05/10 @ approx 10am) I started receiving exceptions detailing the following:
System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm
My connection string to my AWS MySQL RDS had included, since the beginning of time the SSLMode=Required.
I spend an age attempting to unpick what the root cause of this was, and in the end set the SSLMode on the database to none.
The only conclusion I arrive at is that there is conflict between the SSL cert on the website, and forcing my MySQL connection SSLMode Required.
I've updated the website to .net 4.6.* to no avail....
Any thoughts or suggestions welcomed....
I'm using: MySQL Connector, AWS MySQL 5.6, .net 4.6
Inner Exception:
System.Data.Entity.Core.ProviderIncompatibleException: An error occurred accessing the database. This usually means that the connection to the database failed. Check that the connection string is correct and that the appropriate DbContext constructor is being used to specify it or find it in the application's config file. See http://go.microsoft.com/fwlink/?LinkId=386386 for information on DbContext and connections. See the inner exception for details of the failure. ---> System.Data.Entity.Core.ProviderIncompatibleException: The provider did not return a ProviderManifestToken string. ---> System.Security.Authentication.AuthenticationException: A call to SSPI failed, see inner exception. ---> System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm
--- End of inner exception stack trace ---
at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)
at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
Please note that I don't have any clue regarding MySQL Connector or AWS. Having said this, I am making a guess:
From the error message, we eventually can conclude that the client and the server could not agree on a cipher suite. In case you didn't hear about that subject yet:
SSL is a protocol which can use a great number of different key exchange, encryption and MAC algorithms. A certain tuple of (key exchange, encryption, MAC) algorithms (methods) is called a cipher suite. When an SSL connection is being established, the server and the client need to agree on a certain cipher suite which will be used to exchange keys, encrypt and authenticate the connection.
The rationale behind this is that new, more secure ciphers can be easily introduced and used without changing the SSL specification itself, and that old, insecure, broken ciphers can be removed easily without changing the SSL specification itself.
This means that the owner of a server can say: "I offer SSL to my clients, but only with cipher suites X, Y and Z". If a client tries to connect, but only supports cipher suites A, B and C, the connection will fail.
Now, from time to time, a cipher suite becomes deprecated because it is considered unsafe. In such cases, that cipher suite often is silently disabled by security updates the O/S receives, and this is what might have happened to you:
When the server has been updated, one or more of the SSL cipher suites might have been disabled, either by updates to MySQL or by updates to the O/S itself or the libraries which provide cryptographic services to applications. This could have lead to a situation where you (the client) and the server do not have a common cipher suite any more.
It is also possible that somebody has disabled certain cipher suites on the server by intention (i.e. manually, i.e. not as "collateral damage" from installing updates).
Furthermore, it could be the opposite situation: If you have installed updates on your machine (client) or have disabled certain cipher suites, your client and the server might not being able to connect any more.
To determine how to debug this, we need to know a lot more about your configuration. One general tip, though:
During the SSL handshake, the client sends a hello to the server and vice versa. Client and server in this hello present a list of cipher suites they support. Since the client and server hello are not encrypted, you can easily sniff them using tools like Wireshark. Then you can compare the list of cipher suites the client and the server support and check if there is at least one common cipher suite.
If there isn't, you probably have found the problem. In that case, you have to change the configuration either at the client or the server side so that the client and the server have at least one common cipher suite again. Please come back if you need help in doing this, but please first analyze the situation like proposed above.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With