My sites run off a subdomain (yyy.xxx.com), but I'm required to include CSS files from the main domain (xxx.com). We run a CMS that doesn't let me do any server-side stuff during the preview stage, so I'm stuck sending a page over https that includes a CSS import to http. All my IE users get a mixed content warning because of this.
Is there any client side way for me to prevent this, other than maintaining separate security settings for the domain on every client machine?
As far as I know, there's no way to avoid that warning. It's there particularly for this purpose: alert you to the fact that even though you believe your page is SSL-encrypted, some of its content isn't. You'll either need to serve the original page over HTTP (not recommended), or serve the CSS file over HTTPS.
When you say that you cannot do "server-side" stuff, do you mean that you cannot touch your CMS, or that you do not have root access to your HTTP server?
Because if you do have access to your HTTP server, you could set up a very simple reverse proxy (with mod_proxy if you are using Apache). This would allow you to use relative paths in your HTML, while the HTTP server would be acting as a proxy to any "remote" location. In fact this technique can also be used to mitigate some cross-site scripting issues.
The fundamental configuration directive to set up a reverse proxy in mod_proxy is the ProxyPass. You would typically use it as follows:
ProxyPass /css/ http://xxx.com/css_dir/
In this case, the browser would be requesting https://yyy.xxx.com/css/main.css but the server would serve this by acting as a proxy to http://xxx.com/css_dir/main.css. It will not raise the browser warning, and works fine with SSL.
Make use of protocol-relative URL's in the CSS links.
Thus so
<link rel="stylesheet" type="text/css" href="//example.com/style.css">
instead of
<link rel="stylesheet" type="text/css" href="http://example.com/style.css">
It will automatically pick the protocol of the parent request, which should work fine for HTTPS as well.