Hi all,
I am a developer for the cert-manager <https://cert-manager.io> project
which is an operator for issuing
certificates in Kubernetes.
I am reaching out as I have a question regarding perhaps some ambiguity in
the
ACME RFC.
cert-manager implements an ACME client for requesting certificates from ACME
servers. As part of the ACME flow when requesting a certificate, the ACME
Challenge controller worker is responsible for self-checking whether a
Challenge
is valid, accepting that Challenge to the server, and finally waiting for
Authorization.
Due to the nature of the operator model in Kubernetes, before this flow
takes
place, the controller fetches the current state of the ACME Challenge from
the
server. This uses an empty body ("") POST-as-GET request to the Challenge
endpoint in order to recover state which might have been lost.
cert-manager has been successfully used against ACME servers for the past 4
years, including namely Let's Encrypt. Recent implementations of ACME
servers
have had issues with this call whereby they interpret it as an Accept, or
otherwise reject the call and effectively invalidate the Order.
Though this behaviour can be mitigated by calling the authorization
endpoint and
pruning the Challenge that the controller is concerned with, my question is
whether or not querying the Challenge endpoint for its status is valid
according
to the ACME RFC?
It is described in section 7.5.1
<https://datatracker.ietf.org/doc/html/rfc8555#section-7.5.1>:
> To check on the status of an authorization, the client sends a POST-
> as-GET request to the authorization URL, and the server responds with
> the current authorization object. In responding to poll requests
> while the validation is still in progress, the server MUST return a
> 200 (OK) response and MAY include a Retry-After header field to
> suggest a polling interval to the client.
However we are not necessarily concerned with the _authorization_, only a
particular child Challenge. Is querying the Challenge endpoint to discover
state ever intended as a supported call in the RFC?
Cheers,
Josh
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
