6

I receive this error since this morning, new v12 updated server / Azure SQL Database:

TLS Handshake failed: x509: certificate is valid for tr12.northcentralus1-a.worker.database.windows.net, *.tr12.northcentralus1-a.worker.database.windows.net, not [server-name].database.windows.net

Locally I have no problem connecting to the Azure SQL database. On Azure Web App the connection cannot be established.

Same connection string as local - was working fine before v12 update.

I'm using this SQL driver github.com/denisenkom/go-mssqldb/

Any pointer, don't believe I should change the connection string? Why it's working on local and not on Azure web app.

Edit 1: Just tried to replace [server-name].database.windows.net with the tr12... but tcp connection cannot be established.

Edit 2: Here's the connection string if it can help, bottom line, why it's working locally, same driver package version, I'm building executable locally and deploying via FTP, so not using Kudo deployment for this app. Was working A1 until Azure auto-upgraded to v12.

Server=[server-name].database.windows.net;Port=1433;Database=[dbname];User ID=[user];Password=[pass];Trusted_Connection=False;Encrypt=True;Connection Timeout=30;

Should trusted connection be true? or Encryption false? Will try changing those to see....

Edit 3: I've look at the connection string from Azure portal, and v12 seems to have this new parameters: TrustServerCertificate=False but no chance, did not fixed the issue

Raghavendra
  • 1,419
  • 4
  • 19
  • 28
Dominic St-Pierre
  • 2,429
  • 3
  • 27
  • 35
  • To me, it smells like a plain TLS handshake error: the TLS handshake tries to verify the server's certificate (the default behaviour) but the certificate subject (an entity which is entitled to present it) does not match the host name of the server serving the request. So, two things to check: 1) try connecting to `tr12.northcentralus1-a.worker.database.windows.net` or any host in the domain `tr12.northcentralus1-a.worker.database.windows.net`. I know nothing about AWS and have no idea if it makes sense; but the check will supposedly pass; – kostix Dec 11 '15 at 17:47
  • 2) Read the `go-mssqldb` sources and try finding where it does `tls.Dial()` or utherwise uses the `tls` package (it may be used just for authentication phase if I recall `[MS-TDS]` correctly). Try to see if any knobs related to certificate validation are exposed to the clients via connection params. If not, you could hack the required configuration right into the package code to make it work and file an issue to the `go-mssqldb` tracker. The idea is to pass the TLS-setup code a custom [config](https://golang.org/pkg/crypto/tls/#Config) instance which has `InsecureSkipVerify` set to true. – kostix Dec 11 '15 at 17:51
  • ...and in the meantime contact the Azure support as whatever they do is wrong: the only way to get around this problem is to make the client skip the certificate verification check which defeats 80% of the purpose of using TLS in the first place ;-) ...OK, and start with `encrypt=false` -- it should make the handshake phase not use TLS at all. – kostix Dec 11 '15 at 17:52

1 Answers1

3

Based on this closed issue I changed TrustServerCertificate from False to True and added this parameter hostNameInCertificate to the connection string and it is working now:

https://github.com/denisenkom/go-mssqldb/issues/55

TrustServerCertificate=True;hostNameInCertificate=*.database.windows.net;

Azure portal suggests to have TrustServerCertificate=False and no hostNameInCertificate.

Dominic St-Pierre
  • 2,429
  • 3
  • 27
  • 35