9

We are currently experiencing a rather troublesome problem in our development environment with the following message...

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.)

...the commonly accepted wisdom to resolving this problem is to set the TrustServerCertificate portion of the connection to True. However, this does not work reliably or consistently.

This particular error occurs in a number of instances, for instance testing our WCF Service in our Azure Emulator talking to live / hosted SQL Azure Instance or even using SQL Management Studio. The only common denominator we've found is that this occurs only when we connect directly to SQL Azure as opposed to when its hosted and Azure is talking directly to SQL Azure (which does work).

I've tried a number of tactics to resolve the problem (such as the one detailed here), i.e. believing it was connection related and removing pooling and other modifications to the connection string. But alas, none are conclusive and more irritating is that the error is intermittent and will prevent access for a short period of time before magically resolving itself.

Other factors that I've eliminated.

  • We're using the Transcient Application Block to attempt to recover from these errors, but no.
  • Our office has no proxy server with our connection to the Azure hosted services.

Has anyone else experienced this problem or has any suggestions?

SeanCocteau
  • 1,838
  • 19
  • 25
  • Hummm... couple of ideas: did you attempt to copy this database to another one? I wonder if there are issues on the server you are currently on. In fact, did you try in another data center just for kicks? If the problem persists, could be the driver itself? Are you sure you are using the latest drivers/latest SSMS? I say that because when you host in Azure, it seems to work - so I wonder if it's a driver issue. – Herve Roggero Sep 08 '12 at 19:13
  • Thanks for the feedback. We're running on a multi-tenanted system essentially running the same database? Could this cause any particular problem? I have downloaded the new SQL Native Client 11 but have experienced the same problem. I'm not too sure about the steps involved in moving Data Centre, its a hefty system so I'm not too sure how achievable this could be... – SeanCocteau Sep 11 '12 at 11:06
  • 1
    Ah - it's a hefty system? Hummm... I have seen, in rare cases, a specific condition that happens when SQL Database is under heavy login requests. The error I saw was along the lines of a login failure however; not exactly the same issue. I would personally treat this error as a transient fault; you should be able to customize the transient block and add this specific error as a transient error to retry (by default this error isn't considered transient in nature, so the block doesn't account for it unless you tell it). This may do the trick. – Herve Roggero Sep 11 '12 at 20:21
  • I have had seen this problem too, the error is transient in nature but takes minutes to clear. It also only seems to happen when connecting from outside azure (from the office) directly to the databases. – David Steele Sep 12 '12 at 10:58
  • You may not have a proxy server but you likely have a firewall or other routing/scanning going on in the background. I assume you have opened up a database from a home connection to try and replicate this? Did it work? RE: the problem, can we see your connection string please. – Steve Newton Jul 21 '14 at 16:27

2 Answers2

4

You need to scan for Non-IFS Winsock BSPs or LSPs which not compatible with the FILE_SKIP_COMPLETION_PORT_ON_SUCCESS flag ,problem results primarily from non-IFS LSPs Being installed.

Just run "netsh WinSock Show Catalog" from command prompt , and check any "service flag" which doesn't look in the format of 0x20xxx

In my case I found that "Speed Accelerator" with service flag 0x66,removing this software solve my Problem .

More information can be found here : http://support.microsoft.com/kb/2568167

0xFK
  • 2,433
  • 32
  • 24
1

What does your connection string look like? Not sure if you've tried this yet but I remember having a problem similar when using a remote SQL connection to SQL Azure and found that I had to set:

Trusted_Connection=False;Encrypt=True

and remove any Connect Timeout from the string entirely.

Scott Prokopetz
  • 474
  • 3
  • 6
  • I thought setting the username and password would automatically do this, but I can try setting Trusted_Connection and see if it helps. The `SqlConnectionStringBuilder` does not have this property built-in, but FWIW http://msdn.microsoft.com/en-us/library/ee621781.aspx does reference this property. It doesn't make sense that this would only happen *sometimes* based on the connection string, and the error would lead me to believe SQL Azure is sending the wrong certificate on a bad dice roll, but you might be on to something. Thanks for the suggestion. – lc. Jul 23 '14 at 01:57
  • Actually it would appear this has been replaced by the property "Integrated Security". Setting "Trusted_Connection" manually on the `SqlConnectionStringBuilder` modifies the "Integrated Security" property. I believe this defaults to false anyway but I'll try explicitly setting it and see what happens. For reference, http://stackoverflow.com/questions/3077412/what-is-the-difference-between-trusted-connection-and-integrated-security-in-a-c – lc. Jul 23 '14 at 02:03
  • No dice. The problem is still intermittently occurring. – lc. Oct 01 '14 at 07:58