How Digital certificates provides extra security on top of SSL?
In general, I wouldn't say digital certificates provide "extra" security on top of SSL/TLS. Rather, they're an essential part of it. Although the PKI details and how to verify the certificates isn't part of the TLS specification (RFC 5246) (there are a couple of additional specifications for this, such as RFC 5280 and RFC 6125), the specification itself clearly references quite heavily certificates and how they should be used.
You seem to be talking about client certificates, but you probably already know about server certificates, which are far more common.
In both cases, the purpose of certificates in SSL/TLS is to authenticate the communicating parties, so that each party can be sure it's talking with the remote party it expects.
You should always at least have a server certificate (otherwise the connection would be vulnerable to MITM attacks). This proves the identity of the server to the client.
In addition to this, some configurations expect the client to provide a certificate. Since you're talking about users using their certificates from their browser, you seem to be in this situation.
In this case, the extra security is that the client is subjected to the same strength of authentication from the server, as the server is from the client. In particular, since the private key never leaves the remote party in this process, this helps prevents impersonation by password theft (since no password is transmitted). There are more details in this question on Security.SE.
Requesting a client certificate is something that can only be done by the server. If your server is configured to do so, it will send a message to the client (your browser) during the SSL/TLS handshake, and this message will normally contain a list of CA certificates it trusts, to give an indication of which client certificates it is willing to accept. (In this particular case, your server will most likely have been configured to request client certificates issued by your CA.)
Your server will have been coded and configured to do so (I'm not sure from your question whether you're using a Java Servlet container or a bespoke Java server).
The validation of the certificate is done by the trust manager in Java. This is often initialised transparently by providing the application with a trust store and relying on the default behaviour of the default SSLContext (then used by the default SSLSocket or SSLEngine depending on how your application is coded). Assuming your server uses the default trust manager and is configured with a trust store containing your CA certificate (and is also set up to request a certificate), it will send the name of that CA to the browsers than connect to it, and it will also use that CA to verify the certificate then sent by the browser.
(Some applications may also have a customised trust manager, but then its behaviour depends entirely on what it was written to do.)
Java provides two way of requesting a certificate: "need" or "want" (see SSLSocket.setNeedClientAuth(...)). The difference is that with "need", the connection will stop if the client didn't present a user certificate, whereas it will continue in this case with "want".
After this, the server application can check the authentication status of the user by checking the peer certificate from the SSLSession. (It won't get any peer certificate if the client didn't send one and the server used the "want" mode. This may be fine for anonymous access.)
At this stage (provided the server application was coded with the correct trust manager, i.e. not a dummy one), the server code will be ensured that the remote user is indeed the holder of the private key matching that certificate. The Subject Distinguished Name of the certificate can then be used as the identity of the remote party. (Some servers allow you to match this to a different set of user names if necessary. This will depend on which exact server you're using and how it's configured.)
As you said Digital certificates are essential part of ssl not different from it(where digital certificates are sent from server to client containing the publick key and information about the CA whom browser trusts). Now browser will send the data encrypted with public key which will be decrypted at server side with private key. Similarly when server send the response it will be reverse i.e encrypted with public key and decrypted with public key at browser side Right?
No, whether you use client certificates or not, the connection will be encrypted in both directions anyway, using a symmetric key negotiated during the handshake. Client certificate have nothing to do with it. The client certificate is only used to sign the handshake at the end, to prove to the server that the client has the private key for this certificate.
The details in your edit seem to indicate you're using a configuration that's probably a bit more complex than usual.
Firstly, your Connector doesn't have a clientAuth attribute (so its default value is false). This implies that the client certificate will not happen during the initial handshake, but will be triggered by a second handshake when you try to access the protected resource (according to your security-constraint configuration). This is called re-negotiation, and it's not unusual.
(I've also noticed that it doesn't have truststore-related settings, which implies it's using the default JRE truststore, which also implies that your custom CA certificate must have been imported explicitly into that truststore (cacerts in general). Keep this in mind if you upgrade your JRE, since you're probably have to import that cert there manually again.)
Your tomcat-users.xml configuration is what I was talking about earlier (about matching Subject DNs to user names or roles). This, combined with your custom valve is what's unusual in your settings.
My guess would be that this valve maps any valid certificate to a pseudo-user called ignoreAndCheckInWebApp, just to be able to pass that security constraint, although your application would be expected to look at the certificate itself.
In a more traditional case, the usernames in tomcat-users.xml would be the Subject DNs of your certificates, and you would map them to roles this way. Here, it seems your deployment doesn't care about this mapping at that point, but is meant to check this within your application later. This probably means that your application should directly rely on HttpServletRequest.getRemoteUser() (unless it's also set up by a filter later), but should read the certificate using the "javax.servlet.request.X509Certificate" attribute from the request.
This can make sense if the application does all of this correctly. What I'm saying here is really a guess, since it depends entirely on how the Tomcat valve is implemented. This will certainly affect the remote user name and user principals that you get.
Regarding your comments about ActiveX and IE, client-certificate authentication should also work fine with Firefox or Chrome. Two things come to mind:
- That ActiveX code may simply have nothing to do with client certificates, but may be part of the what the application is meant to do.
- That ActiveX code is part of your own CA, as a means to let your users apply for certificates from within their browsers (when they don't already have one). Perhaps this was only implemented for IE, although it could be done for Firefox or other browsers too.
