You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2017/02/10 12:37:59 UTC

[Bug 60721] New: Unable to find key spec if more applications use bundled Bouncy Castle

https://bz.apache.org/bugzilla/show_bug.cgi?id=60721

            Bug ID: 60721
           Summary: Unable to find key spec if more applications use
                    bundled Bouncy Castle
           Product: Tomcat 8
           Version: 8.5.9
          Hardware: PC
                OS: Mac OS X 10.1
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Catalina
          Assignee: dev@tomcat.apache.org
          Reporter: petr@lime-company.eu
  Target Milestone: ----

Created attachment 34744
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=34744&action=edit
Stack trace of an exception.

We are running Tomcat 8.5.9 and we have multiple WARs deployed in /webapps
folder. If more than one of these web apps contain a bundled Bouncy Castle
provider, we receive exception in attached stack trace on attempt to use
cryptographic algorithm.

Steps to reproduce:

0) Get and build the sample application:

$ git clone https://github.com/lime-company/bcissue-20170210
$ cd bcissue-20170210
$ mvn clean package ; open ./target

1) Create a clean instance of Tomcat 8.5.9
2) Deploy one instance of the sample application.
3) Open http://localhost:8080/bcissue/hello
=> Everything works as expected

4) Deploy another instance of the same sample application (rename it to
bcissue2, so that you can have 2 instances on the same Tomcat)
5) Open http://localhost:8080/bcissue2/hello
=> Exception occurs

Expected solution:

Bouncy Castle from particular application is correctly loaded.

Or we would like to see a documentation of how the BC is supposed to work with
Tomcat. Alternatively, we would like to see BC included in Tomcat distribution.

Current Workaround:

We managed to workaround the issue by installing Bouncy Castle in our JRE,
using the "Static Installation", as documented here:

http://www.bouncycastle.org/wiki/display/JA1/Provider+Installation

However, this is not always desired, since global installation may interfere
with other applications (for example, Wildfly has issues in case BC is
installed system wide, since it bundles own BC version).

System information:

$ java -version
java version "1.8.0_92"
Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.92-b14, mixed mode)

Running on MacOS X Sierra 10.12.3 (16D32), but we are having this issues on
other Linux based environments as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 60721] Unable to find key spec if more applications use bundled Bouncy Castle

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60721

Emmanuel Bourg <eb...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|VERIFIED                    |CLOSED

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 60721] Unable to find key spec if more applications use bundled Bouncy Castle

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60721

Mark Thomas <ma...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Mark Thomas <ma...@apache.org> ---
You are having class loader issues because you are registering a web
application provided library (loaded with the web application class loader)
with a JVM wide registry and then trying to use that library in a different web
application (with a different class loader).

That is never going to work.

This is not a Tomcat bug.

Static installation is one solution. Moving the Bouncy Castle JAR(s) to
$CATALINA_BASE/lib should also work.

If you want to discuss your options further, the users@ list is the place to do
that.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 60721] Unable to find key spec if more applications use bundled Bouncy Castle

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60721

Petr Dvorak <pe...@lime-company.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |VERIFIED

--- Comment #2 from Petr Dvorak <pe...@lime-company.eu> ---
Thank you for the response - VERIFIED.

Just to sum up, after I did little bit more focused testing:

This works:

- Installing BC provider in JRE ("static") helps - all applications work
regardless of it they bundle BC provider JAR or not.
- Putting 'bcprov-jdk15on-1.XX.jar' in '$CATALINA_BASE/lib' helps reliably in
case no deployed WAR contains the BC jar (!).

This does not work:

- Putting 'bcprov-jdk15on-1.XX.jar' in '$CATALINA_BASE/lib' in case some WAR
contains the BC jar - only the first application works, regardless of if it
bundles BC provider JAR or not, no other application work.
- ... and as mentioned in the issue response, having per-application provider
does not work.

I hope this issue will be helpful for future reference.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org