{Splitting up replies to make threads easier to deal}
Aaron Gable <[email protected]> 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 <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
