can a x.509 certificate alone be used for user authentication?

Question

we have a scenario for implementing SSO using x.509 certificates. A secure client will download a x.509 certificate (only certificate...no private key is available) upon user logs into the windows machine. Henceforth for all web applications, we would like read this certificate for authenticating the user. when we tried for reading the browser certificates(by configuring tomcat to request client certificate), able to read only certificates with private key. not able to read the x.509 certificate put up by the secure client.

Can somebody help me to read the x.509 certificate from server side? Or only certificates with private key alone could be used for this purpose?

Answer 1

What you describe is unworkable.

Without rewriting the SSL implementation on the client and the server, the client must have the private key for the exchange. The authentication comes from using CN as the identifier for the user - hence for webservers it contain the IP name of the server. For authenticating email addreses, the CN contains the ADDR_SPEC. What you put in your CN is up to you.

There is a further complication in your proposed method - the user must install the certificate, although this is not terribly complex.

You can't prevent a third party website from dreading the details of the client certificate if the user browses to that site (ISR that it is possible to restrict use of client certificates to specific sites, but don't remember the specifics). But they don't get to see the private key (via the SSL/TLS connections).

Your insistence on not providing the private key to the client makes any use of client certificates impossible.

Answer 2

No, or at least, not for any robust user authentication mechanism. (Admittedly, the certificate almost certainly contains more entropy than a typical user password, but that's not the point here.)

Without a key, the decryption and signing operations cannot be performed, these are critical to X.509.

An analogy might make it clearer: compared to a username and shared secret authentication method, the certificate is analogous to the username, and the key analogous to the secret. (I'm using a shared secret as an example, not a password, because the shared secret is not transferred as part of the authentication. both sides prove they know the same secret rather than just blurting out a password for comparison; with TLS the private key(s) are never transferred either.)

This really is quite an oversimplification though, the magic of an asymmetric system such as RSA means that there isn't even a shared secret (more precisely, no shared secret in advance, one is negotiated per-connection for the symmetric encryption). In TLS with a client certificate, the server ensures that the client is in possession of the key by requiring that the client send a signature of the TLS handshake messages which the server will verify. No key means no signature, and the TLS set up will fail.