How to verify detached PKCS7 signature with signtool - cryptography

We have a file, say, scup.jpg, that we want to sign and (later) verify with signtool.
For embedded content we execute
signtool.exe sign /p7 .\ /p7ce embedded /p7co 1.2.840.113549.1.7.2 /a /f .\pfx.p12 /p "somepass" .\scup.jpg
and it produces a file named scup.jpg.p7 that is verifiable with the folowing command:
signtool.exe verify /p7 scup2.jpg.p7
but what we need is not an embedded data, but rather a detached signature, so we change the signing command to
signtool.exe sign /p7 .\ /p7ce DetachedSignedData /p7co 1.2.840.113549.1.7.2 /a /f .\pfx.p12 /p "somepass" .\scup.jpg
and produce a detached signature file also named scup2.jpg.p7, but no matter what command options we try to verify the signature, signtool gives us errors, like tis one:
SignTool Error: CryptVerifyMessageSignature returned error: 0x8009310B
ASN1 bad tag value met.
SignTool Error: File not valid: scup.jpg.p7
Number of errors: 1
What do we do wrong and is it at all possible to verify a detached signature with signtool? I know I could use openssl or progarmming tools/API, but for the moment I need clarity regarding signtool itelf.

Related

msbuild fails on Certificate could not be opened, network password not correct

I am trying to create a signed appx package as a test using a purchased code signing certificate. I cannot get it to build without installing the cert locally first (which I don't want to do given this will be done in a CI/CD environment).
I am executing the following on a solution containing an empty WPF project and WAP project.
msbuild $Solution_Path /p:Platform=x64 /p:Configuration=Release
/p:UapAppxPackageBuildMode=SideLoadOnly /p:AppxBundlePlatforms="x64"
/p:AppxPackageDir=$App_Packages_Directory /p:AppxBundle=Never
/p:AppxPackageSigningEnabled=true /p:PackageCertificateThumbprint=$myThumbprint
/p:PackageCertificateKeyFile=$myCert /p:PackageCertificatePassword=$myPassword
error: Certificate could not be opened
error: The specified network password is not correct
I have confirmed the password of $myPassword and thumbprint is $myThumprint by importing the cert and verifying it. I have also tried assigning "" to $myThumprint. I have confirmed the location of $myCert
It will build if I assign AppxPackageSigningEnable=false, but it will be unusable as it is not signed.
In appxmanifest, I have assigned Identity/Publisher to the publisher id of the cert (e.g., Publisher="CN=John Doe, O=Acme, L=TheMoon, S=OuterSpace, C=Universe") and Properties/PublisherDisplayName = the cert's CN (=John Doe)
I have tried exporting the pfx into a cer and using that, but that fails on the cert is not usable as it doesn't include a private key.
I have tried exporting the pfx into a base64 string and then creating a pfx from that - still fails (desperate measures).
Any tips greatly appreciated!
I read that a password protected cert needs to be stored in a cert store for msbuild to use it. Therefore, I ignored the cert on build and added it later by doing the following:
Remove all signing parameters from msbuild as follows
msbuild $Solution_Path /p:Platform=x64 /p:Configuration=Release
/p:UapAppxPackageBuildMode=SideLoadOnly /p:AppxBundlePlatforms="x64"
/p:AppxPackageDir=$App_Packages_Directory /p:AppxBundle=Never
/p:AppxPackageSigningEnabled=false
Given the name of the appx will change based on version and I couldn't find a way to pass wildcards to the SignTool, I used this to grab the built appx:
$Packages_2Sign = (Get-ChildItem -Recurse -Path $currentDirectory -Include *.appx).fullname
Finally, use the SignTool to sign the appx built from the prior step
SignTool sign /fd sha256 /a
/f $certificatePath /p $certificatePwd $Packages_2Sign

How to resolve error: light.exe error LGHT1105

We are not quite sure what triggered this error to start showing up in our builds.
light.exe : error LGHT1105: Validation could not run due to system policy. To eliminate this warning, run the process as admin or suppress ICE validation.
We are hoping to understand better what circumstances could trigger it, so we can work backwards and fix whatever is causing it.
We are already running as administrator
We checked our antivirus settings, and the source and output folders are excluded from scans.
We checked the size of the environment block using a debugger and it is only about 5.5k.
We tried adding both of these settings to the wixproj mentioned in the command line:
<RunWixToolsOutOfProc>true</RunWixToolsOutOfProc>`
<SuppressValidation>true</SuppressValidation>`
We checked and there were no Software Restriction Policies enabled.
e:\tools\managed\v4.0\WiX3.7\bin\Light.exe -out f:\obj.amd64fre\common\testplugin\msm\objfre\amd64\testplugin.msm -pdbout f:\obj.amd64fre\common\testplugin\msm\objfre\amd64\testplugin.wixpdb -nologo -sw1096 -wx -cultures:null -dPseudoCulture=tk-TM -dps-ps=1 -dProductVersion=10.0.1234.0 -dROOT=e:\rootpath -d_BuildArch=amd64 -dOBJECT_ROOT=f:\obj.amd64fre -d_BuildAlt=objfre\amd64\ -ext e:\tools\managed\v4.0\WiX3.7\bin\WixIIsExtension.dll -ext e:\tools\managed\v4.0\WiX3.7\bin\WixUtilExtension.dll -sice:ICE61 -contentsfile f:\obj.amd64fre\common\testplugin\msm\objfre\amd64\testplugin.msm.wixproj.BindContentsFileListnull.txt -outputsfile f:\obj.amd64fre\common\testplugin\msm\objfre\amd64\testplugin.msm.wixproj.BindOutputsFileListnull.txt -builtoutputsfile f:\obj.amd64fre\common\testplugin\msm\objfre\amd64\testplugin.msm.wixproj.BindBuiltOutputsFileListnull.txt -wixprojectfile e:\common\testplugin\msm\testplugin.msm.wixproj -fv -b f:\binaries.amd64fre\SCOnline f:\obj.amd64fre\common\testplugin\msm\objfre\amd64\testplugin.wixobj
Error:
5>light.exe : error LGHT1105: Validation could not run due to system policy. To eliminate this warning, run the process as admin or suppress ICE validation. [e:\common\testplugin\msm\testplugin.msm.wixproj]
Expect:
No error.

OpenSSL Decryption using a Key.txt and IV.txt file

Working with a client to set up OpenSSL file encryption. They've sent us an encrypted file (I'll call it sample.encrypted), along with key and iv files (key.txt and iv.txt).
The contents of the key.txt file look like this:
KEY: [string of 32 characters]
The contents of the iv.txt file look like this:
IV: [string of 16 characters]
I'm running Windows 7 Professional 64-bit, and learned that OpenSSL doesn't come installed by default with Windows (apparently it's primarily used by Linux users?)
So, I've downloaded and installed a 64-bit OpenSSL package from here:
(https:)//slproweb.com/products/Win32OpenSSL.html
Specifically, the "Win64 OpenSSL v1.0.2d Light" build found here:
(https:)//slproweb.com/download/Win64OpenSSL_Light-1_0_2d.exe
Once installed, I had to manually configure my environment variable for the OpenSSL config files as such (from the command prompt):
set OPENSSL_CONF=C:\OpenSSL-Win64\bin\openssl.cfg
I verified that the path information above was correct, and that the environment variable had stuck, and then attempted to run the following command:
openssl enc -d -K key.txt -iv iv.txt -in sample.encrypted -out sample.decrypted
This was based on the commands found here:https://www.openssl.org/docs/manmaster/apps/openssl.htmland here: https://www.openssl.org/docs/manmaster/apps/enc.html
The command breakdown being:
openssl - the OpenSSL base command
enc - the command used to begin encrypting/decrypting
-d - the tag used to specify decryption
-K - the tag used to specify the use of a key file
key.txt - the key file itself
-iv - the tag used to specify the use of an accompanying initialization vector
iv.txt - the IV file itself
-in - the tag used to specify the input file
sample.encrypted - the input file
-out - the tag used to specify the output file
sample.decrypted - the desired output file
As far as I can tell, the command works - the output file is generated, but its contents are not properly decrypted (it's just garbled text). I don't think there's anything wrong with the files that the client provided, but rather with my implementation of OpenSSL's commands to decrypt the file.
If anyone knows how to properly decrypt a file using provided Key and IV files, help would be greatly appreciated. I've been setting aside other responsibilities while Googling around trying to figure this out.

Jenkins fails in signtool.exe

I am using signtool.exe to sing my msi output through a proj file in Jenkins. My command to sign the msi is, "C:\Program Files\Microsoft SDKs\Windows\v6.1\Bin\signtool.exe" sign /f "C:\Build\SignCertificate.cer" /csp "Microsoft Enhanced Cryptographic Provider v1.0" /k privatekeycontainer /t "http://timestamp.verisign.com/scripts/timstamp.dll" "..\Release\output.msi" . The pfx file is added in certificate store.
Whenever i execute it through command prompt it get pass and the msi get signed. But if i try through Jenkins then it fails. Please help me what is wrong.
My problem was solved. The pfx is not imported with the private key properly. Now the leaf tells that it has a private key. So the problem is with the pfx file.
Import sertificate to Machine Store instead of User store. Steps described here
http://www.dartmouth.edu/~deploypki/materials/web_authn/pages/IISonXP_AddingTrustedCACertToComputer.htm
Try these steps:
Create a user 'Jenkins' as and Administrators group member
Run the Jenkins service as the user 'Jenkins'
log in as Jenkins user and install the certificate in the user store.
Run it through Jenkins
Also, take a look at this link which is very similar to your question:
SignTool Error: ISignedCode::Sign returned error: 0x80092006

SignTool internal error when trying to repackage an APPX package?

I'm analyzing existing Windows Store applications and modifying them to make sure my company's obfuscator works with them.
I've ran into a bit of a problem doing that though. I can grab an APPX package from the store easily enough(requires Fiddler to get the URL). I can then just use any unzip program to extract the appx to a folder. I can then take the assemblies in the APPX and modify the IL a bit. I then remake and sign the package:
makeappx pack /d "mypackage" /p "mypackage.appx"
signtool sign /fd sha256 /f temporarykey.pfx mypackage.appx
I then get an error with signtool though:
SignTool Error: An unexpected internal error has occured
Error information: "Error: SignerSign() failed." (-2147024885/0x800700b)
And then of course get an error when trying to install it with the standard powerscript file created by Visual Studio for installing/sideloading any APPX package.
Found package: C:\....mypackage.appx
Error: The package is not digitally signed or its signature is corrupted
I've used this exact process for packages generated from Visual Studio. Are temporary keys tied to a particular package or something? What am I missing? Is this a bug in signtool?
Apparently, you can't just take any temporary key and sign the APPX with it. In particular the certificate subject lines must match(the "publisher name"). I do not know of a better way of determining what the subject line much actually be. First, try to use signtool and sign the APPX file with any temporary key. Now go to Event Viewer. Then to Applications and Services and then Microsoft and then Windows and then AppxPackaging and finally Microsoft-Windows-AppxPackages/Operational. There should be an error event that just happened from that build. Check it. It should say something like
Error 0x800700B: The app manifest publisher name (CN=random-hex-number) must match the subject name of the signing certificate (CN=MyWrongName)
So, now make sure to hang on to that random-hex-number. That needs to be the subject line of the certificate and is the cause of the error. To generate a working certificate:
makecert.exe mycert.cer -r -n "CN=random-hex-number" -$ individual -sv private.pkv -pe -cy end
pvk2pfx -pvk private.pkv -spc mycert.cer -pfx mytemporarykey.pfx
Now finally, you should have a temporary key that will work with signtool!
Hopefully this answers serves other people well.