Devart Forums

Thanks for the fix.

Any timelines on when this version will be out of beta and released? We are currently working with tight schedules and won't be able to test this beta release.

Hi Shalex,

Just wondering if there is any more information?

Thanks for the update.

Can you tell us about the exact nature of the issues that you have discovered on Windows 7 so that we can analyze if it impacts us?

Also are you implying that the Windows CryptoAPIs themselves are broken on Windows 7? I would assume that if the drivers are using standard windows API, they should work just like any other application. Right?

Do you have a time frame for fixing the Windows 7 problem that you mentioned? Once you make that fix available, I will test all the scenarios again with that version and report the results. It is not that easy and cost effective for us to try the test cases again.

Thanks.

Tried and it works with build 5.80.170. Thanks.

Shalex wrote:Actually, the mentioned fix is included to the 5.80.170 build (it is with the IIS fix and with the Windows 7 problem). It is available for download.

I don't understand. We have tested with version 5.80.170 and found the same problem. Are you saying that you have fixed the code and created another distributable with the same version or that 5.80.170 that we already have should have this fix?

Thanks for the update

Interesting... I will try it again on 5.80.170 version. I think I tried 5.20.x when we saw this issue.

Any updates?

I have opened another almost similar topic that does not concern client certs here http://www.devart.com/forums/viewtopic. ... 1672#61672

I have tried this with the latest version of the drivers and an older version and the problem exists in all the versions...

Steps:

PREPARATION:
1. Configure db server to require SSL
2. Create two client applications that connect to the database and execute some query, one that runs as a Windows Service (LOCAL SYSTEM user account) and the other that runs as a web application (ASPNET user account on XP and Network Service user account on Win2k3)
3. The connection string just needs to use Protocol=Ssl. There is no need to specify a CA-Cert or client certs.

CASE 1: FAILS
1. Take an XP machine and go to your "C:\Documents and Settings\All
Users\Application Data\Microsoft\Crypto\RSA\MachineKeys" folder and delete all files from there.
2. Start the Windows Service first. After a db connection is made, a new file (let's call is "x") is created in the machinekeys folder.
3. Start the web application and notice the connection problems.
Cause: The web application tries to read the "x" file and has not access on it. It then tries to create a file under it's own user profile (ASPNET user's profile) but fails because it picks the wrong folder location to do so.

It tries to create the file "x" under the following folder that does not exist:
C:\Documents and Settings\ASPNET\Application Data\Microsoft\Crypto\RSA\

The correct path should be:
C:\Documents and Settings\\ASPNET\Application Data\Microsoft\Crypto\RSA\


CASE 2: PASS
1. Take a Windows 2k3 machine and go to your "C:\Documents and Settings\All
Users\Application Data\Microsoft\Crypto\RSA\MachineKeys" folder and delete all files from there.
2. Start the Windows Service first. After a db connection is made, a new file (let's call is "x") is created in the machinekeys folder.
3. Start the web application and notice the connection passes.
Cause: The web application tries to read the "x" file and has not access on it. It then tries to create a file under it's own user profile (Network Service user's profile) and succeeds.

It tries to create the file "x" under the following folder that does not exist:
C:\Documents and Settings\NetworkService\Application Data\Microsoft\Crypto\RSA\

--------

We need a resolution to this behavior in next few weeks because he offer Ssl connectivity to the database and our product has windows services and web clients that run on the same machine.

Thanks.

Is there more information on this behavior? Are you guys still looking at this?

Shalex wrote:I have opened the SSL connection without specifying SSL Cipher List using the 6.0.10 version of dotConnect for MySQL and obtained the "AES256-SHA" value.

Sorry for the confusion, it shows AES256-SHA to me as well. The other cipher is what I see when I connect using SqlYog.

The same exact behavior exists in 5.80 and 6.0.10 beta version of your drivers.

We need a solution to this problem soon.

I will try it out shortly and let you guys know and we have not tried using the certificates as compiled resources since that is not an option for us.