> > When trying this out with Boulder (Let's Encrypt staging), I noticed > that Boulder returns urn:ietf:params:acme:error:malformed with detail > "Certificate already revoked" if the certificate has already been > revoked. On the other hand, the Pebble testing server simply returns a > 404 error.
Pebble also returns a malformed problem for this case as of https://github.com/letsencrypt/pebble/commit/c0cc64314be427c6d39679e95a7794c89a293912 - Thanks again for flagging that! On Tue, Jun 12, 2018 at 5:04 PM, Felix Fontein < felix=40fontein...@dmarc.ietf.org> wrote: > Hi, > > while implementing certificate revocation in an ACME client, I noticed > that the current ACME draft is very vague about errors to return when > revocation fails. The draft says "If the revocation fails, the server > returns an > error." (https://tools.ietf.org/html/draft-ietf-acme-acme-12#section-7.6), > which is followed by an example which returns > urn:ietf:params:acme:error:unauthorized with detail "No authorization > provided for name example.net". > > When trying this out with Boulder (Let's Encrypt staging), I noticed > that Boulder returns urn:ietf:params:acme:error:malformed with detail > "Certificate already revoked" if the certificate has already been > revoked. On the other hand, the Pebble testing server simply returns a > 404 error. > > I think it would make sense to define more specific error codes the > server could return for certificate revocation. In particular, there > should be an error code for "certificate has already been > revoked" (maybe urn:ietf:params:acme:error:alreadyRevoked?). This would > make it easier for clients to detect this specific situations. > > The rationale behind this is that it allows the client to distinguish > between errors which require no user interventions (if the certificate > has already been revoked, the action the user wanted to perform did > fail, but everything is fine since there is no need to still revoke the > certificate), and errors which require user intervention (if the > certificate was not revoked, and the user has to do something to make > sure it is really revoked, like providing the correct account key / > private key). Without a well-defined error, a client author has to > guess (or simply assume that every server behaves as Boulder and sends > the same error detail). > > Thank you for your considerations, > Felix > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
