Re: [Acme] case in point of usability

Phillip Hallam-Baker <> Wed, 01 April 2015 13:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 841EC1A9081 for <>; Wed, 1 Apr 2015 06:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uOlaCMXACDlY for <>; Wed, 1 Apr 2015 06:18:31 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1C0B21A9087 for <>; Wed, 1 Apr 2015 06:18:31 -0700 (PDT)
Received: by lbdc10 with SMTP id c10so35785741lbd.2 for <>; Wed, 01 Apr 2015 06:18:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=F+hwPJXXtHJrq8L7m00L8TNvJJs/5dBMRp5PtF4oWrU=; b=Q2wPq+FahCgfRIPCXYUlXztreamAcLEcFj01i3OL5zMQYx7mWDZmErOM5qYwVwmEI3 Em2D5HYs5882uxNXcTlJGhAAvw9MIgwDVXACDTrqMMATJ2r4of9ivUNtKy9oscyR0F8r BBJkXtkdgUFx5Ln21MUXs6bblp4ecelsI1L4reixn/Y/P9jlZI9qY8Jbfc/HUY5Cd3CO Ocb08ApAoJLLbQiSRDQ4P3Lg9LNl33sMT+bfLHUR2Kmh6SmpU2f9e3f0p/LQKz7YugkE 0AUUeS4ZQw4EyHLF6ZKTRYrz7iPs2UginMbu6uQi/C7PAxTb1ThVZOlZWAhppSZvbnXf NYyw==
MIME-Version: 1.0
X-Received: by with SMTP id us4mr9008769lbc.91.1427894309560; Wed, 01 Apr 2015 06:18:29 -0700 (PDT)
Received: by with HTTP; Wed, 1 Apr 2015 06:18:29 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Wed, 1 Apr 2015 09:18:29 -0400
X-Google-Sender-Auth: qVrfD8eWPdBuRLQ68zIf3WPMN-M
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Stephen Farrell <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>, Ben Laurie <>
Subject: Re: [Acme] case in point of usability
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Apr 2015 13:18:32 -0000

On Wed, Apr 1, 2015 at 8:51 AM, Stephen Farrell
<> wrote:
> On 01/04/15 13:38, Ben Laurie wrote:
>> On 1 April 2015 at 13:19, Stephen Farrell <> 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.)

One of the reasons that I do not like unnecessary complication or
variation is that it leads to this sort of situation.

Right now most servers are administered in bespoke fashion and so the
variation in configuration can be quite large. Automating the process
takes the human out of the loop and makes it much easier to get
consistent results.

It is the same problem I have with UNIX admin. Anyone who has ever
tried to administer a machine where the previous sysadmin has spent
their time trying to make Ubuntu look like Solaris and reorganized the
directories accordingly will know what I mean. Every administration
action becomes a hunting expedition. Is the file in the usual place or
was it moved?

Today I am going to have to spend a couple of hours changing a code
generator because someone thought "x5c#256" was a good name for a
structure id. Sure, this is legal JSON but why make unnecessary work?
I now have to implement a hack to serve as a work around. And every
other implementer is also going to have to do a work around. And that
means that all our APIs are going to be a little different when they
should have been the same.