We need to dual sign our binaries with SHA1 and SHA2 using signtool.exe, our certificate supports 256-bit SHA2.
Using the Windows 8 SDK's signtool:
e.g.:
signtool.exe sign /as /fd sha256 /t http://timestamp.verisign.com/scripts/timstamp.dll /f "certificate.pfx" /p XXXXXXX "file.dll"
(where XXXXXXX is our password for the certificate)
fails with the cryptic error:
SignTool Error: SignedCode::Sign returned error: 0x80070057
The parameter is incorrect.
SignTool Error: An error occurred while attempting to sign: file.dll
Signing without a timestamp works, signing individually as SHA1 or SHA256 works, but we need to dual sign, and imagine not having a timestamp is a no no.
I've tried the 32 and 64-bit versions of signtool.exe, tried it on a Win7 and Win8 machine, and tried playing around with the command line options but to no avail. Has anyone hit on this issue before?
I know it's a bit old, but I landed in this thread and maybe someone else will too.
It will work if you sign first with SHA1 and then with SHA256:
signtool.exe sign /f cert_file.pfx /t http://timestamp.comodoca.com/authenticode /p cert_password
signtool.exe sign /f cert_file.pfx /as /fd sha256 /tr http://timestamp.comodoca.com/rfc3161 /td sha256 /p cert_password
It worked using the same certificate in both signatures. I used the signtool from Windows 10 SDK, don't know if it will work with previous versions.
I've been trying to do this exact thing, and found the following did the trick. This approach relies on using two Authenticode certificates, one for SHA-1 and another for SHA-256, in order to ensure the files are accepted as valid by Windows Vista and Windows Server 2008 which do not support being signed by a SHA-256 certificate even if the SHA-1 algorithm is used:
signtool.exe sign /sha1 SHA1_Thumprint /v /d "FileDescription" /du "CompanyURL" /fd sha1 /tr http://timestamp.comodoca.com/rfc3161 /td sha1 "FileName.dll"
signtool.exe sign /sha1 SHA256_Thumprint /as /v /d "FileDescription" /du "CompanyURL" /fd sha256 /tr http://timestamp.comodoca.com/rfc3161 /td sha256 "FileName.dll"
Note that the SHA-1 thumbprints are explicitly specified for each signing step using the /sha1 switch and that /as is used to append the SHA-256 signature. Otherwise the SHA-256 signature will override the SHA-1 signature.
The other gotcha I found in the process was that only DLLs and EXEs support dual signatures. MSI installers do not.
Updated 29/12/15:
The format of the SHA-1/SHA-256 thumbprint is a 40-character hexadecimal upper case string with no spaces. For example:
signtool.exe sign /sha1 0123456789ABCDEF0123456789ABCDEF01234567 /as /v /d "FileDescription" /du "CompanyURL" /fd sha256 /tr http://timestamp.comodoca.com/rfc3161 /td sha256 "FileName.dll"
Updated 30/12/2015
To sign an MSI file with a SHA-256 certificate but with a SHA-1 hash use a command similar to the below:
signtool.exe sign /sha1 SHA256_Thumprint /v /d "FileDescription" /du "CompanyURL" /t http://timestamp.comodoca.com/authenticode "FileName.msi"
The issue is actually way simpler.
The problem is with the time stamp server.
Instead of using signtool.exe with this
/t http://timestamp.comodoca.com
You need to use it like this for SHA1
/tr http://timestamp.comodoca.com /td sha1
And for SHA256
/tr http://timestamp.comodoca.com/?td=sha256 /td sha256
Try using
signtool.exe sign /as /fd sha256 /tr http://timestamp.geotrust.com /td sha256 /f certificate.pfx /p XXXXXX file.dll
/tr is for RFC3161 timestamping, /td obviously for the hash to use.
Adding to martin_costello answer, XP and Vista do not support the RFC timestamp. You need to use the /t option for sha1 signatures.
signtool.exe sign /sha1 SHA1_Thumprint /v /d "FileDescription" /du "CompanyURL" /fd sha1 /t http://timestamp.verisign.com/scripts/timestamp.dll "FileName.dll"
signtool.exe sign /sha1 SHA256_Thumprint /as /v /d "FileDescription" /du "CompanyURL" /fd sha256 /tr http://timestamp.comodoca.com/rfc3161 /td sha256 "FileName.dll"
I also get the above error, however It works with the osslsigncode utility when using the '-nest' option:
osslsigncode sign -pkcs12 cert1.pfx -h sha1 -t http://timestamp.verisign.com/scripts/timestamp.dll -in original.exe -out intermediate.exe
osslsigncode sign -pkcs12 cert2.pfx -nest -h sha1 -t http://timestamp.verisign.com/scripts/timestamp.dll -in intermediate.exe -out final.exe
The official project is for Unix, however I've knocked up my own windows fork.
I think this link has some nice pointers. Some of it is mentioned in the answer by martin_costello, but this article provides some more details. In particular:
'Dual signing and include an SHA1 file digest' is possible if you sign SHA1 first, and use /as for the SHA256. It only works with signtool v6.3 from the Windows 8.1 SDK (or later) though.
Dual signing with 'a FULL SHA1 signature', needed for windows version before XP sp3, requires 2 different certificates.
(I haven't tested all this myself though.)
Related
Earlier today, I was trying to generate a certificate with a DNSName entry in the SubjectAltName extension:
$ openssl req -new -subj "/C=GB/CN=foo" -addext "subjectAltName = DNS:foo.co.uk" \
-addext "certificatePolicies = 1.2.3.4" -key ./private-key.pem -out ~/req.pem
This command led to the following error message:
name is expected to be in the format /type0=value0/type1=value1/type2=... where characters may be escaped by . This name is not in that format: 'C:/Program Files/Git/C=GB/CN=foo'
problems making Certificate Request
How can I stop Git Bash from treating this string parameter as a filepath, or at least stop it from making this alteration?
The release notes to the Git Bash 2.21.0 update today mentioned this as a known issue. Fortunately, they also described two solutions to the problem:
If you specify command-line options starting with a slash, POSIX-to-Windows path conversion will kick in converting e.g. "/usr/bin/bash.exe" to "C:\Program Files\Git\usr\bin\bash.exe". When that is not desired -- e.g. "--upload-pack=/opt/git/bin/git-upload-pack" or "-L/regex/" -- you need to set the environment variable MSYS_NO_PATHCONV temporarily, like so:
MSYS_NO_PATHCONV=1 git blame -L/pathconv/ msys2_path_conv.cc
Alternatively, you can double the first slash to avoid POSIX-to-Windows path conversion, e.g. "//usr/bin/bash.exe".
Using MSYS_NO_PATHCONV=1 can be problematic if your script accesses files.
Prefixing with a double forward slash doesn't work for the specific case of OpenSSL, as it causes the first DN segment key to be read as "/C" instead of "C", so OpenSSL drops it, outputting:
req: Skipping unknown attribute "/C"
Instead, I used a function that detects if running on bash for Windows, and prefixes with a "dummy" segment if so:
# If running on bash for Windows, any argument starting with a forward slash is automatically
# interpreted as a drive path. To stop that, you can prefix with 2 forward slashes instead
# of 1 - but in the specific case of openssl, that causes the first CN segment key to be read as
# "/O" instead of "O", and is skipped. We work around that by prefixing with a spurious segment,
# which will be skipped by openssl
function fixup_cn_subject() {
local result="${1}"
case $OSTYPE in
msys|win32) result="//XX=x${result}"
esac
echo "$result"
}
# Usage example
MY_SUBJECT=$(fixup_cn_subject "/C=GB/CN=foo")
Found a workaround by passing a dummy value as the first attribute, for example: -subj '//SKIP=skip/C=gb/CN=foo'
I had the same issue using bash, but running the exact same command in Powershell worked for me. Hopefully this will help someone.
Searched all the questions related to recover keyerror, got no answer on my situation.
So, I just have several simple operations:
install jmeter 4.0 (on centos 7)
cd to the bin directory, run ./create-rmi-keystore.sh and pressed Enter in each steps(entered a password 123654 at final step), and finally it gives me
Warning:
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore rmi_keystore.jks -destkeystore rmi_keystore.jks -deststoretype pkcs12".
Copy the generated rmi_keystore.jks to jmeter/bin folder or reference it in property 'server.rmi.ssl.keystore.file'
so I run keytool -importkeystore -srckeystore rmi_keystore.jks -destkeystore rmi_keystore.jks -deststoretype pkcs12 and give a password 123654
It gives me:
Enter source keystore password:
keytool error: java.io.IOException: Keystore was tampered with, or password was incorrect
Can anybody give a hand, Thanks advance:)
solved by this , to answer the question What is your first and last name?, you'll have to reply with rmi which must be a corresponding value with server.rmi.ssl.keystore.alias in jmeter.propertise.
I'm currently working on a project that must be a platform signed system app to be privileged to communicate on the I2C bus of a proprietary Android device.
The manifest contains android:sharedUserId="android.uid.system" and the resulting unsigned apk is signed, zipaligned and installed with this batch...
java -jar signapk.jar platform.x509.pem platform.pk8 unsigned.apk signed.apk
zipalign -f -v 4 signed.apk aligned.apk
adb install -rg aligned.apk
This works fine. However, I need to do extensive development running with this privilege requiring the debugger to be attached. I have tried using a custom Configuration that retains the debugger symbols while including the Mono runtime in the package only to find out that you cannot attach to an already running Android app from Xamarin.
Is there a way to create a keystore that is signed with the platform signature that I could put in ...\AppData\Local\Xamarin\Mono for Android\ to replace debug.keystore? The idea being that the debug build-deploy process would pick this up and I'd have the privileges I need AND have attachment to the debugger.
Any help much appreciated.
You can create a JKS keystore from a DER-encoded PKCS #8 private key and the corresponding PEM-encoded X.509 certificate as follows:
openssl pkcs8 -inform der -in platform.pk8 -nocrypt -out platform.key
openssl pkcs12 -export -in platform.x509.pem -inkey platform.key -out platform.p12
keytool -importkeystore \
-srckeystore platform.p12 -srcstoretype pkcs12 \
-destkeystore platform.keystore \
-deststorepass android -destkeypass android
shred -u platform.key platform.p12
For those following, after I performed the steps from Alex, I added this to the .csproj file to get Visual Studio to use it for this specific example.
<PropertyGroup Condition="'$(Configuration)' == 'Debug'">
<AndroidKeyStore>True</AndroidKeyStore>
<AndroidSigningKeyStore>(path)\platform.keystore</AndroidSigningKeyStore>
<AndroidSigningStorePass>android</AndroidSigningStorePass>
<AndroidSigningKeyAlias>1</AndroidSigningKeyAlias>
<AndroidSigningKeyPass>android</AndroidSigningKeyPass>
</PropertyGroup>
I developed a driver an with makecert, certmgr and signtool. I created a digital signature (for Win 7 64 bit) and sign it to the driver (.sys-File). In the settings of the sys-file I see that he has the digital-File which is also value.
In the mmc->certificates I see the creates signature under trusted certificates.
When I start the driver with sc start then come the error 577 that the digital signature cannot be checked.
What am I doing wrong?
I created the signature with the following command line statements:
makecert.exe -$ individual -r -pe -ss "my Certificates" -n CN="certmaker" "myfirstcert.cer"
certmgr.exe /add "myfirstcert.cer" /s /r localMachine root
SignTool.exe sign /v /s "my Certificates" /n "certmaker" /t http://timestamp.verisign.com/scripts/timstamp.dll "C:\Windows\System32\driversMyFirstDriver.sys"
May somebody help me tell why I got this illegal option? I used also C:/Users/myAccount
You need to put quotes around your file specification:
blah blah -keystore "c:\documents and settings\...keystore" blah blah
Otherwise it's treated as multiple arguments first c:\documents, then and (which is what's causing you grief) and so on.
In other words, by not quoting the path, the arguments being seen by your keytool program (other than the program name itself) are:
-exportcert
-alias
androiddebugkey
-keystore
/ C:\Documents
| and
\ Settings\Administrator\.android\debug.keystore
-list
-v
where the three indicated lines should really constitute a single argument.
Your -keystore path is being interpreted as multiple arguments. Surrounding it with double quotes (") shoud help.