Code signing Excel Add-In makes Excel think it's tampered - code-signing

We've created an Excel DNA AddInand we're getting it ready for the wild. So we want to have it signed with our organisation's code-signing certificate.
So, after receiving a pfx certificate, I installed it to my personal space and grabbed the thumbprint and used the SignFile task in our .csproj file to make signed output files on a release build.
Here is the code from the csproj file. Worth noting that there is an AfterBuild target that copies the output files to the out directory and renames them.
<Target Name="SignOutputs" AfterTargets="AfterBuild"
Condition="$(Configuration) == 'Release'">
<PropertyGroup>
<FileToSign32>$(SolutionDir)out\AddIn.xll</FileToSign32>
<FileToSign64>$(SolutionDir)out\AddIn64.xll</FileToSign64>
<CertificateThumbprint>8ccfeae0....</CertificateThumbprint>
<TimestampUrl>http://timestamp.digicert.com</TimestampUrl>
</PropertyGroup>
<SignFile CertificateThumbprint="$(CertificateThumbprint)" SigningTarget="$(FileToSign32)" TimestampUrl="$(TimestampUrl)" />
<SignFile CertificateThumbprint="$(CertificateThumbprint)" SigningTarget="$(FileToSign64)" TimestampUrl="$(TimestampUrl)" />
</Target>
This correctly signs the output files. When you look at the digital signature of the files, it's all happy and good - "This digital signature is OK", etc. The certificate has another 3 years on it, so we're definitely in date.
Running signtool verify on it returns okay as well.
signtool verify /v /pa "AddIn.xll"
Verifying: AddIn.xll
Signature Index: 0 (Primary Signature)
Hash of file (sha256): Hash here
Signing Certificate Chain:
Issued to: DigiCert Assured ID Root CA
Issued by: DigiCert Assured ID Root CA
Expires: Mon Nov 10 01:00:00 2031
SHA1 hash: Hash here
Issued to: DigiCert SHA2 Assured ID Code Signing CA
Issued by: DigiCert Assured ID Root CA
Expires: Sun Oct 22 13:00:00 2028
SHA1 hash: Hash here
Issued to: Us
Issued by: DigiCert SHA2 Assured ID Code Signing CA
Expires: Wed Oct 09 13:00:00 2019
SHA1 hash: Hash here
The signature is timestamped: Tue Oct 25 11:29:42 2016
Timestamp Verified by:
Issued to: DigiCert Assured ID Root CA
Issued by: DigiCert Assured ID Root CA
Expires: Mon Nov 10 01:00:00 2031
SHA1 hash: Hash here
Issued to: DigiCert Assured ID CA-1
Issued by: DigiCert Assured ID Root CA
Expires: Wed Nov 10 01:00:00 2021
SHA1 hash: Hash here
Issued to: DigiCert Timestamp Responder
Issued by: DigiCert Assured ID CA-1
Expires: Tue Oct 22 01:00:00 2024
SHA1 hash: Hash here
Successfully verified: AddIn.xll
Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0
I thought this meant it was all signed and happy. So I went ahead and ran this in Excel, and received a warning message:
Warning: The digital signature on this application add-in is invalid and cannot
be trusted. Application add-in is disabled.
Bemused, mythed and befuddled, I flailed around until I managed to stumble across Enable Trust Center logging. Then, I managed to find the Trust Center logs. For the AddIn, it has this entry.
---
Content Type: Add-in DLL
Binary: "C:\development\out\AddIn.xll"
Certificate: Us
Certificate Signature: DigiCert SHA2 Assured ID Code Signing CA
Certificate Status: Tampered
Trust Center Decision: Block Content
User Decision: Block Content
Error Code: 80096001
80096001 according to MSDN apparently maps to this message: "A system-level error occurred while verifying trust".
That doesn't give me much to go on. I can't see anything obviously wrong, but it's possible I'm missing something.
Signing with signtool in the dev command prompt yields the same result.
I've just been running in circles on Google, and I'm starting to get to the point now where the results are offering me executables to fix the corrupted system files that cause this (spoiler: they're almost certainly malware). So I think I need some guidance.
How do I sign my XLL files without having them come up as "tampered"?

Related

How to set up the issuer of the certificate is Microsoft testing root certificate authority?

I use makecert.exe to get a KM_test1.cer, and then run signtool sign <myfile.dll> to sign myfile.dll. but it failed when I run signtool verify <myfile.dll>.
C:\Windows\System32>>makecert.exe -r -pe -ss PrivateCertStore -n CN=KM_test1 KM_test1.cer
Successed
C:\Windows\System32>>certmgr.msc
// drop this.cer file to Personal store
C:\Windows\System32>>signtool sign /fd sha1 "myfile.dll"
Done Adding Additional Store
Successfully signed: myfile.dll
C:\Windows\System32>signtool verify /debug "myfile.dll"
Signature Index: 0 (Primary Signature)
Hash of file (sha1): 32AEC1684BEACFDA35755E7342ADDA4B5196BF40
Signing Certificate Chain:
Issued to: KM_test1
Issued by: KM_test1
Expires: Sun Jan 01 08:59:59 2040
SHA1 hash: xxxxxxxxxxxxxxxxCC62D5F31D39188206765D27
File is not timestamped.
SignTool Error: A certificate chain processed, but terminated in a root
certificate which is not trusted by the trust provider.
I have a file that can pass signtool vertify "correctFile.dll" and work for my project. it prints the follow info:
C:\Windows\System32>signtool verify /debug correctFile.dll
Verifying: correctFile.dll
Signature Index: 0 (Primary Signature)
Hash of file (sha1): xxxxxxxxxxxxxxxxxxxx7445032578A8D7B6EFAC
Signing Certificate Chain:
Issued to: Microsoft Testing Root Certificate Authority 2010
Issued by: Microsoft Testing Root Certificate Authority 2010
Expires: Mon Jun 18 06:04:11 2035
SHA1 hash: xxxxxxxxxxxxxxxxxxxxxx6A76B8178FA215F344
Issued to: Microsoft Testing PCA 2010
Issued by: Microsoft Testing Root Certificate Authority 2010
Expires: Mon Jun 18 06:04:11 2035
SHA1 hash: xxxxxxxxxxxxxxxxxxxxxAFC0BE2F1D13AB21773
Issued to: Microsoft Windows Publisher
Issued by: Microsoft Testing PCA 2010
Expires: Mon Nov 28 02:21:47 2022
SHA1 hash: xxxxxxxxxxxxxxxxxxx1305E8B85AC0BA257DDDF
File is not timestamped.
Successfully verified: correctFile.dll
Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0
i guess the problem is located in Signing Certificate Chain. Maybe it will work if i set the issuer of certificate is Microsoft Testing Root Certificate Authority 2010. So, does anyone have an idea about this issue?

Driver signing works for some machines only

I developed a kernel-mode driver and signed it with a "standard" code signed certificate because at this time I do not know about Win 10 driver signing.
I tested the driver on many systems from Win7 up to different Win10 machines (real machines and VMs too). The curious thing is: the driver works well on every test setup.
Now, I got some reports that the driver doesn't work on some Win10 machines due to a singning problem.
I tried to install the driver on my own machine and discovered the same problem:
Installation using dpinst works without problems. But the Device Manager shows
Windows cannot verify the digital signature for the drivers required for this device. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source. (Code 52)
Verifying the driver using signtool for kernel mode divers states:
> .\signtool.exe verify /kp driver.cat
File: C:\Users\...\driver.cat
Signature Index: 0 (Primary Signature)
Hash of file (sha1): 1CF4B984575F15AC0A2CAF3C3B138F8B58867E35
Signing Certificate Chain:
Issued to: VeriSign Class 3 Public Primary Certification Authority - G5
Issued by: VeriSign Class 3 Public Primary Certification Authority - G5
Expires: Thu Jul 17 01:59:59 2036
SHA1 hash: 4EB6D578499B1CCF5F581EAD56BE3D9B6744A5E5
Issued to: Symantec Class 3 SHA256 Code Signing CA
Issued by: VeriSign Class 3 Public Primary Certification Authority - G5
Expires: Sun Dec 10 01:59:59 2023
SHA1 hash: 007790F6561DAD89B0BCD85585762495E358F8A5
Issued to: #############
Issued by: Symantec Class 3 SHA256 Code Signing CA
Expires: Tue Mar 21 01:59:59 2023
SHA1 hash: C0AF3235EF9FAABE789A306C4AC9F20E80DE7BDB
The signature is timestamped: Wed Apr 27 09:56:50 2022
Timestamp Verified by:
Issued to: DigiCert Trusted Root G4
Issued by: DigiCert Trusted Root G4
Expires: Fri Jan 15 14:00:00 2038
SHA1 hash: DDFB16CD4931C973A2037D3FC83A4D7D775D05E4
Issued to: DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA
Issued by: DigiCert Trusted Root G4
Expires: Mon Mar 23 01:59:59 2037
SHA1 hash: B6C8AF834D4E53B673C76872AA8C950C7C54DF5F
Issued to: DigiCert Timestamp 2022 - 2
Issued by: DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA
Expires: Tue Mar 15 01:59:59 2033
SHA1 hash: 8508F386515CB3D3077DB6B4B7C07F1B4A5E41DE
SignTool Error: The signing certificate is not valid for the requested usage.
Number of files successfully Verified: 0
Number of warnings: 0
Number of errors: 1
If I'm right, I need a EV code signing certificate to sign the driver for Win10?
If yes, the result of the verification using signtool is not unexpected.
Nevertheless - I'm confused because I can install and run the driver on serveral Win10 test machines without any problem. It seems that there is no difference if the system is up-to-date or not. There are x86 and x64 systems, Home and Pro versions, activated and not-activated setups. On almost all devices the driver still works very well.
That means it is not really necessary to use a "specific" certificate or messed I something up?
The different behaviour of the test setup is caused by Secure Boot. If this is enabled, the driver will be rejected.

impossible gpg signature verification

wget https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/cryptsetup-1.7.3.tar.xz
wget https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/cryptsetup-1.7.3.tar.sign
wget https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/sha256sums.asc
shasum verified: ok
gpg --verify cryptsetup-1.7.3.tar.sign cryptsetup-1.7.3.tar.xz
the output is bad :
gpg: Signature made Sun 30 Oct 2016 01:56:01 PM UTC using RSA key ID D93E98FC
gpg: BAD signature from "Milan Broz <gmazyland#gmail.com>"
then
wget https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.3-ReleaseNotes
wget https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.3-ReleaseNotes.sign
gpg --verify v1.7.3-ReleaseNotes.sign v1.7.3-ReleaseNotes
this is good (although the warning):
gpg: Signature made Sun 30 Oct 2016 01:56:09 PM UTC using RSA key ID D93E98FC
gpg: Good signature from "Milan Broz <gmazyland#gmail.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 2A29 1824 3FDE 4664 8D06 86F9 D9B0 577B D93E 98FC
I make another test on another website:
wget https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.0.30.tar.bz2
wget https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.0.30.tar.bz2.sig
and everything is good as well.
Then I go to the author's blog (Milan Broz's blog), but the download link leads to the same website.
I tried some previous packages and had the same issue:
cryptsetup-1.7.1.tar.sign with cryptsetup-1.7.1.tar.gz & cryptsetup-1.7.1.tar.xz
cryptsetup-1.7.2.tar.sign with cryptsetup-1.7.2.tar.gz & cryptsetup-1.7.2.tar.xz
If I miss something here, plz tell me what.
otherwise, is there a place where I can have a correctly signed version of this software?
thanx folks.
is there a place where I can have a correctly signed version of this software?
Try from the official website: https://gitlab.com/cryptsetup/cryptsetup (now -- Nov. 2017, 9 months later, in 1.7.5 or 2.0-rc1)
this is good (although the warning):
The warning is expected. See "Check PGP Signature and Install Veracrypt 1.17":
The "WARNING: This key is not certified with a trusted signature! There is no indication that the signature belongs to the owner." means that the Veracrypt public key is not signed by you or by anybody whose key you have signed, so there is no direct line of trust between you and the Veracrypt developers.
This is as expected.

Firefox ignores signature on successfully signed XPI - how to diagnose?

I've created a Firefox plugin, a Win32-native code DLL - using Firebreath. I'm working on Windows 7/x64, and targeting Windows only. The plugin itself is working well, but I'm really stuck getting a correctly signed XPI. If I don't sign my XPI, it's accepted and installed by FF 3.6 thru 10 (beta). Of course, during the install it lists the publisher as (Author not verified). So, I spent a week debugging the signing process... but FF 9 and 10 still say (Author not verified)! FF 3.6 rejects the signed XPI as invalid.
How do I troubleshoot this??
Just to repeat: I sign the xpi without error, and the resulting XPI installs successfully on FF 9 and 10, but FF still says (Author not verified).
Here's the batch code I use to sign the XPI:
echo * clean out old signing folder and xpi
if exist package rmdir /S /Q package
if exist %package%.xpi del %package%.xpi
echo * copy in files for package
md package
xcopy ..\*.rdf package
md package\plugins
xcopy ..\build\bin\Plugin\Debug\*.dll package\plugins
echo * clean out certificate database
del *.db
echo * import our signing certificate
pk12util -d . -i %keyfile% -K %pwd% -w keypass.txt
echo * adjust trust on base, intermediate and root cert
certutil -M -d . -n "VeriSign" -t "c,c,C"
certutil -M -d . -n "VeriSign Class 3 Code Signing 2010 CA - VeriSign, Inc." -t "TC,TC,TC"
certutil -M -d . -n "%certname%" -t "u,u,Cu"
certutil -L -d .
echo * create signed package
signtool -d . -X -Z %package%.xpi -k "%certname%" -p %pwd% package
I work for Mozilla, but this isn't an authoritative answer, just what I've gathered asking around:
So, essentially, each certificate authority has three trust bits Mozilla might grant it: they might trust it to sign websites, and/or mail, and/or code. Your certificate is from a certificate authority that Mozilla doesn't trust to sign code. (This is why going and manually setting the bit in your preferences makes it work—for you.)
I'm told so few people try to use binary code in xpi's that Mozilla doesn't really have an organized way to find out which authorities can be used for what. However, you can check out this list: look at the "Code Trust Bit":
https://spreadsheets.google.com/pub?key=ttwCVzDVuWzZYaDosdU6e3w&single=true&gid=0&output=html
For example (picked completely at random), ComSign Secured CA has the "Websites" and "Code" trust bits set.
I gather that Mozilla publicly discusses what rights to grant to each CA, and re-evaluates each CA periodically:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
Basically your signature needs to include full certificate chain up to the trusted VeriSign root certificate, bypassing the "VeriSign Class 3 Public Primary Certification Authority - G5" with unknown trust in mozilla (bug 602107), as by default the chain ends too soon.
Your XPI is currently signed with your certificate, with no further certificate chain included, relying that the user's browser will trust the issuer of your certificate immediately. You can examine this with Mozilla's jarsigner tool (see Mozilla NSS tools):
Tools\nss-3.11>jarsigner -verify -verbose -certs my-old.xpi
2057 Thu Sep 15 15:17:44 CEST 2011 META-INF/zigbert.rsa
sm 87 Thu Sep 15 15:17:44 CEST 2011 chrome.manifest
X.509, CN=Company Name inc., OU=General, OU=Digital ID Class 3 - Microsoft Software Validation v2, O=Company Name inc., L=City, ST=State, C=XX
[certificate will expire on 26.4.13 0:59]
(showing just the output for the 1st file)
You need to include a few more certificates to complete the chain to a certificate that is by default explicitly trusted in the end user's browser. In the end it should look like this:
jarsigner -verify -verbose -certs my-newly-signed.xpi
2057 Thu Sep 15 15:17:44 CEST 2011 META-INF/zigbert.rsa
sm 87 Thu Sep 15 15:17:44 CEST 2011 chrome.manifest
X.509, CN=Company Name inc., OU=General, OU=Digital ID Class 3 - Microsoft Software Validation v2, O=Company Name inc., L=City, ST=State, C=XX
[certificate will expire on 26.4.13 0:59]
X.509, CN=VeriSign Class 3 Code Signing 2010 CA, OU=Terms of use at https://www.verisign.com/rpa (c)10, OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
[certificate is valid from 8.2.10 1:00 to 8.2.20 0:59]
[KeyUsage extension does not support code signing]
X.509, CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
[certificate is valid from 8.11.06 1:00 to 8.11.21 0:59]
[KeyUsage extension does not support code signing]
X.509, OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
[certificate is valid from 23.5.06 19:01 to 23.5.16 19:11]
To achieve this you need to:
remove the not-explicitly-trusted VeriSing's built-in certificates from the certificate database with Mozilla's certutil tool
Build the certificate trust chain of your certificate all the way up to Microsoft's "Class 3 Public Primary Certification Authority".
sign the xpi (this time full certificates chain will be included in the signature)
verify the xpi with jarsigner as described above
test the xpi in Firefox - you should not see "Author not verified" anymore.
Caveats:
Trust bits in the built-in Firefox certificate store are actually 3-state (trusted, untrusted and unknown), despite only being shown as 2-state checkbox in the FF GUI (checked=trusted, unchecked=untrusted OR unknown). By default trust is unknown, which enables you to bypass the VeriSign's certificate as described. If you ever enabled trust via FF's checkboxes it will still work, but if you uncheck the trust checkbox the trust will be set to untrusted, which will prevent bypassing that certificate in the chain. The easiest (only?) way to reset this back to initial unknown is to delete your firefox profile.
After Mozilla eventually enables the code-signing trust bit (see the bug above) you will still need to sign like this if you want to support older versions of Firefox.
Hope it helps!

Why is my code signing (MS authenticode) verification failing?

I posted this question and have a freshly minted code signing cert from Thawte.
I followed the instructions (or so I thought) and the code signing claims to succeed, however when I try to verify the tool shows an error.
The results from the verification step seem to show it is correct, however there is an error and no explanation whatsoever about why the error exists.
Any comments or suggestions are much appreciated.
Command line to sign exe:
signtool sign /f mdt.pfx /p password /t http://timestamp.verisign.com/scripts/timstamp.dll test.exe
Results:
The following certificate was selected:
Issued to: [my company]
Issued by: Thawte Code Signing CA
Expires: 4/23/2011 7:59:59 PM
SHA1 hash: 7D1A42364765F8969E83BC00AB77F901118F3601
Done Adding Additional Store
Attempting to sign: test.exe
Successfully signed and timestamped: test.exe
Number of files successfully Signed: 1
Number of warnings: 0
Number of errors: 0
Note that there are no errors or warnings.
Now, when I try to verify imagine my surprise:
signtool verify /v test.exe
results in:
Verifying: test.exe
SHA1 hash of file: 490BA0656517D3A322D19F432F1C6D40695CAD22
Signing Certificate Chain:
Issued to: Thawte Premium Server CA
Issued by: Thawte Premium Server CA
Expires: 12/31/2020 7:59:59 PM
SHA1 hash: 627F8D7827656399D27D7F9044C9FEB3F33EFA9A
Issued to: Thawte Code Signing CA
Issued by: Thawte Premium Server CA
Expires: 8/5/2013 7:59:59 PM
SHA1 hash: A706BA1ECAB6A2AB18699FC0D7DD8C7DE36F290F
Issued to: [my company]
Issued by: Thawte Code Signing CA
Expires: 4/23/2011 7:59:59 PM
SHA1 hash: 7D1A42364765F8969E83BC00AB77F901118F3601
The signature is timestamped: 4/27/2010 10:19:19 AM
Timestamp Verified by:
Issued to: Thawte Timestamping CA
Issued by: Thawte Timestamping CA
Expires: 12/31/2020 7:59:59 PM
SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656
Issued to: VeriSign Time Stamping Services CA
Issued by: Thawte Timestamping CA
Expires: 12/3/2013 7:59:59 PM
SHA1 hash: F46AC0C6EFBB8C6A14F55F09E2D37DF4C0DE012D
Issued to: VeriSign Time Stamping Services Signer - G2
Issued by: VeriSign Time Stamping Services CA
Expires: 6/14/2012 7:59:59 PM
SHA1 hash: ADA8AAA643FF7DC38DD40FA4C97AD559FF4846DE
Number of files successfully Verified: 0
Number of warnings: 0
Number of errors: 1
Try Signtool verify /v /pa foo.exe
From Using SignTool to Verify a File Signature (emphasis is mine)
SignTool verify MyControl.exe
If the preceding example fails, it
could be that the signature used a
code-signing certificate. SignTool
defaults to the Windows driver policy
for verification.
The following command verifies the
signature, using the default
authentication verification policy:
SignTool verify /pa MyControl.exe

Resources