I'm trying to sign a Mac app but i'm having problems on 10.9.5+. I've generated a new v2 certificate (Developer ID), and signed the app with Xcode, and verified that the cert is indeed v2, but i still get the Gatekeeper warning. I created a brand new test app, thinking maybe some old project setting might have been causing an issue, but same problem.
Here is what codesign tells me about the app (removing some identifying values):
codesign -dvvv NewApp.app/
Executable=/Users/XXXXXXXXXXX/Projects/Tests/NewApp/Releases/NewApp.app/Contents/MacOS/NewApp
Identifier=com.XXXXXXXXXXX.NewApp
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=228 flags=0x0(none) hashes=4+3 location=embedded
Hash type=sha1 size=20
CDHash=732ec1e6c4f2ae7b2a0e2da5f92693c27a8cbf0e
Signature size=8523
Authority=Developer ID Application: XXXXXXXXXXX (XXXXXXXXXXX)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Sep 30, 2014, 11:04:31 AM
Info.plist entries=21
TeamIdentifier=SFM7SSUSXP
Sealed Resources version=2 rules=12 files=1
Internal requirements count=1 size=216
But this is what spectl tells me:
spctl -a -t exec -vv --verbose NewApp.app/
NewApp.app/: rejected
source=Developer ID
origin=Developer ID Application: XXXXXXXXXXX (XXXXXXXXXXX)
What gives? Is there any other feedback i can dig for that will tell me why its rejected?
[UPDATE}
Not building any frameworks in my app, so these posts suggested below didn't much much. I did come across that RB App Checker app, and ran it against my very simple app (brand new app created with XCode6). I get this result:
Evaluating the application “NewApp”.
The application was signed by “Apple Root CA”, “Developer ID Application: XXXXXXXXXX (XXXXXXXXXX)”.
Both the verified timestamp and the signing-time are: Oct 2, 2014, 10:50:08 AM.
The object code format is “bundle with Mach-O thin (x86_64)”.
Both bundle and signing identifiers are “ XXXXXXXXXX.NewApp”.
The signature specifies explicit requirements. 
The signature specifies resource rules (v1). 
The signature specifies resource rules (v2). 
Requirements and resources validate correctly.
The code signature contains 3 certificates. 
Certificate “Apple Root CA”: 
Your keychain contains this trusted root certificate.
Will expire on Feb 9, 2035.
Certificate “Developer ID Certification Authority”: 
Will expire on Feb 1, 2027.
Certificate “Developer ID Application: XXXXXXXXXX (XXXXXXXXXX)”: 
Will expire on Oct 1, 2019.
SHA1 fingerprint: “XXXXXXXXXX”.
The application is probably from an authorized Apple Developer.
The code signature contains entitlements. 
The application is not sandboxed.
Is the fact that there is a v1 and v2 resource rule in there causing the issue?
I was having the same problem and the reason was that my Gatekeeper setting was changed to allow "Mac App store" only.
I think I did this change from command line, while trying various hints from internet and I was not really aware of doing it.
Changing Gatekeeper setting to "Mac App store and identified developers" fixed the problem.
I actually resolved the issue after getting very sparse help from Apple tech support. I happened to catch an off-hand comment in a WWDC video regarding "flat" installers. Looking that up, it seems that you can only sign a flat installer package with the actual Installer Developer ID. If you try to sign a non-flat installer package, you can only sign it with the Application Developer ID, which succeeds, but doesn't actually work with Gatekeeper.
So.... I figured out that my installer was non-flat, cause it was targeting an pretty old OS (10.4). I'm using PackageMaker, and once i set the target OS to be 10.5 or newer, it started building a flat installer package, which i was then able to sign correctly (with the Installer Developer ID).
Related
We have been re-signing an app developed and signed with a sub-contractor’s Apple Enterprise Developer Distribution certificate, with our Apple Enterprise Developer Distribution certificate for MDM distribution through Intune. The sub-contractor says due to a change in Apple policy, they now need to sign the app with an Apple Developer Distribution certificate. During a test, we could re-sign the .ipa file with our Apple Enterprise Developer Distribution certificate. However, when we attempt to install the app on a managed device, we get an error that says, “Unable to install [app name] This app cannot be installed because its integrity could not be verified.”
When the sub-contractor was signing with an Apple Enterprise Developer Distribution certificate, our bundle ID could match theirs. In the test of the new process, were unable to use a bundle ID that matches the one the sub-contractor is using. If we try to use the same bundle ID, we get an error saying “An App ID with identifier [bundle ID] is not available. Please use another string.” Would not using the same bundle ID be causing the integrity verification issue?
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.)
Question:
Please note before reading this that: "Tell them to go to System preferences > Security & privacy and allow 3rd party applications to run. Is not an acceptable solve for this issue.
I have created an .app That has been signed with a valid Mac Developer certificate. Yet downloading it from the internet & running still throws the security prompt:
App can't be opened because it is from an unidentified developer
This is the codesign -vvv terminal dump for the .app:
Executable=/Users/me/Desktop/ADRA.app/Contents/MacOS/ADRA
Identifier=unity.Company.ADRA NSW 2016
Format=app bundle with Mach-O thin (i386)
CodeDirectory v=20200 size=178145 flags=0x0(none) hashes=5561+3 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=79ecf88721d6387749c1f6b10355c3683ef20eb2
CandidateCDHash sha256=0799e968a18a663a0c08d26d3fb7826017ce5a3a
Hash choices=sha1,sha256
CDHash=0799e968a18a663a0c08d26d3fb7826017ce5a3a
Signature size=4739
Authority=3rd Party Mac Developer Application: Company Pty Ltd (NH73TNDB28)
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Signed Time=20 Apr 2017, 2:46:12 PM
Info.plist entries=14
TeamIdentifier=NH73TNDB28
Sealed Resources version=2 rules=12 files=138
Internal requirements count=1 size=224
I don't understand why this does not pass Gatekeeper? Is there something missing? Does Apple require further payments / bribes or something?
Update 1:
#TheDarkKnight has suggested that I am using the incorrect certificate to sign the .app. Looks as though they are correct, so I went to create a new Developer ID Application certificate but apparently because I am not an 'Agent' in the group account, so I now have to wait until the 'Agent' creates one for me - seems backwards, is there no other way around waiting for the 'Agent' to make this for me?
(in Xcode) If the "Developer ID" radio button is greyed out you probably have a group account. These types of accounts only allow for the "Agent" role to create Developer IDs. Contact the person who created your group Apple Developer Account if you get stuck here.
https://developer.mozilla.org/en-US/docs/Mozilla/Signing_Mozilla_apps_for_Mac_OS_X
Update 2:
So I finally got my new cert today, re-signed the .app, downloaded it from the server ran and STILL GOT THE ERROR MESSAGE. The authority seems to be correct now:
Executable=/Users/me/Downloads/ADRA.app/Contents/MacOS/ADRA
Identifier=com.company.adra
Format=app bundle with Mach-O thin (i386)
CodeDirectory v=20200 size=178133 flags=0x0(none) hashes=5561+3 location=embedded
Library validation warning=OS X SDK version before 10.9 does not support Library Validation
OSPlatform=36
OSSDKVersion=657408
OSVersionMin=656896
Hash type=sha256 size=32
CandidateCDHash sha1=90d2a54162d6d018bf4f7602d7707c8e8e522fc6
CandidateCDHash sha256=dadfe5203d1367ea776f9501025dbd4ce751ee30
Hash choices=sha1,sha256
Page size=4096
CDHash=dadfe5203d1367ea776f9501025dbd4ce751ee30
Signature size=8930
Authority=Developer ID Application: Company Pty Ltd (NH73TNDB28)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=10 May 2017, 3:36:51 pm
Info.plist entries=14
TeamIdentifier=NH73TNDB28
Sealed Resources version=2 rules=12 files=138
Internal requirements count=1 size=184
I am only signing the .app is there anything else that I have to do to make this work? Is there a time period I have to wait before this will work?
Apple supply different certificates for different purposes.
If you look at a signature for an app downloaded from the App Store, you'll see that they usually contain the Common Name: Apple Mac OS Application Signing, as Apple re-sign applications that they distribute through the store.
For 3rd party developers that distribute via alternative streams, their Application certificates usually have a Common Name that begins with: "Developer ID Application...".
Note that other 3rd party certificates are available, such as an Installer certificate for signing installer packages, whose Common Name begins with "Developer ID Installer...".
The privilege of being able to sign a product with a certificate must be limited and tightly controlled.
Should a copy of your certificate be leaked, it can be used for nefarious purposes, such as distribution of malware, as was the case with KeRanger, which infected the Transmission BitTorrent application.
If you suspect a leaked certificate that you own, you need to revoke it, which can be initiated from your Apple Developer account.
So, Apple limits the creation of certificates to the Agent, as there can be only one registered with an Apple Developer account and is the person who has legally agreed to take responsibility for it.
I am developing an application that runs on OSX and uses the NEVPNManager for IKEv2 connections introduced in El Capitan. In order to setup/activate a VPN connection it requires the "Personal VPN" entitlement.
If I sign my application with a Development certificate it works as expected on my machine, or on others if they bypass Gatekeeper. However if I sign it with a Developer ID certificate the app fails to start. codesign -vvv and spctl -a say that there's nothing wrong with it's signature but in the system.log file I see this when I try to run the app.
Nov 19 11:00:01 taskgated[562]: no application identifier provided, can't use provisioning profiles [pid=22401]
Nov 19 11:00:01 taskgated[562]: killed com.myorg.myapp[pid 22401] because its use of the com.apple.developer.networking.vpn.api entitlement is not allowed (error code -67050)
Could the Personal VPN capability be forbidden for use outside the Mac App Store? If so it makes no sense as it does not use any Apple service.
UPDATE:
After talking to someone at Apple, it has become clear that the Personal VPN feature is not allowed to be used outside the App Store, thus it cannot be used along with a Developer ID certificate. Here is the list of which feature is allowed for which kind of code signing [the list here]
I know this question is old, but I wanted to provide an update. As of macOS 10.12 and XCode 8, Mac Apps signed with a Developer ID are allowed outside the Mac App Store. Apps signed in this way will run on both 10.11 and 10.12 without issue. This was a change I requested at WWDC 2016, which was implemented. You will see that the list OP linked to has been updated.
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.