Azure SQL Database error TLS Handshake failed since v12 upgrade

4
votes

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

1
azuregoclient-certificatesazure-sql-database
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
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 instance which has InsecureSkipVerify set to true. – kostix
...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

1 Answers

2
votes

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.