Code signing on multiple computers - xcode

I use 2 machines for developing a Mac application. I just submitted my app to the app store from my desktop (generating and using the appropriate certificates from Apple for code signing).
I exported and installed the certificates on my laptop so that they show up in the keychain but, yet, I'm unable to build my app on my laptop because of the following error:
Check dependencies
[BEROR]Code Sign error: The identity '3rd Party Mac Developer Application' doesn't match any valid certificate/private key pair in the default keychain
Is there any way to use the same certificates for code signing on more than 1 machine?

Yes, I use multiple computers and the same certificates all the time.
You need to also make sure you have the private keys imported into your keychains.

Related

Sign an electron app on macos using pfx certificate

I have created an electron app. Now I want to sign code for both windows and mac platform. But I have only go daday pfx certificate.I successfully signed code using pfx certificate from go daday in windows platform. So,Can I sign an electron app on macos platform using go daday certificate?
You can sign a macOS app with a GoDaddy code-signing certificate, but it probably won't do what you want. Here's what Apple's developer documentation says (with my emphasis added):
Note: Apple uses the industry-standard form and format of code signing
certificates. Therefore, 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 macOS codesign command. Similarly, if your company is
a certificate issuing authority, contact your IT department to find
out how to get a signing certificate issued by your company. However,
while these valid certificates allow you to sign your code, you can
only distribute through the App Store or through the Developer ID
program when you sign with a certificate issued by Apple.
So, the question is: how is your application going to be distributed to users' computers?
If it's sold through Apple's App Store, you need to become an Apple Developer, get a Mac App Distribution certificate from Apple, and sign the app with that before submitting it to Apple.
If it's distributed outside Apple's App Store (e.g. via web download), then you also need to become an Apple developer, get a Developer ID certificate, and use that to sign it. If you don't sign it with the right kind of certificate, Gatekeeper will prevent users from opening the app unless they go through a special procedure to trust the app.
Either way, you need to join the Apple Developer program, and use an Apple-issued code signing certificate to sign the macOS version of your app.

Mac App signed with Developer ID fails to start, I get com.apple.developer.networking.vpn.api entitlement is not allowed (error code -67050)

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.

What are the implications of codesigning an OS X application with a self-signed certificate?

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. :-)

Why can't I code sign this Mac app?

I started some days ago a small Mac app for Mac OS X Lion. I've never uploaded a Mac app before, so this is the very first time.
This is what I've already done:
Created App ID
Created Certificate
Installed Certificate
Created a Production Provisioning Profile
Changed the App ID to my generated one
Created a new Configuration based on "Release"
Changed its Code Signing to 3rd Party Mac Developer Application
Selected the "Production"-Configuration which I created for the Archive-Scheme
Archived the Application
Now I wanted to "Share" the Application. Xcode (4.1 btw) said to me, there were no valid signing identities. Does I need to add an Entitlement.plist like in iOS? Have I forgotten something?
Update:
I just figured out, that I have to sign my app twice. I've still selected "3rd Party Mac Developer Application" but I can't select the Installer cert while submitting my app.
Have you installed the WWDR intermediate certificate? I just had the exact same problems and my issue was that the intermediate certificate was not installed on my machine. Granted, nowhere does Apple explicitly say you need it installed, more like suggestions. But, you do need it. You can find it here, or by going to Developer Certificate Utility under the Mac Developer Center.
I got it to work. I deleted my App and created it new.
I didn't create a new Configuration, and I only changed the Code Signing Indentity of the Target to 3rd Party Mac Developer Application. After this, I archived the app and then I was able to select the installer cert.

XCode does not want to use my Developer Certificate since I have used my Distribution Certificate !

I have just uploaded an app to the App Store. For this purpose, I used the Distribution Certificate.
Since then, I cannot switch back to my Developer Certificate when trying to sign the code. I only do Project Settings > Code Signing. My Developer Certificate is visible but when signing it does not show up. XCode only uses the Distribution one.
Did you face the same issue ?
Of course, I am going to try to generate a new project... Those tools drive me crazy.
Apple92
Try changing the active scheme to debug rather than distribution.

Resources