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 <mcr+i...@sandelman.ca>
wrote:
>
> {Splitting up replies to make threads easier to deal}
>
> Aaron Gable <aaron=40letsencrypt....@dmarc.ietf.org> 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 <mcr+i...@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
