Retry-After header does not seem to be honored

[chielteuben]

While testing the order process today I noticed that the certificate request timed out within 30 seconds after hitting finalize despite the ACME server indicating a Retry-After value of 5 in it's header and the order status still being 'processing'.
While digging in the code I saw 10 attempts will be made and, if the Retry-After header is set, it will delay each task attempt by the given value. It should then be impossible to time out after only 30 seconds when the Retry-After header is set to 5 right?

Now I didn't dive into Anvil but is it possible that the 'RetryAfter' value isn't properly propagating and simply isn't set?

[chielteuben]

For further context, when looking at AnvilACMEProvider.cs and it's usage of orderContext.RetryAfter I do not see how Anvil's OrderContext, and specifically Anvil's EntityContext , has it's RetryAfter property set, if ever.

[webprofusion-chrisc]

Hi, thanks for raising this issue. Currently the retry logic is split across the provider and the anvil library with some retries happening based on Retry-After, but not universally. There's also a need for some upper limit because if a server says retry after 5 minutes we should quit the order and just try again later rather than actually sleep for 5 minutes, as our renewal checks have a 5minute resolution anyway.

We do need to improve this but in the meantime if you have a slow ACME service you can work around that by setting DefaultACMERetryInterval in C:\ProgramData\certify\appsettings.json to a value like 30 (meaning 30 seconds wait between ACME operation retries), the default is only a few seconds wait between retries.

Our of interest what ACME service was this (or if internal, which ACME server software).