[yorhel]

Somewhat related question: It's fairly common for sites to have static files (images/css) served on a different (sub)domain. What are you supposed to do when the html content is being served on HTTPS? Should the static files be on HTTPS as well? If so, wouldn't it need a different certificate? Certificates are only valid for a single domain, after all.

[moonboots]

If you don't want to pay a premium for a wildcard certificate, you could just get another certificate for the static subdomain. You can get an unlimited number of free, single subdomain certificates from StartSSL.

[pwaring]

"Certificates are only valid for a single domain, after all"

Actually that's not the case, you can get single certificates which cover different domains, using the Subject Alternative Name field.

[rmc]

You can get SSL certs that are valid for wild card subdomains, e.g. *.example.com

[agwa]

Wildcard certs tend to be very expensive. If you only need two domains it's probably more cost-effective to just buy two certs.

Edit: a downside of using separate certs is that you'll need to serve the respective sites from separate IP addresses, or rely on SNI [1] which isn't supported in older browsers. But if the use case is a separate domain for serving static files, that's probably hosted on a different server/IP address anyways, right?

[1] http://en.wikipedia.org/wiki/Server_Name_Indication

[rmc]

if the use case is a separate domain for serving static files, that's probably hosted on a different server/IP address anyways, right?

Not necessarily. People used to have different domains for images/css/js because browsers used to not want to download more than 2 things at the same time from the same domain name. (Back when the web was young and ugly, and bandwidth was scarce, this made sense). By having multiple domains (e.g. a.static.example.com, b.static.example.com etc.) on the same IP addres/server, you could trick browsers into downloading more in parallel and make your site seem faster. You didn't need multiple IPs for that.

Now-a-days browsers have upped their limit from 2 to something like 8 → 16 or so, so it's less of a problem.

[Erwin]

A certificate can also have a number of alternate names, which providers call a Unified certificate -- UCC. The nice thing about that is that you can add/remove names after you've bought the certificate without having to go through the process.

I haven't tried this in practice though, but this might be useful if you want to provide a bunch of client.yourdomain.com secure subdomains from the same IP address. Only downside is that the organization name will be the same.

[peterwwillis]

This is also wildly more secure than a wildcard certificate, where if someone nicks your private key your entire domain is compromised, but with UCC only select hosts' security could be compromised. I believe it's also supported in more devices than SNI (since X.509v3)

[agwa]

Also more expensive than vanilla single-name certs :-(

That's the one downside of this HTTPS-everywhere movement - we're beholden more than ever to the certificate authority cartel.

[yorhel]

Ah, I wasn't aware of that. Thanks!

[justhw]

If you are concerned about the warnnings that users see, just call your static files in such a format.

'//www.your-cdn.com/image.jpg'

In other words don't specify http or https in the url, just do '//your-url.com/new.js'

[adgar]

Wildcard certificates.