Right order to request certificate


I’m implementing ACME v2 in the Let’s Encrypt script for the Hiawatha webserver (as mentioned in the PHP section of the client-list page at this website). According to section 7.1 of the ACME RFC, I have to finalize the order before polling for the status. However, if I do that, the server keeps saying that the status is ‘processing’. If I poll for the status, wait for a ‘final’ and then finalize the order, I’m able to download a new certificate successfully. What am I doing wrong?

Other issue: once the status is set to ‘processing’, I have no idea what to do next. What must I do to make the server finish the certificate?

If someone wants to see my code, download https://www.hiawatha-webserver.org/files/letsencrypt_beta.tar.gz.

The code relevant to this issue is in ACMv2/libraries/letsencrypt.php. The polling is done at line 236, finalizing the order at line 255. Swap those blocks to reproduce the issue.

Sounds suspiciously like this: ACME v2 - Order processing for a long time

Can you show a link to an order stuck on processing?

o “processing”: The server agrees that the requirements have been
fulfilled, and is in the process of generating the certificate.
Retry after the time given in the “Retry-After” header field of
the response, if any.

Here is one of the stuck orders.

I tried it again this afternoon with the order as described in the RFC (finalize first, then poll for status) and guess what, it worked. I find the test server quite unreliable. Sometimes things work, sometimes they don’t. When things don’t work, I try it again next morning without changing any code and then it works. This makes debugging my own code very hard.

I did some testing again. 3 orders were handled ok, but the last I tried failed. No idea why, I didn’t change any code. The order of the steps I followed is as described in the RFC.

The order which is still in ‘processing’ is https://acme-staging-v02.api.letsencrypt.org/acme/order/5431838/3034. Can you tell me what goes wrong? Why does its status remain in processing?

Another that failed: https://acme-staging-v02.api.letsencrypt.org/acme/order/5431838/3037

It worked fine with the ACMEv1 version of my script.

Any news about this issue?

@cpu is there any activity/open issue? Would a reliable client repro. help?

The issue for this is https://github.com/letsencrypt/boulder/issues/3333

The latest news is that I had a PR out with a fix but we decided to revisit the architecture. I expect to have a PR out with a new fix shortly.

There’s no need for a client repro - I have an integration test written that exersizes the bug.

Thanks for your patience,


Are you sure that’s the same issue? In that one, the status is ‘pending’. My issue is about the status being ‘processing’.

I had another strange thing. I did some more testing. For several websites, I could obtain a certificate. For one, the status was still ‘processing’. I removed my account key, created a new one and registered a new account. From then on, every certificate request failed. Even for the ones that worked fine with my previous account key. I changed my code to where it first does the status polling before finalizing. Now, every certificate request results in a certificate, even for that website that previously had a ‘processing’ state.

It’s a variant of the same order state transition problems. This issue should cover the problem you’re experiencing: https://github.com/letsencrypt/boulder/issues/3403

Can you please open a Boulder issue with a log showing the ACME messages sent/received during the case where every certificate status fails, and in the case where you’ve made the described polling change and can issue successfully? I’m not sure I understand what’s going on and it would be much easier to debug with some logs :slight_smile: Thank you.

Were you previously finalizing the order before the authorizations were all valid? That would also create the condition in #3403 that isn’t being handled correctly where an unauthorized error is returned for the finalization but the state remains processing.

I opened an issue at Github.

1 Like

To close the loop here as well: https://github.com/letsencrypt/boulder/issues/3403 does cover the case observed by @hiawatha where a order that is finalized prematurely gets stuck in the processing state. See [the issue reported by @hiawatha](https://github.com/letsencrypt/boulder/issues/34060 for more discussion about this.


1 Like

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