I am building a site that needs to call a 3rd party web service over https. The service requires an X509 certificate for authentication.
I can successfully call the service and get a response back using a console application, or a web application running in visual studio web server, this suggests to me that the code, and certificate provided by the 3rd party are all ok.
As soon as I deploy the site in IIS, it cannot connect to the service, I am getting "The request was aborted: Could not create SSL/TLS secure channel" error. I spent a couple of hours trying to figure this out, assuming it was permissions related as IIS app pool running under network service etc.
The certificate is installed in the local machine store, not current user, and I have granted network service (also added everyone is desperation!) using the winhttpcertcfg tool and manually in MMC > Manage Private Keys, so I am confident that the network service account has access to the certificate.
I also used the FindPrivateKey tool and checked the physical windows file and permissions look ok! I tried using identity impersonate in the config, using my windows account and that doesn't make a difference.
I am pulling my hair out with this one, can anyone give me any suggestions on what to try next?
Cheers
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 am developing a windows service application that will run on customer PC/servers and access a Web API endpoint hosted in an Azure Website. It needs to authenticate the user, and I would prefer not storing credentials on the customer's machine. So, I've landed on client certificates to authenticate the users. I have this working against a local, non-Azure Website IIS instance with self-signed certificates. However, I'm unable to get it working in an Azure Website.
As far as I can tell, there are two issues that I'm not finding much documentation on:
How do I install my own CA certificate in the Trusted Root of the Website instance(s)? Or will this only work with CA certificates that are already trusted?
How do I enable "Accept Client Certificates" for this application? In IIS you do this under "SSL Settings". Documentation indicates that modifying the system.webServer/security/access node of app.config will accomplish this, but obviously you can't do that in Websites. Documentation for websites suggests this node is unlocked for use in web.config, however adding that node results in an error "The page cannot be displayed because an internal server error has occurred.", even if custom errors is off.
For Azure web sites vs web roles client authentication options are rather limited. Websites don't let you run programs with elevated permissions, which is required for making IIS changes and storing certificates into the trusted root.
There's a way to configure you website to always (you don't get the benefit of making it optional as with IIS 'Accept' configuration) request client certificate. This feature is currently only available through Azure management REST API, you can't access it through the portal UI. You can find more information here.
Essentially you turn on clientCertEnabled website setting to true. The mechanics of this option are different from traditional client authentication where server needs to have a CA certificate with which the client cert is signed in its trusted root. The server doesn't run any validation on the client certificate, the application needs to run the cert check itself, which comes in a request header "X-ARR-ClientCert". GetClientCertificate() extension method on HttpRequestMessage will parse it automatically.
Alternatively, you can host your Web API as a web role. That gives access to running startup tasks with elevated permissions that allows access to trusted root and making IIS configurations, more details/examples here. You can either copy the CA certificate to the app folder or upload to the user store via Azure portal so that it is available for copying over to the trusted root in a startup task. IIS changes can be made via “Microsoft.Web.Administration” library available as NuGet package through ServerManager class.
For question 2, here's a blog post on how to install client certificates on Azure Websites: http://azure.microsoft.com/blog/2014/10/27/using-certificates-in-azure-websites-applications/
For question 1, you can't install your own CA certs as trusted root certificates, but if you have certs from a CA that's already trusted then you can use them without any issues.
We are developing an ASP.NET WebAPI that is hosted in IIS and authenticates using client certificates with iisClientCertificateMappingAuthentication.
In our on-premises development environment we have tested IIS 7-8 and Windows 7-8/Server 2012, all of which work fine.
We have set up a demo environment in Azure with a VM running Windows Server 2012 R2 and IIS 8. Using this configuration we have yet to successfully pass through IIS client certificate validation, where we consistently receive an HTTP 403.16 error.
The service is consumed by a custom iOS app that we have verified is sending the client certificate, which was expected since my understanding of the error implies IIS is unable to validate the certificate that it received.
The Client Certificate Authority is installed in the Trusted Root Certification Authorities and the Client Authentication Issuers stores for the Local Computer.
Pretty much all of the resources we can find on this issue propose the solution here: http://social.technet.microsoft.com/Forums/en-US/fae724e8-628e-45a5-bf39-6e812d8a1a70/40316-problem-in-iss8-on-mp-in-dmz?forum=configmanagerdeployment
where it's suggested we add a registry setting for ClientAuthTrustMode. This has not resolved the issue for us; we also did not need to do it for any of our local testing which involved the exact same OS and IIS versions.
We've spent days on this with no progress and were hoping someone may have some insight into this issue. Is there any default configuration that we have yet to come across to enable this form of authentication for VMs in Azure? It seems as though IIS on a VM in Azure is unable to actually validate against the CA in Trusted Root. One idea I had was that perhaps the certificate is being stripped from the request before it's routed to IIS, but again, that seems unlikely given my understanding of the error code.
Has anyone gotten a setup like this to work?
I happened upon this knowledge base article, maybe it can help you
http://support.microsoft.com/kb/2802568
Apologies for what is probably a question about a simple task but I'm brand new to Azure and a little worried I get this wrong. Actually, I have a new client and don't even have the access yet to their Azure yet have a proper look. The question is:
My new client has an existing MVC application running on IIS within Azure. This application must communicate with a third party SOAP (.asmx) web service that requires parts of the SOAP message to be signed using an SSL digital certificate.
So, I need to install the certificate on Azure. My problem is that the articles I have found deal with securing the website using the certificate and Https - which I don't want.
Can someone please point me to a good article (or show here if simple enough) that shows how to install it for the purpose of communicating with this third party service?
Any help is really appreciated here so that I can hit the ground running.
The approach for installing any certificate is the same. So you would use the same approach as you would for installing SSL certificate. So the steps would be:
Upload the certificate first in the cloud services certificate section. Note down the certificate thumbprint.
In Visual Studio, open up your role's properties and go to "Certificates" tab and specify that certificate thumbprint along with the certificate store location where you want this certificate to be installed.
I am not able to connect to Azure via a webapp deployed in tomcat.
I am getting the below error though i am sending the correct input for the keystore pwd.
"Keystore was tampered with, or password was incorrect"
Plz comment.
When you try connecting to Windows Azure Management Portal, using Service Management API, the connectivity is created over SSL tunnel and a certificate is used to create the SSL tunnel.
I would suggest first that, it is not a Windows Azure specific problem, it is more of a Java/Tomcat related issue mainly happening because while selecting the certificate to create the SSL tunnel the code met with some problem.
To solve this problem, I can suggest the following:
In your VM/Physical machine, where Tomcat web application is running try to locate the physical keystore file first and delete it.
After that try creating keystore with correct password and setup that password properly in your Tomcat configuration
Trustcacerts password was supplied wrongly ! Now it works