I did a console application to manage the azure server using the azure service management rest API. And I followed the instructions from http://msdn.microsoft.com/en-us/library/windowsazure/gg651127.aspx to create certificate, upload to azure under subscription level. import to local My(personal) folder. everything works well. I can get the hosted services. create new host service.
but when I used a web proxy on my machine. the response always be 403 Forbidden. I tried to set the proxy in HttpWebRequest, but still the same error.
Also, I run this console application in a aws EC2 and have the same 403 Forbidden error(maybe EC2 also use proxy?).
Suppose the proxy server should forward the web request to azure management rest API server with the certificate, but I guess it's not. someone told me maybe this certificate only self generated and not valid. so the proxy server refused it. not sure if that is the cause.
Azure Management APIs require signed headers. Some proxies makes changes (add/modify) header tags which would then invalidate the signature and cause the 403.
w.r.t. EC2 - did you install your management certificate on the VM? Without it the request will fail with a 403.
One of the suggestions is to use Fiddler to compare the request before & after the proxy. That will tell you what (if anything) is changing.
Related
We have an Azure Application Gateway V2 setup with WAF feature enabled. We ran into trouble when suddenly, the health of all our backend pools (3 in our case) started showing unhealthy and the error was being shown when we checked backend health:
Backend server certificate expired. Please upload a valid certificate.
Now, the same certificate is applied on application gateway and on the backend pool servers/VMs. We had to switch to non-SSL port for our backend servers to make the problem go away.
I am not able to pinpoint the problem as if any certificate is expired when applied to backend pool VM should give the same error once applied to the application gateway itself. Can someone help to identify the actual root cause of the problem and why it is showing error only at the backend pool level?
Very important thing is that the certificates being shown in browser when the backend pool URL is opened is showing still more than 2 months before it expires.
Thanks.
I can't comment as I have not enough reputation point but this might be connected to the fact that Sectigo's legacy AddTrust External CA Root certificate expires on May 30, 2020
https://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020
In my case, the browser was also showing that everything is ok, but HttpClient responsible for doing the healtheck was not able to connect to the endpoint. What is interesting is the fact that I wasn't able to hit the endpoint with HttpClient running on dotnet core 2.1 but on dotnetcore 3.1 everything was fine
Same thing happened with my web app (roughly at the same time as reported by you) hosted on Azure which is also behind an Application Gateway V2 setup with WAF enabled. Taking a restart of the web app resolved the error.
I'm not sure what the underlying issue is with Application Gateway at the moment, but a restart of the webapp worked for one of my apps, however an other one stayed unhealthy. I could successfully connect to the webapp from the local server however, just not through the app gateway.
What worked for me in the end was removing the server from the backend pool and re-adding it. Once it was added back, the Backend health changed to 'Healthy'.
After checking via openssl, it was identified that the intermediate certificate was revoked by the CA and it was causing the issue.
To check whether certificate is valid or not, Online Certificate Status Protocol can be used or CRI file can be downloaded and the certificate can be checked in that file. The second method has little drawback that CRI files take a little time at the CA end to be updated.
I have an Azure app service and in some cases I need to send a web request to a non-azure webserver. What do I need to do to make it possible.
Currently the web request fails with no clear error message.
In response to a HttpClient Put request I get a System.Net.WebException exception which says there were errors.
THe same request works from a desktop application.
If your webserver is reachable from the internet you should be able to access it through your App Service. Try to log a ping to your webserver and google (8.8.8.8).
If your App Service is in a VNET you should enable some outbound rules to your webservers IP adress.
The server I am connecting to is an other Azure service. After some more investigating, It appears that I can connect to it if I do not use SSL (i.e. http://) but the connection is immediately closed when using SSL (https://). I assume that the problem must be related to the use of SSL.
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.
I'm trying to access a third party service from Azure App Services (ideally Functions, but a Web App would do). However this service is hosted on a non-standard port, e.g. https://myservice.com:445
I'm using the System.Net.Http.HttpClient to make a POST request, but consistently get a SocketException:
An error occurred while sending the request. Unable to connect to the remote server An attempt was made to access a socket in a way forbidden by its access permissions 1.2.3.4:445
The code works on my local environment (Functions emulator or Kestrel), but fails on Azure. I tried using a service hosted on a regular https endpoint, e.g. https://myotherservice.com, and the call goes through normally.
I'm assuming there is some sort of outbound firewall rule that's preventing the fist call, but I haven't found any configuration option to disable this. Is it possible? I unfortunately cannot change the endpoint of the service I need to call.
After checking your application, I did indeed find that those outgoing requests were being blocked by the infrastructure.
I was also able to find public documentation covering those ports here:
https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox#restricted-outgoing-ports
Almost have this working. Almost.
My set up is that I have an Azure B2C Tenant set up, and some modified example code that I've changed to reflect the Tenant information. This all works fine locally, with a localhost uri.
My remote set up is a Ubuntu 16.01 server, with a Nginx 1.10.0 webserver acting as a reverse proxy to a .NET Core 1.0.4 and all with a LetsEncrypt SSL cert.
The proxy serves .NET projects fine, however when I hit the sign in it takes me over to the B2C login with an incorrect redirect_url.
I'd expect the value to reflect what is in the settings file, "https.sub.host.suffix/signin-oidc" instead I'm getting "http.sub.host.suffix,sub.host.suffix/signin-oidc"
Any ideas or suggestions appreciated!
If NGINX is offloading SSL/TLS and then calling the .NET Core app, check as most probably is doing it through open HTTP (port 80).
You either need to ensure HTTPS all-the-way, or signal an HTTPS scheme to get triggered if HTTP endpoint was called.
As the .NET Core App gets a request through an HTTP endpoint, every URI created by it will keep that same scheme. So, you'll need to force https:// at link building time.
Hope it helps!