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.
Related
I have created an asp.net web application and deployed it in IIS10. The design of the application is to require a client certificate for each user which will be provided by us. For testing purposes I created a self-signed certificate using the makecert.exe and followed the instructions at https://blog.jayway.com/2014/10/27/configure-iis-to-use-your-self-signed-certificates-with-your-application/. I added the certificate in the MMC Personal Certificates.
I also configured the iisClientCertificateMappingAuthentication in the IIS Configuration Editor using the one-to-one mapping approach. When I tested it on the browser, at first it asked for a digital certificate (which is correct), but when I clicked the certificate I added on the bindings it returns an error "Your client certificate is either not trusted or is invalid."
What should be the problem here since the installed client certificate is already added in the IIS one to one mapping configuration? Do I need additional configuration in the IIS?
My local development (5 node) cluster have two stateless services installed. One .Net Core Web Gui service and one .Net Core WebAPI service.
Both are configured to use a https endpoint.
The certificates are self signed certificates and are added to both trusted root and personal (in both current user and localmachine).
I can access both endpoints using a local browser without getting any certificate errors. It says the connection is secure and the certificates are trusted.
So far so good.
But when my Web API services calls my Web Gui service, is says it cannot create a trusted connection.
Why can my local browser create a trusted connection but not the Service running in the local cluster?
Does a Node in a local cluster have it's own Certificate Store?
So it turns out that I missed adding the certificates to the machine root and that's what caused the problem.
For local SSL to work, I needed to to add the self signed certificates to:
localmachine/my
localmachine/root
This lets services call services from within the local cluster.
currentuser/my
currentyser/root
This lets my browsers call my services without ssl errors.
Hope this helps someone else :)
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.
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.
I have Azure app containing 4 sites in a single web role (differentiated by host headers). I setup the sites to run over SSL. I issued 2 self signed certificates: 1 as CA installed into Trusted Root CAs store and 1 wildcard SSL certificate (issued using the first one).
The application runs, however I'm getting certificate error 'Mismatched address' in Azure Compute Emulator. I examined the mismatched certificate and found out it is not the one specified in service configuration. I went into IIS management console and checked the bindings - there was no cert set for my sites. So I setup the wildcard certificate manually in the site bindings. But in browser I still have mismatched certificate, still the one for 127.0.0.1 (comming with DevFabric). How can I make the IIS to return the correct certificate configured for the site?
(I have some services in the web sites consumed by Silverlight application and it does not work when there is forced manual confirmation of the certificate by user.)
Thanks!
Are you sure that you really access the service using https://127.0.0.1 and not using https://localhost?