Is it possible to create a HTTPS connection to a java-servlet with a static name (like https://.../logonServlet) so that only clients who already own the public key/certificate can access the servlet? I would like to prevent the server from delivering public certificates and refusing all other clients?
To my knowledge:
I read about the java keytool and the different stores (keystore (certs and private keys) and truststore (client side, public keys)). I am currently reading the book "Glassfish Security" by Masoud Kalali to learn about user groups and different security realms and stuff like different xml options for server configuration but I feel like I start mixing everything in my head so I would like to ask if you could help me with my desire from above.
A big question that is still open to me is "Why do we need certificates?". Shouldn't be a private key which will be kept secret enough and a public key for the clients?
#Edit
What you may want to check is SSL/TLS with client authentication. In this setup, the clients need a certificate and a private key as well. The server will refuse connections if they are not from a client with a trusted certificate. This means that server and client need both a keystore and a truststore.
Seems like you are correct, that is what I am looking for.
Asymetric cryptography works with two elements by design:
Public key: Shared with everybody, so they can know it's you who send the messages. Also to cipher messages that only can be read with the private key.
Private key: Only known to you, so you can guarantee that you are who send the messages. Also to read messages sent to you ciphered using your public key.
In a typical HTTPS setup, the server has the certificate (with a public key) and the private key, but the public part is shared with anyone who connects (you can see the certificate of any HTTPS site in the browser).
This is because usually, the client needs to know who the server is, but the server doesn't need to know who the user is (and if it does, other ways like passwords are cheaper and more convenient for the average user).
Sharing the server's public certificate is necessary for SSL/TLS to work, so there is no way to hide those keys and completing the handshake at the same time.
So no, the server's public key cannot be used to authenticate the clients, as it is assumed by design that everybody can get it.
What you may want to check is SSL/TLS with client authentication. In this setup, the clients need a certificate and a private key as well. The server will refuse connections if they are not from a client with a trusted certificate. This means that server and client need both a keystore and a truststore.
Note that keystore and truststore are conceptual terms. A single file (.jks, for example) can act as both, as it can contain private keys and public certificates at the same time. That said, they tend to be in different files.
Ok! We are trying to implement a client server aplication (chatroom) . Of course the server is multithreaded. We wanted the communication to be secure so we used ssl sockets and certificates. I have read that you can store multiple certificates and keys in one keystore. When a client enters the chat he needs to fill in his username.
Do we have to connect the username to the alias of the certificate/key?
If yes, how can we use the specific certificate/key from the keystore from the alias? Or is there another way? I mean how can we "pick" the specific certificate depending on the name
Is there a way for the clients to create their certificates at the time of they enter? (We want the certificates to be signed by a CA we have already implemented)
Thank you!
Basically what you want is Mutual or 2 way SSL. Read these for more information - here and here
In short - the SSL communication works (in context of certificates for authentication) is server will send the certificate to the client and if that certificate is present in the client's certificate store or Java's keystore in your case, then it authenticates the server.
Typically server never asks client to send certificate but in your case you wants it so it makes it Mutual or 2 way SSL. So, while handshake process, server will ask client also to send its certificate and it will also check in its keystore if that certificate is present, if so then it will be happy else it will end SSL handshake.
What you need:
Your each client and your server should have a valid certificate.
Your server should have those client certificate present in its "trust keystore", so that it can authenticate client.
Your each client should have server's certificate in its "trust keystore", so that it can authenticate server.
Your server should be configured to support 2 way SSL. Read here for Weblogic.
Answering your questions specifically:
Do we have to connect the username to the alias of the
certificate/key?
No, only this you want is that client certificate should present in the server's "trust keystore". But since your client app and server is on same machine, so I would recommend that have different JVM's installations to run client and server so that you have support different certificates.
If yes, how can we use the specific certificate/key from the keystore
from the alias? Or is there another way? I mean how can we "pick" the
specific certificate depending on the name
Not applicable.
Is there a way for the clients to create their certificates at the
time of they enter? (We want the certificates to be signed by a CA we
have already implemented)
Certificate should be prepared beforehand, and certificate creation and signing is a complex process, you have to generate a CSR etc.
Please do read my this answer for other details you may require while doing all this.
I am working on a HTTPS service which will be deployed on a server with a self signed certificate and a client which will accept all certificates.I am new to SSL.
I have gone through this post and this post and understand how to configure trust manager to accept all certificates.
If I understand correctly a java client will use server's public key(installed by using server's public certificate) to encrypt data to be sent to a server.And a server then uses it's private key to decrypt the data.
My questions are:
1.In a common scenario ,we install the server.cer in truststore of client machine(cacerts in java). How does the java client code links to this installed public key to encrypt data while communicating to such server? Who does the SSL encryption here? Is it Java APIs that do it or do i have to handle encryption in my client code before sending data to server?
2.As given in one of the above mentioned post ,we can make client accept all certificates.How will the encryption and decryption work in this scenario? How will the client know which public key to use for encryption as we are not installing any server specific key in client's truststore?
I am looking for more technical details.
I am working on a HTTPS service which will be deployed on a server with a self signed certificate and a client which will accept all certificates. I am new to SSL.
Clearly. You're working on an insecure system. It's a waste of time. You may as well not use SSL at all. The client should accept this certificate and all CA certificates, not all certificates. As described, your system is vulnerable to man-in-the-middle attacks.
If I understand correctly a java client will use server's public key(installed by using server's public certificate) to encrypt data to be sent to a server.
You don't. It doesn't. The certificate is used to authenticate the identity of the server, but SSL encryption is symmetric via a secretly negotiated session key and has nothing to do with the public key in the certificate.
And a server then uses it's private key to decrypt the data.
No.
How does the java client code links to this installed public key to encrypt data while communicating to such server?
Usually via the javax.net.ssl.trustStore property, but again it doesn't use that for encryption, only for authentication.
Who does the SSL encryption here? Is it Java APIs that do it
Yes. It is done by HttpsURLConnection using a javax.net.ssl.SSLSocket.
or do i have to handle encryption in my client code before sending data to server?
No.
As given in one of the above mentioned post ,we can make client accept all certificates.
You can, but it is radically insecure and should never be done that way.
How will the encryption and decryption work in this scenario? How will the client know which public key to use for encryption as we are not installing any server specific key in client's truststore?
See above, you have a misunderstanding here, but when you accept all certificates you have no idea who you're talking to, so any encryption is completely pointless anyway. Don't do this.
I'm working on a Server and Client based app which require two way SSL authentication. (Client authenticates server and Server authenticate client both using SSL Certificates.)
I'm quite new to Netty and have few doubts regarding this.
Is two way authentication possible using Netty?
Can it be simply achievable by adding another SslHandler to the pipelinefactories of both server and client?
If the above is true, how can I grab the required SslHandler at the ChannelConnected() method to do the SslHandshake? And Is it possible to invoke the second handshake at the ChannelConected() method by calling the pipeline back again?
Are there any examples I could refer to regarding this?
I really appreciate any help regarding this, answers or a push in right direction.
Is two way authentication possible using Netty?
Yes
Can it be simply achievable by adding another SslHandler to the pipelinefactories of both server and client?
Yes
If the above is true, how can I grab the required SslHandler at the ChannelConnected() method to do the SslHandshake?
You need the setup the keystore and the truststore correctly when creating your SSLContext.
And Is it possible to invoke the second handshake at the ChannelConected() method by calling the pipeline back again?
From memory, client and server authentication is done in the 1st handshake.
On the client, install the client's private key in the keystore and the server's public key in the truststore.
On the server, install the server's private key in the keystore and the client's public key in the truststore.
Are there any examples I could refer to regarding this?
Here's an example I did for websockets. It only shows you how to setup the server keystore. You will have to add a truststore as the 2nd parameter of serverContext.init(kmf.getKeyManagers(), null, null);
Here's a similar example in Scala with trust store setup.
Here's a good java guide on how to setup SSLContext.
Hope this helps.
Two way authentication requires that both server and client have certificates that the other trusts. The client needs to generate a private key, store it in his keystore, and get it signed by somebody that the server's truststore trusts.
It isn't just a matter of what code you write.
SSL is a presentation layer protocol and the SSL handshake happens right after the socket connection is established and the before the application layer gets a usable socket connection. No matter what application you are using, if you have the SSL protocol layer in place then you can work over SSL.
Two way authentication is just a matter of configuration as mentioned by #EJP above. If both the parties can establish and validate each other trust chain then the handshake succeeds. Refer the netty configuration manual for configuring SSL truststores.
I've read a few related questions, but none of them really helps me. So, let me give you a little background story:
I'm writing a voting-system in which you have couple servers that manage registration, exchange of vote cards, and voting. During the registration user submits his personal data, the server checks if the data match those in the database and then accepts the user's certificate and adds it to its trustStore like this:
KeyStore.Entry entry = new KeyStore.TrustedCertificateEntry(cert);
trustKeyStore.setEntry(alias, entry, null);
and then stores the trustStore in the file. During the registration a lot of users register their certificates, and then they connect to a different server that requests both client and server authentication, and here the problem arises. I thought that this 'other server' can use the aforementioned trustStore to perform the SSLHandshake with users, but it appears that the trustStore 'remembers' only the last user that registered. I'm creating SSLServerSocket like this:
tmf.init(trustKeyStore);
kmf.init(keyStore, password);
// create, init SSLContext
SSLContext sslCtx = SSLContext.getInstance("TLS");
sslCtx.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);
// create SSLSocketFactory and SSLSocket
SSLServerSocketFactory sslSocketFactory = (SSLServerSocketFactory)sslCtx.getServerSocketFactory();
sslSocket = (SSLServerSocket)sslSocketFactory.createServerSocket(1234);
As I mentioned before, both-side authentication works fine, but only for the last entry in the trustStore. So, now finally my question is - do I have to create a separate trustStore for each user? Do I have to overload TrustManager? Basically, is there any way I can make the SSLContext/SSLEngine iterate over all of my trusted certificates and go through with the handshake if it finds the one that matches?
UPDATE
I think I need to clarify a few things. First of all, this is not a web application, just a normal client-server java swing app. Every single certificate used (server or client) is self-signed, but the server's cert is build into the client application, so when the client connects to the server he can compare certificates (works). I have also tried to solve it exactly like Bruno suggested - after user registers, server checks if his data is valid, if it is it issues a new certificate for the client, adds it to his truststore and sends it to the client. But that didn't work even for the last registered client.
(Edited after changes to the question.)
Method 1:
One way to solve this would be to use a CA, possibly your own.
Method 2:
Accept any client certificate at the handshake level. Although accepting any server certificate from a client point of view is a bad idea, since it introduces the possibility of a MITM attack (see here and here, for example), accepting any client certificate during the handshake doesn't present the same problems.
At the end of the handshake, provided that the server certificate is still verified, you will know that:
The communication between the client and the server is established securely, as it would with HTTPS without client-certificate authentication.
The client has the private key for the certificate it has presented during the handshake. This is guaranteed by the TLS CertificateVerify message, which uses the client's private key to sign the concatenation of all messages exchanged during the handshake so far, including the server certificate and the client certificate. This doesn't actually depend on the (trust) verification of the client certificate itself, and will only work if the public key in the client certificate can validate the signature in the TLS CertificateVerify message.
With this, you will know that the client certificate the server gets is used by someone who has its matching private key.
What you won't know, is who that public key certificate belongs to, i.e. who the user at the other end is, because you're missing the verification step normally performed using a CA, which should itself rely on an out-of-band mechanism before issuing the certificate. Since they're using self-signed certificates, you would have to perform this out-of-band step anyway, perhaps via some information during the registration.
Doing this would allow you to manage your users and the way they use their certificates more easily. You could simply store and/or lookup the current user's certificate in a database common to your servers. You can get access to the certificate by looking at the SSLSession within your application. You will find the user certificate in position 0 of the array returned by getPeerCertificates(). You can then simply compare the credential you see (again, because the two-way handshake was successful) with those you've seen before, for the purpose of authentication (and authorization) within your application.
Note that even if you just accepted self-signed certs that you keep adding, you would still have to track this public key information as part of your system, in addition to the Subject DNs because you would have no control over the Subject DNs (two users could choose to use the same, intentionally or not).
To implement this, you will need to configure your server with an SSLContext which uses an X509TrustManager that doesn't throw any exception in its checkClientTrusted method. (If you're using the same SSLContext for other purposes, I would get the default PKIX TrustManager and delegate the calls to checkServerTrusted to it.) Since you're probably not going to know what the Subject/Issuer DN of these self-signed certificates are going to be, you should sent an empty list of accepted CA (*) by returning an empty array in getAcceptedIssuers() (see example here).
(*) TLS 1.0 is silent on this subject, but TLS 1.1 explicitly allows empty lists (with unspecified behaviour). In practice, it will work with most browsers, even with SSLv3/TLSv1.0: the browser will present the full list of certificates to choose from in this case (or pick the first one it finds it it's configure to select one automatically).
(I'm leaving what's more specific about HTTP here... A bit out of context now, but this might be of interest to others.)
Method 1:
You could integrate the certificate issuing as part of your initial registration. When the users register their details, they also apply for a certificate which is immediately issued by your registration server into their browser. (If you're not familiar with this, there are ways to issue certificate within the browser, using <keygen />, CRMF (on Firefox), or ActiveX controls on IE, which one depends on the version of Windows.)
Method 2:
In a Servlet environment you can get it in the servlet request javax.servlet.request.X509Certificate attribute
In addition, this tends to improve the user experience, since the rejection of a client certificate doesn't necessarily terminate the connection. You could still serve a web page (with an HTTP 401 status perhaps, although technically, it would need to be accompanied by a challenge mechanism, and there isn't one for certs) at least telling your user something is wrong. Handshake failures (which the client-cert verification within the handshake would cause in case of problem) can be very confusing for users who don't really know about certificates. The downside is that it's quite hard to "log out" (similarly to HTTP Basic authentication), because of lack of user interface support in most browsers.
For the implementation, if you're using Apache Tomcat, you may be interested in this SSLImplementation or this answer if you're using Apache Tomcat 6.0.33 or above.
I have solved the problem. As it often happens, there was a stupid mistake on my side - one of the servers were overwriting the whole keystore. I have spent a lot of time figuring how to set up this ssl communication and I haven't found much about it on the web, so I hope this will help somebody in the future.
In order to set up server-only communication you need to do the following:
1. On the client side obtain (somehow, in my case it was built in the client app) the server's certificate and add it to your truststore like that:
KeyStore clientTrustedKeyStore = KeyStore.getInstance(KeyStore.getDefaultType());
clientTrustedKeyStore.load(null, "password".toCharArray());
KeyStore.Entry entry = new KeyStore.TrustedCertificateEntry(cert);
clientTrustedKeyStore.setEntry("alias", entry, null);
While creating sslsockets either on the client or the server side, you need to 'feed' the SSLContext with your keyStore (server), or trustStore (client) to the SSLContext:
tmf = TrustManagerFactory.getInstance("SunX509");
kmf = KeyManagerFactory.getInstance("SunX509");
tmf.init(trustKeyStore);
kmf.init(keyStore, password);
// create, init SSLContext
SSLContext sslCtx = SSLContext.getInstance("TLS");
sslCtx.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);
and then create the sslsocketfactory and sockets.
After creating sockets (only useful on the server side) set authentication mode:
sslSocket.setNeedClientAuth(boolean);
In case of setting up the both-side verification, things you have to change are: authentication mode (obviously), adding certificates to the trustStores on both client and server sides.
The other issue with both-side verification is that the below scenario won't work (although, at least for me, it seems logical):
1. Server issues its own self-signed certificate, adds it to its trustStore and then sends it to the client for him to authenticate with during future connections.
Why won't it work? Because when the client gets the certificate he can only add it to his keystore like that:
ks.setCertificateEntry(alias,cert);
whichjust won't do when it comes to SSLHandshake, you have to authenticate yourself with the certificate added to your keystore with setEntry:
ks.setKeyEntry(alias,keyPair.getPrivate(),keyStorePassword,certChain);
where certChain is i.e.
Certificate[] certChain = {myCert};
That would be all, I'm sure for some people all this is quite obvious, but I hope it will help some SSL beginners like myself :)