Forum Moderators: phranque
Is this a standard practice in the industry as we were clearly not informed of this type of policy when we made the purchase, thinking we had all our asses covered. Now we paid a lot of money for a "deluxe" certificate - we did not get the cheapest option. We feel cheated by the issuer.
Any advice?
Some (most?) should have a "probation" period of a few days where you can have the certificate re-issued with changes (for example, if you want it issued to www.example.com instead of example.com). But if you want one for example.com and www.example.com you will need to buy 2 certificates or a wild card certificate.
An alternative solution is to redirect any [example.com...] pages to [example.com....]
For most of us it's really a non-issue. With or without the www, your secure server is your secure server. When you need to encrypt data to and from the server, put the full URL to it, www or not.
One thing catches my eye,
covers the http:// version of the Web site and not the [www....] version
Although the standard hosting/DNS setup is to direct both www and non-www to the same site, this can present negative duplicate content issues. Search engines see these as two sites, diluting the strength of both. You really should pick one or the other, and do an internal rewrite to the one you choose with a 301 permanently moved header. This puts all the search engine mojo to one site.
More info in the apache forum.
rocknbil above mentions the one thing to be careful with when dealing with an SSL certificate for the same domain/subdomain currently used for your main site, that being duplicate content.
Some have taken the route of using SSL only on a specific subdomain, such as secure.example.com. Otherwise, you should look at ways of either dynamically generating noindex meta elements (or X-Robots headers) for HTTPS versions of your pages, or use mod_rewrite to either serve a different robots.txt for the secure and non-secure versions of your site or ensure only the appropriate sections of the site are served via HTTPS, with other pages being redirected to the HTTP version.