[security-dev 00510]: Re: SSLContextFactory

Xuelei Fan Xuelei.Fan at Sun.COM
Thu Jan 22 17:16:15 PST 2009

Bruno Harbulot wrote:
> Hi Xuelei,
> Thanks for looking into this.
> I agree with you, everything that's required is already in the JavaSE 
> API. I find, however, that using these classes requires a careful 
> reading of the JSSE ref. guide and the Certification path ref. guide, 
> both of which are rather long and non-trivial (at least to me). I 
> suspect many developers don't have time to get into such a depth of 
> details.
> One of the use-cases that was the motivation for PKIXSSLContextFactory 
> in jSSLutils was to be able to add CRLs quite easily. Thus, you get 
> something like this:
> PKIXSSLContextFactory sslContextFactory =
>     new PKIXSSLContextFactory(keyStore, "keypassword", trustStore);
> sslContextFactory.addCrl("http://ca.example.org/root-crl");
> sslContextFactory.addCrl("http://ca.example.org/intermediate-crl");
> SSLContext sslContext = sslContextFactory.buildSSLContext();
> It's true that it's not possible to cover all cases, but I would guess 
> that there is small set of cases that are more frequent (such as 
> adding CRLs explicitly).
> Even some high-profile projects don't necessarily handle this case, or 
> haven't been doing it for a long time (for example, as far as I can 
> see, CRL support was added to Tomcat only in 2006, and it accepts only 
> one CRL file).
> I was only suggesting that an SSLContext factory be added to the main 
> API because it seems that a few projects create their own (named one 
> way or another). Having an SSLContextFactory interface and perhaps a 
> default PKIX-based implementation (or following the default value) 
> that would take a keystore and truststore (or fall back to either 
> default values) might help harmonise the practice amongst various 
> projects (such as Tomcat, Grizzly/Glassfish, Jetty, Restlet, ...).
Because the JSSE has already provided the TrustManagerFactory and
KeyManagerFactory, and one can customize the trust manager and key
manager with simple processes, I don't think the SSLContextFactory is a
have-to-have interface, although is is cool knife for some application.

Personally, I would prefer a library or a provider that gives many
customized trust managers and key managers, and then the programmers
join them into SSLContext by SSLContext.init() according to their
> This being said, perhaps the main Java API isn't the right place for 
> this. It can be in a separate library indeed.
Yes, it is of great help for some certain applications, but just as you
said, I really don't think it should be in JRE level.

> Best wishes,
> Bruno.
> Xuelei Fan wrote:
>> Hi Bruno,
>> I have read your jsslutils project times, it is a really good 
>> practice to wrap complex logics into a simple one.
>> By my understanding (If I'm wrong or something missed, correct me), 
>> the underlying requirements for SSLContextFactory are:
>> 1. multiple SSLContext instances per thread or request.
>> 2. customizable key/trust managers.
>> 3. support CRLs.
>> Let's discuss it one by one:
>> 1. multiple SSLContext instances per thread or request.
>>    SSLContext.init(KeyManager[], TrustManager[], SecureRandom)[1][2] 
>> could be used to create SSLContext at anytime you want to.
>> 2. customizable key/trust managers.
>>    KeyManagerFactory[3] defines two initialization methods, 
>> KeyManagerFactory.init(KeyStore, char[]) and 
>> KeyManagerFactory.init(ManagerFactoryParameters). Both of the methods 
>> could be used to customized the key managers.
>>    Similarly, TrustManagerFactory[4] also defines two initialization 
>> methods, TrustManagerFactory.init(KeyStore, char[]) and 
>> TrustManagerFactory.init(ManagerFactoryParameters). Both of the 
>> methods could be used to customized the trust managers.
>>    Once the customized key/trust managers created, you can use the 
>> above SSLContext.init() method for a customized SSLContext.
>> 3. support CRLs.
>>    It is flexible to support CRLs for trust managers with 
>> TrustManagerFactory.init(ManagerFactoryParameters), please refer to 
>> [5]-[10] step by step.
>> OK, by now, the current interfaces meets your requirements, I think. 
>> So, I'm not really want to add a new SSLContextFactory.
>> And Cert path build anor the SSLContextFactory, ind validation is a 
>> very very complex process for enterprise environments, which concerns 
>> policies, constraint, date, cross trust, etc. I don't think there is 
>> a simple way to hide the complex in a general API. F order to 
>> provider enough candidate for various policies, constraints, a dozen 
>> of sub-class must be defined, I don't think it is good.
>> So, because the TrustManagerFactory/KeyManagerFactory has provide the 
>> flexibility, I don't think we still need a SSLContextFactory any more.
>> Thanks,
>> Xuelei
>> [1]: http://java.sun.com/javase/6/docs/api/javax/net/ssl/SSLContext.html
>> [2]: 
>> http://java.sun.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#SSLContext 
>> [3]: 
>> http://java.sun.com/javase/6/docs/api/javax/net/ssl/KeyManagerFactory.html 
>> [4]: 
>> http://java.sun.com/javase/6/docs/api/javax/net/ssl/KeyManagerFactory.html 
>> [5]: 
>> http://java.sun.com/javase/6/docs/api/javax/net/ssl/ManagerFactoryParameters.html 
>> [6]: 
>> http://java.sun.com/javase/6/docs/api/javax/net/ssl/CertPathTrustManagerParameters.html 
>> [7]: 
>> http://java.sun.com/javase/6/docs/api/java/security/cert/CertPathParameters.html 
>> [8]: 
>> http://java.sun.com/javase/6/docs/api/java/security/cert/PKIXBuilderParameters.html 
>> [9]: 
>> http://java.sun.com/javase/6/docs/api/java/security/cert/PKIXParameters.html 
>> [10]: 
>> http://java.sun.com/javase/6/docs/api/java/security/cert/PKIXParameters.html#setCertStores(java.util.List) 
>> [11]: 
>> http://java.sun.com/javase/6/docs/technotes/guides/security/certpath/CertPathProgGuide.html#StorageClasses 
>> Bruno Harbulot wrote:
>>> Hello,
>>> I only found out recently about Sean Mullan's blog entry named 
>>> "Security Feature Planning for JDK 7" (written almost two years ago) 
>>> <http://weblogs.java.net/blog/mullan/archive/2006/08/security_featur.html>. 
>>> After I contacted him, he kindly suggested this mailing-list could 
>>> be the right place to discuss security features in JDK 7.
>>> I've recently been trying to improve SSL support in a couple of 
>>> open-source projects. This led me to build a small library, which 
>>> I've called 'jsslutils' <http://code.google.com/p/jsslutils/>.
>>> The idea behind this library is to provide an SSLContextFactory 
>>> which can help configure an SSLContext for applications such as 
>>> Restlet <http://www.restlet.org/> (Grizzly, Simple or Jetty 
>>> connectors) or Jetty <http://www.mortbay.org/jetty/>. Sub-classes of 
>>> SSLContextFactory can provide extra features such as helping with 
>>> the configuration of CRLs, or customization of the 
>>> Key/TrustManagers. (If you wish to try it out, there are some jUnit 
>>> tests in the subversion repository.)
>>> I would be interested in having your opinions regarding an 
>>> SSLContextFactory, and whether something similar may have already 
>>> been discussed. Looking at the JDK 7 API, there doesn't seem to be 
>>> an such a class/interface. This has been a rather useful feature for 
>>> my application so far, and it should make it easy to support CRLs 
>>> for example in something like Jetty. However, I'm not sure whether 
>>> it would be good to have something like this SSLContextFactory in 
>>> JDK 7. Perhaps there are other better ways to achieve these goals.
>>> One of the main problems I still find is that few applications 
>>> support setting up the SSLContext, which makes it sometimes 
>>> difficult to configure more advanced features such as CRLs. Java 6 
>>> provides a way to set a default SSLContext, but this is not ideal. 
>>> Sometimes, various connectors in the application may want to use 
>>> different SSLContexts (perhaps with different truststores and 
>>> keystores). For example, I would like to be able to set a specific 
>>> SSLContext when using JavaMail, but I haven't found any 
>>> documentation making it possible to set up the truststore and 
>>> keystores independently, instead, it seems to rely on the default 
>>> system properties.
>>> Best wishes,
>>> Bruno.

More information about the security-dev mailing list