Re: [Acme] case in point of usability

[Stephen Farrell <[e-mail]>]

On 01/04/15 13:38, Ben Laurie wrote:
> On 1 April 2015 at 13:19, Stephen Farrell <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/acme
>>>
>>
>> _______________________________________________
>> Acme mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/acme
> 
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
>