Codesigning Kext with kext enabled certificate fails during kextload, "code signature invalid"
Asked Answered
C

1

9

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!

Crowl answered 9/10, 2014 at 16:12 Comment(0)
P
13

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)

Pickmeup answered 10/10, 2014 at 14:42 Comment(5)
Yeah so I had a shell script that was being ran that I forgot to update, but basically signed over my correct signature. So I was signing correctly, but then the shell script would just sign with the invalid cert right over it haha. Just was not on the ball yesterday – Crowl
Apparently kext signing is not available anymore for new certificates... those who already have them, enjoy! #26672385 – Interpellate
@Interpellate as far as I know, kext signing was never enabled on Developer ID certificates by default. Kext signature checking was introduced with OS X 10.9, and my clients requested the kext-enabled Developer ID when 10.9 was still in beta. – Pickmeup
@Pickmeup I can't tell for sure. According Apple's documentation in WWDC 2013 it could be requested through Apple Developer Portal with the standard procedure. The Developer ID for Applications also included the permission for kexts – Interpellate
@Interpellate This hasn't changed since it was introduced. The form is here (via ling from the developer ID page): developer.apple.com/contact/kext Once you're approved, you can re-request your Developer ID for Applications, which will then be compatible with the kext signing requirements. – Pickmeup

© 2022 - 2024 β€” McMap. All rights reserved.