Bing doesn't support SSL | Hacker News Reader

Bing doesn't support SSL

bing.com

287 pointsrljy160 comments

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

TL;DR: Bing doesn't support SSL on www.bing.com and has never publicized it as a supported feature. The submitter had to manually type https://www.bing.com into the address bar to generate this 'error'.

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.

>TL;DR: Bing doesn't support SSL on www.bing.com and has never publicized it as a supported feature. The submitter had to manually type https://www.bing.com into the address bar to generate this 'error'.

Or use HTTPS Everywhere. Personally, I'd also like it if in future, web browsers would try HTTPS first and HTTP second.

I don't think browsers should assume that http://blahblah and https://blahblah refer to the same resource.

Why not?

Because it's up to the individual website administrator to ensure he published them both the same way.

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

http://en.wikipedia.org/wiki/Server_Name_Indication#Support

The bing.com certificate says it is valid for the following names: ieonline.microsoft.com , .bing.com , .windowssearch.com. So why does https://www.bing.com not match *.bing.com?

Because www.bing.com is served by akamai CDN which is different to bing.com. Therefore the SSL on the site is different.

Why don't they just support the thing that is most reasonably expected and not surprise n00bs like me.

Because it would change a massive amount of infrastructure and get about 10 hits a day.

(OK, 10 hits a day is probably an exaggeration but shockingly little of one.)

Wow, that's the first time I've ever seen a 0-word article get the TL;DR treatment.

Actually the warning message from chrome is pretty lengthy

At first I thought it was a joke from Google. Something like: "No you don't want to use bing, here is google."

...what kind of massage you received?

My browser only talk about the warning, but i only have old chromium... Not auto-updating g chrome

All people giving downvotes to this comment, I think you are being unfair to this person who just seems to have a bad English. He probably meant "message".

The medium is the massage. https://en.wikipedia.org/wiki/The_Medium_Is_The_Massage

was typed on swype :) didn't notice the typo

lol

This is the latest message: http://i.imgur.com/ogDhMQp.png

back to safety takes me to about:blank Does it take you to https://www.google.com/ ?

TL;DR means "here's a very short explanation".

Who else remembers when it used to be an insult? I preferred it that way.

Yeah. I remember TL;DR meant wall of text, kinda same way RTFM was used. It was a response to something not a tag to indicate what you were doing. How things change so fast on the Internet.

The new meaning is a lot more useful (in the sense that I find lots of opportunities to use it).

Agreed, I still have insults a plenty in my quiver.

TL;DR: You prefer the old way of doing things.

Funny, I thought it meant...

Too Long; Didn't Read

I thought it stood for "too long; don't read"

Why not use the word "summary"?

I think it's the same reason people write "lol" instead of "hahaha" even though they are not actually laughing out loud.

It sounds like internet speek, it's cooler and more 1337.

To be fair, this is the way language has always evolved.

Interesting article on a related topic: http://www.bbc.co.uk/news/magazine-21956748

"Executive summary" is the original TL;DR.

Working in information security, I see this far, far too often in support tickets from employees who are unable to get to a site because our proxy is blocking misconfigured certificates. Usually we like to reach out to the owner of the site and have them update their configuration, and it gets quite frustrating when we find an unresponsive organization. Having to bypass cert checking for a site on our end is a huge security risk, and defeats the purpose of even having an SSL cert.

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's no reason to send a page to your users over HTTPS if they can't trust the certificate.

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.

Valid points, but in effect what you're doing is training users to believe that HTTPS means trusted. What happens if your site is compromised? The users will see the same untrusted SSL warning that they're seeing if your certs aren't in order. You're giving them security for your site, but removing their security awareness. This hurts them, this hurts the Internet, and this could come back to hurt you.

Training users to click through messages that are completely valid warnings is just shitty behavior.

Right. MitM attacks and variants are a proper subset of the mischief that can be achieved with an unsecured connection. Among other things, it's routine that people (hi!) use self-signed certs for personal or temporary TLS sites. I'd be very annoyed to pass a basic-auth-protected https git url to someone for quick-and-mostly-secure read-only access and have their access be denied by a local proxy...

>I'd be very annoyed to... have their access be denied by a local proxy

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.

Arrgh. Sorry, but this is an absolutely classic example of why "security professionals" get laughed at by engineers. This requirements analysis is just completely backwards.

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.

To answer your question, yes outbound and inbound SSH is blocked except through our secure gateways. Every security organization at every company will have procedures in place for bypassing the official policy on an ad-hoc basis. There's always going to be a one-off situation that requires a different set of rules on a limited time basis, and there are many ways of dealing with these exceptions.

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?

It's true that there's always a procedure in place for bypassing the official policy as needed. However, it often comes down to a question of whether its faster to follow this procedure or to simply undermine the security. I've repeatedly seen people solve the problem of handling unsigned certificates by simply moving back to pure HTTP. This is a great security hole than the unsigned certs ever were, but it's perfectly valid with their security policy.

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.

Completely understood. I can't speak for other companies, but mine has a very strict policy and also many ways to accommodate exceptions to this policy provided the employee has a valid reason for needing an exception.

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.

Every time a lazy and narrow-minded admin causes a browser user to click through a certificate error to access a site, God kills a RAID array.

Don't forget the X09v3 alternate subject names.

https://bing.com/

Subject: CN=* .bing.com

X509v3 Subject Alternative Name: DNS:ieonline.microsoft.com, DNS:* .bing.com, DNS:* .windowssearch.com

https://www.bing.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

We were experiencing a similar issue with a third party analytics solution where their SSL cert all of the sudden started to be delivered by Akamai as opposed to the FQDN of the company, as it was before. I am curious if Akamai is at fault here?

Was this in the past week? Because just a few days ago I was experiencing a similar problem. I attempted to access https://rememberthemilk.com and chrome complained about the SSL cert, as I was receiving the cert for their CDN and not for rememberthemilk itself. I couldn't find anyone that could reproduce the issue, but it occurred consistently on my computer regardless of browser. It resolved itself 20 min after I first noticed it, but I'm still really curious as to why it happened in the first place.

Usually the CDN will have a single certificate which then has multiple SAN entries. What can happen depending on the size of the CDN is it can take a long time for the SSL to be added to the SAN entries on all the edge servers. So if a site just starts moving to a CDN they sometimes jump the gun and instead of waiting for all the edge servers to have the SSL they just change DNS records.

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.

Yeah - happened on Tuesday and was cleared up the following morning.

This is Akamai kinda trying to serve HTTPS on domains that don't have HTTPS setup. I'm not sure why they attempt it at all, but it's not really their fault. Same thing on my domain: https://www.theblaze.com/

I made a site that checked for SSL cert expirations and misconfigurations, but I couldn't acquire any customers. I still think there's a business there somewhere, although maybe it really only sells as part of another product.

Edit: If anyone wants a script to check their certificates, here you go: https://gist.github.com/bretwalker/5420652. You'll just need to add in some sort of notification logic, especially for expirations, since they need to happen before a problem arises.

Sounds like something you could license to companies to use as a lead generation tool - like HubSpot's Marketing Grader http://marketing.grader.com/

That's a very interesting idea, Simon, and one that didn't even cross my mind.

I've since moved on to a new project. If anyone wants to talk about taking over the site, shoot me a message at bretwalker /at/ Google's email. It's Django and has some branding and a domain: http://static.nyquistrate.com.s3.amazonaws.com/media/certcia...

Stackify created this exact thing after the last time this happened with MS Azure about 2 months ago. It's called certalert.me (http://certalert.me) and is a free service.

It's not a huge business, but it was almost trivial to setup with all the advanced monitoring & diagnostics that stackify typically does anyway.

Very useful. It's not a super hard problem to solve, but I did think it provided enough value that companies would be willing to pay for it. SSL is used on the most important pieces of a business' infrastructure, I thought it'd be a simple sell.

I also can't tell if certalert.me checks for hostname mismatches. That was another part of my service, because a misconfiguration is just as fatal as an expired certificate.

Out of curiosity.. how much money were you trying to charge for the service?

I think $5 for 5 sites, $10 for 15 and $20 for 50.

The sad thing is that SCOM can monitor for pending certificate expiration and validity. If Microsoft dogfooded a little more, they might have seen this.

Venafi[1] has made a pretty good business out of cert management.

1. http://www.venafi.com/solutions/ssl-certificate-management/

I usually put a check for "SSL certificate expires in less than 30 days" in the NMS. There is certainly a market for network monitoring as a service and this is a useful check to have in one.

Here's a free service that makes auto-updating iCal calendars from SSL and domain expirations: http://domainical.org/

I love this one:

http://www.whynopadlock.com/

Which protocols do you support besides https? imap or pop with tls perhaps?

Yes, IMAP and POP were supported: https://gist.github.com/bretwalker/5420652

Bing is important. It's a good search engine, comparable to Google's quality and size. And it's the only competition Google has in the US and most of Europe. (Sites like DuckDuckGo and Yahoo pass queries on to Bing). Dumb errors like this SSL problem are embarassing, but the larger frustration is how despite years of having a good product, they have so little market traction.

I have noticed that Bing is actually getting better. However, I still prefer Google for most things. Google "assumes" what you are looking for, this can be good or bad depending on what you are searching. Bing on the other hand is like the early version of Google, literal search with minimum assumption. I am glad it is there as a fallback from Google. If the Google servers go down or if they pull some crap like ban Google search from windows phone, Bing is a decent alternative.

One thing I really appreciate from Bing is catching upto Google maps. Throughout the whole Google Maps and Windows phone fiasco, I din't miss GMaps a bit, between Nokia Maps[1] and Bing Maps [2], there isn't much I missing out from not using Google maps. Infact, I would to love Google to catch up to Nokia by offering offline maps.

Another mention is their Bing Flight [3] search, similar to kayak minus their cookie/OS price manipulations. It also comes with an awesome price prediction.

Overall, Bing has some great products but if they really want to compete with Google Search, they really need to improve their algo.

[1] http://here.com [2] http://maps.bing.com [3] http://flights.bing.com

I think Google has like 90% market share in Europe, and most of the rest is taken by Yandex/Yahoo. Bing has a very tiny market share worldwide (like 2%-4%).

I didn't know that DuckDuckGo and Yahoo pass their queries onto Bing. Does anyone else have any information on that, it sounds really interesting.

If I recall correctly, DDG used to solely depend on Bing's Search API but now they use various sources including their own to compile the search result.

The problem is that whilst being 'close' to as good as Google is a real achievement, they miss by far enough that it actually matters to most people.

Sure they might be godo enough that if they are a default, lots of people won't worry about changing, but not being as good as Google means there isn't much impetus for Google users to switch.

Yep, they don't offer any huge incentive to switch. Google has a much more robust search and as an android user I actually like the integration into Now.

I think it's as simple as having chosen an awful name. Bing is physically difficult to pronounce and it evokes no meaning whatsoever.

Do you really the pronunciation difficulty and lack of meaning is so significantly different than "Google" was when it launched? It's more vocalized, yes, but only a single syllable for Google's two, and relatively noone actually think of "googolplex" when talking about Google. The sound "bing", I think, conveys speediness, which they took advantage of with the slogan "Bing and decide". It's a quick, sharp sound - as should be your searches.

You have to move your mouth into a strange position to say the word's single syllable. And it's an opinion, as common as it may be, that Bing is an awful name for a search engine.

When I first heard of the search engine google, I was immediately reminded of those childhood conversations about a number with 100 zeros following it. So yes, instant evocation. And maybe this would only happen with geeks, but that's exactly who they needed to convince to use their search engine.

Microsoft seems to have decided to ignore geeks and just markets directly to 'average users'. This to me seems like a very poor strategy. No smart people telling you to use Bing or Windows 8 and guess what...

Its so impressing how Bing manages to deliver search results as well curated as those from Google. But wait, I just remembered that is because of they rely on search results from Google. ;P

http://googleblog.blogspot.de/2011/02/microsofts-bing-uses-g...

If you want to learn more about that event than just a ":P", Danny Sullivan's analysis at the time was excellent: http://searchengineland.com/bing-why-googles-wrong-in-its-ac...

Neither does Hulu. https://hulu.com/ Amazon redirects to HTTP: https://www.amazon.com/ Netflix redirects to HTTP: https://netflix.com/ Etc... Etc... Etc... Why pick on Bing?

I understand Hulu and Netflix but I have a hard time understanding why Amazon wouldn't support SSL. It does put a heavier processing load on web servers but you would think that if someone wants to encrypt their shopping traffic Amazon would be open to accommodating that.

It is not, by any means, trivial to find out what products someone is looking to buy and could be the basis of a social engineering hack.

I wished if Youtube videos were allowed under https. Currently, it just redirects to an error. If it didn't, this will put an end to ISPs throttling the Youtube streaming.

The real question is, why were you on bing? :P

Bing's birds-eye view maps are great. Google is trying to add the same isometric views but their coverage isn't nearly as good.

I couldn't find something on google, so I decided to give it a try. Can't hurt. I wanted to find out if anyone has done a study on language confusion(the effect where Russians have a hard time getting good at Polish because they confuse Polish words with Russian ones). Still can't find it ;)

Try asking on http://www.reddit.com/r/linguistics/ -- those guys are pretty sharp about this kind of thing. (Assuming that reddit isn't down due to DOS attack.)

Try googling / binging "L1 interference".

Thanks!

I know about funny word differences, but we have no problems learning russian, why russians would have problems learning polish?

this is my favorite http://translate.google.com/#ru/pl/%D0%BA%D0%BE%D0%B2%D0%B5%... (in polish it sounds like 'caviar in a can')

Well, I know neither Polish nor Russian, but here in Prague I know a lot of Russians that never learn to say the word dobrý. They say dobry(short y) instead, which exists in Russian. They never learn to say it long, even when you point it out to them.

oh, I get it.

we also share a lot of funny misunderstandings with czech. čerstvý chléb is zatuchlý chléb in polish, imagine being there for the first time and seeing grocery stores advertising old bread :D

Don't want google to know everything that I'm doing. Especially when searching for porn.

You can use chrome's incognito mode.

That is not the function of Incognito mode. Use it only if you care about leaving traces of yourself in your local history.

comment of the day!

To Microsoft : Please fix your IE debacle ( somehow!!).. Its affecting your other products.. Its reputation is becoming infectious.

What IE debacle? Trident is now widely considered to have the most correct HTML5 implementation in a major browser. It might not have all of the draft stuff that Webkit has, but it also doesn't require all of the webkit css hacks.

Well, it can certainly do a lot better ... check out caniuse.com for more details.

I think you missed missed point. Many of the features listed there are draft spec. Rapid adoption of early draft specs are what caused the current Webkit mess.

IE 10 doesn't have the most features available, I never said it did. What I did say that that the features that are present are more correctly implemented than other browsers.

Do you mean Windows 8 debacle ? AFAIK, IE10 is a good browser and IE9 is not so bad.

Well, we are finally getting rid of IE6 and IE7. There is still a problem with IE8 market share but the upgrade inertia is nowhere as bad as IE6.

Microsoft is definitively cleaning its tab.

Looks like someone pushed the wrong SSL cert to production:

  www.bing.com uses an invalid security certificate.
  
  The certificate is only valid for the following names:
    a248.e.akamai.net , *.akamaihd.net , *.akamaihd-staging.net  

  (Error code: ssl_error_bad_cert_domain)

Australian Ebay (https://www.ebay.com.au/) has had the same problem for months, although I appear to get no response for https://www.ebay.com, so I'm not sure what their policy is on SSL access to the homepage.

I expect that Microsoft will fix Bing much more quickly.

Passed this on to relevant team to look into for you (I'm with PayPal myself, so not sure about eBay's SSL approach).

Mandrill has also had this problem for months (I notified them, but still broken) https://www.mandrill.com/

It's been this way since 2009... http://revealingerrors.com/akamai_ssl

http://revealingerrors.com/akamai_ssl

The post does not explain why Akamai's cert is being used. If bing over SSL were working correctly in the past---which I believe to be true---and given that Bing were using Akamai in the past, why the problem now?

Bing doesn't do SSL and never has at that domain (they previously used ssl.bing.com). you're seeing an Akamai cert because Akamai servers are hosting bing.com.

nope, bing did not work correctly in the past. A few web searches reveal that it has been like that since at least 2011.

Wow. This has been going on for an hour now. It's such a simple fix, especially since one would assume that they already have a valid cert somewhere (or that Akamai does). Yet they've had an hour of SSL downtime.

Does anyone know if Bing has any SSL-only clients? Like do any of their toolbars or built-in search widgets in Windows use SSL by default?

Easy fix? What the hell?

I don't like or use Bing services but when you get as big and complex as Bing, nothing is easy, it's not like you can open your text editor, modify one line, commit and push.

There so many other variables to take into consideration, by hurrying to fix, you could face all sort of vulnerabilities / other issues.

I'm not saying this error is acceptable, I'm saying it's ridiculous to say it's and easy fix without actually knowing anything, it might or it might now.

This is not new and probably will not be fixed fast - the situation has been like that (unchanged) since at least 2011.

I think it's always been like this. Bing has never run over https as far as I can tell.

According to MS guys this is not an error, SSL is supported at https://ssl.bing.com/ which is what their tools use.

See https://news.ycombinator.com/item?id=5576342

I've gotten a certificate error for over a year with Bing on HTTPS. I always just assumed that they, somewhat surprisingly, just didn't support HTTPS yet.

Slightly off-topic: what's a good way to handle cases such as this where you have a wildcard certificate?

I'll be getting a wildcard certificate for a project and, never having used one before, I had assumed the certificate would be valid for an entire domain.

I understand from this situation that a wildcard certificate is relevant only to https://*.example.com and not the subdomainless https://example.com.

Assuming that to be the case, is having a wildcard certificate for *.example.com and a second certificate for example.com the solution? It'd be nice to have the entire domain covered by a wildcard certificate and not just all subdomains.

Typically a certificate issuer will grant you both when you buy a wildcard one.

This can be achieved via SAN (alternative names): http://en.wikipedia.org/wiki/Wildcard_certificate#Limitation

Comodo's been good to me in this regard.

Incidentally, beware of RapidSSL and their "free www." SAN; they only grant it in certain specific and undocumented circumstances.

With RapidSSL if you order a cert for www.domain.com then it will also cover domain.com. But if you order a cert for domain.com or sub.domain.com then it will NOT secure the www.domain.com.

So basically make sure your CSR request is for www.domain.com if you want to also secure the root domain.

Bizarrely, this only works for second-level domains however, and isn't disclosed in advance.

Really, CAs shouldn't be throwing in "free bonus" SANs without customer authorization ever. It would be much better to have a place to enter the SANs, or a checkbox asking if I want "www." as well, or to apply to the parent also, or whatever. That would also make the process more apparent to the user in addition to being more secure.

Not all that off-topic. For your example, you should get a certificate made out to ("Subject CN") example.com or * .example.com, then list both the wildcard and the subdomainless entry as Subject Alternative Names.

Bing is doing something similar (see https://news.ycombinator.com/item?id=5576271), but they appear to have forgotten to list the plain domain.

Depends on the type of cert. There're EV SSL certificates that do not allow wildcards, for example.

It's not just Bing. I'm always accidentally going to http://stackoverflow.com & getting an error.

Shh, only MS bashing can go on in this thread

SO uses a MS stack so it's not too far off...

I don't understand - that's never resulted in an error for me.

Maybe he meant https://stackoverflow.com/ ?

Wow, that's just terrible.

Why should we take Microsoft's Internet efforts seriously when they continue, perpetually, not to do so, themselves?

(Actions speak louder than words.)

Bing is normally not served over https, so this probably only affects a tiny percentage of the users, even though it looks bad here.

This is the second major flub this year. Azure's cert expired in prod not many weeks ago.

Well, it is not really a flub of this year. Or even something specific to Bing (try https://www.nba.com/ or https://www.jetstar.com/)

Basically Akamai is using the same ssl certifate on (most?) of its edge servers. The reason for that is that traditionally it is difficult to decide for a server that is serving multiple domains, which SSL certificate to show for a client -- the HTTP header, which contains the hostname is sent way after the certificate information has been exchanged.

A certificate can contain several hostnames (in the SubjectAlternativeName extension) - but that does not scale if you have a big number of sites for a number of reasons (re-signing the certificate all the time is a nuisance, browser behavior with certificates containing several thousand hostnames is kind of fun, etc.).

Nowadays there are solutions to that problem (using the Server Name Indication TLS extension -- which basically sends the desired hostname in the TLS exchange before the certificate is exchanged). However, the number of sites actively using SNI is very low - google is the only site known to me that is doing it (try accessing google.com with/without SNI and you will get completely different certificates).

The reason why SNI is not yet that much used is that client support is still a bit flaky. Afaik it is supported by all recent desktop browsers. However, I think the XP TLS stack does not support it (and there are still enough users on that), android only supports it starting with version 3.0, etc.

So - at the moment you basically still need a separate IP for each site (or at least one IP for sites that can share one certificate).

I don't know if akamai also supports custom SSL certificates. Facebook seems to use kind of an interesting mix between akamai and self-hosting - facebook.com itself seems to be hosted by facebook. However, if you use facebook over ssl and check the url of served profile pictures, you will see that they go to https://fbcdn-profile-a.akamaihd.net (or similar) -- hence to one of the hostnames that is mentioned in the akamai edge certificates.

Akamai isn't using the same certificate on its edge servers, unless you mean the same customer certificate being replicated (in which case you are correct). Basically, Akamai maps each ssl certificate to a slot on the cache server, which is assigned to a map similar to the standard edge CDN. Each edge machine thinks itself the site. Each time a new certificate is issued by an Akamai partner CA or the customer's CA of choice, it is pushed out by Akamai to the ssl edge network.

SAN certs are an entirely different ball of wax. Akamai does support them, but there are some challenges getting them deployed.

Unfortunately, the deployment for any type of certificate with Akamai is a very manual process.

Akamai definitely supports custom SSL certs. You provide them a chain cert and they pass it on your behalf.

To me, this looks like they pushed the wrong cert to prod.

Actually, it's been like this a really long time. I just noticed, that HN stories which have nondescript titles fare better, so I decided to conduct a little experiment. 1st spot on the front page seems to confirm my hypothesis.

Was it you who changed the submission title or was it some mod acting up yet again? The original was interesting and it wasn't factually inaccurate.

Some mod... I was quite surprised when I saw it.

bing.com doesn't do SSL, never did except at ssl.bing.com (which doesn't actually do SSL anymore).

Looks like it might be related to the reddit DDOS: http://www.reddit.com/r/redditTraffic/comments/1coaer/201304...

No.

How?

Google should start a "don't get Bingle Berried" campaign like Microsoft's Scroogled.

Don't get Fucked in the ass by Microsoft

No, not that. This => http://www.urbandictionary.com/define.php?term=dingle+berry

The real question is, is bing.com even supposed to be served over https?

With very few exceptions, everything is supposed to be served over HTTPS (or other secure protocols). Certainly something as sensitive as search traffic. Tell me your search queries and I'll tell you your interests, health problems, relationships, if you're happy in your job and what kind of porn you like.

That last one is where they get ya

why wouldn't you want to serve it over SSL?

This just means that there is no redirect on www.bing.com via SSL. Bing.com (ssl) has a proper re-direct to non-ssl www.bing.com.
Most-likely an oversight, but it does suggest ssl isn't supported.

Short Microsoft.
25000 more employees can't fix this kind of incompetence.

There's gotta be some kind of organizational size:responsiveness inverse metric for stuff like this

This is pretty embarrassing after their Azure SSL certification expirations issues just a month or so ago.

For what it's worth I alawys had problems reaching bing.com when using openDNS.

The extra cert dialogue box will really drive up traffic. #not

People use bing?

why would you use bing?

HA!

back up as of 8:42 CST

I'm still seeing it 9:50 EST

I sincerely hope that this not some sick and twisted joke by Microsoft.

I think you're in the clear.

Reply on news.ycombinator.com