I have a thrift endpoint that someone created who is not longer with our company. They implemented the authentication via client side certs, but I having a hard time wrapping my head around how it all works. Does anyone know of a tutorial, or howto on this topic.
All I really have is a sample client class. Here are a list of things that I need help with:
Can a server cert and the client cert both be contained in the same trust store
How do you create a new client side cert?
How do you add that client side cert to the server trust store?
Do you need to set the client trust store, and set the java trust (assuming the server is a self signed endpoint)
What does the following error mean?
ERROR[com.cada.CadaDaoTest][main] - Error:
org.apache.thrift.transport.TTransportException: javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
The truststore (on Tomcat it's configured forthe SSL connector in server.xml) can hold the root of the certificate chain of the client certificate, not the certificate itself. That is, when a certificate is created, it is signed by a CA - certificate authority. If the CA cert is trusted, all certs singed by the CA are trusted as well.
You can create certificates using either keytool (in jdk/bin/) or openssl. There are GUIs for that, like portecle.
The tomcat ssl tutorial might be helpful.
Related
I am using Spring Security to authenticate using an x.509 certificate, and it works only when the client certificate which is configured in the browser key-store is present in server trust-store.
How it is working currently:
I have configured the SSL client authentication as optional (server.ssl.client-auth=want , like in this post)
I have configured a server trust-store that contains all client certificates. If the certificate presented by the client is in the trust-store, the mutual SSL connection is created.
When I have the client certificate(s) present in the server-side trust-store, Firefox opens a popup with my client-side certificate(s), which I can choose and the mutual SSL connection is established.
I have configured Spring Security to extract the username from the SubjectDN of the client certificate and check it against a UserDetailsService. If a UserDetails object is returned for that username, the authentication process completes successfully
The problem is that if I remove the client-certificate from the server-side trust-store, Firefox doesn't open this popup anymore, and only a one-way SSL connection is made. Even if the Root CA cert is present in the server trust-store.
What I want:
store in the server trust-store only the certificate of a Root Certificate Authority
allow mutual SSL connection when the client presents a certificate issued by the Root CA in the server trust-store (even if the client certificate isn't present in the server trust-store)
I am also intrigued by two resources on the internet. In this tutorial on Baeldung, it says that all client certificates must be stored in the server trust-store for X.509 auth to work (which confirms my experience).
You must remember that for each user that should be verified by the server, its own certificate needs to be installed in the configured truststore. For small applications with only a few clients, this may perhaps be practicable, with an increasing number of clients it may lead to complex key-management for users.
However, this tutorial by #robinhowlett says that
The client will present its certificate in its keystore to the server, and the server will validate the client certificate’s chain using the CA certificate in the server’s truststore.
This is basically what I want to achieve, but am not able to.
Bottom line: did someone manage to store one or more Root CA certificates in the server trust-store and use client certificates issued by these Root CAs to authenticate via X.509 mutual SSL handshake in Spring Security?
I am using Spring Boot 1.5.2.RELEASE (spring-security-web 4.2.2.RELEASE). I have tested my working SSL authentication with Firefox 53.
I found my problem - I was modifying the trust-store (removing the client cert and leaving only the CA cert) while the server was up (Tomcat, in my case). But the trust-store is kept in memory and gets read only once, when the JVM is initialized (details on this ServerFault post). So trust-store changes are not being read during runtime by Tomcat.
So the answer is simple: yes, if only CA certs are present in the trust-store, during the SSL handshake the server communicates to the browser it wants client certificates issued by the trusted CAs and then the browser prompts the user to select a certificate that is issued by a trusted CA (if such a cert is present in the browser keystore).
However, if a CA is added dynamically to the server trust-store while the server is up and running, it won't be detected. The new CA will only be recognized after the server reboots (and the JVM is re-initialized).
I am writing a micro service which talks to another service through HTTPS. In java client implementation, reading root certificate from truststore and then validate incoming certificate through that.
Now, my question is - by default only 2nd level certificate will be validated using root Cert or all chained certificates in turn will also get validated?
I am Using okhttp; and my assumption is that all Java clients should behave in same way, please let me know if there is any subjectivity here? Thanks.
If you include the root certificate in the truststore, the entire chain will be validated
The SSL server during handshake sends to client the certification chain from leaf certificate to root. The root certificate may be included but usually it is not
The default Trust Manager of a Java client will validate the provided certification chain looking in the truststore until it find the issuer of the certificate or the certificate itself
I'm having an issue sending our certificate (client) to another server during a web service call.
We're expected to return the certificate with the CN:
b2b-test
however whenever we receive the servers certificate and attempt to send our own, we're getting:
Unable to find valid certificate path to requested target
From my understanding, if I put our certificate b2b-test inside of our keystore jre/lib/security/cacerts, then when receiving the server request, it should send the appropriate certificate.
How does the client know which key from the keystore it should send to the server? Should I be specifying the exact certificate to send during my request, or is it enough for it to be in the keystore?
Currently the server is sending back the certificate
b2b-a
The certificate chain shows:
*** Certificate chain
chain [0] = [
[
Version: V3
Subject: CN=b2b-a, OU=Web Technologies
The URL for the service is:
https://b2b-a/service
If I configure it like one way ssl, and put the servers certificate into our cacerts, then it picks up their cert and fails the handshake (I'm assuming because it's expecting our cert and not theirs back due to it being a two way setup).
I'm a little stumped here. Any clarification on what I've said is greatly appreciated.
The "Unable to find valid certificate path to requested target" error usually occurs when one side passes a certificate for which the other side doesn't trust any of the certs in the chain. You'll generally (always?) see the error message on the side that's receiving the cert (the side that's missing the truststore).
If you're the client and they're the server, one-way SSL would send their cert from them to you and you would validate it (making sure that the hostname matches the content in the cert), but it would not send any cert from you to them nor would they do any validation.
You'll want to make sure you're configuring a truststore that contains either the b2b-a certificate or a certificate that was used to sign it (but that cert doesn't appear to have any root CAs, so you're stuck with directly importing the cert itself). So yes, you want to do what you wrote in your post and put their certificate into your cacerts. And you'll also need to make sure that the b2b-a service trusts the cert you're sending (or a root CA that was used to sign your cert, if any), so you'll need to put your cert into their cacerts as well, or do something equivalent.
Note that putting a cert in cacerts (or in a truststore JKS) DOES NOT send any certs to anyone; any truststore is used only to allow you to validate that you trust the certificate someone else provides you, either because you trust the cert or because you trust a CA cert that was used to sign the cert. No certs are picked out of the cacerts directory to send to another machine.
If you're using a JKS rather than the JRE directory (which is generally a better idea, since you can specify a different set of trusted certs for your process without changing the default set for anyone running a Java project within your JRE), it's possible to use the same JKS as both a keystore and a truststore (you'll just provide the same filename and password for both the keystore and the truststore properties), or you can have two separate files; either approach will work.
From my understanding, if I put our certificate b2b-test inside of our keystore jre/lib/security/cacerts, then when receiving the server request, it should send the appropriate certificate.
Certainly not. That's a truststore. A source of trusted certificates. Don't mess with it. It isn't used for the purpose you require and in any case it is updated every Java dot release, which clobbers your changes.
Your own certificate and private/public key pair should go in a file of your own, a keystore, which is defined to JSSE by the javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword system properties, or by more complex means described in the JSSE Reference Guide.
The keystore is a precious and confidential file containing your private key. Guard and protect it. Private key leakage would compromise your security and identity.
When I create an SSLServerSocket in Java 7 the server correctly uses my server certificate and key. The certificate was issued by a sub-ca of a ca. Therefore the complete chain from the root cert to the server cert has four certificates.
The complete chain is present in the keystore/truststore.
However when a client connects the server always sends only the server certificate itself.
This also applies to Java based web servers like Jetty.
Because most clients have only the root ca certificate installed and not the two sub-ca certificates this is a big problem.
How can I force Java to send the full certificate chain in the SSL/TLS handshake?
A key entry in a keystore isn't just for a single certificate, but for a certificate chain (see KeyStore.setKeyEntry, which takes a Certificate[] chain parameter).
If you want a specific chain to be used, it needs to be set up as a chain in the entry where you have the certificate and its private key. Whether the intermediate certificates are also in the same keystore, in different entries doesn't really matter.
This is a very similar problem to getting a client to send the full client-certificate chain. The same keystore configuration steps should also work from a server point of view, as described in this question.
When I create an SSLServerSocket in Java 7 the server correctly uses my server certificate and key. The certificate was issued by a sub-ca of a ca. Therefore the complete chain from the root cert to the server cert has four certificates.
The complete chain is present in the keystore/truststore.
However when a client connects the server always sends only the server certificate itself.
This also applies to Java based web servers like Jetty.
Because most clients have only the root ca certificate installed and not the two sub-ca certificates this is a big problem.
How can I force Java to send the full certificate chain in the SSL/TLS handshake?
A key entry in a keystore isn't just for a single certificate, but for a certificate chain (see KeyStore.setKeyEntry, which takes a Certificate[] chain parameter).
If you want a specific chain to be used, it needs to be set up as a chain in the entry where you have the certificate and its private key. Whether the intermediate certificates are also in the same keystore, in different entries doesn't really matter.
This is a very similar problem to getting a client to send the full client-certificate chain. The same keystore configuration steps should also work from a server point of view, as described in this question.