-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Details on revocation #134
Comments
Hi @felixfontein, thanks for opening an issue!
Hmm. I think we should probably try to match what Boulder does and return a problem rather than simply an HTTP status code. Thanks for pointing that out! (Addressing with #135 and #136)
There aren't any active plans to define a common behaviour. You could start a discussion on the ACME working group mailing list about the topic if you would like. I do see that ACME draft-12 Section 7.6 says "If the revocation fails, the server returns an error." with an example
Apologies for the confusion, it looks like in 185968a when we added revocation support I read the code as if the only supported authentication method was embedding a JWK with the certificate to be revoked's public key and signing the JWS with the certificate to be revoked's private key. The README and the comments in the code reflect that: Lines 1606 to 1609 in de6fa23
In reality we're using Line 1618 in de6fa23
That will only allow authenticating the revocation by signing the JWS with the account key and using the standard keyID to identify the account. That's why you are seeing the missing key ID error. I think for the short-term I'll fix the existing implementation to suport the certificate key/JWK method we described in the comment/README and will re-add the issuing-account/KeyID revocation authentication method afterwards. See #137 |
Well, for me personally, I'd like to know why revocation failed: is it because authentication didn't work, is it because the certificate is from another CA (or else unknown to the CA), or is it because it has already been revoked? I'm currently trying to detect this by looking out for the precise error message returned by Boulder, which isn't a very good idea(tm). I need this to correctly implement idempotency for a Ansible module for ACME certificate revocation (see ansible/ansible#40995), which should do nothing (i.e. return "no change") if the certificate has already been revoked. Currently, the main check I'm using is asking the OCSP, which of course doesn't work for Pebble, and in general has the problem that OCSP response update could be delayed. If there's no OCSP response, or if it returns valid, I'm trying to revoke the certificate, and if that fails I'm looking at the error. If it is the Boulder error message, I ignore it and return "no change". If there would be a well-defined error message for the case "already revoked", I could simply look out for that one and feel better that I didn't have to use a hack which might stop working at any point in time, or will never work (with other ACME implementations) :) I'll start a discussion on the ML. |
Sounds good 👍 Thanks for explaining your use case here. I agree that specific error codes for some of the revocation error conditions sound like they might help your use case. Starting a ML thread is the best way to get that ball rolling. |
This commit brings over more of Boulder's WFE2 revocation handling to Pebble and supports **both** authenticating revocation requests with: * a JWS with a KeyID specifing the account that previously issued the certificate * a JWS carrying an embedded JWK containing the certificate to be revoked's public key. Previously the revocation implementation specified it only supported authenticating the request with the certificate's key and an embedded JWK. In practice the revocation logic was still expecting a key ID and authentication from the ACME account. It also did not verify that the certificate to be revoked was originally issued by the account that authenticates the revocation request. Resolves #134
I noticed that certificate recovation is now supported in Pebble. Great :-) I've noticed two things:
ACME defines no behavior if one tries to revoke a certificate which has already been revoked. Boulder returns error type
urn:ietf:params:acme:error:malformed
(orurn:acme:error:malformed
for ACME v1) with detailCertificate already revoked
, while Pebble simply returns a 404. Are there plans to define a common behavior in the ACME protocol, or will this be left for implementations to handle as they want?When trying to revoke a certificate with its private key, Boulder does not require the Key ID field, while Pebble does:
{'type': 'urn:ietf:params:acme:error:malformedRequest', 'detail': 'Key ID (kid) in JWS header missing expected URL prefix', 'status': 400}
Which of these behaviors is correct? Or is revocation by certificate's private key simply not supported yet in Pebble?The text was updated successfully, but these errors were encountered: