5

I'm signing an install4j installer for OSX, however OSX is rejecting it. The system log only reports that it was rejected, and spctl only reports that it was rejected, with no explanation. How can I determine why it was rejected?

user1009908
  • 1,390
  • 13
  • 22

1 Answers1

9

I presume you're talking about Gatekeeper not allowing your app to run after it's downloaded? Gatekeeper's rules aren't based on a list of rules to reject an app, they're based on a list of possible rules to accept an app, and if your app doesn't match any or those rules. This makes it hard to log e.g. why your app was rejected beyond "it didn't match any of the allow rules". Now, if you know which "allow" rule you expected to apply to it, you can try to debug it based on that, but Gatekeeper itself doesn't know this and hence isn't much help.

I'm assuming you want your app to be allowed under the "identified developer" rule? If so, there are a couple of tests to look for obvious problems: first, run codesign -vv --deep-verify /path/to/yourapp.app, and make sure it prints "valid on disk" and "satisfies its Designated Requirement" (and doesn't give any errors) -- if not, something's wrong with the signature or the contents of the app.

Second, run codesign -dvv /path/to/yourapp.app, and make sure it the data it lists includes:

Authority=Developer ID Application: [Your name/company here]
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Sealed Resources version=2 rules=[something] files=[something]

If the Authority list is different from that, you used the wrong certificate to sign it. If the Sealed Resources version is 1 or not listed, you signed it with an old version of OS X, and recent versions will reject the signature format.

Gordon Davisson
  • 118,432
  • 16
  • 123
  • 151
  • 1
    When running `codesign --verify`, I recommend also using the `--deep-verify` option, to make sure that any plug-ins, private frameworks, etc. are also properly signed. – JWWalker Mar 23 '15 at 23:16
  • @JWWalker Good idea; I've added it to my answer. – Gordon Davisson Mar 24 '15 at 00:28
  • Can you clarify the bit about the Authority list? The docs http://apple.co/1BMv0Te say " if your company already has a third-party signing identity that you use to sign code on other systems, you can use it with the OS X codesign command". Such a cert wouldn't include "Apple Root CA". Or is this Authority list something else? – user1009908 Mar 25 '15 at 19:18
  • @user1009908 You can sign with any code-signing certificate, but Gatekeeper's default rules only allow apps signed with Apple Developer ID certs. The reason for this is that Apple wants to be able to revoke the cert of anyone caught signing malware, and they can only do this if they're the issuing authority. – Gordon Davisson Mar 25 '15 at 22:52
  • Thank you, this really helped me out! I was trying to codesign on a 10.8 system, and although codesign had indicated success, Gatekeeper was still blocking it. The kicker was that `Sealed Resources` line – only after codesigning on a 10.9 system did it read as `Sealed Resources version=2`. Apple of course has little consideration for anyone not using the latest OS versions, and I did not find this caveat anywhere in their docs. Thanks for saving my sanity! – Dr Marble Apr 02 '15 at 18:53
  • @DrMarble: It's there, but you kind of have to look for it. See the ["Gatekeeper Changes in OS X 10.9.5 and Later" section of OS X Code Signing in Depth](https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG205). – Gordon Davisson Apr 02 '15 at 19:05
  • @GordonDavisson Ah, there it is, tucked halfway down that tech note. Thanks again! – Dr Marble Apr 02 '15 at 23:32
  • This was really helpful. My issue was that I was using a `iPhone Developer ID` instead of a `Developer ID Application`. Thanks. – Joshua Pinter May 22 '18 at 04:27