WordPress has a number of implicit assumptions with regards to using SSL. Specifically, if you are using force_ssl_admin, and the “front” of your site has the same domain as the “back” does, then it assumes that your entire site is actually accessible either via http or https.
This happens in a few different places. Most notably, the Theme Customizer intentionally loads the preview window (the front end view of your site) using SSL when force_ssl_admin is on and the domain of the site matches. The Preview link on the posts screen will be relative and thus will go to an SSL page too.
So, the short answer is that this is by design and it probably will not be fixed by WordPress core anytime soon. It is expected that your site will work over SSL if you’re using SSL anywhere, and so it tries to do it that way. If you have anything else on your site actively preventing the front-end from working over SSL, then it will be broken. And many in the community would say that, yes, it is supposed to do that.
You’re creating the problem yourself, essentially, by the arbitrary action of disallowing SSL on the front-end. You don’t have to actually force SSL on the front-end, but to actively disallow it can lead to security risks. How we define the “front” and “back” end of WordPress is somewhat arbitrary to begin with, and if you really want security, then it has to be capable of loading any page on the whole site with SSL, not just the stuff in wp-admin.
If your CDN is the problem here because they have no https capability, consider a different CDN that will support HTTPS, or maybe change the code to serve from the CDN only over http connections and to use the local versions of files for https ones. That’s a short term fix though. A number of CDNs let you point a domain name you control at them, and then you can set up SSL on that domain name. So if you have a certificate for example.com, you could point cdn.example.com at them, then they could use your cert for securing that connection. Or whatever, different CDN’s have different ways to support HTTPS.
In the long run, the whole of the web is moving more towards 100% SSL all-the-time. Newer protocols like SPDY (supported in most major browsers) can dramatically boost transfer speeds, and they only really work on SSL connections to begin with. With more and more “hacked” sites, and the recent NSA revelations, and everything else, unencrypted connections are rapidly falling out of favor. So most advice you’ll get nowadays will be to just bite the bullet and go forced-SSL over the whole site.