|SSL Certificate Conundrum - how many is one expected to buy?|
| 11:03 pm on Jun 11, 2009 (gmt 0)|
I purchased a security certificate and got it installed. Low and behold, it only covers the http:// version of the Web site and not the [www....] version. Now I hear that we have to pay to get a second certificate that will cover the www. domain.
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.
| 11:26 pm on Jun 11, 2009 (gmt 0)|
Standard practice, you are buying 1 domain (unless you buy a wild card certificate). example.com and www.example.com are 2 completely different domains (technically, 1 domain and 1 subdomain).
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 https://www.example.com pages to https://example.com.
| 11:49 pm on Jun 11, 2009 (gmt 0)|
I get it. The issuer allowed me to switch from http to www at no fees. Guess that's the grace period you were talking about.
| 4:00 am on Jun 12, 2009 (gmt 0)|
Just a side note, as I understand it, this is this way because the precise URL is one of the "seeding factors" in generating the encrypted string that makes up the cert, others being company name, specific server attributes, etc. So a single cert can't really validate and encrypt both www. and non www.
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.
| 4:19 am on Jun 12, 2009 (gmt 0)|
We only use the www and have a redirect in the .htaccess, but I was surprised to see that pages din,t work using the www.
When ordering the certificate, I would never have guessed that it wouldn't work with our www.
| 12:34 am on Jun 13, 2009 (gmt 0)|
It looks like the certificate provider sold you exactly what you asked for, but they failed in their responsibility to explain correctly the importance of specifying the exact domain (including any subdomain elements such as www) when making your order. I'm glad they made the appropriate modification for you for no charge.
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.