HTTP client should have some retry mechanism #31
Description
In some cases, HTTP responses from Let's Encrypt have returned a 50x during Let's Encrypt downtime, or a rate limit was hit. This client should probably handle these gracefully. I would also suggest using Guzzle instead of curl, which allows greater flexibility in handling HTTP requests from PHP, such as adding a retry middleware.
From the Let's Encrypt docs here: https://letsencrypt.org/docs/integration-guide/
Renewal failure should not be treated as a fatal error. You should implement graceful retry logic in your issuing services using an exponential backoff pattern, maxing out at once per day per certificate. For instance, a reasonable backoff schedule would be: 1st retry after one minute, 2nd retry after ten minutes, third retry after 100 minutes, 4th and subsequent retries after one day. You should of course have a way for administrators to request early retries on a per-domain or global basis.
Backoffs on retry means that your issuance software should keep track of failures as well as successes, and check if there was a recent failure before attempting a fresh issuance. There’s no point in attempting issuance hundreds of times per hour, since repeated failures are likely to be persistent.