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:
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.
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.
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.