It looks like they self-issued new certs after patching their servers: A radical move, if that's the case, but it's probably justified given the scope of the bug.
Edit: Looking closer at the invalid cert, it appears to be a host name conflict, not a self-issued cert. This is probably a result of the rush to re-issue.
However, BEWARE! Invalid certs are nearly always suspicious!
Patching OpenSSL is only the first step. In theory having operated the servers with an unpatched OpenSSL for some period of time means that your private keys could have been compromised, so to be safe you have to replace your keys and certificates. This appears to be some consequent misconfiguration with the certificates.
I don't think this is the bug per se, but it may very well be due to their reaction to the bug. The safe response for secure systems is to reissue certs after patching impacted OpenSSL instances. It looks like they instead have switched over to a previously-issued wildcard cert for *.stackexchange.com. The cert is valid, but it's for the wrong domain.
This is more likely the result of a sysadmin screwing up the response and not bothering to check the work. Maybe s/he should post on stackexchange for some help :D
We are actually waiting on a re-issue of a combined wildcard at the moment, but as DNS propagates you'll be served a previous, still valid cert in the interim.
We hope to get the final cert deployed within the hour...as soon as we have it in hand. Our other certs are queued up and ready to do on a secondary load balancer.
CAs are understandably a bit busier than normal today.
> This is more likely the result of a sysadmin screwing up the response and not bothering to check the work.
As an experienced operations/admin individual, I'd ask for a little courtesy for them. Screwing up the response? Possible. But in some cases, our options are few, and the one that provides the least breakage is what we roll with. Sometimes, there aren't any other options.
TL;DR Sometimes, we have to break shit to make it work, but its less broken than before.
Maybe the cert was different before this moment, but yeah, the CN is *.stackexchange.com, but it has suitable Subject Alternative Names for the other domains.
Our load balancer is HAProxy which also does SSL termination, so IIS is not involved with SSL certificates or termination in our setup. Also, the vulnerability was specific to OpenSSL.
We have now deployed new keys and certificates across our network after patching the vulnerability immediately this morning. Forward secrecy was used previously and still is, drastically limiting the surface area/usability of the attack in our case.
16 comments
[ 4.3 ms ] story [ 24.1 ms ] threadEdit: Looking closer at the invalid cert, it appears to be a host name conflict, not a self-issued cert. This is probably a result of the rush to re-issue.
However, BEWARE! Invalid certs are nearly always suspicious!
This is more likely the result of a sysadmin screwing up the response and not bothering to check the work. Maybe s/he should post on stackexchange for some help :D
[1] https://serverfault.com/
We hope to get the final cert deployed within the hour...as soon as we have it in hand. Our other certs are queued up and ready to do on a secondary load balancer.
CAs are understandably a bit busier than normal today.
As an experienced operations/admin individual, I'd ask for a little courtesy for them. Screwing up the response? Possible. But in some cases, our options are few, and the one that provides the least breakage is what we roll with. Sometimes, there aren't any other options.
TL;DR Sometimes, we have to break shit to make it work, but its less broken than before.
You can view stackoverflow.com's current public SSL test here: https://www.ssllabs.com/ssltest/analyze.html?d=stackoverflow...
Nick Craver Stack Exchange Systems Administrator