Re: [Acme] case in point of usability

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 01 April 2015 12:19 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 2661B1A87C8 for <acme@ietfa.amsl.com>; Wed, 1 Apr 2015 05:19:22 -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 iIbIt588VNCH for <acme@ietfa.amsl.com>; Wed, 1 Apr 2015 05:19:19 -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 7D8731A02BE for <acme@ietf.org>; Wed, 1 Apr 2015 05:19:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9CC35BEB2 for <acme@ietf.org>; Wed, 1 Apr 2015 13:19:17 +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 gJe31UNmZaFp for <acme@ietf.org>; Wed, 1 Apr 2015 13:19:17 +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 7DAFABEB0 for <acme@ietf.org>; Wed, 1 Apr 2015 13:19:17 +0100 (IST)
Message-ID: <551BE246.1040603@cs.tcd.ie>
Date: Wed, 01 Apr 2015 13:19:18 +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: "acme@ietf.org" <acme@ietf.org>
References: <551AB92F.6080004@cs.tcd.ie>
In-Reply-To: <551AB92F.6080004@cs.tcd.ie>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/lWl9rHvnpUVBcQHY4GaqtMVUEkU>
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:19:22 -0000

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;-)

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
>