Actually that's not the case, you can get single certificates which cover different domains, using the Subject Alternative Name field.
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?
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.
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.
That's the one downside of this HTTPS-everywhere movement - we're beholden more than ever to the certificate authority cartel.
'//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'