Summary: | Allowing non-file based keystore and other providers | ||
---|---|---|---|
Product: | Tomcat 6 | Reporter: | Bruno Harbulot <Bruno.Harbulot> |
Component: | Connectors | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | hauser |
Priority: | P2 | ||
Version: | 6.0.13 | ||
Target Milestone: | default | ||
Hardware: | Other | ||
OS: | other | ||
Attachments: | Patch for allowing to specify keystores providers and not to need a keystore file |
Description
Bruno Harbulot
2007-08-11 14:50:54 UTC
Created attachment 20649 [details]
Patch for allowing to specify keystores providers and not to need a keystore file
Another improvement to this might be to add a parameter for the provider to the
'getStore' method and pass it through 'keystoreProvider' and
truststoreProvider' attributes.
In my use case, it seems to work without specifying the provider, "Apple", but
I guess there might be cases where it could be useful, for other providers.
The configuration would look like this (I've tried it and it works -- it also
fails if I provide the wrong provider, quite logically):
<Connector SSLEnabled="true" clientAuth="want"
keystoreFile="" keystorePass="-" keystoreProvider="Apple"
keystoreType="KeychainStore" maxThreads="150" port="8443"
keyAlias="host.domain"
protocol="HTTP/1.1" scheme="https" secure="true" sslProtocol="TLS"
truststoreFile="" truststoreProvider="Apple"
truststorePass="-" truststoreType="KeychainStore" />
Thanks for the patch, I will review it and possible extend it to the NIO connector as well I have applied a patch to trunk based on your suggestion and proposed it for 6.0.x. (In reply to comment #3) > I have applied a patch to trunk based on your suggestion and proposed it for > 6.0.x. > Thank you. I've just had a look at http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java?revision=653128&view=markup It seems that you've applied a patch along the original report and not the second patch I sent with comment #1. I believe that second patch (being able to set the provider name) could also be useful, even for PKCS#11 applications (one of the ways to configure PKCS#11 is to set up the PKCS#11 options as part of the JVM security provider list, which adds a provider with a new name). More generally, since I opened this issue, I've been making similar suggestions for other projects, in particular Jetty [1] and Restlet [2]. This led me to write a few classes (SSLContext factories) to make the configuration of SSL properties a bit easier, including more advanced options such as Certificate Revocation Lists (I must admit I'm not quite sure how CRLs are to be configured in Tomcat). These classes are available at http://code.google.com/p/jsslutils/. I'm not sure whether this would be useful for Tomcat, but this might be of interest (feel free to get in touch...). [1] http://www.mortbay.org/jetty/ [2] http://www.restlet.org/ The simple patch has been committed to 6.0.x and will be in 6.0.17 onwards. I am leaving this bug open and I'll come back to it for the provider name bit. Please create a new bz item for the CRL stuff. I'd be happy to look at patches / provide you with some pointers but my focus is going to be bug fixing for the short to medium term. I have committed a modified version of the provider patch to trunk and proposed it for 6.0.x The provider part of the patch has now been applied and will be included in 6.0.17 onwards. |