TLS SQL connections under ASP.NET v2 versus v4.

Question

User-1084607509 posted

Hi folks,

I've come across a new issue I haven't seen to date.

We're starting to ask vendors to configure their web applications to use "encrypt=true; trustservercertificate=false" where possible in their connection strings, but in an interesting development, connections are succeeding when the application pool is configured to use the .NET CLR v4.0 pool setting while those restricted to running under v2.0 fail with the following error:

A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: SSL Provider, error: 0 - The certificate's CN name does not match the passed value.)

Changing the "trustservercertificate=false" to "true" resolves the issue.

From a certificate perspective, because this is serving an AlwaysOn SQL cluster, all the names are registered as SAN entries.

What this seems to suggest is that ASP.NET CLR v2.0 compatibility precludes SANs from being checked. In other words, it's limited to strict subject name checking.

My question is: is this indeed the case?

What I'm trying to achieve here is finding an authoritative answer on the issue so I can mark it as "known", move on and forget about it.

While this is likely a .NET issue rather than a specific ASP.NET issue, I've deliberately posted here as I expect this is the context (a web app and its associated .config file) in which people these days are most likely to have seen it. I'll cross post to MSDN as well.

Cheers,
Lain

Answer 1

User283571144 posted

Hi Lain,

According to your description, I also guess the reason why the connection string work in the CLR4 not work in CLR2 is related with the CLR version.

As far as I know, when the encrypt property is set to true and the trustServerCertificate property is set to false, the Microsoft Driver for SQL Server will validate the SQL Server SSL certificate. Validating the server certificate is a part of the SSL handshake and ensures that the server is the correct server to connect to.

In order to validate the server certificate, the trust material must be supplied at connection time either by using trustStore and trustStorePassword connection properties explicitly, or use the environment's default trust store.

Maybe CLR2 couldn't work well with the default trust store when validating the server certificate.

Best Regards,

Brando

Answer 2

User-1084607509 posted

Thanks for the reply, Brando, but that's not it in this case.

The only issue is that CLR2 is not making use of the subject alternate name field. The trust chain is fine as if I change the server name in the connection string to match the subject name of the same certificate then the above-listed error disappears (however, this is of no use to me for the reasons I mentioned above.) Looking at it from a different perspective, if there was anything wrong with the trust mechanics then the certificate wouldn't work at all under any version of .NET - or anything else, because it'd be a straight-up invalid trust.

I'm literally only chasing documentation that says something to the effect of "ASP.NET v2.0 only validates the subject name of a certificate", or "by default, ASP.NET v2.0 only validates the request against the subject name, but if follow steps x, y and z, it will process the subject alternate name entries in addition to the subject name."

You can likely exchange my references to ASP.NET v2.0 with simply .NET 2, etc. as I don't think this is specific to ASP.NET.

Because I cannot find either kind of statement, I can't prove that what I'm seeing is a hard limit of .NET < 4 or simply a configuration issue.

Cheers,
Lain

Answer 3

User283571144 posted

Hi Lain,

According to your description, I couldn't directly find the reason why the connection string now work in CLR 2.

Could you please tell me what is your .net framework version?

After .NET Framework 4, we can run multiple versions of the CLR in a single process.

Best Regards,

Brando

Answer 4

User-1084607509 posted

I might not be the best search engine operator but after some on-and-off again searching over the past week for documentation outlining the limits of the .NET System.Data.SqlClient in relation to SAN checking in the context of pre .NET 4.5, I can't find a single thing of use.

What I did find is a historic case of someone with the same issue and that thread didn't contain any new information either, so I'm just going to go ahead and close this question while taking the assumed position that it is not possible to further configure applications configured to run under a v2 application pool to work with Subject Alternative Names.

This is the other poor bloke's thread:

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/3506a862-b6d5-4474-9827-73f7cc59c1ba/sql-server-2008-r2-encrypted-connection

Cheers,
Lain

Answer 5

User283571144 posted

Hi Lain,

In my opinion, this issue may related with CLR version.

I suggest you could try to post this issue on the CLR forum.

https://social.msdn.microsoft.com/Forums/vstudio/en-US/home?forum=clr 

Best Regards,

Brando