I am seeing some strange results with SSL certificate verification in relation to Azure SQL Server.
I have an application that is making a secure connection to SQL server. When I run the application on my local PC, the certificate returned by the server returns the following alt DNS names:
DNS:northcentralus1-a.control.database.windows.net, DNS:*.northcentralus1-a.control.database.windows.net, DNS:management.northcentralus1-a.control.database.windows.net, DNS:management.northcentralus.control.database.windows.net, DNS:admin.northcentralus1-a.control.database.windows.net, DNS:*.database.windows.net, DNS:*.secondary.database.windows.net, DNS:*.provisioning.database.windows.net
This is what I would expect, and it matches the server I am trying to talk to under *.database.windows.net.
However, when I deploy that same application into Azure, the SQL Server seems to return a different certificate with the following alt DNS names:
DNS:tr1.northcentralus1-a.worker.database.windows.net, DNS:*.tr1.northcentralus1-a.worker.database.windows.net
These names do not match the server I am trying to talk to, so my client application rejects the connection due to it being an untrusted host.
There was a similar issue entered here, but the solution accepted was to just always trust the certificate without checking it. My question is different in that I would like to verify the certificate, not blindly trust the certificate.
Here are the specific questions, summarized:
Is Azure SQL Server providing an invalid certificate?
Assuming it is providing an invalid certificate, can I configure Azure SQL Server to provide a valid certificate?
Assuming it is providing an invalid certificate, is Azure SQL Server planning on correcting the behavior, or are we supposed to perpetually trust the certificate without checking?
