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
Search results for
ACME
78 results found
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
I had the same issue with dovecot on openbsd using a LE cert updated with acme. In my case the cert was getting refreshed properly but wasn’t picking it up (using openssl s_client to test). The cert presented was expired. Restarting dovecot fixed it for me.
Topic:
Community
SubTopic:
Apple Developers
I received two different emails from Apple regarding my developer account: An App Store invitation email stating: You're invited to join a development team, Acme Corp, in the Apple Developer Program so you can help develop, distribute, and manage their apps. The company name here correctly shows Acme Corp. A TestFlight invitation email with the subject line: TechSolutions LLC has invited you to test ShopEasy. In this email, TechSolutions LLC appears as the company name, but it should be either Acme Corp or simply the app name, ShopEasy. For context, I have two apps in my account: ShopEasy and TechApp. They are created as separate apps under Acme Corp, which is the entity registered in my Apple Developer account membership. Despite this, when I build ShopEasy for TestFlight, the email subject uses TechSolutions LLC as the company name, which is confusing for testers. Could someone help me understand where TechSolutions LLC is coming from, and how I can fix this so that the c
Topic:
Developer Tools & Services
SubTopic:
Apple Developer Program
Tags:
Xcode
App Store Connect
Developer Program
The name in my account Membership details section is: Entity name: Acme Corp
Topic:
Developer Tools & Services
SubTopic:
Apple Developer Program
Tags:
I received two different emails from Apple regarding my developer account: An App Store invitation email stating: You're invited to join a development team, Acme Corp, in the Apple Developer Program so you can help develop, distribute, and manage their apps. The company name here correctly shows Acme Corp. A TestFlight invitation email with the subject line: TechSolutions LLC has invited you to test ShopEasy. In this email, TechSolutions LLC appears as the company name, but it should be either Acme Corp or simply the app name, ShopEasy. For context, I have two apps in my account: ShopEasy and TechApp. They are created as separate apps under Acme Corp, which is the entity registered in my Apple Developer account membership. Despite this, when I build ShopEasy for TestFlight, the email subject uses TechSolutions LLC as the company name, which is confusing for testers. Could someone help me understand where TechSolutions LLC is coming from, and how I can fix this so that the c
Topic:
Developer Tools & Services
SubTopic:
Apple Developer Program
Tags:
Xcode
App Store Connect
TestFlight
Developer Program
I'm assuming EAB means External Account Binding, a part of the ACME protocol. I can't discuss Apple's plans. If you would like Apple to add support for EAB, please file feedback. In your feedback, please give a detailed reason why you want support for EAB. What's your use case? What does EAB do that cannot already be done with the ClientIdentifier?
Topic:
Privacy & Security
SubTopic:
General
Tags:
Current Apple ACME Profile does not support EAB. Do you have any plan to support it?
[quote='797344022, fxk510, /thread/760541?answerId=797344022#797344022, /profile/fxk510'] And I assume by general-purpose signing from 3rd party code you mean that Apple code might be able to do it, but we will not be able to accomplish it? [/quote] Yes, but that “general-purpose” rider is important. The key thing here is the “it” in the above quote. By “general-purpose” I’m talking about calling APIs, like SecKeyCreateSignature and Apple CryptoKit, that allow you to sign arbitrary data. Beyond that, for example, in the Platform SSO stuff, things get more nuanced. [quote='797411022, fxk510, /thread/760541?answerId=797411022#797411022, /profile/fxk510'] would an ACME certificate, which can be hardware bound, be used during the system context prior to login? [/quote] I don’t think so. I don’t know a lot about ACME, but it seems to me that they must be issued to the machine or the user. If they’re issued to the user, you can’t use them prior to login because the user’s keychain is locked. If th
Topic:
Privacy & Security
SubTopic:
General
Tags:
Another question on this topic: would an ACME certificate, which can be hardware bound, be used during the system context prior to login?
Topic:
Privacy & Security
SubTopic:
General
Tags:
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?
I am attempting to communicate over serial with a USB-C device and an M-Series iPad. I have proven the device to communicate as expected (baud rate, parity, etc) via a Swift app on Mac using a third party library (IOKit) that utilizes the AppleUSBACM (v5.0.0) driver on macOS. I am looking to recreate this communication via iPadOS and a custom DriverKit driver that provides this same interface. There is not an example from Apple for serial communication and DriverKit but there is a couple for communicating from an app to the dext, and for other networking examples. There are also other mentions in WWDC videos but they are incomplete and do not provide the needed structure. Communicating between a driver extension and a client app Connecting a network driver Bring your driver to iPad with DriverKit System Extensions and DriverKit My question revolves around architecture and how to set up a driver for these needs. I have gotten the examples to run and understand what is needed for entitlements and other local si
I'm going to take advantage of this thread to answer a question about this topic: When we do not use HardwareBound, is it still considered Managed Device Attestation? Will the Certificate be requested successfully via ACME? Will the Attestation be valid?
Topic:
Business & Education
SubTopic:
Device Management
Tags:
The AllowAllAppsAccess key is for macOS only. It only works for ACME payloads if HardwareBound is false. On macOS there are two keychain technologies. The older file-based keychain supports AllowAllAppsAccess but does not support hardware-bound keys. You can see items in the file-based keychain using the Keychain Access app. Third party apps can access these items if they were installed with AllowAllAppsAccess set to true. The newer data protection keychain supports hardware-bound keys, and does not support AllowAllAppsAccess. Third party apps and processes cannot access the identities that device management installs into the data protection keychain (with one exception for VPN extensions). When installing an ACME payload on macOS it decides which keychain to use based upon the value of HardwareBound. Other Apple OSes only have a data protection keychain and do not have a file-based keychain, so all items go into the data protection keychain.
Topic:
Business & Education
SubTopic:
Device Management
Tags:
Hi, I'm looking into ACME Managed Deice Attestation and was wondering about one of the values in the payload - AllowAllAppsAccess. From the documentation: If true, all apps have access to the private key but what is the case that you would have this set to true? seems like it opens up the device to potentially malicious software. Also, if this were set to true, how would an app access this private key when it is stored in the Secure Enclave? is there a specific tag that it is stored with?
Your ACME server should follow the ACME RFC 8555 section 7.4.2, which states: The default format of the certificate is application/pem-certificate-chain (see Section 9). Section 9.1 gives more detail on that. You wrote: The certificate is issued by an internal CA and the correct root certificate is in the device's trusted certs. It's not strictly necessary for the device to trust the CA that is issuing the cert since the device is not acting as a relying party. It's just installing the cert that the ACME server provided. It's only once the device uses the resulting identity that a relying party must trust the CA. The device does need to trust the cert that the ACME server uses to authenticate itself, but that's not necessarily the same as trusting the CA that the ACME server uses to issue certs.
Topic:
Business & Education
SubTopic:
Device Management
Tags: