I think the issue is with the CosmosDB Endpoint URL pointing to https://family.privatelink.documents.azure.com/
, while it should be pointing to the 'normal' DNS name without the privatelink
portion.
If DNS is set up correctly for privatelink, then resolving the normal public endpoint would return a private IP address - see below example for a storage account endpoint:
Reference: https://github.com/dmauser/PrivateLink/tree/master/DNS-Integration-Scenarios
The certificate error is likely to be coming from the mismatch in the name between the endpoint that is configured on the WebApp (the privatelink DNS name) and the certificate that is reflecting the normal public endpoint name.
So, if family.documents.azure.com
is your CosmosDB account name, then that name should be used for connecting to the database.
In order to test if the name resolution works on your WebApp and test if the CosmosDB endpoint name resolves properly, you can use the built-in console.
To get to the Azure portal-hosted console from your app, go to Tools > Console.
In native Windows apps, the tools ping, nslookup, and tracert won't work through the console because of security constraints (they work in custom Windows containers). To fill the void, two separate tools are added. To test DNS functionality, we added a tool named nameresolver.exe. The syntax is:
nameresolver.exe hostname
Reference: https://learn.microsoft.com/en-us/azure/app-service/overview-vnet-integration#troubleshooting
So if if the URL below is the endpoint of your CosmosDB and DNS for Private Endpoints is set up properly, this command should return a private IP address:
nameresolver.exe family.documents.azure.com
Please also note that your WebApp needs to be properly integrated into the VNET using VNET Integration, otherwise this will not work (but I would expect a different error if that was not the case).