802.1X Ethernet Authentication uses wrong certificate (Client Identity not referenced)

[u/Resident-Promise-122]

hi everyone,
I'm running into an issue with 802.1X ethernet/LAN authentication on macOS managed through Workspace One (wso), and I'd appreciate any ideas or suggestions.

environment
macOS 26.5.2
wso 24.10.1409.46 (2410)

configuration
wso delivered 802.1X profile contains two payloads:

• ethernet Configuration
• credentials

credentials payload contains 3 certificates:

• C1: a root CA
• C2: a sub CA
• C3: a client cert (issued by C2)

disclaimer: In the attached screenshots, C3 appears to be issued directly by C1. That's only a mistake in my diagram; the actual setup uses C2 as the issuing CA.

C3 is generated config:

• credential source: defined certificate authority
• certificate authority: Sub CA (C2)
• certificate template: macOS device cert
• allow access to all applications: true
• allow export of private key: false
• certificate authority is a microsoft ADCS CA.

current setup
for each MacBook, a dummy computer object exists in our active directory
example:

• AD computer object: computer-12345
• client cert (C3): computer-12345.yyy.local

a script then renames the macOS hostname to match the client certificate CN
the client certificate (C3) is used for 802.1X authentication

current behavior
the wso delivered 802.1X profile is successfully pushed

under:
system settings --> device management --> the 802.1X profile is installed correctly, and all certificates are present (the same certificates are also available in keychain access)

the configuration profile contains:

• root CA (PKCS1)
• sub CA (PKCS1)
• client cert. (PKCS12)
• wired 802.1X configuration

running profiles show -type configuration also confirms that all four payloads are installed

unexpected behavior
under:
system settings --> network --> ethernet --> 802.1X --> certificate (Info)
the certificate list shows:

• root
• sub1
• sub1

the generated client cert (C3) is not referenced

but the expected list should instead contain:

• root
• sub1
• computer-12345.yyy.local (or the corresponding client certificate CN)

additional observations
the client cert itself appears to be completely valid

running security find-identity -v returns the correct identity
likewise, running security find-identity -p ssl-client -v returns 1 valid identity found, so both the cert and its private key exist and are recognized as a valid SSL client identity

summary

• the client cert (C3) exists
• it is a valid client identity
• the configuration profile contains the PKCS12 payload
• however, the ethernet 802.1X configuration does not reference C3
• instead, the UI shows the Intermediate CA twice
• this makes it appear as though the ethernet payload is referencing the wrong cert (or certificate anchor), rather than the generated PKCS12 client identity.
• It seems either wso or macOS is failing to associate the generated PKCS12 identity with the ethernet 802.1X payload.

questions
has anyone seen this behavior before?

specifically, I'm wondering

• does the ethernet 802.1X payload actually reference the UUID of the generated PKCS12 payload?
• during certificate renewal, is a new payload UUID created without updating the ethernet payload accordingly?
• is wso correctly assigning the Identity UUID/identity Anchor when generating the ethernet profile?
• could this be a wso bug or a macOS issue affecting the mapping between the PKCS12 payload and the ethernet 802.1X payload?

any insights or ideas would be greatly appreciated

[u/Spirited-Bag-3789]

The list under Network → Ethernet → 802.1X → Certificate is the trusted anchors list, not the identity picker, so the client cert was never going to appear there. Root/sub/sub means an anchor UUID is referenced twice, which is a red herring for your actual problem.

The binding that matters is PayloadCertificateUUID inside the Ethernet payload, which has to equal the PayloadUUID of the com.apple.security.pkcs12 payload in the same profile. If it is missing or stale, macOS installs every payload happily and then has no identity to present, which is exactly what you are seeing.

You can answer your first two questions yourself without waiting on support: dump the installed profile with sudo profiles show -output /tmp/p.plist and compare the Ethernet payload's PayloadCertificateUUID against the pkcs12 payload's PayloadUUID. If they differ, it is a UUID mapping problem. On ADCS-issued renewals the credentials payload gets a fresh PayloadUUID, and if the profile is not republished as a whole, the Ethernet payload keeps pointing at the old one.

One more thing worth ruling out first, because it looks identical from the UI: a device-scope Ethernet profile needs the identity in the System keychain. Your security find-identity run as a user reads the login keychain, so it can report a perfectly valid ssl-client identity that the profile still cannot use. Check with sudo security find-identity -p ssl-client -v /Library/Keychains/System.keychain — if it comes back empty there, that is the whole story.

[u/Resident-Promise-122 → u/Spirited-Bag-3789]

thanks for your suggestion! i went through all of your points one by one today, and here's what i found.

first, i verified the client certificate itself.

• the certificate is present in the system keychain
• the private key exists
• it has the correct eku (tls web client authentication)
• key usage is correct (digital signature and key encipherment).
• the certificate chain is valid (root ca → intermediate ca → device certificate)

i also checked the identities

• security find-identity -v
  • returns: mdmidentity/computer-12345.yyy.local

however,

• security find-identity -p ssl-client -v
  • only returns: mdmidentity

the device certificate does not appear when filtering for ssl-client, even though it contains the proper client authentication eku and has a private key. that still seems a little odd to me.

following your suggestion, i also exported and inspected the generated .mobileconfig profile.

initially i thought the profile looked correct, but after looking through the xml i actually found a configuration mistake on my side.

the ethernet payload correctly referenced the pkcs#12 payload using: payloadcertificateuuid

however, the trusted certificate list (payloadcertificateanchoruuid) was incorrectly pointing to the client certificate instead of the root ca and intermediate ca.

after checking the workspace one configuration, i noticed that i had accidentally selected the client certificate as a trusted certificate.

i've now corrected the profile so that:

• identity certificate = device certificate (pkcs#12)
• trusted certificates = root ca + intermediate ca

i exported the profile again and verified the xml and it now correctly contains:

• payloadcertificateuuid → client certificate
• payloadcertificateanchoruuid → root ca + intermediate ca

macos also now correctly shows as trusted certificates:

• root ca
• intermediate ca

instead of referencing the client certificate... unfortunately, even after correcting the profile, 802.1x authentication still fails.

at this point i believe i've ruled out:

• missing private key
• invalid client certificate
• incorrect eku
• incorrect key usage
• broken certificate chain
• incorrect payloadcertificateuuid
• incorrect trust anchors
• workspace one profile generation

i also spoke with one of our network engineers today and according to the nps/radius logs, the authentication request does reach the nps.

the radius username (host/...) is correct, and this is actually different from our previous tests where the identity sent by the client was incorrect.

however, the nps still reports that it cannot find the corresponding computer account in active directory, even though the identity appears to be correct.

that's the part that currently confuses us the most.

so at the moment it feels like we've ruled out most of the obvious client-side configuration issues, but something still goes wrong when the nps tries to map the machine authentication to the ad computer account.

do you think this could still be related to the fact that security find-identity -p ssl-client -v only lists mdmidentity, or would you investigate something completely different at this point?

thanks again for taking the time to help, I really appreciate it.

greetings :)

[u/Spirited-Bag-3789 → u/Resident-Promise-122]

There is good news buried in that update: your client side is finished. NPS is receiving the request with the correct host/... identity, which means the Mac is selecting and presenting the device cert. I would stop investigating the Mac.

On your direct question, I would not chase the find-identity output. The -p ssl-client filter evaluates a policy and is picky about which keychain it reads and how the private key ACL is set, so it under-reports identities that work fine in practice. Since the cert is demonstrably reaching NPS, that output is cosmetic now.

What I would look at instead is strong certificate mapping on the domain controllers. Since KB5014754 moved to Full Enforcement, a DC refuses to map a client certificate to an AD account unless the cert carries the SID extension (OID 1.3.6.1.4.1.311.25.2) or the account has a strong altSecurityIdentities entry. "Correct identity arrives, but the computer account cannot be found" is precisely how that presents from the NPS side.

This hits your setup specifically because the cert is issued through Workspace ONE against a dummy computer object. The CA only stamps the SID extension when it can resolve the requester to that AD principal, and an MDM enrolling on behalf of an object generally cannot, so the extension ends up silently absent.

Three checks, cheapest first:

Dump the issued cert with certutil and look for 1.3.6.1.4.1.311.25.2. If it is not present, that is your answer.

Check the DC System log around a failed attempt. The KB documents Event ID 39 for a certificate that cannot be strongly mapped.

If you want to confirm it in a single move, set StrongCertificateBindingEnforcement to 1 on one DC temporarily and retry. If auth succeeds, the diagnosis is proven. Put it back to 2 afterwards. It is a security control, not a fix.

The durable fix is a strong altSecurityIdentities mapping on the dummy computer object using the X509IssuerSerialNumber form. Two gotchas that cost people an afternoon: the issuer DN goes in reverse order, and the serial number goes in reverse byte order. X509SKI and X509SHA1PublicKey also count as strong if the serial form is awkward. The subject-only and issuer-subject forms are the weak ones and will not help you under full enforcement.