I'm in the Azure Portal UI attempting to connect our new Azure Search service to our SQL Server on our Azure VM. The UI very simply asks me for a connection string, a username and password. I started by using the exact connection string that is used in all our .Net config files, with which there is no issue connecting. No matter how I tweak the connection string based on many threads I've read here at S/O (set Encrypt to False, set TrustServerCertificate to True) I get this error testing the connection:
"A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 - The certificate chain was issued by an authority that is not trusted.) Learn more about connecting to Azure SQL VMs, http://go.microsoft.com/fwlink/?LinkID=826562"
I must admit that the info in that MS link is like a foreign language to me. As none of those steps have ever been required for me to connect to this SQL Server, I continued my research which lead me to all the different aforementioned tweaks to the connection string.
As none of these tweaks worked, it seems the answer truly lies in that MS article - would someone be able to provide a step-by-step as I am completely new to certificates.
I'd also still fail to understand why I have no issues connecting to this SQL Server from any other app/service/util and only get this error here, but if it works it works and I won't complain!
The basic issue here is that your SQL Server must have a certificate issued by a trusted certificate authority, not a self-signed cert typically used in intranet apps. I suspect the connection strings worked in other apps because they either don't use encryption or trust self-signed certs (that's what TrustServerCertificate setting does).
Please follow the directions in the article you linked - that's the most authoritative step-by-step guide I'm aware of.
Alternatively, if you don't want to configure certificate and ports, you can consider using Azure Data Factory to push data to Azure Search.
Related
I'm using Azure Functions with .NET 6 on an S1-tier App Service Plan with regional VNET integration. In our scenario, we execute some SQL queries accessing an On-Prem database which works pretty fine at the first glance. Unfortunately, sometimes the virtual network connection seems to break and our queries run into following error:
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 - An attempt was made to access a socket in a way forbidden by its access permissions.) An attempt was made to access a socket in a way forbidden by its access permissions.
After disconnecting and reconnecting the function from VNET, it starts working again as expected (I found this approach here)
But it seems like this is just a really poor workaround. Does anybody know how to fix this indefinitely? I've already tried creating a new function app but that didn't change anything.
• According to the error that you are encountering, there might be some issues with the Firewall in the on-premises environment or the TCP/IP connection being established. Thus, I would suggest you to please check all the issues mentioned in the documentation link below and verify whether all the instances of practices mentioned in it are followed correctly: -
https://learn.microsoft.com/en-us/troubleshoot/sql/connect/network-related-or-instance-specific-error-occurred-while-establishing-connection
• Secondly, I would suggest you to please check the SQL Browser Service in the on-premises SQL Database server and check whether ‘UDP port 1434’ is whitelisted for communication between the two environments or not along with TCP 1434. Also, when executing SQL queries to access the on-premises SQL DB, ensure that the instance name is input correctly along with the port number. Also, when mentioning the port number, ensure that it is preceded by ‘,’ and not ‘:’.
• Finally, I would suggest you enable diagnostic logging for an app service plan by referring to the below documentation link that will help you figure out the reason for your connection error to the SQL DB. Also, you can browse through the Kudu console by accessing the url:- https://****.scm.azurewebsites.net/ (enter your website name instead of ****). You should be able to find the log files under the debug console. Please check if there are any failure logs: -
https://learn.microsoft.com/en-us/azure/app-service/troubleshoot-diagnostic-logs#:~:text=To%20enable%20application%20logging%20for,itself%20off%20in%2012%20hours.
https://github.com/projectkudu/kudu/wiki/Investigating-issues
Note: - Please check whether your API URL connection string used in the function app is being replaced correctly and troubleshoot your connection variables thoroughly.
We are developing a app on azure virtual machine and the VM has ngnix installed with TLS version 1.2. The app consists of two action which performs salesforce and office365 oauth flow. The app worked pretty fine on local and azure app service too.
Problem
For some reason, we are moving the app to azure VM. Here is the problem, after oauth the flow returns a code and we need to generate the access_token using that code through a https request to office365 endpoint. The endpoint response is either timeout or Error Read ECONNRESET.
Analysis
The only working URLs,
http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fvault.azure.net
https://myapp.vault.azure.net/secrets/{Secret-Name}?api-version=2016-10-01
Both the above is used to fetch the access token and key vault secrets. Luckily, this is working pretty fine and I am able to get all the secrets from azure key vault.
But the below urls are either no response timeout or Error: Read ECONNRESET
https://login.microsoftonline.com/{Tenant-Id}/oauth2/v2.0/token
https://test.salesforce.com/services/oauth2/token
I’ve also tried other public or fake rest APIs like,
https://reqres.in/
https://jsonplaceholder.typicode.com/
None of them seems to be working. Does anyone faced this kind of issue?
Just clarify the answer from the comments for more references.
The Error Read ECONNRESET means the other side of the TCP conversation abruptly closed its end of the connection. This is most probably due to one or more application protocol errors. Refer to this SO for details.
Moreover, you have only working URLs from Azure Instance Metadata service and Azure Key Vault service, other public or fake rest APIs are failures. So you properly face internet connectivity issue on that VM or VNet itself. You could check if the firewall is blocking the outbound traffic to the Internet on the local VM or NSG rules.
In the end, some change in the firewall settings fixes this issue.
Scenario:
I am connecting to my Azure SQL db(Paas) instance from my laptop using SQL management studio.
Are my queries and the result data encrypted in transport here. I am worried that since the traffic is going through internet, can "Man in the middle attack" happen here.
What are other security concerns/steps I should be taking care of here?
What I read so far from the internet is that Azure SQL Db only allows encrypted connections, so wish to double check my findings and also undertand more if someone has good answers.
Are my queries and the result data encrypted in transport here.
Yes. From this link:
All connections to Azure SQL Database require encryption (SSL/TLS) at
all times while data is "in transit" to and from the database. In your
application's connection string, you must specify parameters to
encrypt the connection and not to trust the server certificate (this
is done for you if you copy your connection string out of the Azure
Classic Portal), otherwise the connection will not verify the identity
of the server and will be susceptible to "man-in-the-middle" attacks.
For the ADO.NET driver, for instance, these connection string
parameters are Encrypt=True and TrustServerCertificate=False.
What are other security concerns/steps I should be taking care of here?
Not specifically for man-in-the-middle attacks, but you should consider setting Firewall Rules properly so that users only from certain IP addresses can access your database.
I would strongly recommend reading this document for securing access to your Azure SQL Databases: https://learn.microsoft.com/en-us/azure/sql-database/sql-database-security-overview.
There are 3 elements to securing your connection to an Azure SQL db.
Encrypted connection (by default)
Allowed IPs. In azure SQL, you automatically get a firewall that
you have to configure to allow access from the internet. Ensure
that you are only configuring the IPs required for access.
DNS resolution. Ensure that you are using a secured/trusted DNS
server to resolve addresses to their correct locations
The underlying connection was closed: Could not establish trust relationship
for the SSL/TLS secure channel
I am facing the above error in MABS (Microsoft Azure BizTalk Services).
Any particular solution for this?
According to my knowledge it may be either a certificate error or an database access error. I am getting this while deploying where as building is successful.
It's very likely your ACS namespace, issuer, or access key is incorrect. Building wouldn't give you this error, as building is only done in the local environment. Deploying actually makes a secure connection with MABS so upload your assemblies.
Another option to check would be to make sure that your current firewall rules allow for the proper connections.
I have a .NET web application which connects to a database hosted in the cloud on Microsoft's SQL Azure platform. Now I'd like to use Domo, a third-party cloud-based business intelligence service, to do some reporting on the data in the Azure database. The Domo consultant has told me that he needs a CA certificate path for the database server (in addition to other standard connection info) in order to connect to it. He has suggested that I need to get a cert and apply it to the database server. However, according to what I have read in the documentation, SQL Azure always uses SSL; it is not possible to connect to it otherwise. Given that I am already connecting to it successfully in my application (using Entity Framework 6), there must be a cert already there (Microsoft's), and therefore a certificate path. How do I find out what the certificate path is? The database server name has the form xxxxxxxxxx.database.windows.net.
And to take this one step further you can get the path and content of the cert by running the following command through OpenSSL.
openssl s_client -connect {yourdbname}.database.windows.net:443 -showcerts
Took me awhile to remember how to do that.
I was able to confirm that SQL Azure DB always uses SSL and therefore does have a cert already installed. I found the certificate path by plugging the database server name (xxxxx.database.windows.net) into the online SSL certificate verification tool at DigiCert.com (https://www.digicert.com/help/). The path was listed at the bottom.