Compromised Key Questions

[jvanasco]

Going through the RFC and posts here, I just want to be sure of a few things:

• reporting a compromised Account Key or Private Key can not be automated via endpoints, it only happens via email
• there isn’t a standard error message from the ACME server if either items are compromised

[mnordhoff]

You can revoke a certificate via the ACME API if you have the private key and the certificate. If you specify the reason as keyCompromise, Let’s Encrypt will add the key to the compromised key blocklist.

Revoking certificates - Let's Encrypt - Free SSL/TLS Certificates

1625322 - Let's Encrypt: Failure to revoke key-compromised certificates...

(The example in the first link does not specify the reason, though.)

To deactivate an account with a compromised key, it should be possible to use the API to get the account information, and then deactivate it.

https://tools.ietf.org/html/rfc8555#section-7.3.1
https://tools.ietf.org/html/rfc8555#section-7.3.6

I believe Let’s Encrypt does not allow a second account to be registered using the same account key, so it would be blocked in effect, though I don’t know if ACME mandates that.

[jvanasco]

Thanks, Matt.

I didn't know about the blocklist via "keyCompromise" . That's a great extension to the RFC, and let's me handle that.

@mnordhoff

I believe Let’s Encrypt does not allow a second account to be registered using the same account key, so it would be blocked in effect, though I don’t know if ACME mandates that.

I actually already know that is mandated by ACME! Section 11.1 - RFC 8555 - Automatic Certificate Management Environment (ACME)

Note that given the requirements of Section 7.3.1, servers will not create accounts with reused keys anyway.

Because ACME accounts are uniquely identified by their account key pair (see Section 7.3.1), the server MUST not allow account key pair reuse across multiple accounts.

So it seems marking an AccountKey as compromised must still be done by alerting the LetsEncrypt service, though a rollover or deactivation would have the same effect of blacklisting it - though it wouldn't necessarily revoke any outstanding certificates. (I am assuming that my client will not necessarily know of every action tied to a given AccountKey that may require revocation, cleanup, etc).

Sorry for being overly pedantic about this. I designed my client before rollovers were possible, so the AccountKey is embedded into the Account in my object model. I'm decoupling it into two discrete objects right now, and have spent the morning sketching out what the interplay of rollover vs deactivation is.