Client Authentication by certificates in Google APP Engine java

Question

I am writing an application in Google APP Engine java which authenticate the user by its certificate. I have created a self signed certificate using keytool at client side. I also enable the HTTPS request in google app engine for my application. The flow of application is every simple.

When the user visits the homepage of application using any browser and then try to access a resource of application, I just authenticate the user if it has valid certificate. I am missing the part that how this certificate that I created at client side will be sent to the application when user access my application by any browser? Also How do I validate the certificate?

Answer 1

The point of user certificates is that there are things which are stored on the user side, in particular the user private key. Certificates for authentication will be used as part of SSL (HTTPS is HTTP-within-SSL).

In SSL things go the following way:

• The client connects. The client and server talk to each other.
• The server shows his certificate (which contains the server public key). The client verifies that the certificate is valid (properly signed by a CA that the client trusts; contains the intended server name; not expired; and so on) and then uses the server's public key to do the asymmetric key exchange from which is derived the session key used to protect the subsequent data flow.
• The server may ask for a client certificate. In that case, the client should send its certificate (which contains the client's public key) and demonstrate mastery of the corresponding private key.

These steps are all done in the SSL protocol and you just have to let them run. Your job, though, on the server, is to validate the client certificate. What is that ? A certificate, by itself, proves nothing. Indeed, everybody can create a self-signed certificate with arbitrary contents; you just did it yourself. What makes a certificate useful is how it has been generated in the first place.

In your case, there are mainly three possibilities:

1. The server has a copy of all user certificates (not the private keys) and thus can compare the received certificate with all the known user certificates. A certificate is thus validated by virtue of being bit-to-bit equal to a known certificate. Since the certificate was created client-side, this requires an initial registration phase where the user presents his certificate to the server.

2. The server issues the certificates to the users. This means that in order to create a certificate, some code on the user side (e.g. in his browser) generates a private/public key pair, sends the public key to the server, and the server puts it in a brand new certificate along with the user name, and the server signs it. The resulting certificate is sent back to the user. Later on, when the user connects, the server recognizes the user certificate by virtue of it being signed by the server itself: the server uses its own public key to check the signature on the user certificate. If that signature is valid, then the server knows that the certificate contents are trustworthy, in particular the user name.

3. Same system as situation 2, except that the certificate issuance is delegated to another, dedicated system which will be called a Certification Authority. The user obtains his certificate from the CA, without involving your server at all. Your server can validate the certificate sent by the user by checking that it is properly signed by the CA; the server has a copy of the CA's public key, and trusts the CA for issuing certificates only to properly authenticated users.

Only the third case actually makes sense. Certificates are useful in situations where the assertion of identity (by the CA) is disjoint from the usage of said identity (in your server). If the server is itself the CA, then using certificates offers no advantage over a simpler password-based authentication (the "password" can be a long sequence automatically stored by the browser; this is known as a cookie).

If you are still intent on using certificates, then you must first be clear in your head about what a CA is, what it does, and where it will fit in your system.

Answer 2

I think you cannot authenticate the client using mutual SSL/TLS handshake with GAE.

To achieve this in Java EE you should put this into web.xml

<login-config>
    <auth-method>CLIENT-CERT</auth-method>
</login-config>

Source: https://docs.oracle.com/javaee/6/tutorial/doc/glien.html

However, AppEngine docs says:

App Engine does not support custom security roles (<security-role>) or alternate authentication mechanisms (<login-config>) in the deployment descriptor.

Source: https://cloud.google.com/appengine/docs/java/config/webxml#Security_and_Authentication

Answer 3

In order to have a user present you with a valid certificate for authentication you would have to provision that certificate based on your self signed key to said user beforehand. Based on your comment about extracting the issue name it seems you will need to establish a Certificate Authority (CA) in order to generate certificates to provide the user beforehand with said embedded name (and your self signed key at the root).

Typically that type of provisioning is cumbersome and contrary to the overall experience of the web. Accordingly, your strategy is not used and browsers are not designed to support it. If you want to continue along these lines consider reviewing how SSH can be authenticated by certificates (uses PKI public and private key but not a CA trust chain however understanding the method should still be enlightening).

Again the users' browsers are not designed to offer this certificate so you will have to provide a function to upload them to your server. As for validating and extracting the name, Java has the needed routines in the functionality that provides the keytool which you have already used.