New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hardware token signing #291
Comments
Hi @Perneel , thanks for that question. This is actually an interesting topic. The original I already have an idea how to provide this feature, but currently this is not (yet) supported. Will tinker with a solution and I'm going to report back to you as soon as possible. You might be required to check with a SNAPSHOT-version, so please make sure you know how to access these versions. |
Ok, thank you for the fast response! |
Hi there, took me a bit to find all configuration-parts, but this should work with a fresh <configuration>
<mainClass>myApp.ui.MainApp</mainClass>
<verbose>true</verbose>
<j2seVersion>1.8+</j2seVersion>
<!-- this only sets the field inside jar-file -->
<allPermissions>true</allPermissions>
<!-- this makes the JNLP-file having permissions being set -->
<!-- AND it is the trigger for signing jar-files using jarsigner -->
<bundleArguments>
<jnlp.allPermissions>true</jnlp.allPermissions>
</bundleArguments>
<!-- this setting is required for the new "jarsigner"-feature -->
<noBlobSigning>true<noBlobSigning>
<!-- these are required, please change them for your own requirements -->
<keyStoreAlias>myalias</keyStoreAlias>
<keyStorePassword>password</keyStorePassword>
<!-- as this keystore is no file, please disable file-checks -->
<skipKeyStoreChecking>true</skipKeyStoreChecking>
<!-- this is used for additional parameters for the jarsigner command -->
<additionalJarsignerParameters>
<additionalJarsignerParameter>-keystore</additionalJarsignerParameter>
<additionalJarsignerParameter>NONE</additionalJarsignerParameter>
<additionalJarsignerParameter>-storetype</additionalJarsignerParameter>
<additionalJarsignerParameter>PKCS11</additionalJarsignerParameter>
<additionalJarsignerParameter>-tsa</additionalJarsignerParameter>
<additionalJarsignerParameter>http://timestamp.globalsign.com/scripts/timestamp.dll</additionalJarsignerParameter>
<additionalJarsignerParameter>-providerClass</additionalJarsignerParameter>
<additionalJarsignerParameter>sun.security.pkcs11.SunPKCS11</additionalJarsignerParameter>
<additionalJarsignerParameter>-providerArg</additionalJarsignerParameter>
<additionalJarsignerParameter>eToken.cfg</additionalJarsignerParameter>
<!-- I DO KNOW that this is verbose ... -->
</additionalJarsignerParameters>
<keyStoreAlias>le-d0e453de-66db-414a-8fa8-0a07cfad66b5</keyStoreAlias>
</configuration> As far as I understood the article you have linked, the Can you try with the current snapshot and configuration above, and report back? |
Ok I'll give it a shot, I think the last row |
Oh, my bad ;) only ONE keyStoreAlias is needed, correct! I created that configuration-block too hasty |
Just tried it out, got the following failure:
Looks like it is still checking for a keystore even though |
Oh, there is the problem, please use the To generate with the new bundler, please set |
Additional note: the result is created in the folder |
Sorry, my bad. It's been a long day :) I got a BUILD SUCCESS now, however, if I check with Probably doing something wrong again... :)
|
ah maybe my bad in the short explanation. With the previous keystore (before the hardware key), I signed all jars (so including dependencies) and created a JNLP file to launch the application. |
I missed another stupid thing, which even is printed in the log:
Please try with this revised version of the configuration: <configuration>
<mainClass>myApp.ui.MainApp</mainClass>
<verbose>true</verbose>
<j2seVersion>1.8+</j2seVersion>
<!-- this only sets the field inside jar-file -->
<allPermissions>true</allPermissions>
<!-- this makes the JNLP-file having permissions being set -->
<!-- AND it is the trigger for signing jar-files using jarsigner -->
<bundleArguments>
<jnlp.allPermissions>true</jnlp.allPermissions>
<!-- the JNLP-bundler is a bit picky about its parametes, it does not use <appName> -->
<jnlp.outfile>YourApplication</jnlp.outfile>
</bundleArguments>
<!-- this setting is required for the new "jarsigner"-feature -->
<noBlobSigning>true<noBlobSigning>
<!-- these are required, please change them for your own requirements -->
<keyStoreAlias>le-d0e453de-66db-414a-8fa8-0a07cfad66b5</keyStoreAlias>
<keyStorePassword>password</keyStorePassword>
<!-- as this keystore is no file, please disable file-checks -->
<skipKeyStoreChecking>true</skipKeyStoreChecking>
<!-- this is used for additional parameters for the jarsigner command -->
<additionalJarsignerParameters>
<additionalJarsignerParameter>-keystore</additionalJarsignerParameter>
<additionalJarsignerParameter>NONE</additionalJarsignerParameter>
<additionalJarsignerParameter>-storetype</additionalJarsignerParameter>
<additionalJarsignerParameter>PKCS11</additionalJarsignerParameter>
<additionalJarsignerParameter>-tsa</additionalJarsignerParameter>
<additionalJarsignerParameter>http://timestamp.globalsign.com/scripts/timestamp.dll</additionalJarsignerParameter>
<additionalJarsignerParameter>-providerClass</additionalJarsignerParameter>
<additionalJarsignerParameter>sun.security.pkcs11.SunPKCS11</additionalJarsignerParameter>
<additionalJarsignerParameter>-providerArg</additionalJarsignerParameter>
<additionalJarsignerParameter>eToken.cfg</additionalJarsignerParameter>
<!-- I DO KNOW that this is verbose ... -->
</additionalJarsignerParameters>
</configuration> |
Sometimes it is better to add the plugin-block for debugging, I never would have guessed you are using |
just tried, yet the jar in |
@Perneel can you try to create some small project including some anonymized configuration inside the pom.xml for me to check? You can use an empty mainClass (which does extend |
not sure if it's possible without the hardware key? :p I can post the plugin configuration thou if you want? |
All I need is the plugin-part of the javafx-maven-plugin, there might be some issue with the plugin-configuration within the executions. Oh, as this is visible for PUBLIC, please make sure to anonymise all critical data. No need for a full compilable project ;) |
There you go! :)
|
Can you try this configuration by calling <plugin>
<groupId>com.zenjava</groupId>
<artifactId>javafx-maven-plugin</artifactId>
<version>8.8.4-SNAPSHOT</version>
<!-- this configuration is share among all executions -->
<configuration>
<mainClass>App_m.ui.MainApp</mainClass>
<description>test signing</description>
<title>launch</title>
<verbose>true</verbose>
<j2seVersion>1.8+</j2seVersion>
<!-- this only sets the field inside jar-file -->
<allPermissions>true</allPermissions>
</configuration>
<executions>
<execution>
<!-- required before build-native, creates target/jfx/app -->
<id>create-jfxjar</id>
<phase>package</phase>
<goals>
<goal>build-jar</goal>
</goals>
</execution>
<execution>
<!-- creates target/jfx/web -->
<id>create-jnlp-bundle</id>
<phase>package</phase>
<goals>
<goal>build-native</goal>
</goals>
<!-- this configuration is only specific to this execution -->
<configuration>
<!-- as we only want to create the JNLP-package, use fixed bundler-ID -->
<bundler>jnlp<bundler>
<!-- this makes the JNLP-file having permissions being set -->
<!-- AND it is the trigger for signing jar-files using jarsigner -->
<bundleArguments>
<jnlp.allPermissions>true</jnlp.allPermissions>
<!-- the JNLP-bundler is a bit picky about its parametes, it does not use <appName> -->
<jnlp.outfile>CL_AppM</jnlp.outfile>
</bundleArguments>
<!-- this setting is required for the new "jarsigner"-feature -->
<noBlobSigning>true</noBlobSigning>
<!-- these are required, please change them for your own requirements -->
<keyStoreAlias>myalias</keyStoreAlias>
<keyStorePassword>mypass</keyStorePassword>
<!-- as this keystore is no file, please disable file-checks -->
<skipKeyStoreChecking>true</skipKeyStoreChecking>
<!-- this is used for additional parameters for the jarsigner command -->
<additionalJarsignerParameters>
<additionalJarsignerParameter>-keystore</additionalJarsignerParameter>
<additionalJarsignerParameter>NONE</additionalJarsignerParameter>
<additionalJarsignerParameter>-storetype</additionalJarsignerParameter>
<additionalJarsignerParameter>PKCS11</additionalJarsignerParameter>
<additionalJarsignerParameter>-tsa</additionalJarsignerParameter>
<additionalJarsignerParameter>http://timestamp.globalsign.com/scripts/timestamp.dll</additionalJarsignerParameter>
<additionalJarsignerParameter>-providerClass</additionalJarsignerParameter>
<additionalJarsignerParameter>sun.security.pkcs11.SunPKCS11</additionalJarsignerParameter>
<additionalJarsignerParameter>-providerArg</additionalJarsignerParameter>
<additionalJarsignerParameter>src/main/resources/token/eToken.config</additionalJarsignerParameter>
<!-- I DO KNOW that this is verbose ... -->
</additionalJarsignerParameters>
<nativeOutputDir>${project.build.directory}/jfx/web</nativeOutputDir>
</configuration>
</execution>
</executions>
</plugin> |
Please note that this will create your jnlp- and jar-files below |
Still unsigned it says :(
|
Can you see the jarsigner being called somewhere in the build-log? |
Nothing in the build-log no... |
Just to confirm: you don't see |
That is correct |
that is more than strange ... will take a deeper look into this :( |
A solution, I think, would be to comment out |
I wasn't aware that this storetype requires keypass to be removed, will think about it ;) but we are a step further this time. |
@Perneel You need to add
Thats kinda true, but it has a nice fallback: https://github.com/javafx-maven-plugin/javafx-maven-plugin/blob/master/src/main/java/com/zenjava/javafx/maven/plugin/NativeMojo.java#L1015 |
jar verified! :) I'll try to put it online and see if it runs. I got to say that EV Code signing (so with that hardware token) is very slow... took me like 44 minutes :s |
Thats great news 👍 when you got this verified, I will prepare a new release of the javafx-maven-plugin (but might take some while) |
I had contact with GlobalSign about the slow signing but they didn't really know what would cause it. Gonna try to put my project folder on the same drive from where I'm starting the building process. Maybe that will speed up some things. Tonight I'll upload the built project, I'll let you know how it went :) |
Seems the certificate is successfully installed. I can start the application through webstart (jnlp file) and it's showing the correct certificate. The program itself won't run yet due to missing manifest things but that's caused by my lack of knowledge and is another 'issue' :) Is there a way to modify the manifest with this plugin?
|
Got it working, awesome job, awesome project :) keep it up! PS: I had a question on stackoverflow about this with a bounty, feel free to answer there as well: http://stackoverflow.com/questions/43594938/maven-jnlp-creation-with-ev-code-signing |
:) good to hear, I hope to get this released next week until then I will hold this issue open. But please check if my copy-pasted configuration really is correct :D |
Looks ok ;) |
Hm did something change at the 8.8.4-SNAPSHOT? For some reason the signing broke again:
However, no signing takes place :( |
Nope, did not change anything. Maybe you want to call |
Hm recreated the profile and now it's working again... I probably fucked something up :D |
At least it still works ;) Will hold this issue open, as this is not yet released. Note to myself: create some new labels, milestones and other stuff |
Yea was my bad, pressed 'Close and comment' instead of Comment... sorry :) |
Not yet published, might take some while as I'm starting to change something bigger here. In the meantime please just use the -SNAPSHOT-version |
I was wondering if it is possible to sign jars with a hardware token. Since February 2017, GlobalSign only issues CodeSigning certificates with an eToken (USB). According to GlobalSign's website, the command for signing a jar with an eToken is as following (full article):
Is it possible to set the
tsa
,providerClass
enproviderArg
in the configuration? Something like this:The text was updated successfully, but these errors were encountered: