BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Not-Yet-Commons-SSL Provides Powerful (and Free) SSL Capabilities

Not-Yet-Commons-SSL Provides Powerful (and Free) SSL Capabilities

This item in japanese

Bookmarks
Not-Yet-Commons-SSL is an Apache licensed Java library designed to simplify the use of SSL by providing an easy-to-use API along with robust support for a variety of certificate formats and configuration options. In particular, it addresses some long standing nuisances with Java's built-in SSL support by allowing the use multiple certificates within a single JVM, handling self-signed certificates gracefully, and supporting all standard certificate format.

The project touts five design goals that sum up the library's features:
Make SSL and Java Easier. Ever wanted to work with self-signed certificates in your Java application in a secure fashion? Ever wanted to use more than one client certificte in a single running JVM? You can edit your $JAVA_HOME/jre/lib/security/cacerts file, and you can invoke Java with -Djavax.net.ssl.keyStore=/path/to/keystore. Both of these approaches are great at first, but they don't scale well. Do you really want to pollute every SSL socket in your JVM (HTTP, LDAP, JDBC, RMI, etc...) with those system-wide changes? Commons-SSL let's you control the SSL options you need in an natural way for each SSLSocketFactory, and those options won't bleed into the rest of your system.
Improve Security. CRL checking turned on by default. We hope to add support for OCSP soon! It's obnoxious to have to download CRL files around 500KB each from Thawte and Verisign every 24 hours. OCSP improves on that.
Improve Flexibility. Checking hostnames, expirations, CRL's, and many other options can be enabled/disabled for each SSLSocketFactory created.
Support more file formats, and support these formats more robustly.
  • commons-ssl supports over 50 formats of PKCS8 and OpenSSL Encrypted Private Keys in PEM or DER
  • X.509 Certificates can be PEM or DER encoded. Can also come in PKCS7 chains. (To be fair, Java always supported this.)
  • PKCS12 files can be in PEM (as created by openssl pkcs12).
  • Parsing of Base64-PEM is more tolerant of extra whitespace or comments, especially outside the Base64 sections.
Automatically detect type of KeyMaterial or TrustMaterial. Consumer does not need to know whether keystore is PKCS12 or JKS. They just need to know the password to decrypt the private key.
Not-Yet-Commons-SSL was developed at the Credit Union Central of British Columbia and was donated to the Apache Software Foundation in 2006. It is currently going through the Apache Incubation policy and the project hopes to soon become part of the Apache-Commons project in the upcoming months.

In comparison to Java's built-in capabilities, Dejan Bosanac wrote:
If you ever tried to work with SSL Socket connections in Java, you probably know that Java, by default, supports its own JKS and PKCS12 certificate formats. For those who need to work with OpenSSL it is usually suggested to convert keys and certificates to PKCS12 and then import them in the keystore using the keytool command provided with the JDK.

While all this is not a big deal for most of the applications, there should be a better solution for projects that rely heavily on SSL. Not-yet-commons-ssl project, called liked this because it is still not the official Apache project, aims to simplify Java and SSL integration.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT