There are a few issues here, the major one being authentication. Both ends need to be sure they are talking to the right person or instituttioninstitution to thrawtthwart man-in-the-middle attacks. On your end it is crucial that you use an SSL certificate which is trusted by the usersuser's browser. By doing so the usersuser's browser can be sure that it is really talking to the correct site. Once the connection is established you can be sure to be talking to that user all the time and the connection is encrypted, i.e. secure against eavesdropping.
Authentication in the other direction (i.e. making sure you are talking to the real user) is usually handled outside of the SSL protocol on the application level by, e.g., username/password, openID or some other form of credentials.
As a last note it should be mentioned that during the SSL connection handshake client and server agree on a Cipher suite and the client could pretend to only do "null encryption", i.e., not encrypt any of the data. If your server agrees to that option, the connection uses SSL, but data is still not encrypted. This is not an issue in practice since server implementations usually do not offer the null cipher as an option.
