>
> 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
