I have configured an Azure DevOps pipeline. When I try to run NuGetToolInstaller, I received ERR:self signed certificate in certificate chain. What is the solution to this error?
If you use Azure DevOps service, and your organization is secured with a firewall or proxy server, you need to add certain IP addresses and domain URLs to the Allow list by following this doc: Allowed address lists and network connections. And if you use self-hosted agents, please follow this doc: Run a self-hosted agent behind a web proxy to configure your agent.
If you use on-premise Azure DevOps Server, please refer to this doc: Run the agent with a self-signed certificate to check this issue.
In addition, if you recently changed your account, you could refer to this thread to check if its solution works for your issue.
BTW, you could review debug logs to diagnose pipeline issues.
Related
I'm trying to make a call to a wcf service from an Azure function hosted in Azure. The wcf service requires a certificate.
I'm able to call to wcf service when I do debug in local machine (I import successfully the cert) but in Azure I got the error "The HTTP request was forbidden with client authentication scheme 'Anonymous'."
I believe this is due to missing certificate in Azure side.
I try to upload the .cer to Public Key Certificates (.cer) but still doesn't work. My Function app still returns the same error "The HTTP request was forbidden with client authentication scheme 'Anonymous'."
Please let me know how to make my request accept in wcf service?
It would be nice if we have solution in Azure Portal rather than doing PowerShell.
Note: I use the same certification and source code when I do debug in local machine and when I publish to Azure Function.
Thank you.
thank you for your time.
The issue has been resolved in WCF side. The WCF guy adds the Azure Function IP address to the white list and it works. It's nothing to do with Azure Function.
Looks like the same issue with this one.
I'm working on some WCF application. I already have client-side and server-side. Both communicates using WCF netTcpBinding or netNamedPipe. I want also a certificate only on server side, similar as it is with HTTPS. I've found very helpful guide here click.
So according to this article, I'm interested in option 1 which is
Option one provides (C + I) no authentication will happen for the client, In this case the TCP SSL (not the HTTPS SSL) will be used to provide the Confidentiality and Integrity, and the service will be configured like this below.
For now everything is clear for me, unfortunately later we can read:
also you need to install the root certificate authority certificate for the service certificate on the client machine (typically in the Local Machine/Trusted Root Certification Authorities), and the service needs to have the below behaviour to specify the certificate for the service.
So here comes my question, is there any way to avoid changes on client machine? As mentioned earlier, I'm looking for a solution similar to WEB where the user is not obligated to install any kind of certificate on his machine.
Maybe I'm missing something, but maybe this rule applies only when I'm using a self-trusted/developer certificate? What if I will get certificate from a trusted company like Verisign?
Install the certificate on the client-side simply to guarantee that the service on the server-side is trusted and that communication I secure. Just like visiting a website, we usually have a built-in certificate for the site before we browse the website, so the browser prompts the website is trusted. Unlike self-signed certificate, website certificates are issued by trusted third-party organizations to a specific host (web server), so all we need to do on the client-side is to install authoritative trusted third-party certificate before accessing the website. but we directly install the server-certificate on the client-side when we configure a self-signed certificate in the Local CA.
In fact, Browsers/OS already have some authoritative third-party certificate built-in. such as GlobalSign, VeriSign, so we just need to buy a certificate from them and configure them on the server-side, in which case, the client always trusts the server.
In addition to installing the server-side certificate, we may also need to configure the server-side identity on the client-side, which is usually the public key of the certificate, or the hostname. These configurations are generated automatically if we generate the client proxy and invoke the service by adding a service reference.
Feel free to let me know if there is anything I can help with.
You don‘t need install somethings when you use an certificate issued by an trusted CA like GoDaddy and so on.
I've written a simple WebAPI Service (hosted with OWIN in a Windows Service) and put the [Authorize] attribute on the POST-method. As I understand, only "known" users can now access the service (don't worry, I know, all known users is not really safe yet).
My test client works fine so far when the host and the client are located on the same machine (f.ex. my workstation). However when I deploy the service on a server machine, and try again to call the service, I get a HTTP 400 failure when using the System.Net.Http.HttpClient and set httpClientHandler.UseDefaultCredentials=true, or a HTTP 401 when I use System.Net.WebClient and set webClient.UseDefaultCredentials=True.
So it seems the authentication mechanism acts different depending if the service is hosted local or remote.
For test reason I've also tried to set the credential explicit with user and password, but with exactly the same result.
However, what do I miss here? Any suggestions?
Thank you in advance!
verify the machine keys.
If the authorization server and the resource server are not on the same computer, the OAuth middleware will use the different machine keys to encrypt and decrypt bearer access token. In order to share the same private key between both projects, we add the same machinekey setting in both web.config files.
https://learn.microsoft.com/en-us/aspnet/aspnet/overview/owin-and-katana/owin-oauth-20-authorization-server
I just setup azure CDN endpoint. Pointed to my origin server. This works with http protocol. But the same files when i try https - it returns a 502 - bad gateway error. How do i troubleshoot and fix the problem?
A very similar setup works perfectly on another endpoint with HTTPs.
I think you may need to do is to serve your CDN assets over HTTPS. To do this you'll need to enable HTTPS within the Azure Portal
if still not then:
You can't yet use your own domain/SSL certificate with Azure CDN although there is a big request for this on the Azure Feedback Site.
If you've created a CDN for an Azure Cloud Service (e.g. http://[yourapp].cloudapp.net/cdn/) it's important that you create a self-signed certificate for your Azure domain ([yourapp].cloudapp.net). If you're using Azure Virtual Machines this can be done through IIS.
This caught us out recently when we enabled HTTPS for an origin server that did have an SSL certificate but it was for our own custom domain and not the *.cloudapp.net one.
for details click on http://benfoster.io/blog/azure-cdn-https
I followed this Microsoft Azure Mobile Service Authentication Tutorial, to try to add a server authentication function for my Windows Store C# app. However, after completing every step, when I run my app, it showed that the application cannot connect to the service.
I found this useful blog tallking about troubleshooting Azure Authentication issues in Azure Mobile Service. To troubleshoot, I type the link in the firefox web browser: myServiceUrl/login/aad, but I receive the error response:
Authorization has been denied for this request.
I also followed the same tutorial to test with Google Log in. It turns out to work properly. And when I type the link: myServiceUrl/login/google, the web browser directed me to the google log in page, unlike the Unauthorization error message when I type in myServiceUrl/login/aad.
Although google log in works out fine, but it is desired for us to use Azure Active Directory authentication. Could anyone tell us what could possibly be wrong? Any troubleshooting suggestions are also appreciated. Thank you.
The "Application cannot connect to the service" error comes from whenever the Web Authentication Broker in Windows receives an error response from the resource it is trying to reach. There are a couple of issues that can cause this, and I'll try and address the most common ones.
I noticed the tutorial you linked to is for the .NET backend. If you are using the Mobile Services .NET backend, there is an extra step required to configure the AAD server flow, and it's a common cause of the issue being described. In the tutorial, it's under the title "Configure your .NET mobile service for AAD login." On the backend project, you will need to install the Mobile Services .NET Backend Security Extension NuGet package. Then, in WebApiConfig.cs, you will need to include
options.LoginProviders.Remove(typeof(AzureActiveDirectoryLoginProvider));
options.LoginProviders.Add(typeof(AzureActiveDirectoryExtendedLoginProvider));
This allows the runtime to use the server flow in addition to the client flow (leveraging the Active Directory Authentication Library) which was first released with the .NET backend.
Pending that, or in the case of the Node runtime, the next thing to do is check the AAD configuration. In the AAD portal, make sure that your application registration uses your mobile service's /login/aad endpoint for the resource URI. It must match exactly the value provided in the Mobile Services portal. This should also be one of the redirect URIs if you are using the Node backend. For .NET, you would use the /signin-aad endpoint for the redirect URI instead.
You should also check that you have copied the Client ID from the AAD registration and pasted it into the Mobile Services portal's Identity Tab. For completeness, the "Allowed Tenants" field should also be filled out, but I don't believe it is the cause of this issue.
Lastly, if your AAD tenant is federated with ADFS, then there is a wide range of issues that could lead to this. The biggest case comes from the WAB needing to be configured for Enterprise Authentication. This typically only causes problems when the device is domain joined / on the corporate network. That behavior is a known bug for the Mobile Services Windows Store SDK, but there is a workaround available. Glad to provide that if needed.