Guspaz wrote:
For your first question, no, it's not possible. The web server doesn't know what domain you want to access until after the encrypted session begins, and the certificate is needed before session begins. So there's no way for the webserver to know what certificate it should use until after its used the certificate; a paradox.
Note that technically this isn't an absolute limitation since SNI was introduced (which embeds the server name information within the encrypted session negotiation, so the information is available before the session begins), but I agree in practice at the moment, since unless you know all your clients support it, it may not be a practical solution.
To the OP, you can cover example.com and
www.example.com with the "Subject Alternate Names" field in the certificate. For example, the primary CN in the certificate would be for
www.example.com (or whichever of the two is your primary use name), but you'd have an alternate name value for example.com (you should also repeat the CN in the SAN field for best compatibility). Making a wildcard certificate (a wildcard value in the CN) would only be needed if you had other hosts/subdomains beneath example.com.
Whether or not your certificate provider lets you create such certificates (or more likely charges more for them) is up to that porvider. Some give them different names like a UC or UCC certificate. Of course, if you're self-signing, do anything you want.
For what it's worth (and only because I just recently had reason to use them, not to try to change to a certificate authority discussion), a free certificate from StartSSL I made recently automatically included the unadorned domain name as an alternate name in the certificate. That is, creating a single host certificate for
www.example.com will should include example.com as an alternate name automatically. I've used very few commercial CAs, so maybe that's common behavior, I don't know.
-- David