[Dev] wiki.tizen.org https certificate revoked (was Re: Cynara + DBUS)

Clark, Joel joel.clark at intel.com
Wed Apr 30 23:45:35 GMT 2014


Thanks very much

From: Pierce, Dean [mailto:dean.e.pierce at intel.com]
Sent: Wednesday, April 30, 2014 4:43 PM
To: Clark, Joel
Cc: Rafal Krypa; application-dev at lists.tizen.org
Subject: Re: [Dev] wiki.tizen.org https certificate revoked (was Re: Cynara + DBUS)

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 <dean.e.pierce at intel.com<mailto:dean.e.pierce at intel.com>> 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 <joel.clark at intel.com<mailto:joel.clark at intel.com>> wrote:
When will this be fixed so that wiki.tizen.org<http://wiki.tizen.org> has a good certificate?  Wiki.tizen.org<http://Wiki.tizen.org> is critical to our project.

Regards
Joel


From: Dev [mailto:dev-bounces at lists.tizen.org<mailto:dev-bounces at lists.tizen.org>] On Behalf Of Pierce, Dean
Sent: Wednesday, April 30, 2014 3:31 PM
To: Rafał Krypa
Cc: application-dev at lists.tizen.org<mailto:application-dev at lists.tizen.org>
Subject: Re: [Dev] wiki.tizen.org<http://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 <r.krypa at samsung.com<mailto:r.krypa at samsung.com>> 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.com<http://crl.startssl.com> and ocsp.startssl.com<http://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<http://wiki.tizen.org> server certificate
> $ openssl s_client -connect wiki.tizen.org:443<http://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
Dev at lists.tizen.org<mailto:Dev at lists.tizen.org>
https://lists.tizen.org/listinfo/dev



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tizen.org/pipermail/dev/attachments/20140430/e256ecbc/attachment-0001.html>


More information about the Dev mailing list