I have my executable binary signed using codesign command and verify successfully on my development machine where my private key and signing certificate are in the keychain. However when I copy my executable to my testing machine and try to do "codesign -dvvv", it returns code object is not signed. My signing certificate is issued by VeriSign root ca. The CA is installed on my testing machine but I am not able to verify executable. Am I missing something?
Yes, you are missing something.
The "Gatekeeper" code signing in Mac OS X only honors signatures which chain back to Apple's CA through developer certificates issued by Apple as part of the Mac OS X developer program. A Verisign code signing certificate is not an acceptable substitute.
Related
I have developed an app in mac osx.
the app runs properly locally.
Now I'm trying to distribute the app internally with other peers. ( without having to go thru the app store )
I created a self signing cert.
I installed the cert and add it to trusted ( it is a ROOT cert )
I then signed the app with my self signing certificate.
all is good. the app still runs properly locally after being signed ( I verified that it is indeed signed )
My next step was to upload the signed app to s3. after downloading the app. the os security settings prevented the launch of the downloaded app - ( unidentified developer) - this is the same machine that has the cert installed..
so I'm not sure why I still receive the unidentified developer error? my assumption is if I the cert is present ( and trusted ) in the target machine - the os should allow the app to go through.
is this assumption is incorrect - if so what values does the self sign add ( I guess nothing ) . if it is not true , I maybe have the wrong cert ?
You receive the error after downloading your .app because whatever you used to download it (your web browser?) has set the quarantine attribute, which forces Gatekeeper to kick in. You can read more here.
Gatekeeper is looking for a "developer" certificate, one that is issued by Apple (and has the Apple Root CA as it's root certificate). It's not just checking that the root CA is trusted.
e.g. codesign -dvvvv /Applications/Google\ Chrome.app/
Authority=Developer ID Application: Google, Inc. (EQHXZ8M8AV)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Your self-signed certificate is not an Apple-issued developer certificate, so Gatekeeper won't recognize it.
This is the first time I have ever tried to sign a kernel extension, so I am open to the possibility that I'm doing it wrong.
I requested a kernel signing certificate from Apple. I was required to fill out a form that demonstrated that I really needed to create an in-kernel driver, rather than a user space driver that talked to an IOUserClient.
$ sudo kextutil FL2000.kext/
Password:
Notice: /Library/Extensions/FL2000.kext has debug properties set.
Diagnostics for /Library/Extensions/FL2000.kext:
Code Signing Failure: code signature is invalid
Untrusted kexts are not allowed
ERROR: invalid signature for com.frescologic.FL2000, will not load
It doesn't load at boot - it needs to because it is a graphics driver.
$ codesign --verify -vvvv FL2000.kext/
FL2000.kext/: valid on disk
FL2000.kext/: satisfies its Designated Requirement
$ codesign --display -vvvv FL2000.kext/
Executable=/Library/Extensions/FL2000.kext/Contents/MacOS/FL2000
Identifier=com.frescologic.FL2000
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=1590 flags=0x0(none) hashes=44+3 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=83a0328f9af971484b7e30c8d04e68a96dee72c1
CandidateCDHash sha256=cd6c72d17f00d2eed36078eece6a5b536c482772
Hash choices=sha1,sha256
Page size=4096
CDHash=cd6c72d17f00d2eed36078eece6a5b536c482772
Signature size=4693
Authority=Mac Developer: Michael Crawford (YU8CSARZFD)
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Signed Time=Nov 10, 2017, 1:10:07 PM
Info.plist entries=20
TeamIdentifier=444JK52Q93
Sealed Resources version=2 rules=13 files=2
Internal requirements count=1 size=184
Help me O Stackoverflow-Wan. You're my only hope!
I should have spotted this in your codesign output, but your comments make it clear: the problem is with the certificate you are using. Apple issues 4 kinds of Mac codesigning certificates:
"Mac Developer" certificates are for signing apps destined for the Mac App Store during the development phase. This is the type of certificate you appeared to be trying to use for signing a kext. This won't work. It will sign it OK, but kextd etc. won't accept the signature.
"Developer ID Application" certificates are for signing apps which will be distributed outside the App Store. A special variant of this type of certificate includes the certificate extension "( 1.2.840.113635.100.6.1.18 )" - only with this extension, it becomes possible to sign kexts such that they are accepted by macOS.
"Developer ID Installer" certificates are for signing Installer .pkg files/bundles. If you are distributing an app via a DMG or ZIP file, you shouldn't need this, but if you need an installer, possibly because what you're distributing isn't an app, but a kext or system service, then you should create an installer package and sign that with such a certificate.
"Mac Distribution" certificates are what you use to sign the build of an app before submitting it to the Mac App Store. These are also irrelevant to kext signing.
Presumably for security reasons, certificate types 2-4 are only issued to Team Agents in an Apple Developer account. Lowly developers are only given "Mac Developer" certificates, which are intended to be purely temporary, so they're not very security-relevant.
So to summarise, your problem is that you're using a "Mac Developer" certificate to sign a kext. You need to use a "Developer ID Application" certificate instead, specifically one that was issued after the development team was granted kext signing privileges by Apple. If you haven't applied for kext signing privileges, you can do so using this form. (It sounds like you have done so previously, but I'm pointing it out for the benefit of people in the same situation who might stumble across this in the future.)
Apple seems to restrict some OS X APIs (e.g. sandboxing) to applications that are codesigned by a trusted certificate, e.g. one issued to members of the paid Mac Developer program.
How does OS X treat applications that are codesigned with a self-signed (or a development) certificate?
Will those features/APIs be available, and the only difference be that users with the default Gatekeeper settings cannot (easily) launch such an application?
Will they be treated just like unsigned apps in every way (entitlements and sandboxing disabled, warning for Gatekeeper users)?
Or will a self-signed certificate be considered an error, and the app will not launch at all regardless of the user's Gatekeeper settings?
AFAIK, apps that aren't code-signed with a certificate that Gatekeeper accepts, would be treated as unsigned. I don't know about access to specific features and API.
But you can make your self-signed cert acceptable to the Gatekeeper. If you sign your code using certificates that weren't issued by Apple, every machine you want to run that code as signed, would have to (a) have your certificate installed, and (b) have policies set via spctl command that tell the Gatekeeper to allow executing and/or installing code signed by that cert. This part has been tested and verified on Mavericks.
It is more difficult with kernel extensions. I'm still working on that. :-)
I'm trying to minimize the cost of code-signing certificates necessary to develop a program for Mac OS X and Windows. As far as I can tell, I can't use a 3rd party certificate to sign my OS X program and have it get past GateKeeper, as indicated here.
Can I go the other way and use an Apple Developer certificate to sign the Windows version of my program?
Also related: Non-Apple Issued Code Signing Certificate: Can it Work with Mac OS 10.8 Gatekeeper?
Had the same idea some time ago. But I don't think it's possible, because the Apple Developer Certificate is verified (signed) by Apple and I don't think that the Apple Root Certificate is installed on average Windows machines.
Hi Joe LTNS I check the status of this question every time my Comodo CS certificate comes up for renewal, because hassle/money vs Apple's
Alas, Apple's CA still not in Windows golden list AFAIK. I checked Apple Software Update under Win10 and its cert issuer is Verisign.
OT Not a cert expert here, but if Apple concocted an intermediate cert that both the CA and Apple could vouch/revoke, not a few Windows devs would pony up for Apple's $100 Dev program for that su-weet 5 year non-MAS codesign cert (and probably dabble in App Store/ios development as a bonus)
Here is a detailed article about it: http://luminaryapps.com/blog/code-signing-and-packaging-windows-apps-on-a-mac/ and more generally about code-signing Windows apps on a Mac. I quote:
Now you need to get a Windows developer certificate. Unfortunately you can't use your Apple certificate (well, actually you can, but it doesn't help because Apple isn't a certificate authority that Windows recognizes). Here is a list of root certificate authorities recognized by Windows.
So this seems to confirm the other answers.
I build an OSX app which is distributed as a DMG outside of the Mac App Store, and I'd like to continue to have it be that way once Gatekeeper enforcement begins.
From studying code signing documentation, it looks like the recommended approach is to get a "Developer ID" certificate and use that to codesign. However, you must be a registered OSX developer and pay Apple $99 each year. I already have a certificate from a recognized CA, and I would like to use it with codesign. I found documentation on how to do this, but I cannot tell whether Gatekeeper will allow applications signed using certs issued by other CAs, not Apple.
Does anyone know?
Gatekeeper only recognizes apps signed with Developer ID, not just any signature. See this which also explains how to test Gatekeeper functionality under Lion.
The point is that if Apple owns the certificate authority, they can revoke the certificate if your app turns out to be a trojan or something.