I'm having trouble signing a .NET Standard 2.0 assembly using the Set-Authenticode
powershell function as part of an Azure DevOps pipeline. I have written a little bit of powershell to go through assembles in a directory and apply signatures to each DLL in the folder:
$project = "${{ parameters.projects }}"; # todo: what about multi-line values here
$folderPath = [System.IO.Directory]::GetParent($project)
$files = Get-ChildItem -Path $folderPath -Filter "*.dll" -Recurse
$securePassword = ConvertTo-SecureString $(CertificatePassword) -AsPlainText -Force
$certificate = Get-PfxCertificate -FilePath $(CodeSignCertificate.secureFilePath) -NoPromptForPassword -Password $securePassword
foreach($file in $files) {
Write-Host "Setting Authenticode Signature for $file"
$result = Set-AuthenticodeSignature -FilePath $file -Certificate $certificate -Force -HashAlgorithm SHA256 -IncludeChain All -TimestampServer "http://tsa.starfieldtech.com"
if ($result.Status.ToString().Contains("Error")) { Write-Error $result.StatusMessage }
else {
Write-Host $result.Status.ToString()
Write-Host $result.StatusMessage.ToString()
}
}
The process appears to complete successfully, each DLL that is signed outputs the following message, as per the three Write-Host
lines in my script:
Setting Authenticode Signature for D:\a\1\s\...\SomeAssembly.dll
Valid
Signature verified.
Now, the problem becomes apparent when inspecting the DLL that is produced at the end of the build using the Nuget Package Explorer. I see the following error: "The file is signed, however the signed hash does not match the computed hash". This is seen here in this screenshot (the error appears as a tooltip when hovering over the red error icon).
I have also tried:
Running this locally with a self-signed certificate, which appears to work fine.
Running the build on an older build agent- in this case the signing process fails during the build with the error "Get-PfxCertificate : The specified network password is not correct".
Using signtool.exe. This produces the same error.
I've certainly run out of ideas now. What could I be missing?
I've actually figured this out on my own.
My Code signing pipeline step was followed by a strong-naming step. The strong-naming step was changing the hash of the assembly so it no longer matched the hash specified in the signature.
The solution was to move the strong-naming step to happen before the code signing one. Now I can successfully strong-name the assembly, sign it, then after packaging, I can sign the nuget package and all the signatures are valid in the output.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With