Hi all,
Working on a personal-use kernel extension (not for distribution, just my own Mac) and hitting a wall between Reduced Security and notarization. A lot of existing threads on this are from 2018–2022, so hoping someone can confirm what's still current.
Setup: Apple Silicon, macOS 27 (Golden Gate beta) Boot Security Policy: Reduced Security with "Allow user management of kernel extensions from identified developers" enabled (confirmed via bputil -d) Standard $99/year Developer Program membership Kext signed with a standard Developer ID Application cert (via normal CSR through Keychain Access)
What happened: codesign -dvvv shows a clean signature — valid Authority chain, correct TeamIdentifier, timestamped. No issues. But kmutil load -p rejects it:
Authenticating extension failed: Bad code signature
I understood from an older DTS reply that notarization was the missing piece, so I ran it through notarytool. Upload/auth succeeded, but the result came back Invalid:
{ "severity": "error", "message": "The binary is not signed with a valid Developer ID certificate.", "architecture": "arm64e" }
Question: Is a standard Developer ID Application cert genuinely insufficient for kext notarization, and is the kext-signing entitlement (via /contact/kext/) still the only way to get a cert with the right extension (OID 1.2.840.113635.100.6.1.18)? Or has this changed for personal use recently? Apple's own Contact page for that form says: "You don't need to request a certificate to sign your kernel extension for personal use... signature checking can be disabled as described in the SIP Guide." That implies Reduced Security + personal kext shouldn't need the special cert — but my results suggest otherwise. Am I missing a step, or is there a documentation gap?
Happy to share kmutil print-diagnostics output if useful. Thanks!
Working on a personal-use kernel extension (not for distribution, just my own Mac) and hitting a wall between Reduced Security and notarization.
First, a broad clarification. The point of notarization is to allow for broader distribution, so you shouldn't really be notarizing personal products.
Question: Is a standard Developer ID Application cert genuinely insufficient for kext notarization?
Yes, that's correct and always has been.
and is the kext-signing entitlement (via /contact/kext/) still the only way to get a cert with the right extension (OID 1.2.840.113635.100.6.1.18)?
Yes, however, we've never approved KEXT signing from "personal" use and, in fact, it's only ever been granted to corporate (not individual) accounts. More to the point, at this point KEXT development has been deprecated long enough that any request is unlikely to be approved.
Or has this changed for personal use recently?
Nothing on the signing side has really changed.
Apple's own Contact page for that form says: "You don't need to request a certificate to sign your kernel extension for personal use... signature checking can be disabled as described in the SIP Guide." That implies Reduced Security + personal kext shouldn't need the special cert — but my results suggest otherwise. Am I missing a step, or is there a documentation gap?
That link is somewhat out of date. The new process is documented here and requires:
-
Disabling SIP.
-
Booting into recoveryOS and switching security policy control to "Permissive Security".
From that document:
Permissive Security: This policy level supports users that are building, signing, and booting their own custom XNU kernels. System Integrity Protection (SIP) needs to be turned off before enabling Permissive Security Mode. For more information, see System Integrity Protection in Apple Platform Security.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
