Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Howto: Multi-domain SSL, Nginx, 1 IP address (playnice.ly)
122 points by adamcharnock on Jan 3, 2011 | hide | past | favorite | 34 comments


"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?


I agree. My apologies to adamcharnock. I should have said "inexactitude" instead of "lie". I did not choose the right word when typing my reply.


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.


i'm assuming you're not joking. it's "browser recognition" and this value is generally 99.9% for paid providers.


that doesn't help if you still want folks who use IE on XP to connect to your site with SSL, since you can't rely on SNI in that instance.

The key part was the "1 ip address"


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.


i know, i saying that getting multiple single domain certificates won't fit the bill. That's why a UCC was needed


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).

1. http://www.google.com/search?q=ssl+cert

2. Click on one of the GoDaddy ads.

3. ???

4. Save


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.tld and https://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.


Thank you for the information on the Android browsers. I have added your points to the post and linked back to your comment.


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"


I wonder if this is why wget'ing from github always returns me the --no-check-certificate error:

ERROR: certificate common name `*.github.com' doesn't match requested host name `github.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 ( \* ).

Edit: or maybe not.


Note that the subjectAltName method GitHub is using doesn't seem to work with stock version of curl and wget on Debian (throws a cert error)


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. ($$--).


An article like this isn't complete without a browser compatibility list.


Good point! I have just added a new section to the blog post which includes the browser compatibility points which have been made here.


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).


No, this uses one certificate, but with multiple domains listed in subjectAltName. Like SNI, it may not be supported by all clients.


Has anyone seen a similarly authoritative guide for those of us stuck on apache?


I used this article as a reference for the post:

http://www.crsr.net/Notes/Apache-HTTPS-virtual-host.html

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:

http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#sslcertifi...

I hope that helps!


[original comment removed]


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.


You are right, I was sure that the title was "Multiple-certificates...", not "Multiple-domain UCC certificate".

That's what I get for not reading the whole thing, sorry.


Yes it does. The page in question describes setting up a certificate with multiple names. This works fine for XP and doesn't need SNI.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: