Tuesday Mar 08, 2016

Adding a Timestamp to a Signed Java RIA

As the title suggests, the focus for this article revolves around adding timestamps to signed Java Rich Internet Applications.  The related subtopics are worth mentioning up front in case the reader is interested in jumping right to one of those areas:

  1. Example Signed (and Timestamped) RIAs
  2. What is Timestamping and Why Should I Care?
  3. How Can Code Be Signed and Timestamped?
  4. How Can you Verify That a Jar File Has Been Signed?
  5. How Can you Integrate Signing and Timestamping into a NetBeans Project?

Example Signed (and Timestamped) RIAs

If your interest lies solely in getting access to a signed and timestamped Java web application, here are two that can be run by clicking on the images below.  The SocketServerFX and SocketClientFX applications, when run simultaneously and connected, demonstrate how simple text can be sent and received over sockets. For those experimenting with Deployment Rule Sets, these two web applications could serve as test examples for use in managing RIA access.


What is Timestamping and Why Should I Care?

Applications signed with a trusted certificate come with an expiration date.  At expiration, the code signer has to re-issue the software package with with an updated certificate in order to maintain a valid trusted signature.  There are a whole host of reasons why re-signing may be impractical; the question becomes, is it possible to validate trusted signatures even after they have expired, thus prolonging their lifetime?  The answer is yes by including a timestamp verified by a Timestamp Authority.  With the timestamp, you're essentially proving that your code signing certificate was still valid at the time of signing.

How Can Code be Signed and Timestamped?

The jarsigner utility, found in the Java Development Kit, is the mechanism used to for signing Java applications.  A -tsa argument can be included on the command-line to specify a Timestamp Authority.  A sample invocation from a Windows system might look something like this:

> jarsigner -keystore code-sign.jks -tsa http://timestamp.comodoca.com \
SocketServerFX.jar "jim connors's comodo ca limited id"

Enter Passphrase for keystore:
jar signed.

As the code signing certificate referenced above comes from Comodo, one of many trusted certificate authorities, we use their Timestamp Authority to authorize the signature.

How Can You Verify That a Jar File Has Been Signed?

Perhaps not the most elegant solution, you can utilize additional command-line arguments provided for by the jarsigner utility (-verify -verbose -certs) and search for a timestamp that is formatted in a specific way, as demonstrated by the following sample invocation:

> jarsigner -verify -verbose -certs SocketServerFX.jar | findstr signed
      [entry was signed on 3/1/16 8:48 AM]
      [entry was signed on 3/1/16 8:48 AM]
      . . .
      [entry was signed on 3/1/16 8:48 AM]

If you see text of the form "[entry was signed on ...]", then you know the jar file has been signed and timestamped.  If the jar is not timestamped, no such output will appear.

How Can you Integrate Signing and Timestamping into a NetBeans Project?

Within the NetBeans IDE, if you'd like to sign and timestamp your application automatically as part of your build process, you can do so by making a few modifications to your NetBeans project.

1. Add the following properties onto your project's project.properties file:

# Properties for custom signjar
jnlp.signjar.alias=<your certificate alias>
jnlp.signjar.keystore=<keystore file containing certificate private key>
jnlp.signjar.keypass=<keystore passphrase>
jnlp.signing.tsaurl=<URL for TimeStamp Authority>


2. Add the following target to the project's build.xml file.
    This should be placed at the bottom of the file but before the </projects> directive.

<!-- Custom Code Timestamping using Ant's signjar instead of NetBeans -->
<target name="sign-jars" depends="-check-signing-possible">
        <echo message="Using custom code for signing and timestamping via build.xml..."/>
        <signjar
               alias="${jnlp.signjar.alias}"
               storepass="${jnlp.signjar.storepass}"
               keystore="${jnlp.signjar.keystore}"
               keypass="${jnlp.signjar.keypass}"
               tsaurl="${jnlp.signing.tsaurl}">
            <path>
                <fileset dir="dist" includes="*.jar" />
            </path>
        </signjar>
    </target>

By running the sign-jars ant target, your project's jar file will be signed and timestampped.

Friday Feb 19, 2010

NetBeans with Subversion, SSH and Windows

Having spent too much time wrestling with the various components required to get NetBeans to access a subversion repository via ssh, I thought it might make sense to jot down a few notes in an effort to save others from such hardships.

NetBeans does have built-in support for CVS, Mercurial and Subversion, but that doesn't mean that these source code revision systems work in a turnkey fashion.  In particular, subversion, especially with Windows, does require some work.

1. To start:
Get the latest JDK.  At the time of this writing it was JDK 6 update 18
Get the latest version of NetBeans,  in this case, NetBeans 6.8.  Install it referencing the latest JDK and furthermore, once inside NetBeans, utilize the update manager to make sure all of your modules are the latest and greatest.

2. Upon starting NetBeans, the menu running along the top of the window has a "Team" entry.  Click on Team and follow Subversion->Checkout (No, you won't be able to check anything out yet). This will bring up an error window which requires you to install a subversion client.

Selecting the default action, which installs a subversion plugin for NetBeans, didn't result in much success. Instead choose the second option: "Install Subversion Commandline Client".  The recommended download for the client points to CollabNet, which is an excellent choice.  Unfortunately the version referred to (v 1.5.5 for Windows) may ultimately prove problematic if you're communicating with a subversion repository that's based on a later version. For this exercise, CollabNet Subversion Command-Line Client v1.6.9 (for Windows) was downloaded and installed.

3. Once Subversion is installed, clicking on Team->Subversion->Checkout again will hopefully bring up a second window which requires you fill in two textfields: (1) A repository URL and (2) a tunnel command.  Let's focus on the tunnel command first.  For windows this requires the equivalent of the Unix/Linux ssh command.  To get this functionality download and install a version of the PuTTY software package.

4. Unlike the Collabnet Subversion Client, PuTTY installation does not put the executables of this package into your PATH.  Make sure to add the PuTTY path (typically C:\\Program Files\\PuTTY) to your PATH.

5. You'll need to edit a subversion configuration file to specify the tunnel command as follows:

C:\\>cd %APPDATA%\\Subversion
C:\\>edit config 

Look for the comment that starts like this:

#ssh = $SVN_SSH ssh

Uncomment it and make it look like the statement below.  The plink.exe executable is part of the PuTTY software bundle:

ssh = $SVN_SSH plink.exe -l user -pw password 

Where user is your remote user name and password is your user's password. You can also use private key authentication if you're uncomfortable with putting your password in the clear, which might look something like:

ssh = $SVN_SSH plink.exe -l user -i C:\\my_private_key.ppk

6. Prior to trying out Netbeans, first connect to your subversion repository via ssh as follows:

C:\\> plink.exe user@host

Prior to running this command, the NetBeans attempt to access the subversion repository hangs, apparently looking for a host fingerprint cache entry.  The plink.exe command above accomplishes its creation, once the correct password is entered.  In addition, it assures that SSH is correctly set up on your Subversion repository server.

7. Returning to the Team->Subversion->Checkout selection from the main NetBeans window, now it's time to fill in the two textfields.  The first entry should look something like this:

svn+ssh://host/subversion_repository_path

for example:

svn+ssh://127.0.0.1/home/svn/myProject

Next should come the tunnel command which should be similar to the entry placed in the %APPDATA%\\Subversion\\config file, namely

plink -l user -pw password

Where, again, user is your remote user name and password is this user's password.

8. With information correctly filled in, and assuming your subversion server is correctly configured, you should be able to begin utilizing subversion through ssh with NetBeans.  For further information, check out:

Good Luck!



About

Jim Connors-Oracle

Search

Categories
Archives
« July 2016
SunMonTueWedThuFriSat
     
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
      
Today