0

I have been trying to get a new Sectigo code signing certificate working, with no luck, and Sectigo support is utterly useless. I am testing with this code, with the executable of course pathed to an actual PS1 file.

$executable = 'PATH TO.ps1'
$cert = Get-ChildItem cert:\CurrentUser\My -codesign
$timeStampServer = "http://timestamp.sectigo.com"

The time server seems to be working, since $timeStampServer echos http://timestamp.sectigo.com to the console. And the certificate SEEMS to be working because $cert echos a Thumbprint and Subject to the console. But

Set-AuthenticodeSignature -filePath:$executable -certificate:$cert -timeStampServer:$timeStampServer -force

produces a blank SignerCertificate and UnknownError for the Status. For what it is worth the Path is just the file name, not the full path. Unlike this thread, $cert.privatekey produces

PublicOnly           : False
CspKeyContainerInfo  : System.Security.Cryptography.CspKeyContainerInfo
KeySize              : 4096
KeyExchangeAlgorithm : RSA-PKCS1-KeyEx
SignatureAlgorithm   : http://www.w3.org/2000/09/xmldsig#rsa-sha1
PersistKeyInCsp      : True
LegalKeySizes        : {System.Security.Cryptography.KeySizes}

I wonder, is there anything else I can do to test the situation? I am waiting (about 110 minutes to go) on Sectigo support before I try downloading and installing a reissued certificate, but as crap as their support has been, I don't expect the new cert to work any better than the old, nor do I expect any insight from them as to the problem. They have my money, I expect them to say "PowerShell is your problem". So, hoping for some suggestions here as to what could be the issue, and what steps to take to isolate the problem.

One thing that does perk my ears up is that this link suggests I should also see EnhancedKeyUsageList for $cert and I do not. And when I look at the cert with Certlm I don't see an Intended Purposes column at all. But I think that's an OS issue as actually looking at the Cert there under the General tab, I have Enable all purposes for this certificate selected, and Code Signing is checked in the greyed out list.

Now, oddly, I get a single line with only UnknownError when I run Set-AuthenticodeSignature without dumping a variable to the console. But, if I dump $cert to the console right before I get

SignerCertificate      : 
TimeStamperCertificate : 
Status                 : UnknownError
StatusMessage          : The data is invalid
Path                   : PATH TO.ps1
SignatureType          : None
IsOSBinary             : False

Again with the correct local path. The StatusMessage doesn't exactly add much, but the fact that the TimeStamperCertificate is also blank makes me wonder if that's the issue. Given how much it seems Sectigo sucks, can I use some other generic timestamp server I can use, or am I limited to using the Timestamp Server of the certificate issuer? I tried using the timestamp server I had been using with my old GlobalSign EV cert, "http://timestamp.globalsign.com/scripts/timestamp.dll", and that produces the same results. Also for what it is worth, the PS1 I am trying to sign for testing is one line

$scriptPath = Split-Path $script:myInvocation.myCommand.path -parent

I have never had such problems before. I had a Sectigo certificate last year and everything worked fine, but that was a different reseller, and in the meantime the Sectigo process seems to have changed. Last year my signed PDF from the KVK (Dutch Better Business Bureau) was fine for validation. But this year they demanded I provide a plain text translation of that document. And for years before I never had issues but then I was using a EV cert on a thumb drive. Which I gave up when GlobalSign took 4 months to get a thumb drive from London to Rotterdam.

But back on topic, suggestions?

EDIT: Further searching led to this, so I tried

$Cert = Get-PfxCertificate -FilePath "PATH TO.pfx"

And I put both the PFX and target PS1 in the root of C. Same results.

EDIT #2: After days of really horrible support from Comodo/Sectigo I demanded a refund, and bought a new certificate from SSL.Com. MUCH better experience with the validation process, but exactly the same issues with signing code. Now verified on both a Windows 10 and an old Windows 7 VM. So the code signing problem is definitely on my end. Meaning, more than ever I hope someone here can provide some insight.

Gordon
  • 6,257
  • 6
  • 36
  • 89

3 Answers3

0

We're sorry you're experiencing an issue. Here is some information to help resolve the issue. If you have any further questions, please feel free to contact Sectigo Support at https://sectigo.com/support and a member of our team will reach out to you.

Powershell ISE uses 'Unicode Big Endian' encoding and that could be the problem. Please try recreating the file using UTF-8 and set the Authenticode signature.

#creating the script into a new file
type \path\scriptfile.ps1 | out-file \path\scriptfile_utf.ps1 -encoding utf8

#get the certificate
$cert = Get-ChildItem cert:\CurrentUser\My -codesigning

#add Authenticode Signature to the script
Set-AuthenticodeSignature \path\scriptfile_utf.ps1

  • Nope, doesn't seem to solve it. I tried changing encoding with PowerShell and also with NotePad++. But now the StatusMessage is `ANSI bad tag value met`. Also, as noted already, this code has worked for YEARS, which is what makes this year so frustrating. Also, thanks for at least trying to help. If your direct tech support had done that I might not have canceled my purchase and bought from SSL.Com. Sectigo saying it's a reseller (Comodo) problem and Comodo saying it's a Sectigo problem is NOT a good look. Probably why the reseller I used last year stopped reselling. – Gordon Sep 26 '22 at 07:14
  • As it’s currently written, your answer is unclear. Please [edit] to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Sep 27 '22 at 15:45
0

I had the same error. I tried to sign a .cmd file with a CodeSigningCert and received Unknown Error with a blank SignerCertificate as well.

When I tried signing a PowerShell script it worked fine. That is because you cannot sign a non-Executable with a CodeSigningCert. Might not be your issue, but that was what was wrong for me.

I did not use an official certificate though, I created one with the New-SelfSignedCertificate Cmdlet. Maybe you can try with a self-signed one and check if the error occurs as well?

ylr
  • 1
  • 2
  • ?? I have been signing PS1 & PSM1 files with a code signing cert for 10 years. That's kind of what `Set-AuthenticodeSignature` is for, signing PowerShell scripts WITH a PowerShell script. . And I can sign them NOW if I use signtool.exe. And SSL.Com's eSigner is fine for PS1, though for some reason they don't allow you to sign PSM1s. – Gordon Sep 26 '22 at 06:59
  • Wait, just reading that again, and it's CMD you said couldn't be signed. Not sure, but my guess is CMD & BAT are both from the days prior to any security in Windows at all, so they can't be signed because the very concept of signed code came later. It's one of the reasons Autodesk still depending on BAT is so frustrating. – Gordon Sep 26 '22 at 07:16
  • And, to answer the Self Signed question, yes, exactly the same behavior. Can't sign with the native PS Cmdlet, can sign using PS to run signtool.exe. Also tried running the code in the console, in the ISE and in VS Code, on both Windows and Mac (so PS 5.1 & PS Core 7.0). Same failure in all cases. – Gordon Sep 26 '22 at 07:19
  • Yes I was talking about .bat and .cmd. I found this as well: https://stackoverflow.com/questions/10937065/signtool-allows-me-to-sign-code-but-set-authenticodesignature-says-the-certific Talking about being able to sign with SignTool but not with Set-AuthenticodeSignature, it had something to do with the EKU, maybe it helps – ylr Sep 27 '22 at 08:12
0

I had this same issue where set-authenticodesignature was only returning "The data is invalid" when I tried to sign a powershell script. I used Powershell get encoding file type to discover that my PowerShells script was "Unicode (Big-Endian)." I copied the PowerShell text and pasted it into a new notepad file and saved it. Afterwards, the file was "Unicode (UTF-7)." Then the set-authenticodesignature cmdlet worked successfully for me.