Right order to request certificate


#1

Hi,

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?


Hiawatha's Let's Encrypt script supports ACME v2
#2

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.


#3

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.


#4

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.


#5

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?

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

P.S.
It worked fine with the ACMEv1 version of my script.


#6

Any news about this issue?


#7

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


#8

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,


#9

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


#10

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.


#11

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.


#12

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.


#13

I opened an issue at Github.


#14

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.

Thanks!