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)
Related
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.
I'm setting up a new development laptop, and have installed a self-issued code signing certificate. I can see it in certmgr under my Current Users's Personal Certificates.
When I try to build from the Developer Command Prompt For Visual Studio 2017 I get:
error : SignTool Error: No certificates were found that met all the given criteria.
This always worked fine on my old laptop.
I have found if I run the same build from the command prompt after starting it as admin that signtool succeeds and can find the cert.
This has happened to 3/4 colleagues when we've set up new laptops. One guy is ok and can sign without running as admin. On our old laptops we never had to run as admin.
I've tried googling to find what could be the cause because I wasn't aware that running as admin or not should have any affect over this. I haven't found any reference to this problem.
How can we use signtool.exe without running it as admin?
When not running as admin it appears to be at the Private Key filter step where the cert I'm expecting to be selected gets filtered out:
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.9.12
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
C:\>signtool sign /v /debug /ph /i "<issuedby>" /fd sha256 /td sha256 "C:\TestSign.dll"
The following certificates were considered:
Issued to: Scott Langham
Issued by: <issuedby>
Expires: Sun Sep 25 09:54:55 2022
SHA1 hash: <a_hash>
Issued to: Scott Langham
Issued by: <issuedby_somethingelse>
Expires: Wed May 13 15:51:14 2020
SHA1 hash: <b_hash>
After EKU filter, 1 certs were left.
After expiry filter, 1 certs were left.
After Issuer Name filter, 1 certs were left.
After Private Key filter, 0 certs were left.
SignTool Error: No certificates were found that met all the given criteria.
I've ensured the version of signtool.exe I'm using is the same as the one that my colleague who has this working is using (10.0.18362.1). I've been able to spot any other differences between our systems.
I ran into this today and here is how I am now able to run signtool.exe via command line without elevating to admin.
Run 'mmc' and add the 'Certificates' snap-in
Select the correct key store location
(mine is in Local Computer so I select 'Computer account' here)
Find and select the certificate
Right click on the certificate, select All Tasks > Manage Private Keys...
In the 'Permissions for private keys' dialog, Add your user account and then give yourself 'Full Control'. You will now be able to sign using a normal command prompt.
Note: If you use a build machine, do the above steps for the account that performs the builds.
Similar to what #Baget said, I'd compare the certificates on your machine to that of your colleague who can successfully run the SignTool.exe command without the elevation token. Here's a chunk of PowerShell to assist you:
get-childitem -Path Cert:\ | foreach-object ({
$location = $_.Location
foreach($store in $_.StoreNames.Keys) {
get-childitem -Path "Cert:\$location\$store" | foreach-object ({
$thumb = $($_.ThumbPrint)
$issuer = $($_.Issuer)
if ($issuer -eq "CN=EXAMPLE, DC=EXAMPLE, DC=EXAMPLE, DC=EXAMPLE") {
write-host "$location $store $issuer"
}
})
}
})
Bear in mind that the output of the above may differ slightly if you run as a normal user and 'run as admin'.
Finally, do you and your colleague have the same UAC settings?
I found myself in a similar situation with signtool, it refused to work with an admin user but does work as actual Administrator.
In my case, I am not actually importing the certificate into the certificate store, but using a .pkcs12 file exported from a comodo certificate in firefox, so this makes things even stranger, as no permissions on any keys in the store are involved.
I tried granting myself permissions on some server key, but that did nothing.
I hope someone finds a solution to this problem.
In the meantime, I am signing my exe with osslsigncode instead, which works perfectly.
I extracted the exe and dependent dlls from the msys2 mingw64 build, here is a zip of everything in case it is of use to anyone, just extract it to a directory and put it in your PATH.
http://cachemiss.com/files/osslsigncode.zip
To extract this program yourself from an msys2 installation, you can use this command:
pacman --noconfirm -S mingw-w64-x86_64-osslsigncode
cd /mingw64/bin
mkdir ~/osslsigncode
cp osslsigncode.exe $(ldd osslsigncode.exe | sed -n 's,^.*\(/mingw64/[^ ]*\).*,\1,p' | sort -u) ~/osslsigncode/
cd
zip -9r osslsigncode.zip osslsigncode
I am using this in Visual Studio cmake builds with no issue.
There are two Certificate Store in Windows, User Store, and a machine store, you probably installed the certificate to the local machine, or you installed it when you run as elevated user.
Firstly you are getting such an error and you are using visual studio then See the signing tab in project properties. You will see a previously assigned signature (strong assembly)
If you enter the correct password here:
If your environment is the same as the environment in which the project is written, you will skip this error. Look the post on about the error
The reasons behind this error are:
1- Visual Studio needs some features when using certificate file to sign strong assembly.
ClickOnce Manifest Signing and Strong-Name Assembly Signing Using Visual Studio Project Designer's Signing Page
You can try this code to determine
signtool sign /debug /f mypfxfile.pfx /p <password> (mydllexectuable).exe
2- These settings can vary from machine to machine, and windows does not write these settings to the environment setting by default. check the config path
This part is just a deep note! not interested with the question you should add your private keystore file to request header and those all for this. My favorite steps about the creation of a certificate on this post
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 have run into a similar problem to the on encountered here:
How to sign code (.EXE file) with a .SPC or .PEM file from GoDaddy (using Ubuntu)?
I have used both the MONO signcode tool (https://developer.mozilla.org/en-US/docs/Signing_an_executable_with_Authenticode) and osslsigncode (http://sourceforge.net/projects/osslsigncode/files/osslsigncode/) and the executables show a digital certificate present signed with "Go Daddy Class 2 Certification Authority". When I view the certificate details it says "No signature was present in the subject" I have tried with the timestamp server and without the timestamp server and there is no difference. I am running the code on Ubuntu Precise and testing on Windows 7.
Suggestions?
I'm experiencing this same issue with a renewed GoDaddy cert.
I'm on Debian v8 / signing a windows EXE. It's a part of a deploy/publish step.
Using the SPC file from last year, it worked well. With both osslsigncode and Mono's signcode.
Now I get security warnings w/ the "No signature was present in the subject"
To FIX
I re-submitted my original CSR, and after receiving the re-re-issued cert I was able to successfully sign using osslsigncode.
Tested with osslsigncode verify <exe-name>
I ended up getting this to work by using the -pkcs12 <pkcs12 file> argument instead of the -cert <certificate file> and -key <key file> arguments. The .pfx file I used was generated from the exact same .spc and .pvk files I was supplying to osslsigncode, but for whatever reason, it worked while they didn't.
The error message "No signature was present in the subject" can be caused by a mismatch between the private key used for signing and the public key in the certificate.
I use sourcerepo.com as SVN server. My XCode5 bot complains : error validating server certificate for "https://myproject.sourcerepo.com:443"
- the certificate is not issued by a trusted authority. Use the fingerprint etc....
How can I make my XCode Server accept this svn server and retrieve sources ?
thanks for your advice
Frank
Verify why the certificate is untrusted. (E.g., is it a self-signed certificate?)
Start Terminal and run svn info https://myproject.sourcerepo.com:443/<path-to-repository>. Accept the certificate permanently when prompted.
I found a way to make it work from the Xcode 5 release notes:
https://developer.apple.com/library/ios/releasenotes/developertools/rn-xcode/xc5_release_notes/xc5_release_notes.html
Communicating with a remote SVN repository over HTTPS can fail with an
error similar to “Error validating server certificate for server
name.” Edit the file
/Library/Server/Xcode/Config/xcsbuildd.plist
and change the TrustSelfSignedSSLCertificates key from false to true.
Then, from a Terminal window, run:
sudo killall xcsbuildd
I did exactly the above. To edit the file you actually need to
sudo vi /Library/Server/Xcode/Config/xcsbuildd.plist
After restarting the build daemon I was able to get my Xcode bot to checkout the sources from the remote repository and perform the integration. Hope this helps!