3 ms·
This is the second major flub this year. Azure's cert expired in prod not many weeks ago.
by taylorbuley 14y ago
This is the second major flub this year. Azure's cert expired in prod not many weeks ago.
- timthelion 14y agoActually, 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.
- huhtenberg 14y agoWas 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.
- timthelion 14y agoSome mod... I was quite surprised when I saw it.
- xonea 14y agoWell, it is not really a flub of this year. Or even something specific to Bing (try https://www.nba.com/ https://www.nba.com/ or https://www.jetstar.com/ 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 https://fbcdn-profile-a.akamaihd.net (or similar) -- hence to one of the hostnames that is mentioned in the akamai edge certificates.
- taylorbuley 14y agoAkamai 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.
- QA_Confidential 14y agoAkamai 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.