Apple ACME client failing to poll order when order is in "processing" status

dharasis1993 · October 30, 2024, 5:32pm

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/<order_id>) 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).

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.

petercooperjr · October 30, 2024, 5:38pm

I'm not familiar with the "Apple ACME client", but when Let's Encrypt attempted to move to "asynchonous finalization", 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.

dharasis1993 · October 30, 2024, 6:35pm

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

jvanasco · October 30, 2024, 9:10pm

LetsEncrypt deviates from the RFC as well:

github.com

letsencrypt/boulder/blob/main/docs/acme-divergences.md

# Boulder divergences from ACME

While Boulder attempts to implement the ACME specification ([RFC 8555]) as strictly as possible there are places at which we will diverge from the letter of the specification for various reasons. This document describes the difference between [RFC 8555] and Boulder's implementation of ACME, informally called ACMEv2 and available at https://acme-v02.api.letsencrypt.org/directory. A listing of RFC conformant design decisions that may differ from other ACME servers is listed in [implementation_details](https://github.com/letsencrypt/boulder/blob/main/docs/acme-implementation_details.md).

Presently, Boulder diverges from the [RFC 8555] ACME spec in the following ways:

## [Section 6.3](https://tools.ietf.org/html/rfc8555#section-6.3)

Boulder supports POST-as-GET but does not mandate it for requests
that simply fetch a resource (certificate, order, authorization, or challenge).

## [Section 6.6](https://tools.ietf.org/html/rfc8555#section-6.6)

For all rate-limits, Boulder includes a `Link` header to additional documentation on rate-limiting. Only rate-limits on `duplicate certificates` and `certificates per registered domain` are accompanied by a `Retry-After` header.

## [Section 7.1.2](https://tools.ietf.org/html/rfc8555#section-7.1.2)

Boulder does not supply the `orders` field on account objects. We intend to
support this non-essential feature in the future. Please follow Boulder Issue
[#3335](https://github.com/letsencrypt/boulder/issues/3335).

This file has been truncated. show original

I would post bug report to Apple on their client.

webprofusion · October 31, 2024, 1:02am

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)

dharasis1993 · October 31, 2024, 4:29am

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.

system · November 30, 2024, 4:29am

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

Topic		Replies	Views
Orders stuck on ready Client dev	15	421	August 2, 2024
Right order to request certificate Client dev	14	3772	February 28, 2018
Error when finalizing order Client dev	5	7167	November 21, 2019
ACME v2 order stuck in "processing" state Client dev	3	3336	March 1, 2018
Client access delay for asynchronous order finalization Client dev	1	509	May 6, 2023

Apple ACME client failing to poll order when order is in "processing" status

Related topics