Bug #95436 PEM certificate support is incomplete
Submitted: 20 May 2019 22:49 Modified: 1 Mar 2023 18:59
Reporter: John Wilson Email Updates:
Status: Verified Impact on me:
None 
Category:Connector / NET Severity:S3 (Non-critical)
Version:8.0.16, 8.0.31 OS:Windows
Assigned to: CPU Architecture:x86
Tags: certificate, PEM, SSL

[20 May 2019 22:49] John Wilson
Description:
A couple of features important to ssl client certificate authentication do not work properly when attempting to use PEM certificates.

The connector library will fail to validate the CA certificate when it is valid.
The connector library will fail to use the client certificate and subsequently fail authentication.

How to repeat:
Configure a MySQL server to require a client certificate for authentication.
Use the .NET connector to connect to the MySQL server with the appropriate client PEM certificates.

Suggested fix:
I've created a patch that resolves the issue for .NET Core apps running on windows. It has not been tested with other configurations.
[20 May 2019 22:50] John Wilson
suggested fix

Attachment: mysql_pem.patch (application/octet-stream, text), 3.37 KiB.

[22 May 2019 7:30] MySQL Verification Team
Hello John Wilson,

Thank you for the report.
Please note that in order to submit contributions you must first sign the Oracle Contribution Agreement (OCA). More details are described in "Contributions" tab, please ensure to re-send the patch via that tab. Otherwise we would not be able to accept it.

Also, I quickly tried to reproduce the issue at my end but not seeing any issues though after following - 
https://dev.mysql.com/doc/connector-net/en/connector-net-tutorials-connection.html
https://dev.mysql.com/doc/connector-net/en/connector-net-tutorials-ssl-pem.html

- VS 2019, MySQL Server 8.0.16 and MySQL Con/NET 8.0.16

- CLI
mysql> CREATE USER 'ushastry'@'%' REQUIRE SSL;
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT ALL ON *.* TO 'ushastry'@'%';
Query OK, 0 rows affected (0.00 sec)

-

using System;
using System.Data;

using MySql.Data;
using MySql.Data.MySqlClient;

namespace Bug95436
{
    class Program
    {
        public static void Main()
        {
            string connStr = "server=xxxxx.yy.oracle.com;user=ushastry;database=test;port=3333;password=;SslMode=VerifyFull;SslCa=C:\\Work\\MySQLNet\\source\\Bug95436\\ca.pem;SslCert=C:\\Work\\MySQLNet\\source\\Bug95436\\client-cert.pem;SslKey=C:\\Work\\MySQLNet\\source\\Bug95436\\client-key.pem;";
            MySqlConnection conn = new MySqlConnection(connStr);
            try
            {
                Console.WriteLine("Connecting to MySQL...");
                conn.Open();
                // Perform database operations
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.ToString());
            }
            conn.Close();
            Console.WriteLine("Done.");
        }
    }
}

-
Connecting to MySQL...
Done.

C:\Program Files\dotnet\dotnet.exe (process 13976) exited with code 0.
Press any key to close this window . . .

Could you please elaborate the issue that you are facing along with a sample C# test case to reproduce this issue at our end? Thank you!

regards,
Umesh
[22 May 2019 11:01] John Wilson
Configuring a user with REQUIRE SSL isn't enough to require client certificates. You must use REQUIRE X509.

You cannot reproduce the CA verification error using the MySQL autogenerated certificates as their issuer information is too simple, containing only one field. Including a second field (like C=US) would be enough to reproduce the issue.

The CA certificate verification will fail because the .NET X509Certificate and the BouncyCastle X509Certificate generate the issuer string in different ways.

This is what a Google Cloud SQL CA issuer string looks like for both certificate types:
DN=9b94949b-952d-4ee0-ae29-cb347474c9c8,CN=Google Cloud SQL Server CA,O=Google\, Inc,C=US
C=US, O="Google, Inc", CN=Google Cloud SQL Server CA, dnQualifier=9b94949b-952d-4ee0-ae29-cb347474c9c8

Besides the obvious difference in ordering, they use different spacing, different escape methods for commas, and even different identifiers.
[22 May 2019 11:33] MySQL Verification Team
Thank you for the feedback.
As stated before - please note that in order to submit contributions you must first sign the Oracle Contribution Agreement (OCA). More details are described in "Contributions" tab, please ensure to re-send the patch via that tab. Otherwise we would not be able to accept it.

thanks,
Umesh
[24 May 2019 4:37] Bradley Grainger
I see two potential problems with the patch:

1) In the netstandard2.0 build, setting "cert.PrivateKey = key;" will throw at runtime.

2) On non-Windows platforms, creating a new CspParameters object will throw a PlatformNotSupportedException at runtime.

John,

FYI, I just pushed working PEM file support to MySqlConnector, if you'd like to consider using/contributing to that library in the future: https://github.com/mysql-net/MySqlConnector/commit/5159fd14ca607f2ce0cdceddc785eacad52e8b0...
[24 May 2019 5:17] John Wilson
I suspected that my patch might cause some issues on other configurations. While I was researching this issue, I read about a minefield of issues regarding cryptography in cross-platform implementations of .NET. I didn't exactly have the time to test for and correct these issues, so I just made sure to mention that the patch was only tested on .NET Core on Windows.

For that reason, I don't believe that accepting my patch as a direct contribution is the best idea. It exists to help inform the bug report.

I will consider using that other .NET connector library.
[24 Oct 2019 3:10] Josh Shand
Hey any movement on this issue?

Just thought I'd add that without this working it is impossible to connect to Amazon RDS Aurora with IAM Authentication/SSL in VerifyCA mode as it also fails to validate the rds-combined-ca-bundle.pem file available here: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html.

Confirmed that the PEM bundle file works with mysql cli tool and a 3rd party .net connector driver just not Connector/NET.

Stack throws:
MySql.Data.MySqlClient.MySqlException (0x80004005): SSL Connection error. ---> System.Exception: The certificate authority (CA) does not match.
[16 Mar 2022 14:05] MySQL Verification Team
Bug #106670 marked as duplicate of this one.
[2 Dec 2022 12:19] MySQL Verification Team
Bug #108929 marked as duplicate of this one
[28 Feb 2023 13:28] Kai Neumann
Das Problem ist in der v8.0.32 immer noch vorhanden.
Ich finde das sehr ärgerlich, das das Problem seit fast 4  Jahren bekannt ist.
[28 Feb 2023 13:29] Kai Neumann
The problem is still present in v8.0.32.
I find it very annoying that the problem has been known for almost 4 years.

(Sorry for the previous german text, i was in thoughts)
[28 Feb 2023 17:30] John Wilson
I'm under the impression that Oracle isn't interested in fixing this bug. They want someone else to fix it and give them the patch. I just ended up switching to the library that Bradley suggested.

https://github.com/mysql-net/MySqlConnector

They maintain a page listing all of the unfixed bugs with this Oracle library that are fixed in MySqlConnector.

https://mysqlconnector.net/tutorials/migrating-from-connector-net/#fixed-bugs
[1 Mar 2023 6:41] Kai Neumann
@John, thank you for pointing this out. I was already on the way to switching to the MySqlConnector. Unfortunately, the Entity Framework based on ".Net Framework 4.8" is also used. I did read the references to the package Pomelo.EntityFrameworkCore.MySql", but that requires (if I understood correctly) at least ".Net Core".
This is the point where I got stuck.
[1 Mar 2023 18:59] John Wilson
The 3.* versions of Entity Framework Core target .NET Standard 2.0, and should work on .NET Framework 4.8

The 3.* versions of Pomelo.EntityFrameworkCore.MySql also target .NET Standard 2.0.

The 0.69.10 version of MySqlConnector is compatible too, and doesn't have the issue described here.

.NET Framework 4.8 is a dead-end, and is going to be less and less supported as time goes on. I strongly recommend you upgrade to a newer version, if at all possible.