What to do if script timesout while waiting for CA to issue cert?

[bokkabonga]

We are required to use a non public CA, that offers ACME. However their systems seem to be a bit slow at times, so that it can happen that the cert is not issued before acme.sh reaches a timeout:

"Signing failed. Could not get Le_LinkCert, and stopped retrying after reaching the retry limit."

I didn´t find any parameter to change this setting. I found multiple varibales defining retry thresholds in the acme.sh itself, but I would rather not change it there since i don´t fancy changing it back after each update to the script.
The CA issued the cert shortly after the timeout. Can i somehow instruct acme.sh to download the issued cert? I couldn´t find anything in the docs.

[JeanPluzo]

Hi,
I found a closed old issue (#4147) where you have to:
"set environment variable export MAX_RETRY_TIMES=9999"
Don't know if this would help your problem or if the variable is still taken into account.
Hope this helps.

Regards,
J.

[bokkabonga]

Yeah i saw that and will give it a shot. However this isn´t a perfect solution.

Le_LinkOrder= was set in my case, so it should be possible to have acme.sh retry the download of the cert. Increasing the retry limit is a workaround, but bears it own risks.

[neilpang]

MAX_RETRY_TIMES will not help. It bounds the authorization polling loop,
which runs before finalize. Your error comes from the order polling loop
after finalize, bounded by _MAX_CERT_RETRY=30 in acme.sh, assigned
unconditionally, with no environment override.

That loop does honor the CA's Retry-After, but the count sits on top of
it as a hard ceiling:

Retry-After: 15 -> 30 polls, gives up after 7.5 minutes
no Retry-After -> falls back to 2s, gives up after 60 seconds

RFC 8555 section 7.4 defines no retry count for the "processing" state,
only "Send a POST-as-GET request after the time given in the Retry-After
header field of the response, if any". The ceiling is ours, and it is
the wrong bound. Same point was raised in #6866.

On resuming: Le_LinkOrder is written to the domain conf but never read
back, so a re-run always creates a new order and there is no supported
way to poll the old one. That also means every retry makes the CA sign
another certificate.

Post the tail of a --debug 2 log from a failing run. Whether your CA
sends Retry-After on the order polls, and its value, decides which of
the two is actually biting you.

[bokkabonga]

After quite a few successful migrations it happend again. I atached the log and redacted a few informations i deemed sensitive. The CA seems to send retry-after:

retry-after: Thu, 13 Aug 2026 12:36:14 GMT

However the script terminates before it reaches the time at "14:35:53 CEST 2026". So roughly 30 seconds before the date that the CA set.

acme.txt

[neilpang]

Fixed in dev (666bf75). The order poll now reads the HTTP-date form of Retry-After and sleeps until that time, so with your log it would have waited until 12:36:14 instead of giving up at 12:35:53.

acme.sh --upgrade -b dev