IMO, if you noticed someone leaked their key then you can disable their account with the ACME API and then try to notify the account owner of the compromise.
I recently did the above. In this particular case the key was leaked years ago and the account was probably unused.
I see that the ACME API also has a keyChange route, so I guess you could keep the account enabled and tell the person that leaked their key to use that. I'd just be worried that they wouldn't do this, and then someone malicious can still come along and issue certificates for domains that were recently verified with the account.
Maybe there's some other option I don't know about? What do you folks think is the right thing to do if you notice someone leaked their ACME account key? 
4 Likes
In my experimenting with this several years back, if you used keyChange to rotate your account key, there was nothing preventing the old key from being used again. You could even then use it as the key for a certificate, since Let's Encrypt isn't aware of it being compromised. There's a check in general that certificate keys don't match account keys, but once the account is using a different key the old key is no longer in their database to get matched with.
There's no clear way to report an account key for being compromised through ACME. The closest one can do through the API (as far as I know) is rotate the account to use a new key, issue a cert (for any name you control) with the cert using the old account key, and then revoke that cert for keyCompromise (signing the request with the compromised key).
One could instead use the compromised account key to change the account to status inactive, but that doesn't flag it publicly as being compromised as far as I can tell.
I think the most-correct way to deal with noticing that someone else's account key has been compromised is to email cert-prob-reports@letsencrypt.org to have them handle it manually, though I may very well be mistaken.
6 Likes
Thanks for looking into that Peter! So it feels to me like deactivating the account is the better thing to do in that case, since it prevents them from creating a new account with this key. It would be nice if there were also something to prevent this key from getting used for certificates in the future, but the risk of that seems quite low in my opinion.
2 Likes
Actually, I think that even for an inactive account, Boulder won't allow a cert to be created for that same key, so that may be good enough within Let's Encrypt's world. There's just nothing stopping them from using the compromised key (for an account or for a cert) with some other CA (or on production for a key on staging or vice versa). Though that may be a similar state of affairs as with compromised cert keys.
You may also be interested in looking at Pwnedkeys, which tries to track compromised keys and what ends up using them.
4 Likes
From what I can tell, a deactivated account isn't added to the blocked keys table. There's a dedicated check to verify that the CSR key isn't the same as the current account key, but I don't see any check against other (deactivated or not) account keys.
It's possible I missed something though. I'm not really familiar with Go/Boulder.
2 Likes
The easiest (well, second easiest after "nothing") thing to do is to use the key to deactivate their account.
The most secure thing to do is exactly what Peter said: deactivate their account, then issue a cert using that same key, then revoke that cert using the key to sign the revocation request.
We have ideas about how to make this admittedly bad process better, but we have to be careful that we don't let someone just generate a hundred million keys and then submit them all as compromised.
6 Likes