Using SSL as means to secure data connections to specific servers on the net is a widely adopted standard.
One of the limitations of domains secured with SSL certificates is that a certificate needs to be hardcoded to be only valid for a single subdomain + top-level-domain combination, like www.example.com. If your sitestructure requires you to setup subdomains like ftp.example.com your (purchased) SSL certificate won't be valid for this subdomain. Every browser will complain, and for example Firefox 3 will completely hide the site until a good amount of clicking and accepting is done.
Anyway, this problem can be solved with what is called a wildcard certificate. On the creation of a SSL certificate, more precisely on the Certificate Signing Request step, you are asked to enter certain key essentials about the organisation asking for a request, among these details is the "Common Name (eg, YOUR name) :" - which is the domain the certificate will be used for.
Under www. only operation you would enter "www.example.com" here. To enable a so-called wildcard certificate, you might assume you would enter "example.com", but actually you need to enter "*.example.com" (a wildcard placeholder). This actually breaks standards but does magically work, furthermore even certification authorities (CAs) require this non-standard notation.
The downside of wildcard certificates is that CAs already charge for standard certificates and they want you to pay even more for wildcard certs! Time to propell development of the free CACert.org CA alternative and enable proper security for all of us without silly trouble.
As you might know you can also self-sign certificates, but this will also pop-up browser warnings and is thus not ready for production environments.
Hint: While debugging your SSL installation, this trick might help you debug your SSL.