Search results for

ACME

78 results found

Post

Replies

Boosts

Views

Activity

Reply to Supporting development of ACME - Freshness code question
First some background: There are two different features that use Managed Device Attestation: ACME attestation and DeviceInformation attestation. When you mention 7 days, that likely refers to the rate limit that applies to DeviceInformation attestation. ACME attestation only generates an attestation at the time the key is initially generated, so there's no 7 day rate limit. The freshness code OID is also different between the two features. For DeviceInformation attestation the freshness code is the value from the DeviceInformation command's DeviceAttestationNonce key. For ACME attestation, it's a SHA256 hash of the nonce specified by the ACME server in its response containing the device-attest-01 challenge. When the documentation uses the term matches, it means that the ACME server should hash the nonce it previously sent and compare that to the value in the freshness code OID.
Topic: Business & Education SubTopic: Device Management Tags:
May ’25
Apple ACME client failing to poll order when order is in "processing" status.
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 i
Topic: Business & Education SubTopic: Device Management Tags:
0
0
617
Nov ’24
Apple ACME client failing to poll order when order is in "processing" status.
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 i
Topic: Community SubTopic: Apple Developers Tags:
0
0
499
Oct ’24
ACME Managed Device attestation - Unsupported URL error for certifcate URL in finalize Order step
I'm trying to implement managed device attestation, I have written server code in Go. So far, I have been able to implement all the steps except finalizing order by sending the Certificate url in the json response from where the client can download the certificate. ACME request flow failed at step 8: Error Domain=NSURLErrorDomain Code=-1002 unsupported URL UserInfo={NSLocalizedDescription=unsupported URL, NSErrorFailingURLStringKey=} For server, I am using localhost with https. The URL in certificate field of json response is working in browser/postman. I am not able to figure out what is the exact the cause of this error. As there is no FailingURLStringKey I suspect there might be some issue with key in the json response. Can anyone point me to the correct direction to figure out what is the issue?
Topic: Business & Education SubTopic: Device Management Tags:
1
0
826
May ’24
Reply to Supporting development of ACME - Freshness code question
The developer figured it out. It doesn't match the nonce because Apple isn't using the nonce for ACME. Apple is using the challenge token. The challenge token hashes to an exact match of the freshness code OID. From device-attest-01: { type: device-attest-01, url: https://example.com/acme/chall/Rg5dV14Gh1Q, status: pending, token: evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA } { protected: base64url({ alg: ES256, kid: https://example.com/acme/acct/evOfKhNU60wg, nonce: SS2sSl1PtspvFZ08kNtzKd, url: https://example.com/acme/chall/Rg5dV14Gh1Q }), payload: base64url({ attObj: base64url(/* WebAuthn attestation object */), }), signature: Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4 } It may be the case that the term nonce is being used too loosely, which unfortunately is a dangerous thing when it has an actual definition in this protocol. We lost the best part of a week to this. ACME YAML needs to be corrected. I can't quite re-find the other instances I thought I saw claiming it's
Topic: Business & Education SubTopic: Device Management Tags:
May ’25
Reply to How to link Apple in-app subscription to company account
If you want that one user only have one account in ACME, you can detect that the original_transaction_id is being used by another account, and inform the user that he has another account. If you decide to allow a user have different accounts in ACME, then that shouldn't be a problem because the user is the same with two accounts. If the user is the same, it shouldn't matter what account he used to log in. To share subscription between members of a family, Apple has now Family Sharing: https://developer.apple.com/documentation/appstoreservernotifications/notification_type#3733656
Topic: App Store Distribution & Marketing SubTopic: General Tags:
Apr ’21
Reply to reference preinstalled certificate keypair from an MDM profile
For additional security we would like to avoid keeping generated certificates (their private keys) on our server after installing them on a device, This is a very good goal for security. However it still involves the movement of private keys, which is inherently less secure than a system where the private key never moves. Apple devices offer support for ACME and SCEP. With those protocols the private key is generated on the device and never moves. In addition Apple's support for ACME includes support for hardware-bound keys, which offer very strong protections against exporting private keys. Considering your attention to the security of your architecture, I would strongly suggest adopting ACME instead of identities generated by your MDM server. That aside, configuration profiles require that (in nearly all cases) when one payload references another payload, both payloads must be in the same configuration profile. That requirement applies to all identity types (PKCS12, ACME
Topic: Business & Education SubTopic: Device Management Tags:
2w
Reply to Supporting development of ACME - Freshness code question
I updated the Mac to 24F74 yesterday. So, there is a new attestation certificate today. Again, the contents of the freshness code OID do not match any hash of the nonces sent by the server. Does macOS store the nonce in a retrievable way or can we put something into debug mode and have it record what it's sending and receiving from the ACME server? It's like something is being lost in translation.
Topic: Business & Education SubTopic: Device Management Tags:
May ’25