Using SHA256 with Authenticode

[nedtwigg]

I can get jsign and signtool to work for SHA-1 signing as follows:

signtool.exe sign /f codesigning.pfx /p %CODESIGN_PASS%  /t http://timestamp.comodoca.com/authenticode tosign.exe`
PESignerCLI --keystore codesigning.pfx --storepass %CODESIGN_PASS% --alg SHA-1 --tsmode Authenticode tosign.exe

But for SHA-256, signtool works but JSign fails.

signtool.exe sign /f codesigning.pfx /p %CODESIGN_PASS% /fd sha256 /tr http://timestamp.comodoca.com/rfc3161 /td sha256 tosign.exe
PESignerCLI --keystore codesigning.pfx --storepass %CODESIGN_PASS% --alg SHA-256 --tsmode RFC3161 tosign.exe

In the case of SHA-256, JSign completes without error, and the executable gets a little bigger, but Windows 10 fails to recognize the cert. It does recognize the cert when signed by signtool.

I'm using the latest code from master, which seems to include SHA-256 and RFC3161. I get the same behavior if I update to BouncyCastle 1.53. Is this related to Issue #7? Any tips?

[fishermans]

Hi, I had the same issue and fixed it as followed with the master branch:

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-antrun-plugin</artifactId>
            <dependencies>
                <dependency>
                    <groupId>net.jsign</groupId>
                    <artifactId>jsign</artifactId>
                    <version>1.3-SNAPSHOT</version>
                </dependency>
            </dependencies>
            <executions>
                <execution>
                    <id>testsign</id>
                    <phase>package</phase>
                    <configuration>
                        <tasks>
                            <taskdef name="signexe" classname="net.jsign.PESignerTask" classpath="jsign-1.3-SNAPSHOT.jar" />
                            <signexe file="${basedir}/target/extra-resources/${setup.MainAppName}"
                                     name="wineyes" url="http://github.com" alias="your alias"
                                     keystore="${basedir}/src/main/resources/your.pfx" storetype="PKCS12" storepass="your pwd" tsmode="AUTHENTICODE"
                                     tsaurl="http://timestamp.comodoca.com/authenticode"/>
                        </tasks>
                    </configuration>
                    <goals>
                        <goal>run</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>

Regards
Fishermans

[fishermans]

To complete my concerns:

Here is how to get the alias name from the pfx file:
keytool -v -list -storetype pkcs12 -keystore "your pfx.pfx" > keyfile.txt

keytool is shipped with java

[nedtwigg]

Thanks @fishermans! But I think the description you gave ends up using SHA1 and an Authenticode timestamp to timestamp the files. Starting January 1st, 2017, Windows isn't going to accept these anymore.

Here's another way of looking at it. The top line is what I think your example does, which will stop working on 1/1/2017. The second line is what JSign is going to need to do if it's still going to work in 9 months. I think it's going to require fixing #7, but all this stuff is mostly magic to me.

signtool.exe sign /f codesigning.pfx /p %CODESIGN_PASS%  /t http://timestamp.comodoca.com/authenticode tosign.exe
signtool.exe sign /f codesigning.pfx /p %CODESIGN_PASS% /fd sha256 /tr http://timestamp.comodoca.com/rfc3161 /td sha256 tosign.exe

PESignerCLI --keystore codesigning.pfx --storepass %CODESIGN_PASS% --alg SHA-1 --tsmode Authenticode tosign.exe
PESignerCLI --keystore codesigning.pfx --storepass %CODESIGN_PASS% --alg SHA-256 --tsmode RFC3161 tosign.exe

[fishermans]

Unfortunately yes. But this is still working as long as the alg is set to sha256.
Using sha256 for timestamping did not work for me. I spend hours to figure it out without success.

[nedtwigg]

It is working until January 2017, in 9 months. Then it will stop working, because that's when windows requires sha256 timestamping.

[stolp]

Will this also affect signed executables timestamped before this date?

[nedtwigg]

According to the Microsoft PKI blog:

Effective January 1, 2016, Windows (version 7 and higher) and Windows Server will no longer trust new code that is signed with a SHA-1 code signing certificate for Mark-of-the-Web related scenarios (e.g. files containing a digital signature) and that has been time-stamped with a value greater than January 1, 2016. This cut-off date applies to the code-signing certificate itself.

This restriction will not apply to the time-stamp certificate used to time-stamp the code-signing certificate or the certificate’s signature hash (thumbprint) until January 1, 2017. After this time, Windows will treat any code with a SHA-1 time-stamp or SHA-1 signature hash (thumbprint) as if the code did not have a time-stamp signature.

To me, this sounds like it will affect the executables signed before this date as well. But even in the best case scenario where it will continue to accept old timestamps, we only have 9 months.

[fishermans]

Nedtwigg, I agree with you. For my understanding all signed exe files even those that are already signed before Jan. 2017 won't be safe anymore.

I hope that someone could help us getting timestamping with RFC3161 mode working soon. I am unfortunately not able to do this.

As a workaround I would switch to signtool and maven ant plugin.

[nedtwigg]

Nothing but thanks to @ebourg and the other contributors! This tool has let my little one-man-shop ship a desktop application to Win/Mac/Linux all on one teensy linux box, and I've done nothing to help get this stuff done! Crypto is magic insofar as I can tell. But I think this valuable tool only has a few more months to live before we'll have to switch to signtool.

[ebourg]

I confirm that a SHA256 signature with a SHA1 authenticode timestamp works. So this issue is actually a duplicate of the issue #7, jsign doesn't support RFC3161 timestamps yet.