Hi, sorry to come up with this issue that late, but it is currently blocking client implementation for me.
I think that the definitions of order status meanings are not covering all possible server states. > “pending”: The server does not believe that the client has fulfilled the > requirements. Check the “authorizations” array for entries that are still > pending. = client action needed > “processing”: The server agrees that the requirements have been fulfilled, > and is in the process of generating the certificate. Retry after the time > given in the “Retry-After” header field of the response, if any. = authorizations are 'valid' = the server has validated the challenge That leaves no status at which the server is validating the challenge. Which in turn raises the question how exactly the order/finalize and polling flow should look like. (I also think that the meaning of the status fields for authorization and challenge objects should be defined explicitly. Currently, the challenge status even seems to be lacking a way to represent that the client has responded to the challenge.) For reference: I have also create an issue for pebble that is related to those problems <https://github.com/letsencrypt/pebble/issues/81> It almost seems like there are different interpretations of the current spec. Best, Sophie _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
