Repository navigation
Set-AuthenticodeSignature does not handle MIME type "application/timestamp-reply" #1752
Description
Activity
TFS:6897298
- added this to the milestone
on Sep 29, 2016 - removed this from the milestone
on May 23, 2017 We could certainly use a better repro here if someone has one. Either way, it's a fairly low-pri issue, moving it out.
Signing against Symantecs SHA256 timestamp server recreates this issue reliably for me.
set-authenticodesignature c:\test.ps1 -certificate $mycert -hashalgorithm "SHA256" -timestampserver "http://sha256timestamp.ws.symantec.com/sha256/timestamp"will reproduce this error. Please consider bumping this up in priority, as it stops us from timestamping signed scripts according to Microsoft's new timestamping standards.
My current workaround is to use signtool.exe to timestamp our scripts with SHA2.
Thanks!
Not sure if there's much we can do here, it appears that the cmdlet simply passes the signing to the native CryptUIWiz API which is returning this error. Looking at the CryptAPI, it appears they only support
octet-stream. They would need to supporttimestamp-replyand this cmdlet should just work.Best way to get this supported is to open or upvote a issue here: https://wpdev.uservoice.com/
Vote here to support Jordan Chan proposal "Cryptuiwiz to support timestamp-reply"
User Voice is no longer up... Anyone knows where we can follow this issue?
Sorry I don't know, and I am less interested in this as I have switched to http://timestamp.digicert.com which works with PowerShell.
Note : Anyone using legacy VeriSign and symantec time stamping services should switch to digicert : https://knowledge.digicert.com/alerts/migration-of-legacy-verisign-and-symantec-time-stamping-services.html
For what it's worth, http://timestamp.acs.microsoft.com also triggers this bug on 26100.6508
Reacted by Marcelo Estriga and OurNotifications
Description: Problem:
When using Set-AuthenticodeSignature and specifying a TimeStampServer http URL, if the time stamp server returns content/MIME type of: "application/timestamp-reply" the cmdlet returns an unknown error with a status of "ASN1 bad tag value met". This is non-compliant according to RFC3161 for Time-Stamp protocol via HTTP.
Expected - Set-AuthenticodeSignature with a specified timestampserver URL appropriately handles the "application/timestamp-reply" content/MIME, commits the authenticode signature as well as the timestamp from said server without error.
Additionally, the success case today is when using Set-AuthenticodeSignature with a specified timestampserver URL and the response is content/MIME type of "application/octet-stream" the cmdlet returns without error, the authenticode signature is committed and the timestamp is commited without error.