Forum Discussion
Post ProdigyAzure the server name provided does not match the server name on the sql server SSL certificate
Post ProdigyHi,
Thanks for suggestion.
However, we are using the FQDN when connect via power bi desktop and service but still get this error.
Is there a way to check the FQDN on the server SSL certificate in Azure and if necessary chnage it so has privatelink within it?
We can connect using below but cannot use encrypted connection due to this.
<db_name>.privatelink.database.windows.net
Hi,
Just my two cents, because the solution wasn't immediately clear to me in its entire scope.
For me and my environment, the SSL certificate for the SQL server was renewed and no longer contained the (SAN) name for the privatelink connection.
The environment has an on-premises datagateway.
Thus, the solution is to manipulate the dns name of the server from the platform side. I doubt we can get Microsoft to deploy a new certificate.
Assuming one is using a private endpoint, "privatelink", you have created a private dns zone within the resource group in Azure.
The solution for me was to change the private DNS zone domain :
- Create a new private DNS zone in the resource group, named "database.windows.net". Azure will give you a warning about this being a system domain. This can (at least in my case) be disregarded.
- Modify the record sets of previous private DNS zones to not have "Auto register" on (assuming you do not have any other resources in the linked vnets)
- Unlink the vnets from the previous private DNS zone (assuming you do not have any other resources in the linked vnets utilizing the DNS zone)
- Delete the current DNS configuration for the endpoint. You can make a note of the current settings.
- Create a new configuration for the private endpoint.
- In the same resource group.
- Using the new private DNS zone.
- In the same DNS zone group (if you have several)
- Link the vnets to the new private dns zone.
- When linked, you can enable auto-registration for the linked vnets.
After this, you should recreate the data source for the SQL server / database in the report, using the proper FQDN, visible in the private DNS zone configuration. This should now be <db/server-name>.database.windows.net.
Also, you should not be required to admin approve anything since we are practically editing a existing private endpoint
For my environment, the solution to create environment variables didn't solve the issue in Cloud PBI.