StartSSL in Java

Yesterday I had a moment to finally try NetBeans 8.0 against our existing Subversion managed code which I had migrated to an https location with a StartSSL certificate. The web browser and, in my hazy memory of the past, TortoiseSVN clients had had no issue with the new location so I was surprised to run into this error message:

Error validating server certificate for 'https://mysvnrepo.tld:443':

 - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually!

 I didn't try accepting because that made me think I had something configured incorrectly. My NetBeans 7.3 install was working fine, but it was limping along in CLI mode for Subversion since it isn't updated for the latest Subversion client version to work with my updated working directories.

Some searching around the NetBeans forums lead me to some suggestions for debugging the issue using -Djavax.net.debug=ssl so I whipped up a test application that uses the Java URL class to GET the content of https pages. Accessing sites using GoDaddy certificates worked just fine, but the ones using StartSSL certificates was a no-go.

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

 StartSSL is reasonably new to the CA arena when compared to the likes of Verisign and Thawte, having operated a Certification Authority (CA) since 2005. Their model of operation is appealing, especially to the budget conscious, because you pay for verifications of individuals and organizations, not for issuing of certificates. When you compare their $59.90 fee for a StartSSL Verified status to get access to as many of their class 2/3 certificates as you need to places that charge you $150+/year for each web site certificate and $200+/year for each type of Microsoft Authenticode, Java, and Adobe AIR certificate you start to see why Thawte was worth so much to Verisign who was in turn purchased by Symantec. StartSSL is supported by Microsoft Windows, the major browsers and on mobile devices by having their root certificate included in those browsers and devices.

It isn't included in the Java cacerts file.

To get a CA root certificate added to the cacerts file, a CA is suppose to apply to the Oracle Java Root Certificate program. The startcom / startssl user Admin indicated in 2011 that they have done this with no success. Users have also tried via bug reports to get the certificate included and were rejected saying it must be the CA and not the users that drive CA inclusion.

I think someone has their head on backwards and is facing the wrong crowd. If the developers, the users of your language, are interested in having a CA added then the way they went about requesting it was exactly right. If a bunch of my users or potential users say they will stay with me or start using my product if I add support for API X, there is a strong incentive for me to contact the makers of API X and not wait for them to contact me. I suspect that in the beginning Sun didn't wait for Verisign and Thawte to come ask to be included in their cacerts file. Even Thawte's dead Personal Freemail CA is still in the list and Thawte says it can be dropped in 2011.

Curious what certs are in your Java install's cacerts file? Have keytool tell you. The trick is to tell keytool to list, verbosely, the cacerts keystore who's password by default is changeit. That's a lot of output so you may want to filter it to just the Owner lines.

*nix Shell:
echo 'changeit' | keytool -list -v -keystore $(find $JAVA_HOME -name cacerts) | grep 'Owner:'

Windows Power Shell:
PS C:\Program Files (x86)\Java\jre1.8.0_25\bin> .\keytool -list -v -keystore ..\lib\security\cacerts | select-string -pattern "Owner:"
Enter keystore password:  changeit

What to do?

The real bear is in desktop Java. For our server systems I can add StartSSL to the certificates. For my Subversion issue I can add an exception and if it doesn't stick I can add the StartSSL root to my desktop's cacerts file. It is not very reasonable for anyone but Oracle to add the StartSSL CA root to every end user's cacerts file which puts a damper on using StartSSL to sign Java Web Start applications or applets or access StartSSL signed web sites.

To avoid the Java security code signing restrictions I could switch away from Java Web Start to shipping "executable JAR files", but still I have issues accessing https servers using StartSSL signed certificates even though these sites work fine from the browser and C++/MFC code on windows using the CHttpFile class. I would still need to either add the StartSSL CA root to the cacerts file, disable certificate checking, or avoid the Java URL class and use something else like the Apache Commons HttpClient to dynamically insert trust for StartSSL. Blah.

I could go all-out. Include java.dll and friends and replace javaw(.exe) with MyApp(.exe) that points to my own cacerts file, uses my own icon, and tries harder to act like a native application. No waiting on Oracle. No trying to dynamically modify how certificates are checked. Keep using StartSSL. This would be at the cost of giving up everything Web start and others are doing for me.

Of course I could also stop using StartSSL and switch back to one of the authorities who's root CA key is in Oracle's Java cacerts file, but I wanted to expand the use of HTTPS, not run it at minimal levels. Or I could switch away from Java.

If you care about this issue, maybe we can use social media to raise our voices instead of getting shut down at a bug report for "open"jdk or swept behind the scenes of a CA only apply here forum. Let's see if we can get #startsslinjava trending. Share. Like. Blog. Pass along.

Java RESTful Web Services, NetBeans Style

I’ve been interested in exploring Java RESTful Web Services to backend some AngularJS front-ends, with my current focus on JAX-RS implementations.

Blaise Doughan has been blogging a lot about EclipseLink, JAXB, and MOXy. I decided to follow the code example in his post MOXy is the New Default JSON-Binding Provider in GlassFish 4 using NetBeans 7.4 since the Java EE download bundles an install of GlassFish Server Open Source Edition 4.0.

Start by creating a new Java Web Application by choosing New Project from the File menu, going to the Java Web category and selecting Web Application. To keep things the same as his example, name it CustomerResource. Select the GlassFish Server 4.0, Java EE 7 Web, with the suggested context path of /CustomerResource. If you run this right away you should be served the index.html page saying “TODO write content”.

We will work backwards a bit in his blog post, building a little infrastructure before we use it. So first we will right-click Source Packages and add a new Java Class named PhoneNumber in the org.example.model package. Paste or type his code into this class. Do the same for the Customer class. NetBeans will suggest you use the diamond inference and make phoneNumbers final. The code works fine either way.

Still working up in the blog, we will create the CustomerApplication and CustomerService classes in the org.example.service namespace. At this point you should be able to click run and visit the local URL to get our “hello world” type xml response for Jane Doe:

http://localhost:8080/CustomerResource/rest/customers/1

Everything up to this point “just works” in the excellent NetBeans IDE and GlassFish Server, but I was interested in his JSON tweaks, having seen some of the shortcomings he mentions unless I map to a JSON object by hand. To do some testing I first commented out the APPLICATION_XML line from the @Produces list so that I could see (download) the output and move forward to Customizing the JSON-Binding with it’s use of MoxyJsonConfig. This is where I was stumped for a bit.

Pulling in the JAXBContextProperties wasn’t a big deal. The EclipseLink from GlassFish library seemed to have what I was after. Just right-click the Libraries folder in the project and Add Library then choose that library and click Add Library.

To get MoxyJsonConfig, download jersey-media-moxy-2.4.1.jar and stick it someplace handy. I use a folder named Libraries in my NetBeansProjects folder. Then right-click the Libraries folder in the CustomerResource project in NetBeans and click Create in the Add Library dialog. Name it something like Jersey Media Moxy and then in the library classpath Add Jar/Folder to add jersey-media-moxy-2.4.1.jar. Then add this library to your project.

At this point you should have output like Blaise has documented for New Response in his blog post. Enjoy.

If you can’t find jersey-media-moxy-2.4.1.jar or the API has switched around again and a later version is missing the dependency, then read on for my tale of woe and sorrow trying to locate it in the first place. Perhaps it will help.

I haven’t jumped on board with maven yet, so when I came across Blaise’s follow-up question to the StackOverflow question Cannot import EclipseLink MOXy while searching for MoxyJsonConfig where he implied the use of Maven, I was a little disappointed. I was equally disappointed in my next dozen searches all failing to find the jar containing MoxyJsonConfig. I could find API docs, people talking about using it, etc. findjar.com failed. Even mvnrepository.com searches failed. Finally after Google searches of varying portions of the class or package name, one for org.glassfish.jersey.moxy pointed me to jersey-media-moxy within MVN. Unfortunately it was pointing me to 2.0-m07 which has MoxyJsonConfiguration and not MoxyJsonConfig. I didn’t realize that right away and tried implementing using it. It doesn’t work. The current latest version, 2.4.1, has MoxyJsonConfig and does work. I have no idea when things changed or what version Blaise used.

I was glad to finally find the jar, but there has got to be some better way to find a class and know what version of things people are talking about. If there is, please share. If there isn’t, please keep this in mind when sharing code examples.