Current Apple ACME Profile does not support EAB. Do you have any plan to support it?
Search results for
ACME
78 results found
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
I'm curious about suggested workflows for a 3rd party ACME server handling a request for a managed device. Specifically, when the MDM server does not control the ACME server like it likely would when using the ACME payload for the MDM client identity. i.e., an organization with a CA that can distribute client identities using ACME; how should ACME servers validate the request is authorized? The server, of course, would be able to validate that the attestation is valid from Apple, but how would an ACME server validate that the request is authorized for a device? I would assume that the ACME server would use the ClientIdentifier key similarly to a SCEP challenge. And that identifier should be populated in MDM either as a static challenge or dynamically fetched by MDM from the ACME service? Or possibly that the ACME service would need a connection (i.e., through a restful API) to the MDM server to validate it is a device under manag
It seems like there are some mixed messages out there about what should be in OID 1.2.840.113635.100.8.11.1 in the attestation cert. Is it just a SHA256 hash of the nonce issued by the ACME server? The MDM profile yaml says: In the attestation certificate the value of the freshness code OID matches the nonce specified by the ACME server via the ACME protocol. I'm hoping the difficulty we're seeing is down to the certificate being created once (and not again for 7 days). Otherwise, we're not decoding/understanding the OID's contents properly. Thanks.
Hi allI am trying to Write a Serial/ACM driver for mac os Catalina Since all these kind of drivers has to be moved to User Space (as per wwdc 2019).I am new to kext/dext.In kext, for ACM data driver we created nub using IOModemSerialStreamSync class.In case of dext which class we will use for the same purpose?Thanks in advance.
I'm trying to implement ACME managed device attestation, I have ACME server code written in C# and I've been able to get all of the steps working except for the very last one - issuing the certificate. I so far have not been able to get the device to accept the certificate, the device logs show: Got certificate {length = ......} ACME request flow failed at step 9: Error Domain=NSOSStatusErrorDomain Code=-67673 failed to obtain certificate UserInfo={NSLocalizedDescription=failed to obtain certificate} The certificate is issued by an internal CA and the correct root certificate is in the device's trusted certs. I have tried returning the certificate chain as a file response or content response to the device as a application/pem-certificate-chain mime type (as outlined as the default in the ACME RFC), returning just the leaf certificate as PEM, returning the leaf certificate as DER with mime type application/pkix-cert, application/pkcs7-mime, application/x-pkcs12 or applicatio
We are testing the ACMECertificate payload in Mac 13.1 beta and getting this error. The same payload when sent to iOS works fine. Any help on this would be appreciated. Thanks. FB Raised: FB11736586 PayloadVersion 1 PayloadUUID 70e4b45e3c1e PayloadType Configuration PayloadOrganization NewComp PayloadIdentifier 4565353a3a84 PayloadDisplayName ACME PayloadRemovalDisallowed PayloadContent PayloadVersion 1 PayloadUUID f84ef110e39b PayloadType com.apple.security.acme PayloadOrganization NewComp PayloadIdentifier f84ef110e39b PayloadDisplayName ACME Configuration DirectoryURL https://acmeserver/acme/acme/directory ClientIdentifier test HardwareBound KeyType ECSECPrimeRandom KeySize 384 Subject 1.2.840.113549.1.9.1 test@test.com SubjectAltName KeyUsage 5 Attest
Finally got to the stage where the ACME certificate profile is successfully installed. However, the public key/certificate itself isn't appearing in the System Keychain. I'm not sure if this is normal or if it's an indication that something went wrong after the profile installation. Unfortunately, I didn't study the log detail at the time and I'm uncertain of how to retrieve those logs from two days ago for the ACME activities. Can anyone confirm that macOS 26 should be storing ACME-retrieved MDM profile-based certificates in the System Keychain? If they should be there, what can possibly go wrong? The most obvious issue I can see is that the ACME server has requested the certificate with two CN's, which comes from the MDM profile asking for the subject against CN and the OID (2.5.4.3). Both CN's are identical. I'm surprised the profile installed if something is wrong. At first, I assumed Apple had decided to stop installing the certificates into the System Keychain.
Topic:
Business & Education
SubTopic:
Device Management
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?
The step-ca demo server I was using didn't issue a Client Certificate if the Attest is set to false. Below ACME payload is verified to be working in iOS. PayloadVersion 1 PayloadUUID 70e4b45e3c1e PayloadType Configuration PayloadOrganization NewComp PayloadIdentifier 4565353a3a84 PayloadDisplayName ACME PayloadRemovalDisallowed PayloadContent PayloadVersion 1 PayloadUUID f84ef110e39b PayloadType com.apple.security.acme PayloadOrganization NewComp PayloadIdentifier f84ef110e39b PayloadDisplayName ACME Configuration DirectoryURL https://acmeserver/acme/acme/directory ClientIdentifier test HardwareBound KeyType ECSECPrimeRandom KeySize 384 Subject 1.2.840.113549.1.9.1 test@test.com SubjectAltName KeyUsage 5 Attest
Topic:
Business & Education
SubTopic:
Device Management
Tags:
Hello All, We are looking to implement the ACME protocol for our organization PKI and as of now, we are trying out the demo ACME server hosted here. So far, we had a minor piece of luck in getting it to work properly twice, but after that, it errors out every time. This is the payload we are using: <?xml version=1.0 encoding=UTF-8?> <!DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd> <plist version=1.0> <dict> <key>PayloadContent</key> <array> <dict> <key>ClientIdentifier</key> <string>123123123123123123123</string> <key>ExtendedKeyUsage</key> <array> <string>1.3.6.1.5.5.7.3.2</string&
Topic:
Business & Education
SubTopic:
Device Management
Tags:
wwdc2022-10143
Device Management
App Attest
Hello! I’m testing certificate issuance using a locally running Smallstep step-ca ACME server with the device-attest-01 challenge. I’ve created a custom MDM profile for this purpose. When I install the profile, the certificate is issued successfully, but it is not saved to the Keychain as stated in the documentation. I can only see the certificate via mdmclient or in the Wi-Fi settings dropdown menu. Is this expected behavior, or are there additional settings that need to be included in the MDM profile?
Topic:
Business & Education
SubTopic:
Device Management
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:
Will it be supported (soon)? I'm also testing the ACME certificate payload. Not receiving the attestation payload in the ACME request significantly reduces the utility of the payload. E.g. there's no evidence the key is protected, no assurance this is a known Apple device, etc.
Topic:
Business & Education
SubTopic:
Device Management
Tags:
Oy. Going over the UI again... target | app-name | build phases | link binary with libraries - 2 of the 3 packages/modules were missing. After adding them I got a clean build and it runs again. But now I remember how I got here in the first place: the Swift UI preview won't run. I'm signed into my Apple.com account so I have no idea what to do now. == PREVIEW UPDATE ERROR: PotentialCrashError: Update failed RecipeBook may have crashed. Check ~/Library/Logs/DiagnosticReports for any crash logs from your application. ================================== | RemoteHumanReadableError | | LoadingError: failed to load library at path /Users/acm/Library/Containers/com.logipath.home.recipebook.RecipeBook/Data/Document.1.preview-thunk.dylib: Optional(dlopen(/Users/acm/Library/Containers/com.logipath.home.recipebook.RecipeBook/Data/Document.1.preview-thunk.dylib, 0x0002): tried: '/Users/acm/Library/Developer/Xcode/DerivedData/RecipeBook-bbtjcxbeoiafanbqznopflogglmf/Build/Intermediates.noindex/Pre
Topic:
Developer Tools & Services
SubTopic:
General
Tags:
You're right that the ClientIdentifier can work similarly to the SCEP challenge. ClientIdentifier management systems amount to some kind of coordination between the ACME server and the system that's generating the configuration profile containing an ACME payload (usually the MDM server). There's many ways to arrange it: It could be that the ACME server and MDM server agree on some ClientIdentifier generation scheme based on increasing counters or timestamps, or the MDM server asks the ACME server to issue a ClientIdentifier to embed in the profile, or the MDM server generates them and the ACME server verifies them when a certificate is requested. But this is ultimately weak evidence. If the ClientIdentifier is fumbled at any step of the way, someone else could use it. That's why the only specifically recommended use is as a rate limiting system, so that the ACME server can quickly reject clients that don't have valid ClientIdentifiers. So how does the ACME
Topic:
Business & Education
SubTopic:
Device Management
Tags: