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.
Related
In a TLS communication I always thought the server would send the public certificate to the client during the handshake process.
However, I received a request from a provider asking us to manually install a certificate in order to initiate a TLS communication with one of their STunnel server.
I'm a bit confuse by this request. Is there's a situation where TLS server would not be able to send the certificate to the client and therefore required a manuel certificate installation?
There are two cases where a certificate installation is needed on the client side:
The server is using a certificate not issued by a public CA, i.e. self-signed or issued by a private CA. In this case the client must import the certificate or CA up front and install it as trusted.
The server is requiring client authentication based on certificates, i.e. not only the server authenticates to the client with a certificate but also the client to the server (instead or additionally to typical passwords). In this case the client has to get a client certificate and matching key and import so that it can be used for authentication.
It is unclear which of these cases is the one you are dealing with.
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?
I made HTTP proxy server. But the problem that I can't decrypt SSL traffic.
I found that Fiddler install Trust Root Certificate. I did the same and now I don't have error that certificate untrusted but I got other error: wrong Common Name (CN). How fiddler change the CN of installed trusted certificate?
Will appreciate any answer.
Fiddler acts as an SSL termination proxy.
I.e. the connection goes like this:
Browser ---(SSL handshake)---> Fiddler --- (SSL handshake) ---> Actual Site
So your connection is first time encrypted and sent to Fiddler, where it is first decrypted by Fiddler and then again encrypted to be sent to the actual site that you access.
Additionally when you access a site Fiddler automatically generates a server certificate with a CN that is equal to the host name of the site and this certificate is signed by the CA of fiddler That's why Fiddler needs to install a set of trusted CAs in your browser so that the first SSL handshake can be made against a trusted authority.
I'm trying to create web application with client certificates, generated programmatically. My main problem is following: I've added generated .p12 keystore to my web browser, but it doesn't send certificate to the server.
How does browser understand which x509 certificate it should use? And is it possible to debug SSL in Chrome of Firefox?
SSL/TLS server sends Certificate Request message (see RFC 4346 for TLS 1.1 or others). In this message there is only certificate type and acceptable certificate authorities names, so server doesn't tell anything about particular certificate.
The possible reason is that your certificate of invalid type (i.e. DSA instead of RSA but key exchange algorithm depends on client RSA certificate), or server requests certificate of different certificate authority.