[CSHARP-2662] Latest MongoDB Driver nuget package does not work on Azure Server 2019 Classic Cloud Service VM because only TLS 2.0 is enabled on these VMs Created: 08/Jul/19  Updated: 15/Nov/21  Resolved: 15/Oct/19

Status: Closed
Project: C# Driver
Component/s: Connectivity
Affects Version/s: 2.8.1
Fix Version/s: None

Type: Bug Priority: Blocker - P1
Reporter: Vijay Devappa Assignee: Vincent Kam (Inactive)
Resolution: Cannot Reproduce Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File From Azure Support.png     PNG File error-log-part.png     PNG File workaround-1.png    

 Description   

We have been unable to upgrade our Azure classic cloud services to Windows Server 2019 for a few months now.

The matter is confusing because the same nuget package works fine on a regular Windows Server 2019 VM.

Turns out that the OS Image of Windows Server 2019 used for Azure classic cloud services specifically turns OFF TLS 1.0 and 1.1, and only has 2.0 enabled.

Once, we turned on support for the previous versions, we were able to get Mongo connectivity back and everything works.

Now, we have a startup script which enables the older TLS versions on Windows Server 2019.

Please support TLS 2.0 for customers so we can use it.

This is .NET 4.8 on C# on Azure which is a Classic ASP.NET Web Api application.



 Comments   
Comment by Vijay Devappa [ 22/Oct/19 ]

support@mlab.com can you take a look at this case? From the description sounds that the problem maybe that the protocol is not enabled from the Mongo server side, as the client API apparently has no issues. If this is the problem, can we enable this on my cluster please? I will also forward you this case link via email.

Comment by Vincent Kam (Inactive) [ 22/Oct/19 ]

Hi vijay1979,

Thank you for your patience and your reply. Your initial report stated that your application was hosted on a machine that only had TLS1.2 enabled and that this application was unable to connect to a MongoDB instance until you enabled TLS1.0 and TLS1.1 on the application machine. In order to test the hypothesis that v2.8.1 of the driver does not support TLS1.2, we chose to create an Atlas cluster that only accepts TLS1.2, thereby forcing the driver to connect via TLS1.2 or not at all. Our test application, targeting .NET Framework 4.8, was able to connect under this scenario, which would seem to disprove the hypothesis that the v2.8.1 of the driver does not support TLS1.2.

Based off your latest reply, I also understand that you'd like us to investigate using Windows Server 2019 with only TLS1.2 enabled. So, to that end, I spun up a Windows Server 2019 image and disabled TLS1.0 and TLS1.1 via the Registry. I then ran the same test application as described above (v2.8.1 of the driver and targeting .NET Framework 4.8), and the application was able to connect to the Atlas cluster that only has TLS1.2 enabled. I then enabled all TLS protocols on the Atlas cluster (while still keeping TLS1.0/1.1 disabled via the registry), and the test application was still able to connect.

As such, I will be closing this ticket as “could not reproduce” as it seems that v2.8.1 of the driver does indeed support TLS1.2. If your business requires additional support from MongoDB then we do offer enterprise support. Additionally, if you are able to reproduce this error, please let us know, and we’d be happy to look into it.

Thank you for your time.
Kind regards,
Vincent

Comment by Vijay Devappa [ 15/Oct/19 ]

You are not able to reproduce, because you are testing on the wrong scenario: "while connecting to an Atlas cluster hosted on Azure with only TLS1.2 enabled" - this is not the scenario.

The .NET application should be hosted on Windows Server 2019 - on this OS, only TLS 1.2 should be enabled.

It does not matter what is OR not enabled on Mongo Server. This has nothing to do with the Mongo Server - and everything to do where the client APP is hosted.

 

Comment by Vincent Kam (Inactive) [ 15/Oct/19 ]

Initially, I thought I had found a reproduction where it appeared that v2.8.1 of the driver had issues connecting to an TLS1.2-only 4.2 replicaset in Atlas when not using SRV. Further investigation revealed that this was simply because driver v2.8.1's connection string parsing does not support tls=true (it supports the older ssl=true). I am therefore closing this issue.

Comment by Vincent Kam (Inactive) [ 08/Oct/19 ]

Re-opening this ticket as new evidence has surfaced regarding v2.8.1's inability to connect to a TLS1.2 server when not using SRV.

Comment by Vincent Kam (Inactive) [ 08/Oct/19 ]

Hi vijay1979,
Thank you for your patience. Unfortunately, I was unable to reproduce your problem with a test app utilizing .NET Framework 4.8 and v2.8.1 of the driver while connecting to an Atlas cluster hosted on Azure with only TLS1.2 enabled. I understand that you'd like us to investigate using classic cloud service on Azure, but unfortunately, we cannot offer that level of support given our current workload. If your business requires an answer from MongoDB then we do offer enterprise support. If you are able to reproduce this error without classic cloud service on Azure, please let us know, and we'd be happy to look into it.
Thank you for your time.
Kind regards,
Vincent

Comment by Vincent Kam (Inactive) [ 26/Jul/19 ]

Hi Vijay,

My sincere apologies! Totally my fault: I missed the part of the ticket where you listed the driver version (I incorrectly assumed when you said "latest" you meant the latest beta). We'll continue investigating. 

Kind regards,

Vincent

Comment by Vijay Devappa [ 25/Jul/19 ]

The issue is with v2.8.1 of the driver as mentioned.

"but I was able to connect successfully to a standalone MongoDB instance that only allows TLS1.2 using a test app running on .NET Framework 4.8 and the latest version of the driver (2.9.0-beta2) ."

>> Can you confirm it does not work with v2.8.1 and then it works with v2.9.0 beta 2? It is a bad idea to try and reproduce a bug with a different/ latest version of the code and then say it does not happen. Maybe it is fixed in v2.9.0 beta 2 - but to confirm that, you need to reproduce with the correct reported version first.

If you still cannot reproduce with v2.8.1 of the nuget package, this could be a problem with your OS image.

Again, try to reproduce using the exact scenario as mine - classic cloud service on Azure. It may have other differences from the OS image you are using.

I can 100% reproduce this, and as the screenshots show, we fixed it with a lot of difficulty.

Please try to reproduce with the exact same steps as mine, and then we can discuss further.

Comment by Vincent Kam (Inactive) [ 25/Jul/19 ]

Hi! vijay1979 

Sorry to hear about the issues. I tried to reproduce your issue, but I was able to connect successfully to a standalone MongoDB instance that only allows TLS1.2 using a test app running on .NET Framework 4.8 and the latest version of the driver (2.9.0-beta2) .

The following information will hopefully help us diagnose the issues you're seeing:
1. What version of the driver you are using? TLS1.2 has been supported since at least 2016 (see https://jira.mongodb.org/browse/CSHARP-1744) so it's doubtful that your driver is too old, but this is still a good starting point. 
2. Are you using the legacy API?
3. How are you configuring your MongoClient? By default, a MongoClient's MongoClientSettings's should allow TLS1.2 through the SslSettings.EnabledSsslProtocols property: is this value being manually set by the application by any chance?

Kind regards,

Vincent

Comment by Vijay Devappa [ 22/Jul/19 ]

3.6.12 (WiredTiger). The issue was resolved (by us using a workaround) a while ago. The error is not with the mongo server, it is a client only error, where the client is running on Windows Server 2019.

Comment by Esha Bhargava [ 22/Jul/19 ]

vijay1979 Can you tell us which version of the server are you using and how is it configured? Also, if possible, please upload the server logs.

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