Error when browsing Outlook.svc from IIS.
Cannot find the X.509 certificate using the following search criteria: StoreName 'My', StoreLocation 'LocalMachine', FindType 'FindBySubjectName', FindValue ''
Because your WCF service uses a certificate to secure communication, it is usually based on the transport layer or the message layer to encrypt and sign messages.
This makes it necessary to configure a certificate for the service when hosting the WCF service in IIS.
Certificates are usually stored in the certificate Store of windows computers and are divided into current users and local machines.
You can access it using the following shell commands.
Current User Store: Certmgr.msc
Local Machine Store: Certlm.msc
https://learn.microsoft.com/en-us/windows-hardware/drivers/install/local-machine-and-current-user-certificate-stores
The error details mainly indicate that there isn’t a specific certificate that meets the search condition in the Local Machine certificate store.
To solve the problem, we could specify another certificate or change the security mode of the WCF service.
Feel free to let me know if there is anything I can help with.
Related
When configuring the WCF-WebHttp security tab, I have set Security Mode to Transport, Client Credential type to Certificate.
When I go to browse for Client Cert, it comes up with the only options being Current User/My Store instead of Local Machine/Address Book. So, to see what happens, I imported my cert into the Current User/My Store. This worked fine and I imported the same cert into the Service Certificate tab. When a message is processed through the send port, an error like so occurs:
Cannot find the X.509 certificate using the following search criteria: StoreName 'My', StoreLocation 'CurrentUser', FindType 'FindByThumbprint', FindValue 'EF742FBAF0A13A7BEA859DC573308D52F0611CDB'.
When it tries to do a GET to the REST service we are trying to consume.
The configuration I'm using looks like so:
I'm assuming that since the BizTalk service is not running as myself, it can't find the client cert. I've also imported the cert into the Local Computer/Personal store to see if that helps, to no avail.
My question is, how can I get the correct client cert selected through the BizTalk interface? Is there a way to specify it in the Outbound Message Headers perhaps?
Certificate Usage Scenarios for the WCF Send Ports
Log on to each computer running BizTalk Server that will host the send ports as each host instance service account, and import the client certificate to the Current User \ Personal (My) store.
You can also do this by just launching the MMC as the BizTalk Service Account user.
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 want to enable transport security for my Self-Hosted WCF service that uses NetTcpBinding with Certificate as client credential type. The client for this service is a WebAPI. I created certificates using makecert and everything works fine in a single PC. But when I distribute the API and the service to different PCs, I get Certificate errors like "Cannot find Server certificate in Trusted People Store" on the client side even though the certificate is present in the store.
Can someone help me where I have gone wrong?
Store your own certificate in a resources file and read that in , then set the client credential to the certificate you just read.
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.
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.