Q:

Handling password updates in Java SSL

I have a client-server java application, where communication happens over SSL. Right now I am generating keypairs by hand, but I need a programmatic system for key management.
The server maintains a user database, and on the client side I do not want to store a copy of the password. Somehow the client will log in to the server using a password. If the password is correct, the server and client will set up keys. From then on they can use those keys and not have to use the password. This brings me to my first question:

When the user enters the password the first time, how do I encrypt that transmission? Because there will be no keys and thus no SSL at this point.

Then there is the issue of the user changing their password. The idea is they will go through a web interface to change their password on the server. Then the next time a client connects, their old keys should not work and they should be asked to enter the new password. Which brings me to my next question:

What is the best practice for
handling the password change when
dealing with SSL?

I can just delete the server side key when they change their password. Then the client wont be able to communicate, and then I can have the client ask for a new password. But it seems a little kludgey.

A:

You still can have SSL between client and server. In fact, you should. 
The server won't be able to trust the client yet. Client can trust the server, because the server certificate is available to the client.
For example, look how most logins on web are implemented: you are not authenticated yet, but you're going into HTTPS. This is one-way SSL. Client is using a temporal key. Password is passed over the encrypted connection. This protects from eavesdropping.
When the mutual trust (through validation of the password) is established, you can pass client certificate over the same connection and reset the session. From that moment you'll have a two-way SSL, a mutual trust.
UPDATE
I see a bit of confusion in the thread due to not clear wording of "requirements". Let me write down the collaboration between client and server:
Session 1:

Client needs to talk to server
Client generates a temporal pair of private and public key
Client connects to server via SSL and passes public key to server for the session
Client receives server public key/certificate and compares it to one it knows a priori; bail out if mismatched.
One-way SSL connection has been established at this point; client knows for sure it talks to server, while server doesn't know the identity of the client. The connection is encrypted though.
Client passes in credentials (userid and password, likely).
Server validates them and bails out if they do not match.
Server now trusts the client is, say, John Smith from Nebraska.
Client asks server to store current public key as client permanent public key OR generates another key pair and sends the public one to server (I do not see a problem to use the same key, but I may be overlooking something).
End of session.

Session 2:

Client connects to server over SSL
Client provides its public key/certificate
Server compares it to the one stored on server side
Server provides its public key/certificate
Client compares it to the known one.
Mutual trust has been established, connection is encrypted, server knows the client is John Smith from Nebraska.
Still, to be on the safe side, server may still request John to enter the password.

