Re: [Acme] case in point of usability

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 01 April 2015 12:51 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0291A8ADD for <acme@ietfa.amsl.com>; Wed, 1 Apr 2015 05:51:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5YMYSqFyPoP for <acme@ietfa.amsl.com>; Wed, 1 Apr 2015 05:51:05 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2F471A8ACD for <acme@ietf.org>; Wed, 1 Apr 2015 05:51:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 69665BE3F; Wed, 1 Apr 2015 13:51:03 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aK3SgrHu-f3X; Wed, 1 Apr 2015 13:51:03 +0100 (IST)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 46131BE38; Wed, 1 Apr 2015 13:51:03 +0100 (IST)
Message-ID: <551BE9B8.1010503@cs.tcd.ie>
Date: Wed, 01 Apr 2015 13:51:04 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Ben Laurie <benl@google.com>
References: <551AB92F.6080004@cs.tcd.ie> <551BE246.1040603@cs.tcd.ie> <CABrd9SSnVD16USto=wP0EuXma+QcO2cH8AAbGZUymc1VhpC8hQ@mail.gmail.com>
In-Reply-To: <CABrd9SSnVD16USto=wP0EuXma+QcO2cH8AAbGZUymc1VhpC8hQ@mail.gmail.com>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/uP3hnmBLHtbnt5dg-MxSpQZXxsk>
Cc: "acme@ietf.org" <acme@ietf.org>
Subject: Re: [Acme] case in point of usability
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2015 12:51:08 -0000


On 01/04/15 13:38, Ben Laurie wrote:
> On 1 April 2015 at 13:19, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>>
>> And in a happy ending for this thread, when I whacked in
>> the new cert today it all worked.
>>
>> Interestingly, there was a point where it was fine in all
>> but one browser - that lasted an hour or so before they
>> were all ok, not quite sure why, but there's clearly more
>> going on with ocsp caching than I know about;-)
> 
> Are you sure it wasn't the intermediate problem you were originally
> investigating?

I am sure in the sense of "I did what the forum post said and
it worked," yes:-) [1]

And while the CA has produced a new chain, the old intermediates
chain works fine and is what's in place now and working with all
browsers. I did check the new chain differs from the old one, but
I didn't bother checking exactly how, other than the dates. So I
guess it really was OCSP.

But from the acme POV, it doesn't really matter what was going on
in the OCSP infrastructure - the point was that the renewal process
didn't take that into account at all, leading to user-visible errors.
Bleh. And something where we can do better with acme now we (well,
some of we), know how OSCP caching happens in CDNs and all that.
(Or, as Rob said, we could go all stapled with acme maybe.)

S.

[1] https://forum.startcom.org/viewtopic.php?f=15&t=2654
> 
>>
>> S.
>>
>>
>> On 31/03/15 16:11, Stephen Farrell wrote:
>>>
>>> So today I was updating a web server cert as I do a few
>>> times a year. And I have a usability story to tell...
>>>
>>> I got the new cert and installed it in apache without any
>>> Cullen-like problems:-) That cost me €0.00 in payment and
>>> about 5-10 minutes. All good so far.
>>>
>>> Chrome was happy, but FF/opera/my phone weren't.
>>>
>>> I then messed about for 30 minutes checking to see if
>>> a new intermediate cert was needed etc. (i.e. I was back
>>> to Cullen-mode:-)
>>>
>>> Turns out after a bit of searching, I'd installed the new
>>> cert too soon, and when I tested it, a "dunno" OCSP
>>> response was sent before the responder had seen the new
>>> cert and that OCSP response has now been cached for some
>>> unknowable (to me) number of hours in who-knows-what
>>> places. And that caching behaviour has changed since the
>>> last time I got a cert from the same provider a few months
>>> ago. So I reverted my apache to the old cert and will
>>> try install the new cert again tomorrow.
>>>
>>> That's exactly that kind of thing I'd love to see fixed
>>> with acme and that is not handled by CMP, CMC, PKCS#10,
>>> EST or SCEP. At least I don't believe there's a standard
>>> way of getting the right thing to happen with those
>>> without some proprietary extension/surroundings.
>>>
>>> And one big reason CMP etc don't support that is that we
>>> didn't have that requirement when we had the big fight
>>> that lead to CRMF back nearly 20 years ago. (Since OCSP
>>> didn't exist then and we didn't know how folks would be
>>> updating web servers, and we're much more intolerant of
>>> Cullen-like messing about being needed these days, and
>>> rightly so.)
>>>
>>> I would like acme defined so that when I get the cert
>>> back all the PKI stuff has happened already and is
>>> working. I'm sure some other semantics could also work
>>> out, (e.g. if acme had a "ready-yet?" query I could
>>> emit after getting the cert), but those are the kind
>>> of problems we're currently facing that are killers and
>>> that we can address, now that we know the deployment
>>> requirements much better than we did in 1996.
>>>
>>> I hope this helps those who are worried that acme is
>>> only about business models. In my head what acme ought
>>> be about is getting rid of that 1 hour of silly sysadmin
>>> time I just spent - the system-automated web server s/w
>>> update should just have done all of this for me without
>>> me even having to know a new cert was needed until I
>>> get the system update email tomorrow.
>>>
>>> Cheers,
>>> S.
>>>
>>> PS: Apologies, Cullen but it's your own fault:-)
>>>
>>> _______________________________________________
>>> Acme mailing list
>>> Acme@ietf.org
>>> https://www.ietf.org/mailman/listinfo/acme
>>>
>>
>> _______________________________________________
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
> 
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>