I have a WCF application running as net tcp and installed a server certificate (xxx.domain.com) in server.
Enabled Transport with certificate security. IIS web site configured and its working fine with above certificate also its not installed in local machine as its found correct root ca and intermediate certificate .
Can i call the wcf service with out installing certificate if yes which one i should use Root CA or intermediate .
Please see the certificate chain below
Root CA
Intermediate
xxx.domain.com
Here is the code used in client
channel.Credentials.ClientCertificate.SetCertificate(
StoreLocation.LocalMachine,
StoreName.CertificateAuthority,
X509FindType.FindByThumbprint,
"tried intermediate and root CA its not working ");
When a WCF service created by Nettcpbinding authenticates the client with a certificate, we need to specify a service certificate in the service credentials.
sh.Credentials.ServiceCertificate.SetCertificate(StoreLocation.LocalMachine, StoreName.My, X509FindType.FindByThumbprint, "5ba5022f527e32ac02548fc5afc558de1d314cb6");
Then the service will work properly. Subsequently, the client should provide a client certificate when calling the service since the Clientcredentialtype property is Certificate on the server-side.
binding.Security.Transport.ClientCredentialType = TcpClientCredentialType.Certificate;
Client-side.
ServiceReference1.ServiceClient client = new ServiceClient();
client.ClientCredentials.ClientCertificate.SetCertificate(StoreLocation.LocalMachine, StoreName.My, X509FindType.FindByThumbprint, "f0969c5725b2f142b7f150515ec2bd12bc45250b");
var result = client.Test();
Console.WriteLine(result);
During this process, please note we should install the certificate each other in the Root CA so that the certificate trust relationship between the client-side and the server-side can be established.
Look back to your question, the cause might be the certificate trust relationship cannot be established between the client-side and the server-side. We have to ensure that the client-side has installed the service certificate in the Root CA and the server has installed the client certificate in the Root CA.
Feel free to let me know if there is anything I can help with.
Related
I'm creating an app hosted by IIS and I want to have it communicate securely with SoapUi (so IIS is the client is this scenario). I'm using certificates at both ends because I want mutual authentication. When IIS connects to SoapUi, I can see in WireShark that:
The client hello is sent from IIS
Then SoapUi responds with the server hello and continues with the certificate and a certificate request
Then IIS terminats the connection with a TCP [FIN, ACK]
And finally SoapUi sends the Alert(Level: Fatal, Description: Handshake Failure)
In my application log I can see the error Could not establish secure channel for SSL/TLS with authority 'localhost:8443'.
From the logs in my app I can see that my app is apparently loading the certificate as expected. The certificate is loaded from the LocalMachine certificate store and the CA certificate is located in the Trusted Root Certification Authorities. In SoapUi I've added .pfx files for the SoapUi certificate/private key and for the CA certificate/private key. Both the IIS certificate and the SoapUi certificate is signed by the same CA.
Is there anything special I need to configure in IIS to allow an app to connect with mutual certificate authentication.
IIS does not necessarily have access to the private keys in the local machine certificate store. If you have installed the certificate with e.g. an administrator account you will have to give the app pool that runs your application access to the private key of the certificate.
I have a business process which send messages to SAP via soap endpoint exposed by them.
I am using WCF-BasicHttp Send Adapter(In-Process).
As you can see below, earlier the url was http, now they have moved their system to cloud so now they have https endpoints.
I wanted to test this change from http->https, so I have modified the url to https, fill in the credentials for basic auth. it working fine in Test system without SSL Certificate, I need to make sure it wont cause any issue after moving to production system.
My Question is,
1/ Will it work in Production system too as its in TEST without SSL Certificate ?
2/ or Do I need to apply SSL for WCF-BasicHttp Adapter, if yes How can I do that ??
If you are moving to https URL, Certificate is must for SSL/TLS handshake. Many times, Certificate used by specific endpoint is signed by a third party Trusted Root CA e.g. Trustwave, DigiCert etc and these Root CA certs are already trusted on most of the systems. It’s possible in your test system, your endpoint certificate Root CA is already trusted and that’s why you did’t need to install the certificate. In order to check this, you can do following:
Browse your https service url in browser in chrome/IE
Look for Security/Lock sign to find it’s cert. Clicking the lock sign will open certificate.
Check the certificate root by going to Certification Path. You should see a chain of certificates in path. A cert can be by signed by just root CA Or by Intermediary CA first and then root CA. e.g.
—- Trustwave Root
—- Trustwave Intermediary
—- service cert
Or
—- Some Root
—- service cert
Check if Root CA is in your Trusted Root store of system. And Intermediary Cert (if applicable) is in Intermediary Cert Store. You can check this by opening certificate mmc snap-in using mmc command in Windows->Run and adding Certificates snap in of local computer.
If Root CA Cert and Intermediary Certs are not in your system store. SSL/TLS handshake will not complete successfully and BizTalk send port will not work.
If these are installed, you should be good. Otherwise install these certificates in local computer stores.
Another way to verify if endpoint certificate is trusted on a BizTalk system is to login with service account under which your send host is running and then browse the URL in IE. If you don’t get any Cert error, and URL opens such as wsdl URL, then you are good. If you get a cert error, this means end point certificate is not trusted and you need to install the certs as described above.
Some references:
View Certificate
Working with Certificates
I'm debugging SSL errors between Websphere MQ Server and Client using T.Rob's suggestions and need help understanding the SSL handshake (SSL connect to MQ using .net mq client SSLV3?).
My WMQ 7.5 client application is C code and uses a keystore (.kdb). Utilizing a CHLTAB provided by the WebSphere admin. The WMQ server is running Java and the channel is defined with mutual authentication.
The article states that in the SSL/TLS handshake, the server always sends its public certificate in response to a connections request. The client then must validate that certificate by first checking the signature and validity date, then looking in its trust store for the thing that signed the certificate.
Here's my confusion: Since my keystore on the client side has only the application personal cert, how does the client validate the public certificate sent by the server? I have provided the Common Name of my application cert to the WebSphere server admin but nothing more than that.
Thanks in advance for the clarification!
The bit about "my keystore on the client side has only the application personal cert" is troubling. That won't work. The client KDB must have the server's public key. If the MQ server has SSLCAUTH(OPTIONAL) the the server's public cert is all that's required in the KDB for the connection to succeed.
The first part of the TLS handshake is where the client validates the server's certificate. The use of public/private key pairs is how the authenticity of the thing on the other side is assured. In order for that to happen the server must have its own personal certificate and the client must have the public key of the root of the signer chain. In the case of self-signed certificates the public portion of the personal cert must be trusted by the client. In the case of CA-signed certs the CA Root must be trusted by the client. Whichever one it is, the client must trust something used to sign the server's personal cert or that cert can't be validated.
The TLS handshake is symmetrical so the second part works exactly the same as the first but the roles are reversed. Therefore, in cases where mutual authentication is enabled the client must have its own personal cert (because that contains the private key) and the server must trust whatever signed the client's matching public key. If the client cert is self-signed the QMgr has to trust it. If the client's cert is CA-signed, the QMgr must trust the signer. Either way, the QMgr has to have a cert to validate the client in its KDB.
Following this logic, for anonymous client connections the required parts are the personal certificate in the QMgr's keystore (because it contains the QMgr's private key), and the matching trusted certificate in the client's KDB or for Java the Trust Store. Neither of these is optional.
If the client is to be authenticated you still need the same two certs as for anonymous clients because that part of the handshake has to complete before the client is authenticated. In addition, now you also need the client to have its own personal certificate (because it contains the client's private key) and the QMgr now needs to trust whatever signed the client's certificate - the client cert if self-signed or the signer root if CA-signed.
As a side note, There is also some confusion in the post because it says that "My WMQ 7.5 client application is C code and the WMQ server is running Java." There is nothing in the queue manager that uses Java on the server side. There are Java components installed to do things like manage JNDI objects and run the sample code. In modern MQ versions Java runs the Web Console. But there are no Java components in the QMgr itself and no Java components in the path of the incoming channel connection request. That's all habdled by the QMgr's listener, agent, and other internal processes. So I'm not at all sure what is being referred to there other than that the notion of Java running on the MQ server side and participating in the TLS handshake might be a source of some of the confusion mentioned in the post. ;-)
My webapplication has a https binding with an SSL certificate configured from Entrust. In the SSL settings of the web application, I set the Client certificate settings as required.This forces client to supply a valid certificate when requesting the content to the server, which is the requirement.
I have Entrust listed as a Trusted Root Certification Authority in both Client and server.
Now my query is how to generate the client certificates for all the clients which could be authenticated by server?
When securing WCF services with server and client certificates there is an easy way to ensure the identity of the service provider certificate (server certificate), by comparing the public key or finger print of the sender certificate with an expected value.
On http://msdn.microsoft.com/en-us/library/ff648360.aspx this is explained in step 8. You can config your app.config file in the endpoint section with an identity element where you can pass in the expected encoded finger print value of the server certificate. A comparison between received service certificate and expected value ensures I am talking to the server I expect.
But now I consider the servers point of view. The server can have several RootCA certificates in its certificate store. If the client certificate send from the requester was issued (and signed) by one of these RootCA my service will trust this client certificate. How can I ensure that my service will only trust certificates issued by one determined RootCA? And how can I configure the one trusted RootCA?
(I think this could be some kind of an equivalent way of certificate pinning for client certificates issued by on RootCA)
The only way to achieve this would be to roll your own custom x509 certificate validator. Then for each incoming request you can simply check to make sure the client certificate was issued by your root CA. It's actually quite easy to do. You can find the steps to implement this here:
How to: Create a Service that Employs a Custom Certificate Validator