You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Set-AuthenticodeSignature does not handle MIME type "application/timestamp-reply" #1752
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.
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.
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 support timestamp-reply and this cmdlet should just work.
Activity
SteveL-MSFT commentedon Sep 29, 2016
TFS:6897298
joeyaiello commentedon 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.
kechols2406 commentedon Oct 10, 2017
Signing against Symantecs SHA256 timestamp server recreates this issue reliably for me.
chandj commentedon Feb 6, 2018
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!
SteveL-MSFT commentedon Feb 7, 2018
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/
gillesveyet commentedon Apr 24, 2018
Vote here to support Jordan Chan proposal "Cryptuiwiz to support timestamp-reply"
GregoryOtt commentedon Mar 10, 2020
User Voice is no longer up... Anyone knows where we can follow this issue?
gillesveyet commentedon Mar 10, 2020
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
pl4nty commentedon Sep 17, 2025
For what it's worth, http://timestamp.acs.microsoft.com also triggers this bug on 26100.6508