Your browser checks the certificate to see who issued it, and if it was issued by a Certificate Authority (ie company like Thawte, Globalsign etc) that it “trusts”, then it checks it against that company’s public key to ensure it is authentic.
If the certificate was not issued by any company your browser recognises (as in the case of a self-made key) or any other information appears suspect, then the browser will give a warning.
Note that just because a trusted Certificate Authority issued a certificate does not mean that the person you’re communicate can be trusted. It’s just a means of identifying that they are who they say they are, so it’s also important that the user checks the domain name or company name on the certificate and makes up their own mind about whether the company they are dealing with is trustworthy.
Why do you say that?
What if the client is a “bad guy”?!
Shouldn’t the server need to know something about who the client is?
Normally on the web, if the server needs to be able to verify who the client is, they do this once the secure session has already been opened. For instance, by requiring a login. The login details are all sent over the already secure channel. That is why I said the server doesn’t need to know who the client is in order to start the secure session.
This is a bit more user friendly, and privacy-friendly, than requiring all web users to have a certificate installed in their browser signed by a certain certificate authority (though some rare services do sometimes request a certificate from a client for security reasons).
So how does this relate to my original post and concerns?
Do you agree that all I need is a web-hosting account and an SSL certificate?
Or is there something missing?
Yep, you’ll need an SSL certificate signed by a trusted Certificate Authority and issued for your actual domain name. An SSL certificate included free with your hosting package may not satisfy both those criteria.
You’ll need to get your host to enable HTTPS with that certificate. For Jane’s sake, make sure that the same content is not available via regular HTTP, and make sure none of your internal links, and links to things like scripts, stylesheets and images, lead to non-HTTPS sites. That’ll ensure her browser will never lead her to the same site, unprotected, or show a confusing warning about non-encrypted page elements.
There’s no special code to switch into or out of a secure connection except the “https:” at the beginning of a URL. Make sure the user is using a secure connection before logging in (ie, the login page should be included in those pages that are only accessible via “https:”).