Sectigo timestamp server always using SHA384 instead of SHA1

Question

I am trying to dual sign a program with a Sectigo Code Signing certificate. It works but there is a problem. The commands are:

signtool.exe sign /t http://timestamp.sectigo.com /f "CertFile.pfx" /p "password" /v "MyProgram.exe"

signtool.exe sign /tr http://timestamp.sectigo.com?td=sha256 /td sha256 /fd sha256 /as /f "CertFile.pfx" /p "password" /v "MyProgram.exe"

So the first call uses CertFile.pfx and what is supposed to be SHA1 timestamp server and the second one uses what is supposed to be SHA256. The result is however SHA384 timestamp on both (the certificate is SHA1 + SHA384 timestamp, and the second one is SHA256 + SHA384 timestamp).

Now, I've tried to use different timestamp server: http://timestamp.digicert.com

signtool.exe sign /t http://timestamp.digicert.com /f "CertFile.pfx" /p "password" /v "MyProgram.exe"

signtool.exe sign /tr http://timestamp.digicert.com /td sha256 /fd sha256 /as /f "CertFile.pfx" /p "password" /v "MyProgram.exe"

That gives me proper result SHA1 + SHA1 timestamp and SHA256 + SHA256 timestamp.

My question - can I combine the Digicert timestamp server with a Sectigo certificate to get a properly signed file, is there any drawback, and is there a way to force Sectigo timestamp server to use proper timestamp? It seems like a server misbehavior if it uses SHA384 when SHA256 is explicitly requested.

Answer 1

I believe I found an answer myself. Found here: Alternative timestamping services for Authenticode

The answer by @RickWeb specifies that one can use any timestamp server to produce a valid signature.

As for the Sectigo, I've been contacting their support and they don't provide much help, what I could discover is only that their timestamp server is always sending SHA384 and entirely disregards the parameters placed into the SignTool. And they don't support SHA1 countersigning so it is not possible to create proper dual code signing signatures compatible with older versions of Windows like XP and Vista (if you have the requirement to still support those OS-es).

The only drawback that I see is that after signing your executable depends on 2 different CAs which might present an issue that if one root certificate is not valid for whatever reason, the executable is not detected as properly signed. I have seen such a case on Windows XP, so instead of having to update manually 1 root CA (Sectigo/AAA) instead it required updating two of them (also DigiCert) after which the software was shown as correctly signed.