Ssl improvements

this patch also has a fix for http://jira.codehaus.org/browse/JETTY-89.

fix from nik applied and committed

I'm looking over the source code changes but I haven't tested it yet.

1. The trustmanager initialization is wrong. You are using the same keystore as for the KeyManagerFactory!

2. Judging from some info in the JSSE docs... if a password is not specified then the empty string should be used. Search it for "" and you'll see. This should probably be handled in createFactory() as this is a JSSE peculiarity.
http://java.sun.com/j2se/1.4.2/docs/guide/security/jsse/JSSERefGuide.html

3. I am confused over the "keypassword" versus just "password"... the Java API docs don't suggest any distinction (to me), yet the JSSE reference guide talks about keytool where there is this distinction. If the authors of Jetty's SSL code is right and so there is a distinction... then there probably is one more thing left to do. If keypassword isn't specified, then keyManagerFactory.init() should use the keystore's password by default. That is how keytool does it. This will mean we don't have to say the same password twice in our Jetty config's.

1. We had assumed that trust certificates could be put in the same key store, but looking around this is not common
practise, so I am adding support for a separate truststore.

2. will do.

3. If you read the javadoc for KeyStore you will see:

"Note that although the same password may be used to load the keystore, to protect the private key entry, to protect the secret key entry, and to store the keystore (as is shown in the sample code above), different passwords or other protection parameters may also be used."

so we will continue to support two passwords per keystore.

Fixes have been committed.

Nik - can you make sure your work on the NIO SslEngine is compatible with this (ie in password
handling and truststore configuration).

Note that I split out the ssl configuration into a separate xml file, so you now can start ssl
with out editing config files:

java -jar start.jar etc/jetty.xml etc/jetty-ssl.xml

Tony Thompson wrote:
> Way back (somewhere in Jetty 4, I believe), I had added something to the
> SSL listener so that you could configure it to use the default
> truststore which lets you use the cacerts in the JVM as your truststore.
> I haven't looked at the Jetty 6 code but, I would vote for keeping this
> type of mechanism around as well. The way you are presenting it, it
> sounds like you would have to specifically configure a truststore as
> well as a keystore which is a bit of a hassle.
>
> Just my 2 cents.
> Tony

I completely agree. So Greg... if the "keystore" or "truststore" locations are not specified, then don't configure them... and the result will be that SSLContext.init() will have a null parameter for either of these which will result in the default (JSSE specified) keystore/truststore being looked up.

The trust manager is certainly optional.
If JVMs also come with builtin keystores, then I guess we can make that optional as well.

Nik. can you check that if no keystore or truststore is set, then the JVMs are used.

Is this a known exception, or should I file a bug on it:

java.lang.NullPointerException
	at org.mortbay.jetty.security.SslHttpChannelEndPoint.<init>(SslHttpChannelEndPoint.java:49)
	at org.mortbay.jetty.security.SslSelectChannelConnector.newHttpChannelEndPoint(SslSelectChannelConnector.java:137)
	at org.mortbay.jetty.nio.SelectChannelConnector$SelectSet.accept(SelectChannelConnector.java:424)
	at org.mortbay.jetty.nio.SelectChannelConnector.accept(SelectChannelConnector.java:178)
	at org.mortbay.jetty.AbstractConnector$Acceptor.run(AbstractConnector.java:630)
	at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)

Anders - use JETTY-3 to raise issues about the SslSelectChannelConnector.

It is a work in progres.... I have not seen this NPE, but I have not run the latest patch very much.

Greg,

found this on the jsse reference guide :

"A newly-created SSLContext should be initialized by calling the init method:

public void init(KeyManager[] km, TrustManager[] tm,
SecureRandom random);

If the KeyManager[] paramater is null, then an empty KeyManager will be defined for this context. If the TrustManager[] parameter is null, the installed security providers will be searched for the highest-priority implementation of the TrustManagerFactory, from which an appropriate TrustManager will be obtained. Likewise, the SecureRandom parameter may be null, in which case a default implementation will be used. "

Great,

then we should be able to allow both Key and Trust Managers to be used if a key store has not been set for them.
(I think I have the code so the trustmanager will default to the keystore - which is wrong).

Can you also allow for an optional SecureRandom instance to be set and passed to the context .

cheers

Nik,

What is the status of this issue? Can it be closed yet?

Jan,

Its been fixed already. Now closing this issue.

Thanks!
Nik