If the client can not verify the server's certificate with the rootCA certificate, can the server pass the authentication?
It would be terrible insecure if a server could just instruct a client to ignore any certificate problems. Validation of the server certificate is done by the client to make sure that it actually talks to the expected server and not to some man-in-the-middle attacker. If a server could instruct the client to ignore certificate problems so could a man-in-the-middle attacker do, which means it would be easy to do man in the middle attacks.
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. ;-)
We are configuring HAProxy to force require Client Certificate Validation. This works well. However, we couldn't find much information about OCSP support specifically for client certificate validation. There are information about Certificate Revocation list and OCSP Stapling (which I believe is for server certificates).
So my questions are
1. Does HAProxy supports OCSP during client certificate validation?
and
2. If it is supported, can this be manually configured without requiring the OCSP URL included in the client certificate itself or possibly overriding the url on the server?
We are configuring HAProxy to force require Client Certificate Validation.
Please define exactly what Client Certificate Validation means to you. You say it works well, so my best guess is that you're generating client certificates and you have configured haproxy to require valid client certificates in order to access resources that haproxy is in front of.
However, we couldn't find much information about OCSP support specifically for client certificate validation. ... 1. Does HAProxy supports OCSP during client certificate validation?
No. That's quite simply "out of scope" for a server like haproxy. HAproxy only does OCSP stapling, and only then if you supply the OCSP response in the form of .ocsp files in the certificate directory. It's unusual to want haproxy to block TLS connections while it tries to get HTTP responses from each TLS certificate for all the reasons that OCSP stapling exists. Along those same lines, having haproxy block TLS connections from your clients while it tries to validate their certs via OCSP (or for that matter, CRLs) is not a good idea.
Update: See this thread on in the haproxy forums.
I'm not sure is similar question has been asked before (I couldn't find any), but is it possible to protect Client/Server from Man-In-The-Middle attack?
I'm writing a Client application to communicate with Server. Communication will be SSLv3 based.
I am OK with server's self-signed certificates, but worried about someone else generating same self-signed certificate in the same server name and pretend to be it. My Client application uses OpenSSL library. [Client and Server are thrift based, if it makes any difference]. Can I avoid such attack at the same time maintaining support for self-signed certificates?
Yes.
In short, a self signed certificate is more insecure than a CA certificate only when the client does not know the certificate in advance and therefore has no way to validate that the server is who it says it is.
If you add the self signed certificate to the client and don't accept any other certificate, you're actually as secure (or, one could argue, even more so) than having a certificate authority signed certificate.
The important parts to keep SSL secure with or without a certificate authority are;
The server private key (and in the case of a CA, the private keys of all its roots) is kept secret.
The client knows the server certificate (or its CA root).
You can hard-code the server's certificate and compare it against what you receive.
Or better yet, create a CA certificate and server certificate, signed by the CA. Have the CA trusted on the client (again by hardcoding it in your application) and validate received server certificate using the CA certificate.
If you can protect your private keys well enough, a middleman will not be able to masquerade as you, assuming the user actually looks at the certificate. The problem with self-signed is that if you want the user to add the exception to their browser, or just ignore the warning, then you are exposed to man-in-the-middle attack, because anyone else may create their own certificate.
Of course, "protecting your private keys well enough" is not trivial at all. When you pay for a "Verisign" certificate, you're not paying for their software creating the certificate - you're paying for the security forces they have guarding the building in which the private keys are stored.
That's easy! NOOOO !!! Not anymore than you could prevent a man-in-the-middle attack from certificate issued-by a well-know authority. >:)
What is the best way to implement https security for transport without a certificate? Should I just for instance use basicHttpBinding with SecurityMode to Transport and ClientCredentialType to HttpClientCredentialType? I did it in a way described but then when accessing WSDL I have a ceritificate warning.
I don't think you can have https without a certificate. It can be a self-created one, but then the client needs to explicitly install it in its trusted store.
You cannot. HTTPS is just HTTP tunneled inside of SSL/TLS and SSL/TLS requires the use of a certificate on the server side. If this is for testing, or only use by clients that you control, you can choose to do one of these options in place of paying for a CA-issued certificate.
Use a self-signed certificate. In order for this to work without your client getting a warning, you would need to import the certificate into the clients' trust store (usually part of the browser).
Use a certificate issued by a Certificate Authority (CA) that you control and have that CA's issuing certificate (or root) imported/trusted by all of your clients. This is mos useful if you have multiple servers in your environment and you need all of the clients in your environment to trust them.
If you need external clients to connect to your servers without doing any import/trust on the clients, you will need to procure a certificate from a globally-recognized CA like Verisign.
If you want to encrypt the contents of the messages, as well as HTTPs transport security, a further option you can consider is to use message security. This encrypts just the content of the message and not the transport channel. A potential benefit of this is that the message can be secured passing through intermediate systems, whereas HTTPs is point to point
This will require an X509 certificate on the server, which as with https certificates you can either self-sign or get from a CA like Verisign