Revoke a authorization-resource


Hey there, Is there a workflow for authorization revocation?

I’m currently facing following problem:
Bob has registered the domain - he also made a Let’s Encrypt-Account, solved the challenge and got a certificate for the domain. His authorization is valid till 01.01.2016, so he can request/reissue as many certificates as he wants for the domain
Now Bob transfers the domain to Alice. Alice buys a new certificate from another CA.

Is it correct that Bob still can reissue new certificates for even if he lost the control over the domain and Alice has no chance to invalidate Bobs authentication resource? - even if Alice would create a Let’s Encrypt-Account and solves the challenges - Bobs authentication wouldn’t be invalidated till it expires?


Let’s not forget that if Bob transfers the domain to Alice then she can install whatever certificate she likes on the web server that will host this domain. Thus, she can remove Bob’s certificate and install her own. It doesn’t matter if Bob still has a technically valid certificate because the one that users will receive will be the one Alice installed. When the domain is transferred to Alice she will configure the domain’s registrar to direct users to the web server she owns through authoritative DNS records.


However, it could be seen as a security risk to users if Bob still has a valid certificate or the ability to produce new ones.

One thing that Alice could do that would work in this case is to publish CAA records asking Let’s Encrypt not to issue any new certs for the domain. Let’s Encrypt should honor CAA and not issue the new certs in this case.


exactly - just imagine Bob is one of the bad guys, if he has a valid HTTPS certificate, he would be able to create a HTTPS-Proxy and starts his Man-in-the-middle attack.

I think at least when someone requests a new authentication and solves the challenges, the old authentication must me invalidated/revoked.


However Bob has to re-authenticate his domain at some point to issue more certs.

More information:


This discussion might fit better in the GitHub issues on the ACME spec, or the IETF mailing list about it, to talk about the scope or duration of authorizations. I don’t think it’s completely off-topic here, but I doubt that people who are involved in making these decisions on the ACME side will be likely to look at this discussion on this forum.