[CSHARP-3560] x509 Auth with intermediate CA Created: 09/Apr/21  Updated: 20/Apr/21  Resolved: 20/Apr/21

Status: Closed
Project: C# Driver
Component/s: None
Affects Version/s: 2.9.3, 2.11.6
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Tomas Žaleniakas Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RHEL 7, dotnet core 3.1, python 2.7


Issue Links:
Related
is related to CSHARP-3588 Document limitation whereby SslStream... Backlog

 Description   

We have a replica set of 3 nodes. Each nodes authenticates using x509 certificates. Some clients also authenticates using x509 certificates. Everything works if certification path is like this:
root_ca -> certificate

but if certification path is
root_ca -> intermediate_ca -> certificate

the C# driver cannot connect using x509 auth. Python, mongo command can connect using same certificate just fine. Upon further investigation i assume C# client only sends single certificate for validation. 

relevant code part used for testing:

                    var certificateCollection = new X509Certificate2Collection();
                    certificateCollection.Import(certificatePath);
                    var certificateList = certificateCollection.Cast<X509Certificate2>().ToList().OrderByDescending(c => c.HasPrivateKey);
                    settings.SslSettings = new SslSettings {
                        ClientCertificates = certificateList,
                        CheckCertificateRevocation = false,
                    };

certificatePath: location of pfx file containing intermediate CA cert and client cert with key

List contains two X509Certificate2 objects. if first certificate in list is intermediate CA, error on mongodb server is:
Failed to authenticate CN=xsuser@$external with mechanism MONGODB-X509: AuthenticationFailed: There is no x.509 client certificate matching the user.

But if first certificate in list is client certificate (second intermediate certificate), mongodb says: 
SSL peer certificate validation failed: unable to verify the first certificate

since mongo command and python client with same certificate chain can connect just fine i assume C# driver has something to do with it. Or maybe i'm  missing something about client configuration regarding x509 auth with intermediate CA? There is no documentation specific about intermediate CA.



 Comments   
Comment by Esha Bhargava [ 20/Apr/21 ]

Closing this ticket since a workaround has been provided for the original issue. I have filed a separate ticket (CSHARP-3588) to document the limitation and linked it to this issue. 

Comment by Tomas Žaleniakas [ 13/Apr/21 ]

Setting SSL_CERT_FILE  to intermediate CA certificate issue is solved. So it would be good to mention it in docs as it is .NET Core limitation

Comment by James Kovacs [ 09/Apr/21 ]

Hi, Tomas,

Thank you for reaching out about x509 certificate auth not working with the .NET/C# driver when using an intermediate CA.

Although we haven't had time to attempt to reproduce the issue yet, we did find some information that might be helpful to you. Based on some quick research, this appears to be a .NET bug/limitation whereby SslStream doesn't send intermediate certs from a certificate file:

https://github.com/dotnet/runtime/issues/26323

One suggested workaround is to point to the certificate bundle using the SSL_CERT_FILE environment variable when launching your app:

SSL_CERT_FILE=/opt/my-app/etc/ca-bundle.crt ./My.App

We are investigating a fix that would require using the new SslStreamCertificateContext.Create(X509Certificate2, X509Certificate2Collection, Boolean) to build the cert chain. Unfortunately that method was introduced in .NET 5.0 and would require not only changes to the driver but also upgrading your app to target .NET 5.0.

https://docs.microsoft.com/en-us/dotnet/api/system.net.security.sslstreamcertificatecontext.create?view=net-5.0

This issue definitely requires further investigation into potential workarounds and fixes as well as reproducing it in our environment so we can be sure of any proposed solutions. We hope that this preliminary information is helpful. Please let us know if you have any additional questions or observations, especially whether the SSL_CERT_FILE environment variable works in your environment.

Sincerely,
James

Generated at Wed Feb 07 21:45:38 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.