So we have a certificate that allows us to sign kexts, but when we run > sudo kextload friendly.kext, it fails and we sign the kext we want, and to prove it's signed, here's some diagnostic output:
👉 codesign --verify -vvvv friendly.kext
friendly.kext: valid on disk
friendly.kext: satisfies its Designated Requirement
👉 spctl -a -vvvv friendly.kext
friendly.kext: accepted
source=Developer ID
origin=Developer ID Application: Friendly Corporation
/Library/Extensions
👉 codesign -dvvv friendly.kext
Executable=/Library/Extensions/friendly.kext/Contents/MacOS/friendly
Identifier=com.friendly.friendly
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=502 flags=0x0(none) hashes=18+3 location=embedded
Hash type=sha1 size=20
CDHash=a1e2bf8d53ea67c6cfe9fc3d6d2001fe56c838a7
Signature size=8528
Authority=Developer ID Application: Friendly Corporation
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Oct 9, 2014, 11:49:02 AM
Info.plist entries=21
TeamIdentifier=1234567890
Sealed Resources version=2 rules=12 files=1
Internal requirements count=1 size=180
👉 codesign --verify -vvvv friendly.kext
friendly.kext: valid on disk
friendly.kext: satisfies its Designated Requirement
It looks like it's signed properly; However, when I run > sudo kextutil -v friendly.kext :
Defaulting to kernel file '/System/Library/Kernels/kernel'
Diagnostics for /Library/Extensions/friendly.kext:
Code Signing Failure: code signature is invalid
/Library/Extensions/friendly.kext appears to be loadable (not including linkage for on-disk libraries).
ERROR: invalid signature for com.techsmith.friendly, will not load
I'm thinking either I downloaded the certificate wrong (we definitely got approved for kext signing), although I tried redownloading the certificate once before so that may not be the problem. Otherwise, it's the way that I'm signing. I'm thinking maybe it has something to do with the permissions I set on the kext before I sign them?
Has anybody seen this problem before?
Thanks in advance!
The kext signing certificate must have the extension "( 1.2.840.113635.100.6.1.18 )" listed - this is what designates it as a kext-enabled certificate. You can easily verify this by viewing it in Keychain Access.app. (it's listed near the bottom, below extension "( 1.2.840.113635.100.6.1.13 )" which I think is used for apps and thus present in all Developer ID certificates)
来源：https://stackoverflow.com/questions/26283158/codesigning-kext-with-kext-enabled-certificate-fails-during-kextload-code-sign