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"?
