OSX El Capitan version 10.11.4
I am building an application in Xcode and signing it with an official developer cert. I then package this into a DMG which I am also signing.
My application listens for TCP connections on a specific port (7772 in this case).
I verified the signature:
$ codesign -dvvvv /Applications/Foo.app/
Executable=/Applications/Foo.app/Contents/MacOS/Foo
Identifier=com.foo.bar.Foo
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=69949 flags=0x0(none) hashes=2179+4 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=188672458e5a40f9f5eb72a864ecaee6dbb46970
CandidateCDHash sha256=c0f4bc81011db7123d8bf881d14868e6e4203cdf
Hash choices=sha1,sha256
CDHash=c0f4bc81011db7123d8bf881d14868e6e4203cdf
Signature size=8912
Authority=Developer ID Application: *** Inc. (3********2)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Apr 15, 2016, 4:12:19 PM
Info.plist entries=27
TeamIdentifier=3*********2
Sealed Resources version=2 rules=12 files=32
Internal requirements count=1 size=192
When I reboot with the firewall enabled I get a prompt asking me to allow the application to accept incoming connections.
If I say ok, then it works (obviously) and if "deny" then the firewall blocks the port.
My question is why am I getting prompted if my app signature is good?
Once I hit "accept" I don't see it in my firewall applications either.
EDIT: I forgot to mention that my firewall is configured to "Automatically allow signed software to receive incoming connections". That's why I'm puzzled since my app is being signed and passes codesign verification.
According to this:https://developer.apple.com/library/content/documentation/Security/Conceptual/CodeSigningGuide/AboutCS/AboutCS.html
you should check the Code Designated Requirement:
codesign -vv yourapp.app
Making a Game Center ANE for OS X.
When my app was unsigned, (and with enabled workaround, described here https://devforums.apple.com/message/736545), it works fine.
But when I sign my app for distribution, and disable workaround, it raise errors, when I try to authorize local player
Could not get services from gamed. Please file a radar including GameKit logs, and any gamed crash logs. ERROR Error Domain=NSCocoaErrorDomain Code=4099 "Couldn’t communicate with a helper application." (The connection to service named com.apple.gamed.osx was invalidated.) UserInfo=0x325c90 {NSDebugDescription=The connection to service named com.apple.gamed.osx was invalidated.}
Error Domain=GKErrorDomain Code=3 "The requested operation could not be completed due to an error communicating with the server." UserInfo=0x21ce90 {NSLocalizedDescription=The requested operation could not be completed due to an error communicating with the server.}
Has anyone encountered a similar problem?
Here is script, which I use to sign my app:
App=MyApp.app
Cert=3rd Party Mac Developer Application: ...
rm "$App"/Contents/Frameworks/Adobe\ AIR.framework/Versions/1.0/Resources/WebKit.dylib
rm "$App"/Contents/Frameworks/Adobe\ AIR.framework/Versions/1.0/Resources/adobecp.vch
rm -rf "$App"/Contents/Frameworks/Adobe\ AIR.framework/Versions/1.0/Resources/adobecp.plugin
rm -rf "$App"/Contents/Frameworks/Adobe\ AIR.framework/Versions/1.0/Resources/AdobeCP15.plugin
rm "$App"/Contents/Frameworks/Adobe\ AIR.framework/Versions/1.0/Resources/Adobe\ AIR.vch
chmod -R 777 "$App"/
codesign -f -v -s "$Cert" "$App"/Contents/Frameworks/Adobe\ AIR.framework/Versions/1.0/Resources/Flash\ Player.plugin/
codesign -f -v -s "$Cert" "$App"/Contents/Frameworks/Adobe\ AIR.framework/
codesign -f -v -s "$Cert" "$App"/Contents/Resources/META-INF/AIR/extensions/my.awesome.gc/META-INF/ANE/MacOS-x86/GC.framework/GC
codesign -f -s "$Cert" --entitlements MyApp.entitlements "$App"
UPD
The problem occurs only if I sign with the --entitlements MyApp.entitlements.
Here is MyApp.entitlements
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.app-sandbox</key>
<true/>
</dict>
</plist>
Please, tell me, what am i doing wrong?
My Mac Os X app needs to access different servers in Brazil and one of the servers seems to have an sslv3 issue. It seems that access thru MS Windows solutions is normal. I tried using Internet Explorer and it works. This is an example of what Firefox shows me:
I have written a sample app at http://www.idanfe.com/trustAuthenticationTester.zip that demonstrates that method - (void)connection:(NSURLConnection *)aConnection willSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge *)aChallenge is not called at all when talking to the server https://nfe.sefaz.ce.gov.br/nfe2/services/NfeStatusServico2, but I works fine with server https://nfe.sefazvirtual.rs.gov.br/ws/NfeStatusServico/NfeStatusServico2. The purpose is to customize the server trust evaluation. But at this point it is not possible.
These are the error I get:
CFNetwork SSLHandshake failed (-9824)
CFNetwork SSLHandshake failed (-9802)
CFNetwork SSLHandshake failed (-9802)
NSURLConnection/CFURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9802)
Thanks.
Latest version of OS X require TLSv1.2 SSL in the host server and hence the SSL fails. You can set exceptions in your info.plist file.
<key>NSAppTransportSecurity</key>
<dict>
<key>NSExceptionDomains</key>
<dict>
<key>BrazilServer.com</key>
<dict>
<key>NSIncludesSubdomains</key>
<true/>
<key>NSExceptionMinimumTLSVersion</key>
<string>TLSv1.1</string>
</dict>
</dict>
</dict>
Also NSURLConnection is deprecated and you should switch to NSURLSession instead, as there are bugs with handling the exceptions in the info.plist and NSURLConnection.
Should you want to get more info about the error you can set the CFNETWORK_DIAGNOSTICS environment variable under the schema setting to 1, and the log will produce more exact results of what is happening during the SSL handshake.
Our automated build is running on Jenkins. The build itself is running on slaves, with the slaves being executed via SSH.
I get an error:
00:03:25.113 [codesign-app] build/App.app: User interaction is not allowed.
I have tried every suggestion I have seen so far in other posts here:
Using security unlock-keychain immediately before signing to unlock the keychain.
Moving the signing key out into its own keychain.
Moving the signing key into the login keychain.
Moving the signing key into the system keychain.
Manually setting list-keychains to only the keychain which contains the key.
In all cases, I get the same error.
In an attempt to diagnose the issue, I tried running the "security unlock-keychain" command on my local terminal and found that it doesn't actually unlock the keychain - if I look in Keychain Access, the lock symbol is still there. This is the case whether I pass the password on the command-line or whether I let it prompt me for it. Unlocking the same keychain using the GUI will prompt me for the password and then unlock it. Additionally, if I run "security lock-keychain", I do see the key lock immediately after running the command. This makes me think that unlock-keychain doesn't actually work. I experience the same behaviour on Lion (which we're using for the build slaves) and Mavericks (which I'm developing on.)
Next, I tried adding -v to all the security commands:
list-keychains "-d" "system" "-s" "/Users/tester/.secret/App.keychain"
Listing keychains to see if it was added: ((
"/Library/Keychains/System.keychain"
))
unlock-keychain "-p" "**PASSWORD**" "/Users/tester/.secret/App.keychain"
build/App.app: User interaction is not allowed.
From this, it would seem that list-keychains is what isn't working. Maybe neither work. :/
There is a similar question here. The solution is interesting - set "SessionCreate" to true in launchctl. But I'm not building on the master - my build process is started from SSH on a slave build machine. Maybe there is a command-line way to do what launchctl is doing when you run "SessionCreate"?
I too have been fighting this. Nothing helped until I tried the suggestion on http://devnet.jetbrains.com/thread/311971. Thanks ashish agrawal!
Login your build user via the GUI and open Keychain Access. Select your signing private key, right-click, choose Get Info, change to the Access Control tab and select the "Allow all applications to access this item".
Well, I guess I get to answer my own question today, because after stabbing at it over two and a half days, one of the things I tried seems to have worked. I'm just going to back away from it now and hope it keeps working.
Essentially, it looks like it comes down to -d system not actually working. So a lot of answers to other questions around here should probably be updated to reflect that.
security -v list-keychains -s "$KEYCHAIN" "$HOME/Library/Keychains/login.keychain"
security list-keychains # so we can verify that it was added if it fails again
security -v unlock-keychain -p "$KEYCHAIN_PASSWORD" "$KEYCHAIN"
codesign --sign "$SIGNER_IDENTITY" --force --signature-size 9600 \
--resource-rules src/AppResourceRules.plist --timestamp --verbose \
"$APP"
Using Security to create a Keychain for /usr/bin/codesign
Importing the certificate and having it work with codesign programmatically isn't a matter of using login or System keychains or praying to some god of codesign. You just need to have the correct permissions set. I recommend creating a new keychain specifically for codesign purposes.
These days to get codesign to not yield an errSecInternalComponent you need to get the partition list (ACLs) correct. I'll walk through the steps:
Create the Keychain
security create-keychain -p "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"
at this point the keychain is unlocked but won't appear in Keychain Access.
Add the new Keychain to the search list
security list-keychains -s "${KEYCHAIN_NAME}" "${OLD_KEYCHAIN_NAMES[#]}"
Add the new Keychain to the list. If you don't first grab out the original list from list-keychains you'll no longer have login.keychain in your search-list.
Unlock the keychain
security unlock-keychain -p "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"
This is redundant if you created the Keychain above, but if the Keychain already existed it is necessary.
Remove the defaults from the Keychain
security set-keychain-settings "${TESTING_KEYCHAIN}"
By not specifying any arguments this will set the auto-lock timeout to unlimited and remove auto-lock on sleep.
Import your signing certs from a .p12
security import "${DIST_CER}" -P "${CERTIFICATE_PASSWORD}" -k "${KEYCHAIN_NAME}" -T /usr/bin/codesign
Import the certs and gives codesign access through the -T option.
Set the ACL on the keychain
security set-key-partition-list -S apple-tool:,apple: -s -k "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"
This is a requirement that many people miss. You can see what macOS does by using dump-keychain. Which in the case of codesigning requires apple: and apple-tool:. -s refers to signing certificates.
Where's my signing certificate?
Always a good idea to make sure you can find your certificates
security find-identity -p codesigning -v /path/to/keychain
Gitlab-Runner, Jenkins and the like
One very important thing for any CI-type runner or build system is to make sure the process is started from launchd correctly. Make sure your plist contains <SessionCreate> </true>.
Not correctly matching the the owner of the keychain with the build process and making sure a security session is created will result is all sorts of headaches. Diagnostically speaking you can introduce list-keychains and see if the output matches your expectations.
This is from the launchd.plist man-page:
SessionCreate <boolean>
This key specifies that the job should be spawned into a new security
audit session rather than the default session for the context is belongs
to. See auditon(2) for details.
UserName <string>
This optional key specifies the user to run the job as. This key is only
applicable for services that are loaded into the privileged system
domain.
GroupName <string>
This optional key specifies the group to run the job as. This key is only
applicable for services that are loaded into the privileged system
domain. If UserName is set and GroupName is not, then the group will be
set to the primary group of the user.
Example /Library/LaunchDaemons/com.company.gitlab-runner.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.company.gitlab-runner</string>
<key>SessionCreate</key><true/>
<key>KeepAlive</key><true/>
<key>Disabled</key><false/>
<key>UserName</key>
<string>bob</string>
<key>GroupName</key>
<string>staff</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/opt/gitlab-runner/bin/gitlab-runner</string>
<string>run</string>
<string>--working-directory</string>
<string>/Users/bob/gitlab-runner</string>
<string>--config</string>
<string>/Users/bob/gitlab-runner/config.toml</string>
<string>--service</string>
<string>gitlab-runner</string>
<string>--syslog</string>
</array>
<key>EnvironmentVariables</key>
<dict>
<key>PATH</key>
<string>/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin</string>
</dict>
</dict>
</plist>
Register the runner
gitlab-runner register \
--non-interactive \
--tls-ca-file "{{ gitlab_runner_dir }}/certs/git.company.com.crt" \
--config "{{ gitlab_runner_dir }}/config.toml" \
--builds-dir "{{ gitlab_runner_dir }}/builds" \
--url "{{ gitlab_ci }}" \
--registration-token "{{ gitlab_token }}" \
--name "{{ computername }}" \
--tag-list "{{ gitlab_runner_tags }}" \
--output-limit 16384 \
--executor shell \
--shell bash
Finally codesign
You can lookup the signing certificates hash using find-identity
security find-identity -p codesigning -v
Before beginning signing Xcode sets the environment variable CODESIGN_ALLOCATE to use the codesign_allocate that comes with Xcode, not in /usr/bin.
export CODESIGN_ALLOCATE="$( xcrun --find codesign_allocate )"
Codesign a framework, dylib, etc.
If you're codesigning manually, start with the frameworks and dylibs and after they are all signed, then sign the .app. Or in other words - you codesign from the bottom up.
/usr/bin/codesign --verbose=4 -f -s "$SIGNER_HASH" "$SIGNABLE"
Codesign the app bundle
After all the other signables are signed, sign the .app itself. In theory, you could do this all in one go with --deep, however, you would still need to make sure your app has entitlements and possibly other flags.
/usr/bin/codesign --verbose=4 -f -s "$SIGNER_HASH" "$SIGNABLE"
Flag passed to all items:
--timestamp=none disable timestamps
Other flags to the app signing step:
--entitlements /path/to/entitlements.xcent new entitlements
--preserve-metadata=entitlements keep current entitlements
New codesign requirement - DER encoded entitlements
Apple has recently started requiring entitlements to not be embedded only in plist form, but also in DER encoded form. If you are using an older Mac/Xcode you might encounter the error...
The code signature version is no longer supported
None of the other answers worked for me.
What eventually saved me was this post
To sum it up, this can be caused by a default timeout of 5 minutes, that will trigger this error after a long build.
To fix:
security set-keychain-settings -t 3600 -l ~/Library/Keychains/login.keychain
Try to call security unlock-keychain and codesign as an one-line command. This helped me. Something like:
security unlock-keychain -p <password> /Users/<user>/Library/Keychains/login.keychain && codesign --force --verify --verbose --sign "<certificate id>" <app name>
Put your keys in the System keychain
So this is the command that works. -A is to prevent Mac from asking password. Importing to system.keychain doesn't require an GUI.
sudo security import <cert.p12> -k "/Library/Keychains/System.keychain" -P <passphrase> -A
My keychain was locked. It resisted my advances to change that fact...
Keychain Access -> Keychain First Aid -> Repair, et voilá!
Unlocking the keychain is not enough. You also have to set the private key access to "Allow all apps to access this item". And to do that from command line requires reimporting the key. So to take things at a time:
Unlock the login keychain if it is locked. It shouldn't be locked though, but anyway here's how you do that:
security -v unlock-keychain -p "$KEYCHAIN_PASSWORD" "~/Library/Keychains/login.keychain"
If for some reason your build machine has the login keychain locked, and you don't want to expose that password in a script, then you should use a different keychain. You can create one on the spot and use that in the previous and the following command. To create one on the spot:
security create-keychain -p 'temporaryPassword' MyKeychain.keychain
security list-keychains -d user -s login.keychain MyKeychain.keychain
Then import your certificates and associated private keys into the login keychain using the -A parameter. Note that you don't need to sudo for all this...
security import <cert.p12> -k "~/Library/Keychains/login.keychain" -P <passphrase> -A
The -A parameter is what will make your private key to be set to "Allow all apps to access this item"
So using all these you should be able to make a script that installs the required certificate to build a release ipa and sign it without prompt. You can store the .p12 file in your repo, so any machine can build your ipa without requiring manual setup.
Apart from unlocking keychain (as mentioned in another answers), you need to allow access from all applications to Xcode authentication token in keychain:
Select "login" keychain
Select "All Items" category
Search for "xcode" keyword
Select "Allow all applications to access this item" for all Xcode tokens
Don't forget to add unlock keychain step (from previous answers)
Import your keys to System keychain. You can use this command:
sudo security import YourKey.p12 -k /Library/Keychains/System.keychain -P PasswordToYourKey -T /usr/bin/codesign
So I tried every answer here and something wasn't quite adding up. Finally I figured out when I rebooted my CI service, it was running under a different user than I had expected. Changing to the user that actually had access to the key in their login chain fixed everything. This may not be a common problem, but wanted to document my specific reason for this error, in case it happens to others.
For me nothing worked seems have to reinstall Xcode all over again. Jenkins keeps giving the same error.
You would save lot of time if you just move Xcode installation to Trash and reinstall. Ensure you run the codesign command from command line atleast once.
Even after if you get the same error try setting 'Unlock Keychain?' property within Jenkins and give path to your login.keychain under /Users/${USER}/Library/Keychains/login.keychain
I hope god be with you after that.
In my case, this was caused by a keychain being created with a default timeout of 300s and a long xcode compile lasting more than 300s. The workaround, for me, was to invoke:
security set-keychain-settings -t <longer timeout in seconds> <keychain>
immediately after creating the temporary keychain.
I ran through all these suggestions and was still having problems using fastlane's gym in a Jenkins job. I had the certificate installed and keychain unlocked, and was able to codesign on the slave when I manually ran the codesign command on the command line.
As a workaround, if Jenkins connects to the slave using JNLP instead of SSH, you'll be able to codesign.
For me it happens when there is a second keychain added manually and it's locked. For some reason codesign tries to access the locked keychain and fails even though the certificates are in the login keychain (and is unlocked). Unlocking the second one solves the problem. Just doesn't make sense to me.
After trying a number of the above solutions. I realized that one factor I had, was that I was starting the build using the ION Console. When I switched back to making the build from the Terminal app, everything worked just fine.
I am getting this message when setting "aps-environment" to "production" in my entitlements.plist file:
The executable was signed with invalid entitlements.
The entitlements specified in your application’s Code Signing Entitlements file do not match those specified in your provisioning profile.
(0xE8008016).
My entitlements:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>keychain-access-groups</key>
<array>
<string>123.*</string>
</array>
<key>application-identifier</key>
<string>123.com.app.mine</string>
<key>aps-environment</key>
<string>production</string>
</dict>
</plist>
you need to use a valid distribution certificate for the app ID -- and it can't be a wildcard one
First go to developer.apple.com login in member centre select manage profile, certificate section.
1) create Certificate of type distribution (if you want it to upload to App Store)
2) create app id you should enter same package name as specified in your application
3) create provisional profile with the same certificate and app identifier which you had
already created.
4) download certificate and profile
5) go to build setting of your application target and select the particular profile and certificate which you had downloaded.
Hope it will resolve your issue