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

Pierce, Dean dean.e.pierce at intel.com
Wed Apr 30 23:00:12 GMT 2014


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> 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: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
> *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 <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.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
> 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/0bf0a2f4/attachment-0001.html>


More information about the Dev mailing list