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.
Related
I want to setup mutual authentication on Tomcat 8.
I have done the setup of keys primarily keystore and truststore and the setup is working with Firefox tested.
When accessing the URL I am prompted for certificate and when appropriate certificate is provided I am allowed the access.
The piece of puzzle I am missing is, the truststore that I have which has CA cert and public keys of few clients. This CA should be a self signed CA, not from known authorities on the web, as.
I just do not want anybody to have access, people using my CA only should be able to access. Assuming say abc.com has certificate signed by authority godady or verisign, which are well known and trusted should not be able to call. I want strict access.
In my truststore I just want to keep CA no public keys, I do not want to keep adding certs as clients grow up. Clients would use my CA.
I think my self signed CA in truststore and clients using my CA only in chain for their certificates should be good enough for secure(only clients with my CA) scalable solution, where I do not have to keep adding clients in truststore.
Please advice my assumptions are correct for a production cloud based system.
Thanks for the time.
Yes, your assumption are correct. During SSL handshake server will ask client to provide any certificate issued by CA present in server trust-store. Also you need to consider that client trust-store should have issuing CA of server certificate otherwise it will show untrusted server certificate on client/browser.
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.
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.