"In the past it has not been possible to serve SSL requests for multiple domains from the same IP address."
This is a plain lie. This article just describes a technology that has been available for years: using Subject Alternative Names to declare all the host names in a single X.509 certificate. As far as I can tell, real CAs have been signing these types of certs for years (one random example: https://www.rapid7.com is valid for "www.rapid7.com" and "rapid7.com" without using a wildcard cert). The article call these certs "UCC SSL certs" but it is nothing more than a marketing name to sell Subject Alternative Names.
I see, this was just down to a lack of awareness on my part when I wrote the article. It was an assumption I based on the fact that I just hadn't seen these certificates around before now. It was certainly not my intention to mislead.
I have a bit of a problem with people, like you, who will call someone a liar.
lie, noun, an intentionally false statement.
To insinuate that someone is a liar used to be a considerable personal slight and writing it here makes it libelous. Have you proven intention? Would it not be more polite to say that the OP was simply mistaken. I would kindly ask the OP to rewrite the offending sentence, perhaps like so "In the past it has been difficult to serve SSL requests for multiple domains from the same IP address."
That this comment has received a number of up votes is disconcerting. Where is the decorum oft afforded the HN community?
May be worth mentioning a tip I learned on an earlier HN thread: https://www.startssl.com/ provide single-domain standard SSL certs for free, and look considerably cheaper than GoDaddy for the UCC certificates discussed here.
If you only need a certificate for (www).domain.com, (not a certificate with multiple names as detailed in the story) then here are step-by-step instructions for getting a free certificate from StartSSL: https://github.com/ioerror/duraconf/blob/master/startssl/REA...
Do StartSSL issued free 1-domain certificates valid for all major desktop and mobile browsers? Can anyone confirm this? Most cert providers claim almost always 99% and above comptability but they dont claim any percent value on their website.
99 percent of what? Browsers ever made? Visitors to your site?
I read that Microsoft added the StartCom CA to Windows in 2009. So I would assume that people browsing the web with ancient, unpatched versions of IE will have problems. How big a deal that is probably depends on your site.
Multiple names in the certificate isn't the same as SNI. The server is still giving the same certificate to every client so SNI support isn't needed and XP clients will work.
A note about GoDaddy: their prices fluctuate. If you enter the site via a Google Ad, the price drops from ~$60 to ~$13 (I'm in Canada so I'd be interested to know what the prices are like from other places).
I'm in Russia. They seem to classify me as a European and issue prices in Euros. I see "Only €10.91" in the ad text, and €9.71/year when I click on the yellow offer and put "Standard (Turbo) SSL (1 Year) (annual)" to cart. That might be excluded VAT, because Russia is outside European Union.
Care should be taken to test across multiple platforms (especially mobile!) when using SSL configurations other than the classic 1-domain, 1-ip, 1-server setup.
The problems with SNI have already been discussed here, but we've also found issues with older Android browsers getting certificate warnings when using UC certificates. Specifically, there are issues when using a wildcard UC certificate (so one can have both https://root.tldandhttps://anyvar.root.tld) on Android OS's prior to 2.0.
Also, if you use StartSSL, be sure to configure the intermediate CA (in addition to a root CA) in your server's config. Again, this was an issue where most desktop browsers worked fine, but a handful of mobile browsers failed or had extended load times.
FYI, one major website which relies on subjectAltName which many of you will be aware of is github. The CommonName is ".github.com" which means it wouldn't be valid for https://github.com/, but they also have "github.com" in the subjectAltName field.
https://www.cacert.org/ also lets you generate certificates for multiple domains using subjectAltName. My website at https://secure.grepular.com/ has a CN of ".cardwellit.com", but then has three values in subjectAltName, "cardwellit.com", "grepular.com" and "*.grepular.com"
Yes, that is the reason. wget doesn't seem to have been updated to support subjectAltName yet. If you do a search for "wget subjectAltName" you'll see that patches have been submitted for such support. I guess support will be rolled out eventually.
The comment system here has munged the above. Anywhere you see an opening double quotation mark followed by a full stop, there should be an asterisk inbetween the two.
For future reference, any text between two asterisks will be italicized, as you probably already know, but any escaped asterisk will show up as an asterisk ( \* ).
Yeah, I noticed this recently too as Debian is my server OS of choice. I'm surprised they haven't been updated yet. Maybe they have, and Debian hasn't been updated yet?
Cool. Any idea if there are more browsers supporting UCC certs than those supporting SNI?
If your domain list is quite static/stable, this is great.
Otherwise, as I believe it still suffers from the problem that you must create a new UCC cert ($$++) each time you want to add to the domain list, I'd be happier with SNI and one cert per domain. ($$--).
is this related to SNI which doesn't work in IE under Windows XP? That would still be a considerable amount of users for whom SSL wouldn't work (right).
It does cover the Apache config towards the end, and it doesn't look too involved. You can still follow the OP up until just before the "Chained certificates" section.
If you do need to use a chained certificate in Apache, you should see:
The article doesn't describe SNI at all. With SNI, you can deploy multiple certificates on the same IP address. The method described here uses a single certificate that includes multiple domains in the subjectAltName.
Obviously, SNI is the superior solution for a shared hosting environment. The approach described in the article is fine for consolidating some related domains into one certificate, but would be an expensive management headache for many unrelated domains.
This is a plain lie. This article just describes a technology that has been available for years: using Subject Alternative Names to declare all the host names in a single X.509 certificate. As far as I can tell, real CAs have been signing these types of certs for years (one random example: https://www.rapid7.com is valid for "www.rapid7.com" and "rapid7.com" without using a wildcard cert). The article call these certs "UCC SSL certs" but it is nothing more than a marketing name to sell Subject Alternative Names.