A question about Order Status: pending to ready

[test_mail_new]

Here is my experience:

First, I set the DNS TXT record properly.

Then I triggered the challenge, invoke the /finalize API immediately and got the error response:

{u\'status\': 403, u\'type\': u\'urn:ietf:params:acme:error:orderNotReady\', u\'detail\': u\'Order\\\'s status ("pending") is not acceptable for finalization\'}

So Question is:

How long time does order spent for transforming status pending to ready?

It seem that order status would not change immediately after challenge.

What average time value between pending to ready ?

5 min or more?

[JuergenAuer]

Hi @test_mail_new

please read the specification if you want to write an own client.

That's

@test_mail_new

Then I triggered the challenge, invoke the /finalize API immediately

wrong. Why do you think that should work?

You have to check the status of the order before you fire the finalize call.

So that error says: Your client is buggy.

[test_mail_new]

@JuergenAuer

wrong. Why do you think that should work?

Because I ensured that the DNS TXT record had been set correctly.

[Osiris]

But that doesn't ensure anything from the Let's Encrypt side. There is no fixed time after which the order magically changes status. This can vary, perhaps due to high loads.

You can of course poll /finalize randomly, but that's just guess work. First check the order status, then go to /finalize.

[JuergenAuer]

@Osiris

First check the order status, then go to /finalize.

That's possible, but that's not really a solution you should use.

Better:

• Create all challenges
• Confirm all challenges, so Letsencrypt starts to check every challenge
• check every challenge, if the challenge is valid / invalid -> loop per challenge
• If one challenge is invalid, you can stop and you have the exact error
• If all challenges are valid, check the order status, must be ready
• Order ready -> finalize

Result: Normally only one check of the order status is required.

[griffin]

@JuergenAuer

• Confirm all challenges, so Letsencrypt starts to check every challenge
• check every challenge, if the challenge is valid / invalid -> loop per challenge

While I fully agree with the functionality of the flow that @JuergenAuer has presented (and have used it myself in the past two versions of my own ACME client), there is a significant benefit to be had by triggering and polling one authorization at a time: your user can address any issues with their FQDNs one at a time. This comes at the cost of completion time via serialization of the process. If you trigger all of the authorization checks at once then poll, your client will probably only report any error it encounters for the first invalid authorization it finds. Fixing the cause of that error then submitting a new order sets up a pattern of repeatedly failing authorizations for other FQDNs that also have errors. If there are enough FQDNs in the list with problems, your user will eventually face the limit of 5 invalid authorizations / FQDN / account / hour. The point is: telling Let's Encrypt to check an authorization associated with an FQDN with a known problem that has not been reported to the user yet (and thus likely hasn't been fixed) creates a pattern of waste with consequences.

[test_mail_new]

Em...

So, according to my understanding,

When LetsEncrypt received challenge trigger request, It begin POLL and check the dns-01 or http-01 or TLS-ALPN-01.

How many time that LetsEncrypt would check the challenge was done?

Is there a limit times?

[test_mail_new]

@griffin
@Osiris
@JuergenAuer

[griffin]

Not quite. YOUR CLIENT needs to poll an authorization after one of its challenges is triggered.

[test_mail_new]

If LetsEncrypt found challenge value was no set properly at first

and client set the challenge value 5 min later,

would LetsEncrypt check this challenge again at this situation?

How many times that client could be failed on challenge value setting?

[griffin]

If any authorization is failed even once in any order, the entire order fails. You're limited to 5 failed authorizations per FQDN per ACME account per hour.

[test_mail_new]

So, actually,

client has only one chance to trigger the challenge.

Although the order status would not change to ready immediately,

LetsEncrypt only check every order's authorization just one time.

[griffin]

Basically. Technically Let's Encrypt checks once from its primary server then three more times from three different AWS instances.

[Osiris]

@test_mail_new

@Osiris

Please don't tag persons (myself at least) after only three hours. In my opinion that's impatient and rude.

Also I would again urge you to open just a single thread pertaining all your ACME client building efforts. Currently, almost the whole top section of the Client dev section are threads related to a single issue by you: