Hi, I have a problem with a new Cosmos account service. I have never deployed one before. Both the App Service and the Cosmos database account have private endpoints. Both private endpoints are in the same vnet and subnet. It seems the App Service cannot connect to the Cosmos database due to RemoteCertificateNameMismatch . All references to resources use standard Microsoft FQDNs as this is in Dev, so no custom certificates are used. As all certificates are therefore MS controlled I wouldn't have expected a RemoteCertificateNameMismatch to happen? These are the steps that the application goes through… Uploads doc to blob storage Writes to SQL DB (not Cosmos) of the link to the file in blob storage Writes to SQL DB (not Cosmos) to create a conversation entry External library reads doc as filestream and converts/reads tokens Checks if doc is of certain size (txt size exceeds token limit set) Breaks down to chunks – the Log Stream on the backend App Service shows the following so confirms the process gets this far: Processed document alices-adventures-in-wonderland 1.pdf with content type application/pdf into 38 chunks Connect to the Cosmos database to upload the chunks to the database… this is the part that appears to be related to the failure. … app should then continue on to further steps _ App Service backend application Log Stream: 2025-02-12T08:51:29.8020806Z System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception._ 2025-02-12T08:51:29.8020837Z ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure: RemoteCertificateNameMismatch 2025-02-12T08:51:29.8020861Z at System.Net.Security.SslStream.CompleteHandshake(SslAuthenticationOptions sslAuthenticationOptions) 2025-02-12T08:51:29.8020893Z at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter] _2025-02-12T08:51:29.8020924Z at System.Net.Http.ConnectHelper.EstablishSslConnectionAsync(SslClientAuthenticationOptions sslOptions, HttpRequestMessage request, Boolean async, Stream stream, CancellationToken cancellationToken) _ Any assistance/guidance would be very much appreciated. Thanks, Tim.

@TH I'm glad that you were able to resolve your issue and thank you for posting your solution so that others experiencing the same thing can easily reference this! Since the Microsoft Q&A community has a policy that " The question author cannot accept their own answer. They can only accept answers by others ", I'll repost your solution in case you'd like to " Accept " the answer. Accepted answers show up at the top, resulting in improved discoverability for others. Issue : App Service unable to connect to Cosmos database with private endpoints - RemoteCertificateNameMismatch Solution: by removing .privatelink. and it works!If the resource is enabled with a private endpoint, you do not need to add the FQDN like privatelink.documents.azure.com instead, it should be CosmosDBAccountName.documents.azure.com

FIXED! I went back over some settings with one of our developers and he noticed he had the connection string in an environment variable on the App Service with the .privatelink. section added which we know shouldn't have been there. This I guess caused the certificate mismatch. After removing .privatelink. it works! What we don't understand is how this got there as the dev would have copied this from the Keys section of the Cosmos Account which clearly doesn't list it with .privatelink in the name. That part is a bit of a mystery. Thanks for your assistance!

FIXED: App Service unable to connect to Cosmos database with private endpoints - RemoteCertificateNameMismatch

TH-4622 20

Hi, I have a problem with a new Cosmos account service. I have never deployed one before.

Both the App Service and the Cosmos database account have private endpoints. Both private endpoints are in the same vnet and subnet. It seems the App Service cannot connect to the Cosmos database due to RemoteCertificateNameMismatch.

All references to resources use standard Microsoft FQDNs as this is in Dev, so no custom certificates are used. As all certificates are therefore MS controlled I wouldn't have expected a RemoteCertificateNameMismatch to happen?

These are the steps that the application goes through…

Uploads doc to blob storage
Writes to SQL DB (not Cosmos) of the link to the file in blob storage
Writes to SQL DB (not Cosmos) to create a conversation entry
External library reads doc as filestream and converts/reads tokens
Checks if doc is of certain size (txt size exceeds token limit set)
Breaks down to chunks – the Log Stream on the backend App Service shows the following so confirms the process gets this far: Processed document alices-adventures-in-wonderland 1.pdf with content type application/pdf into 38 chunks
Connect to the Cosmos database to upload the chunks to the database… this is the part that appears to be related to the failure.
… app should then continue on to further steps

_
App Service backend application Log Stream:

2025-02-12T08:51:29.8020806Z System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception._

2025-02-12T08:51:29.8020837Z ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure: RemoteCertificateNameMismatch

2025-02-12T08:51:29.8020861Z at System.Net.Security.SslStream.CompleteHandshake(SslAuthenticationOptions sslAuthenticationOptions)

2025-02-12T08:51:29.8020893Z at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter]

_2025-02-12T08:51:29.8020924Z at System.Net.Http.ConnectHelper.EstablishSslConnectionAsync(SslClientAuthenticationOptions sslOptions, HttpRequestMessage request, Boolean async, Stream stream, CancellationToken cancellationToken)
_
Any assistance/guidance would be very much appreciated.

Thanks,

Tim.

Ganesh Patapati 3,605 Reputation points Microsoft Vendor

2025-02-13T10:18:26.66+00:00
Hi TH

Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well.

For further Investigation could you please try to share below information:

Could you please confirm how you are trying to connect, where I can see that you are using private endpoint for both Cosmo DB and app service?

Please confirm for App services whether you are done the VNet Integration for this setup.

Refer: https://learn.microsoft.com/en-us/azure/app-service/overview-vnet-integration#how-regional-virtual-network-integration-works

For testing purpose, could you please try to remove private endpoint in your setup and try to test it publicly If it is working then there shouldn't be any issue from Private endpoint side.

Ensure that the connection string used in your application to connect to Cosmos DB is using the correct FQDN. When using private endpoints, the connection string should point to the private endpoint's FQDN.

Private endpoint is Layer 4 and there is no concept of SSL based on your error details, the issue seems like to be a certificate, can you please validate the certificate.

Kindly let us know if the above helps or you need further assistance on this issue.
TH-4622 20 Reputation points

2025-02-13T11:30:11.4466667+00:00

Hi Ganesh, thanks for responding.

The connection comes from the backend Azure App Service to the Cosmos Account. The App Service has a private end point and an integration network. There is a front end App Service in the same integration network and the front end and back end App Services can already communicate.

There does not seem to be the concept of Integration Network for a Cosmos account, hence I couldn't add it to this integration network. Its private endpoint is on the same vnet and subnet as the private endpoint for the back end App Service.

Private DNS zone and A records are present for the Cosmos resource for .privatelink.documents.azure.com and can be resolved from the back end App Service to the associated private IP address. There is also the additional A record for the cosmos account with the "-regionzonename" appended and different IP address as on the FGDNs listed on the PEP (learned that one yesterday!). Both IP addresses can be resolved by the respective nslookup in the App Service Kudu console.

When Public Access to the Cosmos Account is enabled, connectivity from the back end App Service does work, however this is obviously not what we want for security, and the purpose of Private Endpoints for us.

The private link resource on the PEP is the same as for the Cosmos account albeit without the .documents.azure.com on the end. Are you suggesting I should be omitting the .documents.azure.com part for the connection string if using private endpoints? My research suggests the original FQDN should be used and it's the addition of the DNS records that redirect this to the internal IP address.
Vallepu Venkateswarlu 165 Reputation points Microsoft Vendor

2025-02-13T17:13:01.7466667+00:00
Hi TH

Since your App Service can connect to Cosmos DB when Public Access is enabled but fails with a RemoteCertificateNameMismatch error when using Private Endpoints, you may try the following troubleshooting steps

Step1 :

Check the FQDN your App Service is connecting to by navigating to the App Service Kudu Console (Advanced Tools > Debug Console > CMD) and running the following command:

nslookup yourcosmosaccount.documents.azure.com

Output:

Cosmos DB PE configuration
**
Step 2 :

Make sure that the Private DNS Zone is configured correctly by navigating to the Azure Portal → Private DNS Zones → privatelink.documents.azure.com.

Click on Virtual Network Links and ensure that the Auto-registration option is enabled.

Step 3:

Even though your Cosmos DB is using a Private Endpoint, your application must continue using the standard connection string with the original FQDN, as shown below:

https://yourcosmosaccount.documents.azure.com

DO NOT modify this to use Azure Private DNS Azureprivatelink.documents.azure.com Private DNS should automatically resolve it to the private IP.

Step 4:

Once you have completed all the steps, make sure to restart the App Service and flush the DNS cache.

Hope this helps!

I just wanted to follow up and see if you had a chance to review my response in the comment to your question. Please let us know if it was helpful, and feel free to reach out if you have any further queries.
TH-4622 20 Reputation points

2025-02-14T10:43:22.4133333+00:00

Thanks Vallepu, not had chance to look at this yet, will do today. Looks great, thank you. Will report back.
TH-4622 20 Reputation points

2025-02-14T11:03:55.76+00:00
Hi Vallepu, thanks for responding.

I have checked everything you said and thank you for the screenshots. The only difference here is that the DNS records are not set for autoregistration as we assign them manually.

Private DNS zone and A records are present for the Cosmos resource for .privatelink.documents.azure.com and can be resolved from the back end App Service to the associated private IP address. There is also the additional A record for the cosmos account with the "-regionzonename" appended and different IP address as on the FGDNs listed on the PEP (learned that one yesterday!). Both IP addresses can be resolved by the respective nslookup in the App Service Kudu console.

We are using the normal format for connecting without the .privatelink. like you said... https://yourcosmosaccount.documents.azure.com

The Cosmos account is resolvable from Kudu console to the local IP address on the PEP.

I could not perform an ipconfig /flushdns however, as the Azure App Service is running on a Linux host. I don't believe we have access to equivalent Linux commands such as

sudo systemd-resolve --flush-caches

with Azure App Service but I have restarted the App Service.
Vallepu Venkateswarlu 165 Reputation points Microsoft Vendor

2025-02-14T11:36:40.5266667+00:00

Hi TH

I did not get you. Could you kindly clarify whether your issue has been resolved or not?

If the above is unclear and/or you are unsure about something, add a comment below.
TH-4622 20 Reputation points

2025-02-14T12:46:37.73+00:00

Hi Vallepu, no, I checked against your advice and everything is as you expected. There was nothing to change. The situation is the same. It seems like it's a certificate issue, however we have no custom domain names and have added no certificates, we're just using the Azure default provided FQDNs for the resources in this project so don't expect to need to configure certificates. Correct me if I'm wrong.

The SSL connection could not be established, see inner exception._

*2025-02-12T08:51:29.8020837Z ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure: RemoteCertificateNameMismatch
*
I don't know what this validation procedure is?

Thanks,

Tim.

Accepted answer

Oury Ba-MSFT 20,346 Reputation points Microsoft Employee

2025-02-14T21:12:16.0666667+00:00

@TH

I'm glad that you were able to resolve your issue and thank you for posting your solution so that others experiencing the same thing can easily reference this!

Since the Microsoft Q&A community has a policy that "The question author cannot accept their own answer. They can only accept answers by others ", I'll repost your solution in case you'd like to "Accept " the answer. Accepted answers show up at the top, resulting in improved discoverability for others.

Issue:

App Service unable to connect to Cosmos database with private endpoints - RemoteCertificateNameMismatch

Solution:

by removing.privatelink. and it works!If the resource is enabled with a private endpoint, you do not need to add the FQDN like privatelink.documents.azure.com instead, it should be CosmosDBAccountName.documents.azure.com
Please sign in to rate this answer.

0 comments No comments
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

1 additional answer

TH-4622 20 Reputation points

2025-02-14T12:48:24.1666667+00:00

FIXED!

I went back over some settings with one of our developers and he noticed he had the connection string in an environment variable on the App Service with the .privatelink. section added which we know shouldn't have been there. This I guess caused the certificate mismatch. After removing .privatelink. it works!

What we don't understand is how this got there as the dev would have copied this from the Keys section of the Cosmos Account which clearly doesn't list it with .privatelink in the name. That part is a bit of a mystery.

Thanks for your assistance!
Please sign in to rate this answer.
Vallepu Venkateswarlu 165 Reputation points Microsoft Vendor

2025-02-14T13:24:13.9+00:00

Hi TH

As I can see, your self-posted answer resolves the issue by removing.privatelink. and it works!If the resource is enabled with a private endpoint, you do not need to add the FQDN like privatelink.documents.azure.com instead, it should be CosmosDBAccountName.documents.azure.com as mentioned in my answer in step 3.

Hope this helps!
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

FIXED: App Service unable to connect to Cosmos database with private endpoints - RemoteCertificateNameMismatch

1 additional answer

Your answer