TL;DR: bing SSL certificate is wrong.
https://bing.com: subject=/CN=*.bing.com
https://www.bing.com: subject=/C=US/O=Akamai Technologies, Inc./CN=a248.e.akamai.net
https://bing.com: subject=/CN=*.bing.com
https://www.bing.com: subject=/C=US/O=Akamai Technologies, Inc./CN=a248.e.akamai.net
Bing does support SSL on ssl.bing.com and publishes various links on that sub-domain, such as https://ssl.bing.com/webmaster/home/mysites
The fact that the https://www.bing.com redirects to the HTTP version should be enough to show that this a known, unsupported case on the primary domain. The behavior has been like that for years.
Or use HTTPS Everywhere. Personally, I'd also like it if in future, web browsers would try HTTPS first and HTTP second.
I can construct a web server that sends version A of a site over normal HTTP, and version B of that same site over HTTPS.
In fact, sometimes I do that by accident. :)
It's a bad assumption.
Deleted comment
(OK, 10 hits a day is probably an exaggeration but shockingly little of one.)
My browser only talk about the warning, but i only have old chromium... Not auto-updating g chrome
Too Long; Didn't Read
It sounds like internet speek, it's cooler and more 1337.
Interesting article on a related topic: http://www.bbc.co.uk/news/magazine-21956748
Companies! Make sure your certs are all in order! There's no reason to send a page to your users over HTTPS if they can't trust the certificate. Canonical has been a long-time offender of this, with many of their pages sporting a certificate signed to canonical.com but being served by ubuntu.com.
There can be. HTTPS still gives you encryption over the wire. It still protects against a passive eavesdropper, like a casual packet sniffer on a public wi-fi network. The whole certificate deal protects against a Mallory with power to intercept and spoof messages. Of course nobody on the public internet can be sure there isn't a Mallory in or at the edge of the user's ISP, but in plenty of intranet or otherwise controlled networking scenarios, HTTPS with certificates lacking a trust chain can be reasonable.
Training users to click through messages that are completely valid warnings is just shitty behavior.
Untrusted certificate chains is a valid security risk. If it annoys you that users are blocked from viewing your site because you haven't gone through the established and accepted practice of actually completing the SSL trust chain, that's not the local proxy's fault.
My number one concern is the integrity and security of my company's data. Your personal or temporary TLS site is much lower down that list, especially if you're serving up untrusted certificates and expecting that users will completely ignore the warnings that try to keep them from falling victim to the kinds of attacks SSL is meant to avoid.
In the example in question (which frankly isn't very interesting, I can come up with hundreds of scenarios like this) I have a git archive I need to share with someone on an ad-hoc basis. For whatever reason, I'd like to do it securely, so it needs authentication and encryption and shouldn't go on anyone else's site. So the obvious solution is to throw it up on a static webserver somewhere and use TLS (or use ssh, of course, but that's subject to exactly the same root-of-trust problem as a self-signed cert -- surely you disallow outbound ssh access too, right? right?).
Your fantasy world wants to pretend requirements like this don't exist, and that you can simply refuse to support this kind of transfer via fiat. But it's not the real world. In the real world, this is what people have to do. Unless you break their systems, in which case they'll work around your silly rules in even less secure ways.
On a broad basis, though, untrusted certificates are blocked outright. I'm sure you can understand that for every one-to-one or one-to-few valid communications like your case, there are dozens or hundreds of one-to-many not-so-valid communications. SSL has certificate trust built in for a reason. Engineers may laugh at security professionals, but we're here for a reason. Even though we're directly at odds with each other in approach, our goal is the same. You want to help further the business by pushing new software. We want to further the business by making sure that software is secure. No one benefits from the new e-commerce solution if the business bank account is completely drained the day after the product launches.
I can come up with a hundred good reasons why I should be able to enter a store after business hours, pick up a few things, and leave (I left the money on the counter!), but for some reason businesses still lock their doors. Do you laugh at them for having completely backwards requirements?
I can actually take your key analogy into true story territory. I worked at an office where a manager had to be gone for a month. He had the only key and the policy to get a new key wouldn't get one to us for weeks. It was also against policy for him to give the key to someone else while he was gone. The solution was to simply leave all the doors unlocked while he was gone.
I understand the need for security. I understand that security is your job and that you don't want to compromise for mediocre security. However, when you won't compromise, we don't get great security. We get no security.
I agree that strict policies with no recourse for exceptions is a bad thing. I don't know of anyone who would stand up under that kind draconian stance.
Subject: CN=* .bing.com
X509v3 Subject Alternative Name: DNS:ieonline.microsoft.com, DNS:* .bing.com, DNS:* .windowssearch.com
--
Subject: C=US, O=Akamai Technologies, Inc., CN=a248.e.akamai.net
X509v3 Subject Alternative Name: DNS:a248.e.akamai.net, DNS:* .akamaihd.net, DNS:* .akamaihd-staging.net
You then have a scenario where the DNS is waiting to propagate and the SSL is still propagating around the CDN. Hence you get soem users without a problem, some with and it eventually all clears itself up.