We have a wcf service hosted in IIS. We like to restrict the client callers to known clients so we implemented a custom X509CertificateValidator. The service is configured with WSHttpBinding binding and IIS set to SSL and require client certificate. Everything is working as expected.
However, we found that we have other aspx pages hosted within the same site that should not require client certificate. It breaks our usage pattern.
I read that turning the IIS setting from Required Client Certificate to Accept Client certificate does not work. I tried this out, while still passing in the client cert from client and it seems to invoke my custom validator. However, using wcf proxy library, I'm unable to call it without a client cert to verify not passing one in.
If "accept client certificate" is not an option, what is the best alternative? Adding some type of message inspector?
Thanks very much in advance.
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?
Configuration:
Iis web app with require ssl and accept client certificates.
Web app contains wcf service.
Requesting a page from web app works as wel as requesting the wcf svc
Calling wcf from wcf client give 406.13 with same client certificate send.
Same setup works on development and several other production servers.
Checked cert store trusted root for illegal certificates. ( issued by <> issued to )
Applied reg setting schannel (from MS solutions).
How is this possible that browser requests do not fail but wcf requests do?
Must be something iis or windows related as same code works on other machines.
Any way to get more info why it thinks the client certificate is not trusted.
P.s. the wcf service method is never entered ( as my own tracing shows nothing)
Maybe this SO answer might be of some help. CAPI2 event log is the place where you should find more information why WCF considers the client certificate not trusted. Enable it both on the client side and also on the server side.
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.
I think there's a gap in my mental model of WCF authentication, hoping someone can help me fill it in.
So, I'm creating a WCF service and would like to have clients authenticate using certificates, and message-level security. I'd like the service to validate these using chain trust so that I don't need each client cert installed on the service. For now, I'm not interested in having the service authenticate to the client.
Here's my understanding of what's needed to do this:
The client needs a certificate signed by a CA that's trusted on the service side.
The service needs a CRL installed for that CA.
The service config should have message security turned on, specify clientCredentialType="Certificate", and chain trust for client certificate validation.
The client config should have message security turned on, specify clientCredentialType="Certificate", and an endpoint behavior that tells how to find the client certificate in the store.
The client makes a request to the service, sending its certificate. The service sees that the client's cert is signed by its trusted CA and lets the request through.
Now, all of the walkthroughs of this process I've found also include a step of creating a certificate for the service. None of them explain what this is for, which is throwing me. Why is a service certificate needed if I just want to authenticate the clients?
You are right. In theory no server certificate is required, in practice wcf enforce you to use one. The good news is that you should use a dummy certificate for the server and also set ProtectionLevel to SignOnly. I suggest to read this article which talks on a similar scenario and mostly relevant.
Do not really know how x509 works.
If I have a Web Service that needs to authenticate and validate the client, and he uses a ClientCertificate, could he send me some information that I could then validate against?
I do not create the Web Site itself so I can't be sure they would do it right. I don't wan't to allow someone to say to the Web Service "It's okay, I ClientCertificated him and he's good".
You can implement your own custom client certificate validator but its usage will be different based on the way how do you use the client certificate. If you use pure message security your validator will be the only component used to validate the certificate. If you use HTTPS with client certificate (transport security) the certificate will be first validated by Windows (= your service hosting server must trust the certificate) and after that it will be passed to WCF and validated by your validator.