Hacker News Reader

Comment by JoshTriplett | Hacker News Reader

If you're willing to write off users of Internet Explorer on Windows XP, you don't need a dedicated IP for SSL; you can simply use Server Name Indication (SNI).

View on HN

Android 2.x also doesn't support SNI.

Android 2.x is rapidly becoming the new "Windows XP".

But then I'd need to support SSL for all domains hosted on the server, and this would mean getting 5 certificates instead of one.

That's not true. Why do you think that?

Actually it is, because you'd still have a domain pointed to an IP address listening on 443, and that IP address wouldn't know how to handle the domain that is not configured to listen on 443, so it would serve the default domain (generally the first SSL-configured domain with Apache, or 'default_server' on Nginx). This means you'll be serving a certificate for your default site 'foo.com' when you requested 'bar.org', providing the user with a domain mismatch security warning.

The second non-solution would be to configure every domain with self-signed certificates, but then you'd still be sending your clients an untrusted certificate. The only way to truly provide SSL on a shared host is to configure it with a UCC certificate that includes every domain you are pointing at it, or generate cheap/free certificates like StartSSL's for every unique domain and subdomain you listen for.

Why does that matter if bar.org doesn't and isn't supposed to support HTTPS, and if there are no links to bar.org via HTTPS? In either scenario if someone manually types in https:// bar.org it's not going to work.

People wouldn't be connecting to the website using HTTPS if it didn't have a certificate in the first place, so why does it matter if 'bar.org' doesn't have a certificate?

I don't think it's at all obvious or universally true that it's better to get an 'Unable to connect' error message than a certificate warning (btw, the default site could tell the user they arrived there by accident should they continue past the warning). Depends on the context.

I'd still say it's definitely not true that you "have to" get an SSL cert for all virtual-hosted domains on one IP address if that IP address is responding to SSL requests on 443.

You'd need at most two IP addresses to resolve this problem: one for HTTP/HTTPS sites, and one for HTTP-only sites.

Nope, just find a CA that will give you a certificate with SAN extensions at a cost that you can afford. Usually you can get up to 5 SANs at a reasonable cost, and up to 100-150 SANs for more dollars.

Reply on news.ycombinator.com