Huge codesigning trouble

Hello everybody !

I’m about to sign an app written in Xojo on OS X 10.10 with a class-2 code object certificate issued by StartSSL. On Windows this is working fine, but signing on OS X leads to the “app from an unknown developer” message.

For signing I’m using the codesign utility:
codesign -s “Mario Hammer” -f -v “My”
or codesign -s “Mario Hammer” --deep -f -v “My”

It returns “signed bundle with Mach-O thin (i386) [com.mariohammer.testapp]”.

Signature checking with ‘spctl --verbose=4 --assess --type execute “My”’ returns ‘My rejected’.

And 'codesign -dv “My” returns this:
Executable=/Users/mario/Desktop/Test/My App
Format=bundle with Mach-O thin (i386)
CodeDirectory v=20100 size=67752 flags=0x0(none) hashes=3381+3 location=embedded
Signature size=5893
Signed Time=05.11.2014 15:51:59
Info.plist entries=13
TeamIdentifier=not set
Sealed Resources version=2 rules=12 files=22
Internal requirements count=1 size=100

I have also tried to manually sign each file within “My”, but same result.

I’m not sure where to look at fixing this. Any help is highly appreciated.

Looking at my key chain, I have a key chain “Anmeldung” (not sure how this is labelled in English) that contains my private key and my certificate (as two separate entries, key is listed first). Clicking “Information” shows my cert with “Certificate is valid” and a green sign.

Using the certificate assistant to verify my certificate, it shows “Checking state: No root certificate found” and “Certificate condition: Good”. The root certificate however is there (the intermediate certificate “StartCom Class 2 Primary Intermediate Object CA” is in my “Anmeldung” keychain and the root certificate “StartCom Certification Authority” is on my “Anmeldung” key chain as well as on “System” pre-installed (cannot change anything there).

Any help you can provide me with is highly appreciated.


I believe the only way to get the signature to pass GateKeeper is to use a certificate issued by Apple.

Are you absolutely sure ? I’m not wanting to sell over the App Store and code signing certification is a standardized thing, isn’t ?

I wasn’t absolutely sure when I wrote that, it was just my belief from the beginning. But I did a little bit of research and came across a solid no. So now I am absolutely sure.

To pass GateKeeper it must be signed with a certificate from Apple.

Apple only trusts their certificates.

Yes, you need an Apple developer account. Even if you do not want to release on the App Store.

There are two different certificates that Apple provides - one for signing apps to submit to the Mac App Store, and one for non-MAS apps.

Or you can forget the whole thing, no OSX application HAS to be code-signed. None of mine are, and I have not had anyone complain about it. Everyone seems to know how to switch off Gatekeeper, and everyone seems to have already done it.

(Whenever I hear the word “Gatekeeper”, I think of the movie The Net: that was the name of the trojan software used the the Praetorians.)

[quote=141567:@Garth Hjelte]Everyone seems to know how to switch off Gatekeeper, and everyone seems to have already done it.
Gatekeeper should NOT be turned off. It’s there for a reason. But if you right click on an app and select “Open” you can approve that single app only.

What reason?

(Please let’s not get into a “Apple Is Really Your Friend” argument.)

I read somewhere that sales are about 50% lower (outside the appstore) when you do not coding your app.
If any user cannot double click on an app to launch, most will just remove your app - even if you give instructions on your site how they can launch it by right clicking.

Not code signing your app is just plain stupid if you care about sales. Thats just common sense now…

[quote=141571:@Garth Hjelte]What reason?

(Please let’s not get into a “Apple Is Really Your Friend” argument.)[/quote]
Panic has a good read on the subject :slight_smile:

I must be thick, but I do not see the difference between $99 for a Comodo code signing certificate destined to sign Windows programs, and $99 for the Apple developer program which will give access to a gatekeeper certificate. What is the beef ? You want to sell your software and your customers not get nasty messages when they launch your programs, you buy what is required.

If you want to drive a car, you get a license…

Did I wake up this morning and find myself on the “non-diversity” planet? (Must have lost reelection.)

I never said code-signing wasn’t a good idea. All I said was that as soon as my customers see it as a big deal, and start responding about it, I’ll react. But none of my customers have said a word - and I’m talking about thousands - ten-thousands of users. When they do, I’ll assign it a priority in my schedule, and do it.

In my case, this makes no sense. The person has to buy the software in order to even run it. They would never know if it was code-signed or not.

Not after spending $100 or so.

Again, I’m just letting it be known that there’s more worlds than just selling $5 apps that count the amount of eclipses since your birthday. I’m sure that apps that go commercial and are way more beholden to the general public - sure, you have to dress up and wear your Code-Sign Tuxedo. But when you are talking about work-specific targeted apps that people actually go looking for, it’s not that important. Trust me, if it was, I’d hear about it. But after 2 years post Mountain Lion, nary a peep.

It’s quite disappointing that Apple forces developers into this membership.

It’s not so about the $100 (nevertheless, hard-earned money…) or the fact that Apple runs a multi-multi-million dollar business, but I haven’t expected such bad business behaviour.

What’s next… a special certificate for Windows, Android, iOS (hey, I read that you really need another membership for mobile apps). I wonder what a shitstorm Microsoft could cause when forcing programmers to buy their certificates, but Apple seems to have a carte blanche.

Anyway, I think I have to bite the bullet and make Apple $100 richer… . :frowning:

Thanks to all here in this forum for helping me (the support at StartSSL for example had no idea that Apple doesn’t accept their certificates - or any other 3rd party one.

Again, remember no one is forcing you, and it is not mandatory. Now, if you think that the way your app is marketed, Code-Signing would improve the look and acceptance of your app, than wouldn’t the $100 be worth that expense? “Pay $100, make your app look better.” Sounds like a normal business transaction.

But don’t make it seem like APple has a gun to your head -they don’t, and again Code-Signing is not mandatory. If your app is not code-signed, fine. Like I said, in my long experience, most/all users cope with it without concern. It’s like the nasty warning screen in Windows that comes up when a driver isn’t “signed” - everyone learned to completely ignore it.

[quote=141576:@Albin Kiland]Panic has a good read on the subject :slight_smile: [/quote]
The latest update to Coda is no longer on the App Store, seems even Panic has trouble with the App Sandbox.

In my experience, Gate Keeper has had an effect on people’s attitude to un-accepted certificates.

Before Gate Keeper our most popular application HDRtist Pro was cracked and pirated like crazy, the way how I know about this is people who were contacting us from the cracked version.

In the last few years, this has dropped to an absolute minimum, I’ve had one request for support from a cracked version in the last 5 months. The cracked version couldn’t be signed with a recognized certificate and so by default Gate Keeper will reject it and for good reason. The last time I checked for cracked versions of HDRtist Pro, I found only one and the binary was 20mb heavier than the version on our site. Which leads me to conclude that the crackers were loading something nasty inside.

It’s a piece of mind for the consumer, if it’s been signed by an Apple certificate it means that the developer hasn’t yet been accused of doing something malicious. Ultimately if you want maximum exposure without the App Store, I would suggest investing in the certificate and the trials and tribulations it brings (as the apps need to conform to rules to be code signed).

Thanks for the response Sam, very interesting.

Is there a difference between an app that is NOT Code-Signed and one that is Code-Signed but the cert is corrupt/illegal/hacked?

Since my apps don’t need 7 billion person exposure, I can avoid all this. $200 saved for 2 years of Apple Dev charges (and counting), and my apps can do whatever they want (although I play by the rules mostly) without having a company look over my shoulder and tell me what I can do and what I can’t. But most certainly the time saved is by far the greatest money-saver.

One thing my apps do is read disks (usually CD’s and removable media) low-level. Starting with Mountain Lion Apple cracked down and decided that was a security problem. So although I played by the rules (sorta had to) and created a helper app that runs as root, I can’t help but think that as soon as I either Code-Sign or try to sell on the AppStore, Apple is going to go apoplectic on me. I’m also resigned to completely remove the feature to avoid the hassle.

This can’t be done on the App Store, but it can be done with a code signed application.

The only difference I know is that Apple still won’t authorize your application and if the user wants to run it, they have to bypass Gate Keeper. The cracked copy of HDRtist Pro wasn’t code signed at all, but earlier cracked versions were signed by ‘Core’, which got rejected anyway.

Code signing at the very least provided me a way to tell if the application was cracked as it would report the code signature in the feedback system.

[quote]Is there a difference between an app that is NOT Code-Signed and one that is Code-Signed but the cert is corrupt/illegal/hacked?

I believe so : I’ve run some tests with V2 signature on 10.10, and if the V2 signature is bad, the app won’t launch, whereas if the app has no signature, it will launch. (This is in a very special case, where my app (which is actually an Installer) installs a second app. YMMV.