I'm trying to build for App Store but I got the error Command /usr/bin/codesign failed with exit code 1. I tried to clean DerivedData, restart computer, revoke keys and create new one. I had updated my mac to catalina and Xcode 11, before the upgrade it was working.
/Users/digistarts/Library/Developer/Xcode/DerivedData/Runner-glehwjejufujqwblxzreggowpgvb/Build/Intermediates.noindex/ArchiveIntermediates/Runner/InstallationBuildProductsLocation/Applications/Runner.app/Frameworks/Flutter.framework: replacing existing signature
Warning: unable to build chain to self-signed root for signer "Apple Development: Daniel Santana (85UL9U2WVT)"
/Users/digistarts/Library/Developer/Xcode/DerivedData/Runner-glehwjejufujqwblxzreggowpgvb/Build/Intermediates.noindex/ArchiveIntermediates/Runner/InstallationBuildProductsLocation/Applications/Runner.app/Frameworks/Flutter.framework: errSecInternalComponent
Command /usr/bin/codesign failed with exit code 1
In Keychain Access... The solution was right clicking on Apple Worldwide Developer Relations Certification Authority and select Get Info. In the Image bellow, I've change When using this certificate to Use System Defaults and the system asked me to put password. Now it's working \o/
In case it'll be helpful for someone else - I had the same problem, which only was reproduced with no internet connection, and as fast as I connect back - error disappears.
My project xamarin forms.
I had such a problem after renewing the certificate, it turned out at the end of the build on the Mac it asks for the user's password when checking the certificate.
Related
I have been trying to test my app on a real device and I keep getting this error. I have tried changing my project to this selected answer already XCode 9.1 Command /bin/sh failed with exit code 1 , but it did not work and I have also deleted my derived data already. I hope someone can help me! Thanks!!
If you search around there are a lot of solutions presented to solve this problem. But a few them are outdated or very specific to a certain domain. Recently I ran into the same issue with Charts and Xcode refusing to build to my device with the same error message. The problem you're having has nothing to do with your free developer account but rather with the keychain.
To solve it you'll have to do the following:
Open Terminal and type: security set-key-partition-list -S apple-tool:,apple:,codesign: -s /Users/YOUR_USERNAME/Library/Keychains/login.keychain-db
You'll be prompted for your password. If you enter your password correctly and are repeatedly told it is incorrect go into Utilities -> Keychain Access.
Select and deselect the lock. Enter your password when prompted. Re-enter the command on terminal input your password and then clean/build on Xcode. Everything should work as before.
I’m trying to upload my certs to Bitrise by using the codesigndoc tool, which I’m running with the following command
bash -l -c "$(curl -sfL https://raw.githubusercontent.com/bitrise-tools/codesigndoc/master/_scripts/install_wrap-xcode.sh) --scheme='my Scheme' --certs-only"
The issue is that it’s not detecting any distribution certificates
The Xcode archive used development certificate: iPhone Developer: Me (XXX) [1234].
Please select a distribution certificate:
Please select from the list:
(type in the option's number, then hit Enter) [1] :
It errors out if I try and continue, with an invalid option response (if I just try to put in 1 or 0).
I already archived and exported the ipa manually, which I heard is sometimes needed.
This seems to be an issue in codesigndoc - tracking it at: https://discuss.bitrise.io/t/no-codesigndoc-distribution-certificatea/4355
Will report the progress there.
I was able to circumvent the problem by removing the scheme & certs-only flags.
Not sure why, but it fixed the problem.
I tried to code sign an iOS application,
These are the steps that i followed
security create-keychain -p password ${KEYCHAIN}
security set-keychain-settings -u -t 300 ${KEYCHAIN}
security list-keychains -d user -s login.keychain ${KEYCHAIN}
security import "$1" -k ${KEYCHAIN} -A -P "${PASSPHRASE}" -A >/dev/null
security unlock-keychain -p password ${KEYCHAIN}
/usr/bin/codesign -f -s $IDENTITY --keychain $KEYCHAIN --entitlements $ENTITLEMENTS Payload/Test.app
This returned me Codesign returned unknown error -1=ffffffffffffffff via ssh.
If i directly execute the code sign command in the machine, it's successfully signing.
The issue is only in Mac OS Sierra.
Had the same problem a while ago, adding
security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k password ${KEYCHAIN}
solved it for me.
Got the same issue but while archiving directly from Xcode.
Sharing the solution in case it helps.
Sometimes, Keychain seems to end up in a corrupted state. Using MacOS Sierra too.
Symptoms :
Relogin needed to access Accounts after restarting Xcode
Prompting for password while using Keychain Access for some operations
Keychain Access - Error while accessing login keychain via Change Settings for Keychain ...
What fixes it for me is locking and unlocking (password required) the involved Keychain, login in my case.
I am going to chip in as well as I had to try a few more things than the ones mentioned here: the problem was that keychain doesn't like SSH sessions. I had to execute these in my session to fix it:
security unlock-keychain -p MY_PASS ~/Library/Keychains/login.keychain
security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k MY_PASS ~/Library/Keychains/login.keychain
security set-keychain-settings ~/Library/Keychains/login.keychain
I've also removed my current certificates system/account certificates by removing my account from XCode (I use fastlane to do building) but I suspect that this shouldn't have impacted it.
#madhu I have been trying to fix the same issue and found that Access Control for the key associated with the certificate in question was set to "Confirm before allowing access" which didn't work in Jenkins. I modified it (thru Keychain Access gui - Get Info, Access Control) to "Allow all applications to access this item" and my build was successful.
You might have exported some file like p12 from KeyChain, and when OS asked for your root password, and you denied it, then Xcode will code sign error with this info.
If this maybe so, you should repeat the above action, input your password and click allow, and then it will be ok to code sign.
This happens in a headless build because the prompt for key access cannot be shown or responded to. The solution is to prevent that prompt from showing by granting access to the key in advance.
Open Keychain Access, find the key for your signing certificate (login-> Certificates, then expand the certificate to reveal its key). Right-click on the key and select: Get Info -> Access Control, and select "Allow all applications to access this item".
I've tried almost all the existing suggestions over the web, none of them helped...
Finally only re-generating the Provisioning Profile (for AdHoc), re-downloading it and placing it to ~/Library/MobileDevice/Provisioning Profiles/ overwriting the existing one saved my life.
By the way, AppStore build was successful all this time, so the issue was definitely in the AdHoc profile itself (pretty strange, since it looked nice by all means).
Even though we installed the right certs in the keychain and the right Provisioning Profile under ~/Library/MobileDevices/Provisioning Profiles.
We may also see
unknown error -1=ffffffffffffffff
For this error, I tried the below steps to fixed the issue:
Reboot the machine, unlock keychain using "securify unlock-keychain", lock the keychain again
Remove ~/Library/Developer/Xcode/DerivedData folder.
Run carthage bootstrap --platform iOS
Open the source code syncing down workspace, run "xattr -rc ." then open the .xcodeproject file in xcode.
Turned on the automatic signing for each target. Need to login with valid credentials.
Click on the provisioning profile under signing.
unlock the keychain again
Changing the build device to Generic Devices, under Product --> Clean, then Product –> Archive
There will be a keychain access allow showed up, click "Always Allow".
You should make sure the archive is successful then trigger the Jenkins job again.
While using signtool for code signing on our buildserver jenkins shows the following error message:
Done Adding Additional Store
Error information: "Error: SignerSign() failed." (-2147023673/0x800704c7)
SignTool Error: An unexpected internal error has occurred.
We use an EV code sign certificate on a USB token. All tools are the latest ones available actually.
Any ideas?
It is not a problem at all using the same build task and running it manually on the same machine (as the user mentioned below) that jenkins is running on, and the same environment / directory.
The Jenkins service runs on a Windows 10 pro VM as a simple user with admin rights (not as Local System).
For more details see this excerpt from the Jenkins log:
Signiere FlinkySchule.FormularEditor.exe:
Verbindung zu Token auf- bzw. abbauen
***** code signing *****
Aktueller Pfad des signtool:
c:\JW\FS\Production\Deployment\Tools\signtool\kits
Zu signierende Datei:
c:\JW\FS\Production\Application\Assemblies\FlinkySchule.FormularEditor\bin\Release\\FlinkySchule.FormularEditor.exe
The following certificate was selected:
Issued to: Dirk W.
Issued by: GlobalSign CodeSigning CA - SHA256 - G3
Expires: Fri Apr 03 15:58:51 2020
SHA1 hash: 4187Cxyxyxyxyxyxyxyxyxyxyx7978C4
Done Adding Additional Store
EXEC : error information: "Error: SignerSign() failed." (2147023673/0x800704c7) [c:\JW\FS\Production\Application\Assemblies\FlinkySchule.FormularEditor\FlinkySchule.FormularEditor.csproj]
EXEC : SignTool error : An unexpected internal error has occurred. [c:\JW\FS\Production\Application\Assemblies\FlinkySchule.FormularEditor\FlinkySchule.FormularEditor.csproj]
One issue was the over all path length:
Even in the year 2017 you will run into the 260 characters path length restriction. Annoying! But we solved this and the error still occurs sometimes.
EV codesign with Jenkins using an eToken
Found a solution using jsign
java -jar jsign-2.0.jar --keystore .\eToken.cfg --alias %yourCertAlias% --storetype PKCS11 --tsaurl http://rfc3161timestamp.globalsign.com/advanced --tsmode RFC3161 --storepass %tokenPassword% %file2sign%
eToken.cfg:
name=eToken
library=c:\WINDOWS\system32\eTPKCS11.dll
Get the certificates alias using java keytool
keytool -list -keystore NONE -storetype PKCS11 -providerclass sun.security.pkcs11.SunPKCS11 -providerArg eToken.cfg
This should output something like
Keystore-Typ: PKCS11
Keystore-Provider: SunPKCS11-eToken
Keystore enthält 1 Eintrag
te-318f471f-9a0e-4101-bf45-96a656cc2306, PrivateKeyEntry,
Zertifikat-Fingerprint (SHA1):
41:87:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:X:XX:XX:XX:XX:79:78:C4
Maybe there are some more entries in the store. To find the right have look at your certifcate's fingerprint. The alias you need for jsign's alias parameter is the string in the example that starts with "te-318f4...."
Need more detailed help about this part? Please have a look at Trustzone.
Please let me know if you are interested in knowing how we do an automated build process on a separate build machine using only one eToken USB device.
I ran into this problem as well. I was able to duplicate error outside of Jenkins by running Signtool.exe, but when the prompt appeared for the token password, click cancel. You'll get the same error.
I have a C program which watches for the Symantec prompt and automatically enters the toke password. But Jenkins clearly wasn't running Signtool.exe in the same context as my password helper program. So I then edited my program which runs Signtool.exe to run the password helper program as well. It was still no good. Then I realized that maybe the problem how Jenkins is being run on the node. I had the Jenkins node running a service. Once I stopped the service, and connected by running the java command directly on the command line, it worked!
So now I know, if I'm going to run signtool on a Windows node, make sure the node is connected by running on the command line (via scheduled task), not a service. This changes the context Jenkins is run under which allows SignTool and the Token Prompt to play nice.
I had the same issue and solved it by installing the latest Windows 10 SDK, i.e. 10.0.15063.0
I omitted the countersignature :
/tr http://tsa.starfieldtech.com
I had to specify which certificate should be used for signing
/n "My Certificate Name"
Edit: Sorry my error code was different but google brought me here, so still might be helpful.
(-2146435071/0x80100001)
Scenario:
I have a .pkg file that needs to be signed using TeamCity after our TeamCity build has completed.
Ideally this could be a build step or script that runs at the end. After research, I tried the following:
Script INPUT:
security import applicationkey.p12 -k login.keychain -P "password"
security import installerkey.p12 -k login.keychain -P "password"
security -v unlock-keychain -p "password" /Users/administrator/Library/Keychains/login.keychain
security -v unlock-keychain -u /Library/Keychains/System.keychain
productsign --keychain /Users/administrator/Library/Keychains/login.keychain --sign 'Developer ID Installer: Company LLC' CompanyInstaller.pkg CompanyInstallerSigned.pkg
pkgutil --check-signature CompanyInstallerSigned.pkg
OUTPUT:
unlock-keychain "-p" "mypassword" "/Users/administrator/Library/Keychains/login.keychain"
unlock-keychain "-u" "/Library/Keychains/System.keychain"
productsign: using timestamp authority for signature
productsign: signing product with identity "Developer ID Installer: Company LLC" from keychain /Users/administrator/Library/Keychains/login.keychain
productsign: adding certificate "Developer ID Certification Authority"
productsign: adding certificate "Apple Root CA"
2016-10-05 14:57:11.484 productsign[9385:29611120] SignData failed: CSSMERR_CSP_NO_USER_INTERACTION (-2147415840)
Error signing data.
productsign: error: Failed to sign the product.
QUESTION:
I've noticed many solutions to this mentioning to click the "Always Allow" from the dialog prompt the first time it appears in reference to the Keychain's Access Control, however my only known interaction with this build agent is through SSH. Is there a means to sign a .pkg using productsign on Teamcity mac build agent without gui interaction with this "Always Allow" prompt? Or, is there a way to login to the build agent and view a gui so I could click on this "Always Allow" to enable this?
Note: I've also tried saving the (local signing machine) private key's Access Control to "Allow all application to access this item", exported it, imported it to the build agent's login.keychain, then tried the above again, to only have the same output. When I do the same process on my macbookpro, everything works, however I do not recall if I did click "Alway Allow" from long ago.
Any thoughts? Much appreciated.
We ran into this problem as well - we are using TeamCity to sign packages on a Mac build agent.
The first time we set up the build agent, we imported the certificate into the keychain and granted the 'always allow' permission; this seemed to work. At some point the build agent was rebooted and then signing packages no longer worked, whatever we tried with permission & trust settings. We kept getting the SignData failed: CSSMERR_CSP_NO_USER_INTERACTION error.
We fixed this (hopefully for good!) by moving the certificate into the 'System' keychain (it was previously in the 'login') keychain. We didn't need to change our call to productsign at all - it picked up the system keychain correctly. I imagine that if you had the certificate in both keychains then you would need to tell productsign which keychain to use (--keychain ...).