Verification Timeouts

you don’t. you can use multiple clients with the same key.

1 Like

I don’t know how that client works. Never used ACME-v1.

But:

Order - select a challenge -> pending -> challenge created -> say “Please check that challenge” -> then wait. Throwing an exception after 5 seconds is wrong. So add a loop.

1 Like

using ACME-v2, not v1
There is a loop checking if verification is pending / valid - after 5 rounds it’s throwing Error - so I guess that’s where I need to clean the Pending Auth.
According to https://letsencrypt.org/docs/rate-limits/:

If you have a large number of pending authorization objects and are getting a rate limiting error, you can trigger a validation attempt for those authorization objects by submitting a JWS-signed POST to one of its challenges, as described in the ACME spec. The pending authorization objects are represented by URLs of the form https://acme-v02.api.letsencrypt.org/acme/authz/XYZ , and should show up in your client logs. Note that it doesn’t matter whether validation succeeds or fails. Either will take the authorization out of ‘pending’ state.

So I guess it should solve the Problem when doing this before throwing the Error? In addition to modifying the Loop so it uses exponential delay … 1s, 5s, 25s, …

Just want to be sure I don’t do anything “wrong” here when modifying the Client … :wink:

1 Like

Then you have already the loop. Play there - add more checks and more time.

And may be a better log.

PS: I would add something like

1, 5, 6, 7, 8, …

or

1, 5, 10, 20, 30, 30, 30

2 Likes

yea - just modifying the loop to give the Verification Process more time …
But if it finally is taking too long, several minutes I want to clear out the Pending Auth - The Client will then try it again within the next few days. (When Validation is hopefully a bit faster … :wink: )

So sending an empty, signed Post to https://acme-v02.api.letsencrypt.org/acme/authz-v3/AuthID should do it’s work - am I correct here?

Info: With increasing SleepTime between the checks all Certs I’ve tested have been successfully verified by now …
But just in case if it will take even longer for some Certs I want to implement the “clean Pending Auth” too …

In no case they will take more than a week (before failing, eventually). Let them run, restarting them will not make them go faster.

Then you should never have pending authorizations.

So

that problem doesn’t exist.

1 Like

the problem with that PHP Client - it won’t save pending Requests … it’s running while the PHP Process is running … so a few Minutes is all I can give the Script to finish … not a whole week … :grimacing:
But all Test-Renews I did finished within 20-40 Seconds now … So I hope this should do the trick! :wink:

1 Like

alright - thx - then I hope that the Prob is solved by this! :wink:
Will monitor it more closely the next time …

Thank you all! :slight_smile:

1 Like

It should store that stuff in some kind of database or text file, change client asap please.

1 Like

will reach out to the initial coder of this Client … maybe he’s going to add this behaviour … otherwise maybe I’m going to do it … if it’s to complicated to get it into this Client a Client Switch may be adviseable … you are right …

1 Like

you are managing a lot of certs. maybe you should think of some client that would renew without relying on a webserver executing a php script (even using a php script, but from the cli, which have no stringent time limits if you set it, anyway)

renewals should happen in the background, not interactively. and they definitely should not make a frontend wait.

1 Like

they run CLI-wise CRON triggered … completely Background - no Frontend Waiting for anything … :wink:
but you are right - normally one could increase Time Limit as needed … it’s just not tested by me if simultaneously running this script is working without problem (normally it should …)
Was no matter until now as it was working without any problems for some years now … with ACME-v1 and later also with v2 …
There is an Error Log with all those Errors so one can good see when Problems started … mhm … maybe it’s time after a few years again to put some love+time in the LE Stack of the CMS … :wink:
Not thought about it yet …

1 Like

this in a cron can be an idea:

LOCK=/var/yourclient.lock 
if [[ ! -e "$LOCK" ]]; then
  echo 'I am running' > "$LOCK" ; 
  php -f yourclientblabla && rm "$LOCK";
else 
  echo "yourclient is still running" 1>&2;
fi

(you can also check with ps aux | grep)

2 Likes

at least in theory … this one CMS Server is responsible for way over 1.000 Domains, all with LE Certs. Now if 1 Domain could lock up the renewal Process for up to 1 Weeks (worst case) … it could happen we run into problems getting all those Certs renewed … :wink:
Of course speaking worst case … so there are only 2 viable Options I see (with this Client)

  • check if it’s working without hassle when running multiple times (i think so … maybe just need to add a check if Domain XYZ is already running)
  • make it pick up PENDING Verifications later on subsequent calls of the Client

mhm

… next to just completely replace this Client with some more robust solution … :wink:

1 Like

If every domain has its certificate and domains do not share a certificate, any sensible client would renew the working domains and retry failed ones in the following run.

1 Like

that was related to your CRON suggestion above - if i do a locking like that we would run into the mentioned problem! :wink:

I don’t think so. If a domain fails the challenge fails, doesn’t stay pending indefinitely.

I guess this is the solution. You might even want to reverse proxy all the thing.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.