ACME passive revocation

[ShoootLight]

Hi,

I apologize for my stupidity, but I can't passively revoke a cert via acme.

I use:
Step-CA (Version 0.21.0)
Step CLI (Version 0.21.0)
acme.sh (Version 3.0.5)
Apache2 Webserver
(Everythig running on an ubuntu desktop in VirtualBox)

I added the ACME prosivioner to Step-CA and set up acme.sh to issue and renew certificates (everything successful).
acme.sh --issue -d localhost --webroot /var/www/html/ --force
acme.sh --renew -d localhost --force
I wanted to test if I can revoke a certificate.
With acme.sh I did so:
acme.sh --revoke -d localhost (I made a backup of the private key and cert before)
acme.sh also declares a successful revocation
Step-CA shows the revocation event in its console output
However when I use the backup of the private key to issue a new cert it is possible (in both certs unter public key info the modulus is the same -> guessing it is the same private key).

I guessed that (passive) revocation over acme is not supported and tried to revoke the cert via Step CLI revoke command:
step ca revoke localhost.cer localhost.key
By renewing I get an error (which shall happen -> passive revocation -> cert should not be renewed)
step ca renew localhost.cer localhost.key error renewing certificate: The request lacked necessary authorization to be completed. Please see the certificate authority logs for more info.
However when using acme.sh renewal again I get a new cert (the modulus is again the same). The cert also has a longer validity period than the old cert. In the console output of step-ca both events are shown (Step CLI with a warning and acme.sh renewal as always).

I was assuming that when I revoke a private key (through acme prosivioner or JWK (default) provisioner) it is passively revoked, so no provisioner in Step-CA can renew it.

Is my assumption correct? And if it is not how is the way to go to revoke a cert in an ACME / Step-CA environment?

Thanks in Advance

Stephan

[hslatman]

Hey Stephan,

What you've tried so far, sounds OK to me. What you're trying to do, however, is in fact active revocation. We call revocation passive when certificates have short lifetimes and thus expire frequently. Active revocation is the "classical" method of revocation, involving CRLs and OCSP.

When a certificate is revoked, this generally means that only that specific certificate is revoked, based on its serial number. This serial number is then recorded in a CRL or its revocation status can be requested using OCSP. I'm not aware of a requirement that the private key that corresponds to a certificate to be revoked MUST be marked as not usable anymore; at least not in the Web PKI. I have heard about specific cases in which CAs put known compromised private keys on a blocklist, but not for all revocations. I think it thus boils down to the user/system revoking the certificate to getting rid of the private key too and generate a new one to request a new certificate.

The reason the step ca renew fails to renew after revoking the certificate is because that code path does check if the certificate to be renewed is revoked based on its serial. This doesn't take into account which private key belongs to the cert, so you could still use the same private key and request a new certificate if you want to. When using the ACME protocol, a "renewal" is essentially a totally new certificate request (using the same or a different private key; in this case it's the same) and thus it doesn't go through the renew code path. That's why it'll successfully "renew" the certificate with the same key.

That said, this issue got me thinking, and I think what you're after does make sense. It could be an option to implement additional validation to not allow known compromised keys from being reused. A key would be known if a cert were revoked with the keyCompromised reason. WDYT, @maraino, @dopey?

As an aside: we also support a rekey operation in the CLI and CA. A rekeying operation is not included in the ACME protocol, however.

[maraino]

@hslatman Sounds reasonable; let's bring this up in our design discussions. But we should check both (keyCompromise) and intermediate (cACompromise).

[ShoootLight]

Hey Herman,

thanks for your quick reply. I overthaught some of my assumptions based on your reply.
The first false assumption was to revoke a cert only due to keyCompromise and excluding other reasons such as superseded.
The second false assumption was to believe that a renewal of a cert (at ACME provisioner) is possible only by providing a certificate and the private key to step-ca (like with JWK provisioner).
Of course with the renewal via ACME a new challenge must be completed. Since an attacker won't have control over a domain the challenge won't be completed and the renewal will fail. In my test setup Apache always ran in the background and completed the challenge.

Am I getting this right that a website owner can passively revoke a certificate by simply not using the compromised private key anymore? Sounds a bit too simply for me :D

PS: I feel honoured to have given a meaningful suggestion :D

[hslatman]

Hey Stephan,

When the ACME protocol is in use, passive revocation indeed comes down to not using the compromised private key anymore. Since the challenge has to be completed again when a new certificate is issued, having the key isn't enough to get a new certificate. There exist options for a malicious party to abuse the private key in the time between it was obtained and the certificate expiring, so it's not entirely safe to rely on it, but with sufficiently short certificate lifetimes the risk may be very small. I would still advise to revoke the certificate using the ACME revocation functionality if the ACME client supports it, because that invalidates the current certificate immediately (or at least when a client looks up the revocation status).

One more thing: the ACME protocol also supports the concept of preauthorization, which means that an ACME account can be preauthorized to request a certificate for a certain identifier without having to complete a challenge. With this active, this would mean that an attacker could abuse an ACME account private key to request certificates at will and that would require deactivating the ACME account and revoking all certificates immediately. At this time step-ca doesn't support preauthorization, so this scenario can't happen now, but just wanted to note it here.