We have a wcf client, which calls an external webservice. The service is accessed over SSL. The certificate is not a self signed cert. It is issued by Verisign.
The client is hosted in IIS 6 and the application pool's identity is a domain service user.
Every time we want our client to access the remote service we get the following well known exception: "Could not establish trust relationship for the SSL/TLS secure channel with authority-.."
It turned out, that once you access the URL with IE on the same server, our WCF client is working as expected and the certificate is accepted!
My conclusion is, that the URL accessed with IE modified the server in a way, that our WCF client is able to do the validation afterwards. What is our WCF client missing?
(I'm aware that one can circumvent certificate validation by returning true in the ServerCertificateValidationCallback, but this is not an option for production.)
Considering the situation as described, I suspect that your IIS hosted client is not able to load the Verisign root certificate. And it is always a bit unclear to me under which account such IIS based client is trying to access the certificate store. It might be your domain service account user, it might be the ASP.NET user, it might be some other system defined account. This often causing the error.
When you browse the service with IE, there is no doubt about the user (your own credentials) being able to load the Verisign root certificate and resolve the trust relationship correctly.
Please:
Make sure the Verisign root certificate in in the Trusted Root Authorities store under the Local Computer Account
Have your app.config of your client refer to the correct root certificate to be loaded from the correct store.
You might want to run ProcessMonitor to find out which user is trying to load the certificate from the store.
Related
I have some applications that use pinned client certificates as credentials to access WCF services, and am in the process of moving some of this functionality into ASP.NET WebAPI and would like to continue accepting pinned certificates, but over mutual TLS instead of as a WCF service credential.
..However, I'm getting 403's back from IIS when I try to submit requests, and based on IIS failed request tracing, the reason is: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
This is not wrong. The cert in question is self-signed and absolutely not trusted for any reason except that it's been explicitly tied to an identity in the software. And..I want IIS to accept it so we can get to the application to decide how to proceed. My code is never run, however, because the cert is already rejected.
Is it possible to force IIS to pass the cert through, the way a WCF service would, without affecting other websites or processes running on the server?
Here's my setup
an IdentityServer 4 as a stateless reliable ASP.NET Core service.
a WebAPI as a reliable ASP.NET Core service.
using them with a JS client, it is now working with HTTP. The problem is with HTTPS. The WebAPI needs to request the openID config via htttps [is4URL].well-known/openid-configuration. I'm getting this error
System.InvalidOperationException: IDX10803: Unable to obtain
configuration from:
'https://localhost:9999/.well-known/openid-configuration'. --->
System.IO.IOException: IDX10804: Unable to retrieve document from:
'https://localhost:9999/.well-known/openid-configuration'. --->
System.Net.Http.HttpRequestException: An error occurred while sending
the request. ---> System.Net.WebException: The underlying connection
was closed: Could not establish trust relationship for the SSL/TLS
secure channel. --->
System.Security.Authentication.AuthenticationException: The remote
certificate is invalid according to the validation procedure.
can anybody help me to make this work in localhost with the SF Local Cluster Manager?
Thanks
Here's my two cents worth but it will need to be verified...
I am assuming that you have created a self-signed certificate using following article or similar but the certificate has same properties.
https://learn.microsoft.com/en-us/azure/app-service-web/web-sites-configure-ssl-certificate
This means that the certificate can not be verified via actual CA. Ofcourse with self-signed certificate this is not possible.
Now when you upload the certificate to Azure App Service it installs in CurrentUser - MyStore. With self-signed certificate, it also needs to be installed in LocalMachine Root store.
This is becouse then the machine's Certificate Authority can verify that certificate to be valid. (May be a security expert can correct me if I am wrong but thats my theory). I have got same setup on my locally hosted windows server where the self-signed certificate is installed in Root Certificate Store as well as Personal store and the app works. This is the reason I belive this happens.
So this part which needs to be verified. Following is the article which shows you how you can do this in Azure App service.
https://learn.microsoft.com/en-us/azure/cloud-services/cloud-services-configure-ssl-certificate-portal
AGAIN THIS IS JUST A THEORY THIS NEEDS TO BE VERIFIED. :)
EDIT:
I have just tested this and it is the case. In cloud services you can do as shown in second link above and create Web Job which install certificate in appropriate store.
For Azure App Service unfortunaltly you dont have access to root store. It has to be install in CurrentUser's personal store. Which means the self signed certificate will not work, and you have to purchase a real certificate. :( I think this is a real thumb down to Microsoft. Why should I need to pay for real certificate for my dev/test environment? (Rant Over)
For Service Fabric you will need to find out how to install certificate in Root Store as well as personal store (if thats possible at all). Here's Links that might be useful
http://ronaldwildenberg.com/running-an-azure-service-fabric-cluster-locally-on-ssl/
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-security-update-certs-azure
Hope this helps.
I have the following setup:
A self signed certificate for development purposes
An OWIN hosted Web API, deployed on a local Azure Service Fabric Cluster as a ASF service. The Web API uses HTTPS facilitated with the dev certificate in question.
A simple .net client application that calls the Web API. In that application the ServicePointManager.ServerCertificateValidationCallback method is set so it always returns true (since the CA is not trusted)
Both the client application and the Web API are on the same local development machine. The certificate is installed in that same machine on the "machine store"
Now I am able to make calls to the web api using Fiddler by providing the required client certificate. However when I try to do the same via .net code (be it RestSharp or WebRequest) the client certificate is not present in the RequestContext object on the server side. This result in an Unauthorized response. I do not think the problem is with the client code, the certificate is loaded correctly and assigned to the http client or request. Fiddler shows encrypted tunneling to the server. However the client certificate does not seem to be present at the server side.
I am at a complete loss regarding what am I missing that could cause this behavior. Any help will be deeply appreciated.
Install the certificate into the 'Local Machine/Trusted People'.
The server needs to already trust the certificate before it asks. The CertificateRequest message that it sends lists the acceptable CAs that can sign the client certificate. If the client certificate's signer isn't in that message, it can't send it.
How you accomplish that in your environment is left as an exercise for the reader. In general now that SSL certificates are available free there is little reason to indulge in the time costs and administrative inconveniences of self-signed certificates. IMHO there wasn't even if you were paying for a CA signature.
I had a problem when a service called another service over HTTPS and it couldn't setup a secure connection. My problem was that since the service is running as NETWORK SERVICE, it couldn't find the certificate, because it was looking in the localmachine/my certificate store.
When I was running from my web browser it was working fine because then, my browser found the certificate in the currectuser/my certificate store.
Add the certificate to the machine/my store and see if it helps.
Scenario: We have a server located in a Windows Active Directory domain which implements a web service API, implemented with WCF and exposed via IIS 8 over HTTPS. The clients making requests to the web service are not located in the domain. However, they should be mapped to AD users via SSL client certificates. I.e., when making a HTTP request, they include a client certificate, and I want that certificate to be mapped to the corresponding AD user.
I know that IIS supports two ways of client certificate authentication, IIS Client Certificate Authentication and Client Certificate Authentication using Active Directory. I'd really like to use the AD approach in our scenario, as it makes the management of client certificates easier (we can map certificates to users in the AD rather than in the IIS configuration).
However, the docs linked above say that,
[Client Certificate Authentication using Active Directory] requires that the IIS 7 server and the client computer are members of an Active Directory domain [...]
This indicates that we cannot use this approach, since our client computers are not part of the AD domain. However, this doesn't really make sense to me. How would the server even know whether the client making an HTTPS request is in the same domain?
So, here's the question: Can we use Client Certificate Authentication using Active Directory with clients outside the AD domain or not?
We've now had the chance to implement and test our solution with a machine outside of the AD domain. Indeed, it works - the client computer does not have to be part of the domain, the documentation seems to be wrong here.
I have a client site that when a button is clicked it calls a wcf web service. The client site is http, while the url for the web service is https and requires a certificate. I have a valid signed private key certificate I am using.
Everything works fine on my localhost; however, after deploying to a windows 2003 server running iis 6, I get the below error when the web service is called:
Could not establish trust relationship for the SSL/TLS secure channel
with authority "host's url"
I added the cert to the store, using same web.config that works locally. I have validated that the web service call finds and sets the valid X509Certificate.
Not sure what I am missing, and I don't want to override the servicepiont manager to return true every time.
Any ideas or things I might looks into?
Found the problem.
The root certificate which the host of the web service uses was not trusted by my server. (not sure why it was on my local machine and not my server). I found this out by opening the host's url in a web browser from the server to view their wsdl and got the security warning.
Remedy: went to the issuer's site downloaded their root cert and added to my trusted root certifcation authorities.
Bam, it works now.
If it is a private cert it must be added to both the client and the server as no client can validate its root key.