Skip to content

Conversation

@ignoramous
Copy link

Neilpang and others added 2 commits October 24, 2025 21:15
MAX_REQUEST_RETRY_TIMES controls no. of retries acme.sh
will perform when the CA is processing issue requests. Instead of
short-circuiting the entire operation when retryAfter is set to
more than 10m (600 seconds), wait for a maximum of 10m and
issue a retry. Some CAs, like ZeroSSL, set very high retryAfter.
@ignoramous
Copy link
Author

Emitting _err from a few relevant places so GitHub's built-in Copliot will help catch the issue (--debug 2 generates a LOT of logs and options like Copilot help reduce time it takes to parse them).

Even after these changes, a few places with return 1 emit logs as _info or _debug or not emitted at all (should be probably changed to _err).

@Neilpang
Copy link
Member

Neilpang commented Nov 9, 2025

if the retryafter is too large, it usually means the ca is refusing your requests. so we should give up.
Maybe 600 is not that large to give up. how about make it 3600?

@ignoramous
Copy link
Author

if the retryafter is too large, it usually means the ca is refusing your requests ... Maybe 600 is not that large to give up. how about make it 3600?

What I've found with ZeroSSL is, when there are 8+ domains in a single cert request, it takes a while (I've seen it take 10mins). But their retrtAfter is set to 84600 (1 day), which is over-the-top, as the response is usually available within 10mins.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants