Alright, looks like the issue has been resolved. Still working on figuring out how it happened, but at least everything is back up as expected.
- DEAN On Wed, Apr 30, 2014 at 4:00 PM, Pierce, Dean <[email protected]>wrote: > Before responding to this thread I sent out emails to all the sysadmins I > know of who might have more information about this. Hopefully we already > have the good cert somewhere, and all we need to do is deploy it (you can > see that all the other Tizen domains are using post-heartbleed > certificates). I'm also working on getting to the bottom of how this could > have happened, because we had some pretty solid (and conservative) > procedures in place to make sure this wouldn't happen. > > Best case scenario is that we already have this cert lying around, and > just didn't deploy it due to some mix up. If that's the case, the issue > will likely be fixed within a minute or two of when my email gets read. > Worst case (which I doubt), it might be a few days while we get a new cert > issued. > > - DEAN > > > On Wed, Apr 30, 2014 at 3:39 PM, Clark, Joel <[email protected]> wrote: > >> When will this be fixed so that wiki.tizen.org has a good certificate? >> Wiki.tizen.org is critical to our project. >> >> >> >> Regards >> >> Joel >> >> >> >> >> >> *From:* Dev [mailto:[email protected]] *On Behalf Of *Pierce, >> Dean >> *Sent:* Wednesday, April 30, 2014 3:31 PM >> *To:* Rafał Krypa >> *Cc:* [email protected] >> *Subject:* Re: [Dev] wiki.tizen.org https certificate revoked (was Re: >> Cynara + DBUS) >> >> >> >> To clear up some mystery here. We are definitely revoking and re-rolling >> all of our keys as a safety measure due to the recent heartbleed bug. We >> had everything patched within hours of when the fixes were available, but >> we, like the rest of the world are in the process of reissuing, replacing, >> and revoking everything, but I'm surprised that we would have revoked a >> cert before we replaced it. It's a long and manual process, and I'm sure >> StartSSL is being overwhelmed with revocation requests. >> >> >> >> The reason that Chrome etc still works is because they scrapped their >> CRL/OCSP code recently, and moved to a static, and regularly updated list >> of revoked certificates. I'm betting that if we don't put in a new cert >> soon, Chrome will get the revocation in its next update, and it will stop >> working there too. >> >> >> >> >> http://www.computerworld.com/s/article/9224078/Google_Chrome_will_no_longer_check_for_revoked_SSL_certificates_online >> >> >> >> - DEAN >> >> >> >> On Wed, Apr 30, 2014 at 10:39 AM, Rafał Krypa <[email protected]> >> wrote: >> >> On 2014-04-30 19:08, Rafał Krypa wrote: >> > On 2014-04-30 17:11, Schaufler, Casey wrote: >> >> Hmm. I see the same thing from outside the Intel firewall, while >> access from inside Intel works just fine. No, it's not just you. >> > Are you using the same browsers inside and outside the firewall? I can >> see the revocation message in Firefox and MSIE, but Chromium doesn't report >> it. >> > >> > Either way the certificate seems to be revoked by issuer, StartSSL. >> >> I found a dumb way to work around this problem. Mapping crl.startssl.comand >> ocsp.startssl.com to 127.0.0.1 in /etc/hosts works for me. >> >> >> > I have checked it with openssl command line, using both CRL and OCSP: >> > >> > ### Get the wiki.tizen.org server certificate >> > $ openssl s_client -connect wiki.tizen.org:443 -showcerts </dev/null >> 2>/dev/null | grep -m1 BEGIN -A100 | openssl x509 -text >server.pem >> >> By the way, it seems odd that s_client doesn't inform that server >> certificate is revoked. I tried passing "-crl_check -crl_check_all" >> options, but it didn't cause any certificate error. >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> https://lists.tizen.org/listinfo/dev >> >> >> > >
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
