ACME

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.

Log in iPAD17 (section A) DExt's entry points are called in this sample within <1sec after plugin (1 or 3 times). 2 of 3 times those are called >5 sec later. Here are messages change handling USB2<=>USB3 (the gadget is actually USB2) efault 09:42:58.561261+0900 kernel IOAccessoryManagerUSBC::setLDCMPin(): ldcmPin: 2 [Trace] default 09:42:58.561335+0900 kernel IOAccessoryManagerUSBC::setLDCMPin(): ldcmPin: 2 [Trace] default 09:42:58.561851+0900 kernel IOPort::setLDCMState(): [Port-USB-C@1] setLDCMState: 3 [Measure] default 09:42:58.683860+0900 kernel wlan0:com.apple.p2p: reportDataPathEvents[6702]: WiFi default 09:42:58.747963+0900 kernel IOPortTransportState::handleStateChange(): [Port-USB-C@1: USB3] Handling state change... default 09:42:58.748028+0900 kernel IOServiceNotificationManager::sendMessages(): [Port-USB-C@1/USB3] Sending 2 message(s)... (m_propertyChanged: YES) default 09:42:58.748210+0900 kernel IOPortTransportState::handleStateChange(): [Port-USB-C@1: USB2] Handling state change... d

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.

Thank you. I think this is an issue that only occurs during the development stage, if you don't have the server side validation step in place when you start testing the previous steps. So, I extracted the attestation certificate (to view with the UI) which had a timestamp of Mon May 5th at 21:18 GMT+1. My Mac is sending this same certificate for every request. I take it then that this won't change until there is a change to the information it contains, e.g. a software update, or it expires? I can't match the OID to any of the nonces that the ACME server sent that day. I'm not sure why there is such a discrepancy between the certificate start timestamp and when the actual transactions took place. I see a nonce generated at 19:16 and then another at 23:24. Is there something about the encoding of the OID that we're missing? The hex we see in the certificate, is it directly the SHA256 hash of the relevant nonce? So, if the nonce sent was: SS2sSl1PtspvFZ08kNtzKd Then the hex I should see in the certifica

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.

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

I have a USB composite device with multiple interfaces that support CDC-ACM UARTs. My custom driver (.dext) loads and works for a single-channel USB-CDC-CCM device with these entries in the Info.plist: Two different answers here: (1) The IOKitPersonalities dictionary is basically a list* of specific match criteria, each of which is treated independently by the kernel. So the (general) way you match the same driver against different hardware configurations is by defining a separate personality dictionary for each configuration. See this Info.plist for a concrete example of this: /System/Library/DriverExtensions/com.apple.AppleUserHIDDrivers.dext/Info.plist Note that IOKitPersonalities is defined as a dictionary (instead of an array) because the top-level key value ends up being used in the IORegistry (it's returned by IORegistryEntryGetName), and using a dictionary ensures that the entry names are unambiguous within a given driver bundle. The keys themselves are not meaningful, nor does entry order ma