|Summary:||Enhancement to set security-provider within AjpAprProcessor|
|Component:||Catalina||Assignee:||Tomcat Developers Mailing List <dev>|
Patches to set a securityProvider
Proposed patch for Tomcat 6
Description pknopp 2011-03-08 04:49:48 UTC
Created attachment 26742 [details] Patches to set a securityProvider We need support of X.509 certificates using elliptic curves for client-auth within an servlet-application. The certificates we use are coded using DomainParameters within the PublicKey object. When using the sun-jdk this will lead to an error because the sun-jce implementation only supports elliptic curves as NamedCurves. The best way to fix this is to use another security-provider e.g. bouncycastle. For that we need a way to configure it within tomcat.
Comment 1 pknopp 2011-03-08 05:19:58 UTC
Mark Thomas has commented by email: >The patch raises a couple of questions for me. > - Security providers are normally configured at the JVM level. > - Patches that change one of 5 connectors usually mean the other >connectors need changing too > - There are other places where CertificateFactory is used that may >conflict with this patch. I will not define the provider in the JVM. For that I have to insert e.g. bouncycastle at the first position to not get sun security-provider for X.509 CertificateFactory. With that definition bouncycastle is used anywhere within the JVM first. This could lead to some other effects I cannot estimate. I'm not able to see if the changes are necessary for other connectors. For Http11AprProcessor and AjpProcessor it is nearly the same as for AjpArProcessor. Http11NioProcessor and Http11Processor are not using CertificateFactory. The last remark is unclear for me. With my proposed patch all other places are unchanged. So there will be no conflict.
Comment 2 Mark Thomas 2011-03-12 04:57:53 UTC
I've had a chance to look at this further. With regard to the three points I raised previously: > - Security providers are normally configured at the JVM level I can see why you don't like this and your reasoning is consistent with the design of the Tomcat SSL connector implementation. It is meant to be possible to configure each connector independently of any JVM configuration. > - Patches that change one of 5 connectors usually mean the other >connectors need changing too All of the connectors use CertifcateFactory. HTTP BIO & NIO use it via JSSESupport so all five connectors will need changes. > - There are other places where CertificateFactory is used that may >conflict with this patch. My point is that it isn't just the connectors that create client certificates from SSL data. The SSL Valve also does this and will also need a configuration option for this. I'll work on a patch for 7.0.x which will then be back-ported to 6.0.x.
Comment 3 Mark Thomas 2011-03-13 10:01:45 UTC
Fixed in 7.0.x and will be in 7.0.12 onwards.
Comment 4 Mark Thomas 2011-03-13 14:08:46 UTC
Created attachment 26765 [details] Proposed patch for Tomcat 6
Comment 5 pknopp 2011-03-14 12:58:25 UTC
(In reply to comment #4) > Created an attachment (id=26765) [details] > Proposed patch for Tomcat 6 I have tested the proposed patch within Tomcat 6.0.32, it works fine. The client-certificate with a ECDSA-key is converted correctly within tomcat. One remark to your patch: You use different logging within the class SSLValve, but not within the Connectors. It would be nice for debbuging if the messages differ between a CertificateException and a NoSuchProviderException.
Comment 6 Mark Thomas 2011-06-03 08:16:53 UTC
Fixed in 6.0.x and will be included in 6.0.33 onwards.