n/p @voutasaurus, happy to help!
To make sure I understand, you mean A would POST the
new-cert endpoint with a CSR, but timeout, not getting the certificate that is returned from the API as a result?
If I’m understanding right that shouldn’t influence the problem at hand. The primary issue with that scenario is that you can’t recover the certificate from the API and have eaten the rate limit cost of issuing it without having the resulting certificate.
Yes - but to be even more explicit it would be best if your client skipped challenges if the authorization the challenge is associated with is already valid. The reason the distinction matters is a scenario where a pending authorization “abcd” is shared between two workers but one worker prefers TLS-SNI-01 challenges and one worker prefers HTTP-01 challenges.
In that case Worker A might complete a TLS-SNI-01 challenge for authz “abcd”, making the pending authorization switch to a valid authorization with a valid TLS-SNI-01 challenge. The DNS-01 and HTTP-01 challenge associated with that valid authorization will still be “pending”. So if Worker B were to only look at the HTTP-01 challenge it wanted to POST it would see a “pending” challenge and decide that the authorization must be pending too when in fact it is already “valid” by way of the TLS-SNI-01 challenge.
Does that make sense? Challenges and authorizations both have a “status” field. When the status of a specific challenge for an authorization changes to valid, the status of the authorization changes to valid. The other unsolved challenges associated with the authorization are locked in the state they were in before the associated authorization was switched to valid.