You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Julius Davies <ju...@gmail.com> on 2007/02/24 23:13:00 UTC
not-yet-commons-ssl
Hi,
There's a vote on "jakarta-general" to have Jakarta sponsor
"not-yet-commons-ssl" for incubation. I thought Synapse might be
interested.
I recently did an "alpha" release (0.3.7) of "not-yet-commons-ssl" to help
interop with Oleg's NIO-SSL stuff. Please take a look if you have some
time!
http://juliusdavies.ca/commons-ssl/
Here's a code example:
==============================
SSLClient client = new SSLClient();
// Let's trust usual "cacerts" that come with Java.
// (This is actually redundant unless a previous
// setTrustMaterial() had wiped out the DEFAULT trust.)
client.addTrustMaterial( TrustMaterial.DEFAULT );
// Plus, let's also trust a self-signed cert.
client.addTrustMaterial( new TrustMaterial( "/path/to/self-signed.pem" ) );
// To be different, let's allow for expired certificates (not recommended).
client.setCheckExpiry( false );
client.setCheckCRL( true );
// Let's load a client certificate. Can be OpenSSL style PEM
// or Netscape PCKS12 or Java Keystore format.
// Max: 1 private-key per SSLClient instance.
KeyMaterial km;
km = new KeyMaterial( "/path/to/client.pfx", "secret".toCharArray() );
client.setKeyMaterial( km );
// Get the SSLContext object to feed into Oleg's SSL-NIO module.
SSLContext context = client.getSSLContext();
// [later....]
String hostname = "mydomain.com";
X509Certificate cert = extractFromSSLSession(); // however you do that
// It will throw an SSLException if verification fails.
HostnameVerifier.DEFAULT.check( hostname, cert );
=========================================
not-yet-common-ssl also includes good support for hostname verification in
all its sundry variations (wildcards, subject alt names, both at the same
time!). But when using NIO-SSL you need to extract the X509Certificate and
pass it into the HostnameVerifier.DEFAULT object. It's not automatic with
NIO. It's only automatic with the blocking SSL.
We based our hostname verification on this documentation:
http://wiki.cacert.org/wiki/VhostTaskForce
http://juliusdavies.ca/commons-ssl/javadocs/org/apache/commons/ssl/HostnameVerifier.html
[Sorry about the rich-text. I'll follow up with a plain-text copy.]
--
yours,
Julius Davies
416-652-0183
http://juliusdavies.ca/
Re: not-yet-commons-ssl
Posted by Paul Fremantle <pz...@gmail.com>.
Julius
Thanks for the update! I occasionally follow jakarta-general. This
looks like a very useful set of code. In fact we have two requirements
that this seems to meet:
1) easily using different certs on different connections
2) working on any recent JDK, not just 1.5
I will happily support this for incubation if that's the right way to go.
Paul
On 2/24/07, Julius Davies <ju...@gmail.com> wrote:
> Hi,
>
> There's a vote on "jakarta-general" to have Jakarta sponsor
> "not-yet-commons-ssl" for incubation. I thought Synapse might be
> interested.
>
> I recently did an "alpha" release ( 0.3.7) of "not-yet-commons-ssl" to help
> interop with Oleg's NIO-SSL stuff. Please take a look if you have some
> time!
>
> http://juliusdavies.ca/commons-ssl/
>
> Here's a code example:
>
> ==============================
> SSLClient client = new SSLClient();
>
> // Let's trust usual "cacerts" that come with Java.
> // (This is actually redundant unless a previous
> // setTrustMaterial() had wiped out the DEFAULT trust.)
> client.addTrustMaterial( TrustMaterial.DEFAULT );
>
> // Plus, let's also trust a self-signed cert.
> client.addTrustMaterial( new TrustMaterial( "/path/to/self-signed.pem" ) );
>
> // To be different, let's allow for expired certificates (not recommended).
> client.setCheckExpiry( false );
> client.setCheckCRL( true );
>
> // Let's load a client certificate. Can be OpenSSL style PEM
> // or Netscape PCKS12 or Java Keystore format.
> // Max: 1 private-key per SSLClient instance.
> KeyMaterial km;
> km = new KeyMaterial( "/path/to/client.pfx", "secret".toCharArray() );
> client.setKeyMaterial( km );
>
> // Get the SSLContext object to feed into Oleg's SSL-NIO module.
> SSLContext context = client.getSSLContext();
>
> // [later....]
> String hostname = " mydomain.com";
> X509Certificate cert = extractFromSSLSession(); // however you do that
>
> // It will throw an SSLException if verification fails.
> HostnameVerifier.DEFAULT.check( hostname, cert );
> =========================================
>
> not-yet-common-ssl also includes good support for hostname verification in
> all its sundry variations (wildcards, subject alt names, both at the same
> time!). But when using NIO-SSL you need to extract the X509Certificate and
> pass it into the HostnameVerifier.DEFAULT object. It's not automatic with
> NIO. It's only automatic with the blocking SSL.
>
> We based our hostname verification on this documentation:
> http://wiki.cacert.org/wiki/VhostTaskForce
>
> http://juliusdavies.ca/commons-ssl/javadocs/org/apache/commons/ssl/HostnameVerifier.html
>
> [Sorry about the rich-text. I'll follow up with a plain-text copy.]
>
> --
> yours,
>
> Julius Davies
> 416-652-0183
> http://juliusdavies.ca/
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: not-yet-commons-ssl
Posted by Julius Davies <ju...@gmail.com>.
Thanks for your replies! I haven't bit the maven bullet yet. Right
now I've got the binary jar, and the full-source zip hosted directly
off "http://juliusdavies.ca/commons-ssl/".
http://juliusdavies.ca/commons-ssl/not-yet-commons-ssl-0.3.7.zip
http://juliusdavies.ca/commons-ssl/not-yet-commons-ssl-0.3.7.jar
To compile "not-yet-commons-ssl" depends on:
log4j
httpclient-3.0
I'm storing both of these jar files in the "zip" download for easy
building. To build:
------------------------------------------
unzip not-yet-commons-ssl-0.3.7.zip
cd not-yet-commons-ssl-0.3.7
ant
------------------------------------------
At runtime "not-yet-commons-ssl" has no dependencies.
> In fact we have two requirements that this seems to meet:
>
> 1) easily using different certs on different connections
I tried to make loading client certs as easy as possible by supporting
all the formats. Take a look at this page:
http://juliusdavies.ca/commons-ssl/pkcs8.html
Here's an example loading all the different client cert formats:
// Java Keystore
KeyMaterial km = new KeyMaterial( "my.keystore", pwd );
// PKCS12 (Microsoft .pfx or Netscape .p12)
KeyMaterial km = new KeyMaterial( "my.pfx", pwd );
// OpenSSL key + chain all in one:
// http://juliusdavies.ca/commons-ssl/samples/pkcs12/pkcs12_client_cert.pem
KeyMaterial km = new KeyMaterial( "rsa_key_and_chain.pem", pwd );
Notice how the consumer never has to specify the type. It's the same
constructor every time - String, char[] - and yet it figures
everything out. If the provided arguments are meant to become a
private key and associated certificate chain, not-yet-commons-ssl will
figure it out.
More formats! (Doesn't actually matter which argument is private-key
and which is cert-chain, but I thought I might as well pretend it
matters to help keep users from going insane.)
// OpenSSL private-key PEM and cert-chain PEM
// http://juliusdavies.ca/commons-ssl/samples/rsa/openssl_rsa_des3_cbc.pem
//
// Or instead of OpenSSL 'traditional' format, you can do PKCS8 in PEM:
// http://juliusdavies.ca/commons-ssl/samples/rsa/pkcs8v2_rsa_des3.pem
//
// Don't forget the cert-chain that goes with the private key:
// http://juliusdavies.ca/commons-ssl/samples/x509/certificate_chain.pem
KeyMaterial km = new KeyMaterial( "rsa_key.pem", "x509chain.pem", pwd );
// OpenSSL DER instead of PEM
// (Warning: the DER links are ugly binary files that confuse browsers).
// http://juliusdavies.ca/commons-ssl/samples/rsa/pkcs8v2_rsa_des3.der
// http://juliusdavies.ca/commons-ssl/samples/x509/certificate.der
KeyMaterial km = new KeyMaterial( "pkcs8_rsa_key.der", "x509chain.der", pwd );
// OpenSSL DER and PEM! :-)
// http://juliusdavies.ca/commons-ssl/samples/rsa/pkcs8v2_rsa_des3.der
// http://juliusdavies.ca/commons-ssl/samples/x509/certificate.pem
KeyMaterial km = new KeyMaterial( "pkcs8_rsa_key.der", "x509chain.pem", pwd );
// OpenSSL PEM and DER! (Okay, just making noise on your mailing list - sorry!)
// http://juliusdavies.ca/commons-ssl/samples/rsa/pkcs8v2_rsa_des3.pem
// http://juliusdavies.ca/commons-ssl/samples/x509/certificate.der
SSLClient client = new SSLClient();
client.setKeyMaterial( km );
That's for the client's private key + certificate. But what server
certificates should the client trust? You can quickly disable the
standard "cacerts" for even better security!
client.setTrustMaterial( new TrustMaterial( "/path/to/cert.pem" ) );
Or you can trust everything (very insecure):
client.setTrustMaterial( TrustMaterial.TRUST_ALL );
I think the flexibility of this library suits it well for web-services
where the SSL can range from extremely insecure (dev environments) to
extremely secure (mutual auth with standard "cacerts" disabled and CRL
checking enabled).
We'll probably have the OCSP working in a month or two, as well.
> 2) working on any recent JDK, not just 1.5
I probably have to always support Java 1.3 due to requirements where I
work. But the library switches to the Java 1.4 JSSE packages
(javax.net.ssl.*) if they are available.
yours,
Julius
On 2/25/07, Asankha C. Perera <as...@wso2.com> wrote:
>
> Hi Julius
>
> I am not subscribed to jakarta-general but am in the apache incubator group
> already, and would be glad to help you get into incubation if we can.
> Synapse would like to be able to perform hostname verification and mutual
> auth when its possible with the NIO SSL module on which we are based now. Do
> you place your alpha JARs into a Maven repo by any chance?
>
> asankha
>
>
--
yours,
Julius Davies
416-652-0183
http://juliusdavies.ca/
http://juliusdavies.ca/commons-ssl/
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org