Devart Forums

We have a MySQL 5.0.86 database setup for SSL. The database user that we have is setup with "REQUIRE X509" option. From the client side, we are constructing the connection string using the certificate and the key files in pem format generated using OpenSSL.

The driver version is CoreLab.MySql v3.55.17

The connection string looks like this:
User Id=user;Password=pwd;Host=dbHost;Port=3306;Database=dbName;Direct=True;Unicode=True;Protocol=Ssl;Pooling=True;Connection Lifetime=1800;SSL CA Cert="file://C:\newcerts\ca-cert.pem";SSL Cert="file://C:\newcerts\client-cert.pem";SSL Key="file://C:\newcerts\client-key.pem";

We are able to make a connection from the windows desktop client (c# .net 3.5) but we cannot connect to the database from the web application.

If we run as the default process identity ASPNET (or Network Service), we receive the following exception:
CryptographicException: Couldn't acquire crypto service provider context.
at CoreLab.Cryptography.e.a(Int32& A_0, String A_1)
at CoreLab.Cryptography.e.a()
at CoreLab.Security.j.a(Byte[] A_0)
at CoreLab.Security.j.f(String A_0)
at CoreLab.MySql.j.a(String A_0, String A_1)
at CoreLab.MySql.b.a(String A_0, String A_1, String A_2, String A_3, Int32 A_4, String A_5, Int32 A_6, SshOptions A_7, SslOptions A_8)
at CoreLab.MySql.MySqlInternalConnection.Connect(String userId, String password, String host, String database, Int32 port, Int32 connectionTimeout, MySqlProtocol protocol, Boolean compress)
at CoreLab.MySql.MySqlInternalConnection..ctor(ac connectionOptions)
at CoreLab.MySql.a7.a(DbConnectionOptions A_0, Object A_1, DbConnectionBase A_2)
at CoreLab.Common.DbConnectionFactory.a(DbConnectionPool A_0, DbConnectionOptions A_1)
at CoreLab.Common.DbConnectionPoolGroup.c(DbConnectionPool A_0)
at CoreLab.Common.DbConnectionPool.a()
at CoreLab.Common.DbConnectionPool.GetObject()
at CoreLab.Common.DbConnectionFactory.a(DbConnectionBase A_0)
at CoreLab.Common.DbConnectionClosed.Open(DbConnectionBase outerConnection)
at CoreLab.Common.DbConnectionBase.Open()
at CoreLab.MySql.MySqlConnection.Open()

If we run the application as a higher privileged user (Local System), we get the following exception:
Lost connection to MySQL server during query
at CoreLab.MySql.a0.c(Byte[] A_0, Int32 A_1, Int32 A_2)
at CoreLab.MySql.a0.j()
at CoreLab.MySql.b.a(String A_0, String A_1, String A_2, String A_3, Int32 A_4, String A_5, Int32 A_6, SshOptions A_7, SslOptions A_8)
at CoreLab.MySql.MySqlInternalConnection.Connect(String userId, String password, String host, String database, Int32 port, Int32 connectionTimeout, MySqlProtocol protocol, Boolean compress)
at CoreLab.MySql.MySqlInternalConnection..ctor(ac connectionOptions)
at CoreLab.MySql.a7.a(DbConnectionOptions A_0, Object A_1, DbConnectionBase A_2)
at CoreLab.Common.DbConnectionFactory.a(DbConnectionPool A_0, DbConnectionOptions A_1)
at CoreLab.Common.DbConnectionPoolGroup.c(DbConnectionPool A_0)
at CoreLab.Common.DbConnectionPool.a()
at CoreLab.Common.DbConnectionPool.GetObject()
at CoreLab.Common.DbConnectionFactory.a(DbConnectionBase A_0)
at CoreLab.Common.DbConnectionClosed.Open(DbConnectionBase outerConnection)
at CoreLab.Common.DbConnectionBase.Open()
at CoreLab.MySql.MySqlConnection.Open()

I have tried to grant "Everyone" access to the certificate files (including client-key.pem) and still it does not work but if we run the web process as a user who is an admin on the machine, it works.

Please let me know what kind of access is required by the Corelab drivers when trying to read and process the certificate key so that we can fix it.

Thanks.

Could you please try granting access to your web account or to "Everyone" for the whole folder of your web application (not in IIS but for the actual folder)? Notify us about the results.

The web account user already has required access on the folder that the virtual application maps to.

Any other thoughts?

Just for testing purpose, when I use the new version of drivers (v 5.50.79) on IIS 7.5 (Windows 7 running as Local Service, Local System, Network Service or AppPoolId), I get the following error.

SSL connection error (2026): Could not acquire private key. at Devart.Data.MySql.v.a(String A_0, String A_1, String A_2, String A_3, Int32 A_4, String A_5, Int32 A_6, SshOptions A_7, SslOptions A_8, ProxyOptions A_9, MySqlHttpOptions A_10, HttpOptions A_11)
at Devart.Data.MySql.MySqlInternalConnection.Connect(MySqlConnection owner, String userId, String password, String host, String database, Int32 port, Int32 connectionTimeout, MySqlProtocol protocol, Boolean compress, Boolean clientInteractive)
at Devart.Data.MySql.MySqlInternalConnection..ctor(p connectionOptions, MySqlConnection owner)
at Devart.Data.MySql.as.a(w A_0, Object A_1, DbConnectionBase A_2)
at Devart.Common.DbConnectionFactory.a(DbConnectionPool A_0, w A_1, DbConnectionBase A_2)
at Devart.Common.DbConnectionPoolGroup.a(DbConnectionPool A_0, DbConnectionBase A_1)
at Devart.Common.DbConnectionPool.a(DbConnectionBase A_0)
at Devart.Common.DbConnectionPool.GetObject(DbConnectionBase owningConnection)
at Devart.Common.DbConnectionFactory.a(DbConnectionBase A_0)
at Devart.Common.DbConnectionClosed.Open(DbConnectionBase outerConnection)
at Devart.Common.DbConnectionBase.Open()
at Devart.Data.MySql.MySqlConnection.Open()

When I use a user that is an interactive user and part of the administrator group, everything looks good.

On an XP machine, when running asp.net as ASPNET, I always get Lost Connection to MySql... error even if I add the ASPNET user to the administrators group.

Like I mentioned earlier, we have to use Corelab.MySql v 3.55.17 for this release and need to resolve this issue fast. Thanks.

We did some more research into the problem using procmon tool (from sysinternals) and here is what we found out.

Setup:

Database: MySql v5.0.86 setup for SSL
Environment: ASP.Net 3.5, IIS 7.5, Windows 7 (no UAC)
Drivers: Both Corelab 3.55 and Devart 5.50.79 exhibit almost similar behavior, Devar 5.20.33 is useless for SSL connections.
ConnectionString: User Id=user;Password=pwd;Host=dbHost;Port=3306;Database=dbName;Direct=True;Unicode=True;Protocol=Ssl;Pooling=True;Connection Lifetime=1800;SSL CA Cert="file://C:\newcerts\ca-cert.pem";SSL Cert="file://C:\newcerts\client-cert.pem";SSL Key="file://C:\newcerts\client-key.pem";
Permissions: All the permissions "are" setup properly on the machine.
Error with Corelab v3.55.17: "Lost connection to MySQL server during query"
Error with Devart v5.50.79: "SSL connection error (2026): Could not acquire private key"
Web Process Identity: ApplicationPoolIdentity (on my machine, it translates to "DefaultAppPool" user)
Certificate pair key filename: 9662578eb35f925aaa97e4941ca3d838_d88f3339-2e1e-4ad0-81b3-26c347ee9fbc


Case 1: Works

The console application is always referring to the following location when trying to create/open/close the certificate pair key file and if the file does not exist, it is created:
C:\Users\testUser\AppData\Roaming\Microsoft\Crypto\RSA\S-1-5-21-790525478-1383384898-839522115-9693\

Case 2: Never works

The web application when running as DefaultAppPool is looking at two different places when trying to create/open/close the key file. If the file does not exist, it is created in the first folder location below but it is not created in the second folder location:
C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\
C:\Users\DefaultAppPool\AppData\Roaming\Microsoft\Crypto\RSA\S-1-5-82-3006700770-424185619-1745488364-794895919-4004696415\

Workaround: After the first failed connection attempt, try to copy the file from the first folder location and paste it into the second folder location. Restart IIS everything starts to work after that.

Case 3: Works only after Case 1 has been executed. If you delete the key file from the location mentioned in Case 1, this case fails as well.

The web application when run as "testUser" is also looking at two different places when trying to create/open/close the key file:
C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\
C:\Users\testUser\AppData\Roaming\Microsoft\Crypto\RSA\S-1-5-21-790525478-1383384898-839522115-9693\


Conclusion:

The console application is always looking into a single folder location (the user's keystore) but the web application (does not matter what identity you run it as) is looking into two different folder locations (the machine keystore and the user keystore). The web application process is creating the file in the machine keystore but cannot use it because to read it, it looks at the user keystore where the file does not exist unless manually copied.

I am guessing that this maybe because of "interactive" login vs "non-interactive" user login?

Your thoughts?

For this release we will probably not support MySQL SSL client authentication but for the next release, we want to support this feature, so we need a fix for this from you guys since even version 5.50.79 of the drivers have this problem.

Thanks.

Please confirm that this issue persists with the 6.0.10 version of dotConnect for MySQL. If you don't have access to the licensed version, please use the trial version: http://www.devart.com/dotconnect/mysql/download.html.
As a workaround, have you tried to specify the locations of certificates as compiled resource (documentation)?

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.

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.

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

We are investigating the issue.

Thanks.

Any updates?

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

We have fixed the original issue with SSL connection via IIS. It works on Windows XP and IIS 5.1 with internal build (public build should be available in a week or so). But we have found one more problem. It is specific for Windows 7. We are working on it. I will post here about the results.

Thanks for the update

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.