Re: [Acme] confirming the certificate renewal in draft-aaron-acme-ari-01

[Aaron Gable <[e-mail]>]

Thanks for the detailed feedback, and apologies for the delayed reply!

I've incorporated a specification for how clients can inform the acme
server that a certificate has been renewed/replaced in the next draft of
this document, and will go over this aspect in the IETF 133 session next
week.

Aaron

On Thu, Nov 18, 2021 at 10:43 AM Michael Richardson <[e-mail]>
wrote:

>
> {Splitting up replies to make threads easier to deal}
>
> Aaron Gable <aaron=[e-mail]> wrote:
>     > 2) Considering inclusion of a "this has been renewed" callback
> endpoint
>
>     > This is tracked as
> https://github.com/aarongable/draft-acme-ari/issues/15
>
>     > One of the motivating use-cases for this protocol extension is the
>     > "business continuity in spite of revocation" case: a CA that is
> about to
>     > revoke a certificate could, the next time that cert's subscriber's
> client
>     > polls the ARI endpoint, inform the client that it should renew right
> away.
>     > Then the client could replace the cert as normal, and the original
> could be
>     > revoked without any disruption to the subscriber.
>
> I manage LE's certificates for a few dozen machines.  Not so many that it's
> worth the overhead of more formal monitoring, but not so few that it's
> easy.
> They machines are very different in OSes and versions and whether they do
> dns-01 or http-01 challenges, and so suffer from various different
> failures.
>
> In about 2 out of 5 cases,  a few weeks after the last renewal, I've
> changed
> something (added a new virtual host, for instance), which results in me
> renewing early.  Alas, LE sends me a notice of expiry based upon the
> original
> certificate expiry, and I make a note to check that it's really renewed,
> not
> remembering which is which.
>
> Long story: this confirmation stuff would be helpful for many situations.
>
>     > Therefore it would be useful for the client to be able to inform the
> server
>     > "Thanks for telling me I should renew this cert; I have no completed
> that
>     > task to my own satisfaction", so that the server can then go ahead
> and
>     > revoke the cert, knowing it will not cause any disruption by doing
> so.
>
>     > One idea to implement this would be for the client to POST to the
> same
>     > resource url as it polls for renewalInfo, with the body being a
> signed JWT
>     > containing a single "renewalComplete=true" as the body. The server
> would
>     > only accept this if the POST were signed by the same account key as
>     > originally ordered the cert.
>
> This seems good.
> When a certificate is re-issues with an expanded (or diminished) set of
> SANs,
> then I hope that we can use this to mark the old certificate as satisfied.
> Should the CA revoke?  I'm not sure if it's worth the CRL space, if CRLs
> are
> being used.
>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>