Using SHA256 with Authenticode about jsign HOT 10 CLOSED

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

from jsign.

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

from jsign.

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

from jsign.

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.

from jsign.

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

from jsign.

Will this also affect signed executables timestamped before this date?

from jsign.

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.

from jsign.

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.

from jsign.

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.

from jsign.

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.

from jsign.