# Apple ACME client failing to poll order when order is in "processing" status **URL:** \ **Category:** Help\ **Created:** [October 30, 2024, 5:32pm UTC](https://community.letsencrypt.org/t/apple-acme-client-failing-to-poll-order-when-order-is-in-processing-status/228020 "2024-10-30T17:32:07Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![dharasis1993](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/dharasis1993/32/83690_2.png) [@dharasis1993](https://community.letsencrypt.org/u/dharasis1993)\ **Post date:** [October 30, 2024, 5:32pm UTC](https://community.letsencrypt.org/t/apple-acme-client-failing-to-poll-order-when-order-is-in-processing-status/228020/1 "2024-10-30T17:32:07Z")
I'm developing an ACME server to issue identity certificates to macOS/iOS devices for MDM attestation, following RFC 8555. Per RFC, the client creates an order, performs authorization, verifies the challenge, and finalizes the order by submitting a CSR to the CA. In my setup, the CA sometimes takes longer to issue the certificate (around 50 seconds). According to RFC 8555, if certificate issuance isn’t complete after the /finalize call, the server should respond with an "order" object with a "processing" status. The client should then send a POST-as-GET request to the order resource (e.g., /order/\) to check the current state. If the CA still hasn’t issued the certificate, the server should return the order object with the same "processing" status and include a "Retry-After" header, indicating when the client should retry. The client is expected to poll the order resource at this specified interval with POST-as-GET requests. However, it seems the Apple ACME client ignores the "Retry-After" header and instead returns the error: "Profile failed - Order status is processing, not yet valid" immediately upon the first poll response with "processing." Apple ACME client deviating from the RFC documentation. Has anyone found a reliable solution to this issue? Ref -[RFC 8555 - Automatic Certificate Management Environment (ACME)](https://datatracker.ietf.org/doc/html/rfc8555#:~:text=A%20request%20to%20finalize%20an%20order%20will%20result%20in%20error,to%20the%20%22certificate%22%20field%20of%20the%20order.%20%20Download%20the%0A%20%20%20%20%20%20certificate). To work around this, I’m holding the /finalize call until the CA issues the certificate. This works when issuance is quick (under 20 seconds), but if it takes more than that , the client times out. Interestingly, the Apple ACME client’s timeout appears shorter than the usual 60-second URLSession default. ---
**Author:** ![petercooperjr](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/petercooperjr/32/84698_2.png) [@petercooperjr](https://community.letsencrypt.org/u/petercooperjr)\ **Post date:** [October 30, 2024, 5:38pm UTC](https://community.letsencrypt.org/t/apple-acme-client-failing-to-poll-order-when-order-is-in-processing-status/228020/2 "2024-10-30T17:38:25Z")
I'm not familiar with the "Apple ACME client", but when Let's Encrypt attempted to [move to "asynchonous finalization"](https://community.letsencrypt.org/t/enabling-asynchronous-order-finalization/193522), they ended up postponing it indefinitely because there were too many broken clients that didn't actually follow the spec and assumed they wouldn't get a "processing" status. My understanding is that other CAs _do_ use it, though. ---
**Author:** ![dharasis1993](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/dharasis1993/32/83690_2.png) [@dharasis1993](https://community.letsencrypt.org/u/dharasis1993)\ **Post date:** [October 30, 2024, 6:35pm UTC](https://community.letsencrypt.org/t/apple-acme-client-failing-to-poll-order-when-order-is-in-processing-status/228020/3 "2024-10-30T18:35:05Z")
It is understood for other clients for deviating from the spec, but didn't thought Apple not following it. Here i am struck in-between ---
**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\ **Post date:** [October 30, 2024, 9:10pm UTC](https://community.letsencrypt.org/t/apple-acme-client-failing-to-poll-order-when-order-is-in-processing-status/228020/4 "2024-10-30T21:10:58Z")
> [@dharasis1993](#): > > However, it seems the Apple ACME client ignores the "Retry-After" header and instead returns the error: "Profile failed - Order status is processing, not yet valid" immediately upon the first poll response with "processing." Apple ACME client deviating from the RFC documentation. LetsEncrypt deviates from the RFC as well: > I would post bug report to Apple on their client. ---
**Author:** ![webprofusion](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/webprofusion/32/85310_2.png) [@webprofusion](https://community.letsencrypt.org/u/webprofusion)\ **Post date:** [October 31, 2024, 1:02am UTC](https://community.letsencrypt.org/t/apple-acme-client-failing-to-poll-order-when-order-is-in-processing-status/228020/5 "2024-10-31T01:02:45Z")
Is there a link to any info about the Apple ACME client? Is it open source etc? I see their docs imply their use of ACME is mainly for device attestation. [Automated Certificate Management Environment (ACME) MDM payload settings for Apple devices – Apple Support (AU)](https://support.apple.com/en-au/guide/deployment/depb95c66a07/web) ---
**Author:** ![dharasis1993](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/dharasis1993/32/83690_2.png) [@dharasis1993](https://community.letsencrypt.org/u/dharasis1993)\ **Post date:** [October 31, 2024, 4:29am UTC](https://community.letsencrypt.org/t/apple-acme-client-failing-to-poll-order-when-order-is-in-processing-status/228020/6 "2024-10-31T04:29:14Z")
No Apple acme client is not a open source. It may be a part of MdmClient that apple has inbuilt with its endpoints. It can be found in "/usr/libexec/mdmclient" in mac. In iPhone i don't have any idea where it resides. Yes Apple provides ACME support for device attestations. ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [November 30, 2024, 4:29am UTC](https://community.letsencrypt.org/t/apple-acme-client-failing-to-poll-order-when-order-is-in-processing-status/228020/7 "2024-11-30T04:29:50Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.