-
Notifications
You must be signed in to change notification settings - Fork 293
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Azure SQL Private Link: The remote certificate was rejected by the provided RemoteCertificateValidationCallback. #1535
Comments
@Nico-VanHaaster is domain of the private link same as public one? If not certificate wont be working correctly. the domain of the certificate needs to be same as AD user. See issue #1437 |
@Nico-VanHaaster on some other notes, are you able to get access using SSMS when encryption is requested by private link? |
Having same issue when trying to connect to AWS RDS SQL 2019 instance from a lambda running dotnet 6 and using Microsoft.Data.SqlClient 4.0.1 . |
@Nico-VanHaaster two questions to narrow down the issue:
|
These are private endpoints to Azure Sql Databases. We don't manage the certificates, SNI etc as it's an Azure PaaS services It is very easy to duplicate the issue following my OP. |
@Nico-VanHaaster we had this same issue within our environment, which is as follows: It turns out the the issue was due to not being able to reach the Certificate Revocation List. In version 4 of the SqlClient library there was a change in behavior that cause this to drop the connection - the exception that you are seeing. there is quite a long thread on a similar issue, scrolling to the bottom will show a fix merged into the SqlClient library that changes this behavior for V5 For us, the firewall was blocking access to *.digicert.com, in our case AppInsights had the failing requests (failures), and we could see the This was testable by jumping on the server (in our case both non-prod and prod, given non-prod actually worked) and running: In non-prod, we got the CRL, in prod we got a 403. So while there as a change in behavior, in the end the fix on our side is to update the firewall with appropriate rules. An alternative was to add Hope this helps |
@Nico-VanHaaster can you test with the latest release (v5.0) of M.D.S to check if the issue still exists? |
Closing due to inactivity. Feel free to comment if the issue still exists. |
This still exists. Trying to connect to a private endpoint of an Azure Database Server using a VPN results in this exception. |
@GilShvarzman the error message is very different in your case. the server has rejected the login. |
For anyone finding this thread I would like to report that updating the |
I experienced the same error when trying to run code first migrations on a GKE deployed SQL Server when I rolled back to Microsoft.EntityFrameworkCore.SqlServer 6.0.11 the connection succeeded and the migration went through. I think this still may be an issue. So, I would suggest reopening this issue. The full stack trace: System.Security.Authentication.AuthenticationException: The remote certificate was rejected by the provided RemoteCertificateValidationCallback. |
Stumbled upon this issue when attempting to connect Azure Function to Azure SQL using Managed Identity Auth as I was receiving the same error. My issue was DNS had not been correctly configured in my environment and so I was trying to use the Private Endpoint IP of Azure SQL instead of relying on DNS which was causing this error. Setting up Private DNS Zone in Azure to resolve the FQDN to the Private Endpoint has resolved the |
Although this issue may be similar to #1402 we have the following environments and scenarios.
Client
Microsoft.Data.SqlClient - 4.0.1 & 4.1.0 (tried both versions with same results)
Dockerized application running on Kubernetes. Image: mcr.microsoft.com/dotnet/runtime-deps:latest
Server
Azure SQL Database with Private Link enabled
Scenario 1
When executing the application from outside of the private link (using the public IP Address) we are able to connect the SQL Server Database with no errors.
Scenario 2
When executing the same application and within the Private LINK networks. Using the standard .database.windows.net (which resolves to .privatelink.database.windows.net and the internal private IP Address). We receive the error.
Scenario 3
When executing the same application and using private link (private IP Address) however adding "TrustServerCertificate=true". We are able to connect to the SQL Server.
Ideally we do not want to set TrustServerCertificate=true as from our understanding the could put us at risk of a man-in-the-middle attack.
Has anyone come across this issue in the past or have a workaround that keeps our connections secure?
Cheers.
The text was updated successfully, but these errors were encountered: