Correct me if I'm wrong but one problem is multiple domains on a single machine. Each SSL cert should correspond to a unique IP, and if you don't have wildcard SSL, that means every single domain and sub-domain.
Separating requests through host header / name-based virtual hosting is not supported on https. Startups discussed on HN will most probably own the machine, but it's problematic for small sites.
Not true. SSL doesn't even really know what an IP address is, and it's quite possible to use a single SSL certificate on multiple IP addresses if the CN resolves to all of them (in round robin DNS, for example). If you mean that one IP address can only support a single SSL host, that's never been entirely true, as it has always been possible to support multiple SSL sites on a single IP using different ports (example.com:4443, for example). But you probably don't want to specify the port, which is addressed now by Server Name Indication (SNI): http://en.wikipedia.org/wiki/Server_Name_Indication
if you don't have wildcard SSL, that means every single domain and sub-domain
Some CAs now sometimes include a X509v3 Subject Alternative Name for DNS, so you might get www.example.com tossed in for free when you buy a cert for example.com. Unfortunately, not all clients support this field.
Separating requests through host header / name-based virtual hosting is not supported on https.
Once again, SNI is likely to fix this as soon as it is ubiquitously supported by browsers (already support is pretty good). However, note that name-based virtual hosting is a web server feature that really has nothing to do with SSL/TLS. It's quite possible to use it for HTTPS without any problems for at least a single domain. In fact, I do it for all of my secure sites to ensure that content cannot be requested using the bare IP address or a different domain that resolves to the same IP. This should really be a best practice, but there's a lot of shrill advice against it that is extremely outdated and needs to just die.
In any case, most of the problems you mention are solvable now, even for small sites. The real problem is in saying that obsolete insecure web clients will not be supported on your site, and that's getting easier to do every day.
Wondering if one could practically implement a site with TLS+SNI for browsers that support it while letting browsers on XP and others that don't support it hit the site with HTTP unencrypted.
Of course, not appropriate for all sites, but definitely a step forward for sites holding out due to incomplete support.
Comments
Correct me if I'm wrong but one problem is multiple domains on a single machine. Each SSL cert should correspond to a unique IP, and if you don't have wildcard SSL, that means every single domain and sub-domain.
Separating requests through host header / name-based virtual hosting is not supported on https. Startups discussed on HN will most probably own the machine, but it's problematic for small sites.
Each SSL cert should correspond to a unique IP
Not true. SSL doesn't even really know what an IP address is, and it's quite possible to use a single SSL certificate on multiple IP addresses if the CN resolves to all of them (in round robin DNS, for example). If you mean that one IP address can only support a single SSL host, that's never been entirely true, as it has always been possible to support multiple SSL sites on a single IP using different ports (example.com:4443, for example). But you probably don't want to specify the port, which is addressed now by Server Name Indication (SNI): http://en.wikipedia.org/wiki/Server_Name_Indication
if you don't have wildcard SSL, that means every single domain and sub-domain
Some CAs now sometimes include a X509v3 Subject Alternative Name for DNS, so you might get www.example.com tossed in for free when you buy a cert for example.com. Unfortunately, not all clients support this field.
Separating requests through host header / name-based virtual hosting is not supported on https.
Once again, SNI is likely to fix this as soon as it is ubiquitously supported by browsers (already support is pretty good). However, note that name-based virtual hosting is a web server feature that really has nothing to do with SSL/TLS. It's quite possible to use it for HTTPS without any problems for at least a single domain. In fact, I do it for all of my secure sites to ensure that content cannot be requested using the bare IP address or a different domain that resolves to the same IP. This should really be a best practice, but there's a lot of shrill advice against it that is extremely outdated and needs to just die.
In any case, most of the problems you mention are solvable now, even for small sites. The real problem is in saying that obsolete insecure web clients will not be supported on your site, and that's getting easier to do every day.
http://en.wikipedia.org/wiki/Server_Name_Indication#Client_s...
It's possible, but needs XP to die before it's practical.
Wondering if one could practically implement a site with TLS+SNI for browsers that support it while letting browsers on XP and others that don't support it hit the site with HTTP unencrypted.
Of course, not appropriate for all sites, but definitely a step forward for sites holding out due to incomplete support.
You can with SNI. See here: http://en.wikipedia.org/wiki/Server_Name_Indication Check the support section too.