problem with loading bouncy castle under java 1.4.2

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

problem with loading bouncy castle under java 1.4.2

zoicas
We have a  web application that runs  under tomcat 4 with  java 1.4.2 and there is
no option of installing another  version of java and/or tomcat. I  have  two
questions  (the  first  one is  related  only  to the  java 1.4.2. environment).

Question 1:

       I've followed  the installation instructions on  the Bouncy Caslte
       website, that is:

          * I've downloaded and installed the java policy files in the
            appropriate location;
          * I've installed the file (a simple copy) bcprov-ext-jdk14-155.jar under
            /usr/local/j2sdk1.4.2_08/jre/lib/ext/
          * I've referenced the class org.bouncycastle.jce.provider.BouncyCastleProvider
            as a security provider in the file
            /usr/local/j2sdk1.4.2_08/jre/lib/security/java.security

       Question:
          When I run a command line program that makes an HTTPS connection I receive the  following error:

          javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: Certificate signature validation failed

          and another error says:

          Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.1.11 Signature not available

          The command line to run the program is:
          /usr/local/j2sdk1.4.2_08/jre/bin/java  -classpath .  HttpsWithCert 'https://orcid.org/0000-0002-3217-0990'

          However, the error disappear and all works well if use the  following command line:

          /usr/local/j2sdk1.4.2_08/jre/bin/java -classpath .:/home/cristi/local/BouncyCastle/bcprov-ext-jdk14-155.jar  HttpsWithCert 'https://orcid.org/0000-0002-3217-0990'

          Why is it necessary to add the bcprov-ext-jdk14-155.jar file in
          the classpath? BTW:  the execution is correct even  if I remove
          the  file bcprov-ext-jdk14-155.jar  from the  standard location
          (/usr/local/j2sdk1.4.2_08/jre/lib/ext/).


Question 2:

     Now that I  realized that the file  bcprov-ext-jdk14-155.jar must be
     found in  the classpath I decided  to put the file  under the folder
     <webapp>/WEB-INF/lib  in order  to  make it  accessible  to the  web
     application. But  I receive the same  errors as above?  Why  is this
     file not  loaded from this  location in the  same way as  other .jar
     files are loaded?

     If I modify tomcat startup script catalina.sh and add bcprov-ext-jdk14-155.jar
     to the classpath manually it works. But this is not the prefered solution.

Regards
Cristian


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: problem with loading bouncy castle under java 1.4.2

Tim Panton new

> On 28 Sep 2016, at 15:51, [hidden email] wrote:
>
> We have a  web application that runs  under tomcat 4 with  java 1.4.2 and there is
> no option of installing another  version of java and/or tomcat. I  have  two
> questions  (the  first  one is  related  only  to the  java 1.4.2. environment).
>
>
> Question 2:
>
>    Now that I  realized that the file  bcprov-ext-jdk14-155.jar must be
>    found in  the classpath I decided  to put the file  under the folder
>    <webapp>/WEB-INF/lib  in order  to  make it  accessible  to the  web
>    application. But  I receive the same  errors as above?  Why  is this
>    file not  loaded from this  location in the  same way as  other .jar
>    files are loaded?
>
>    If I modify tomcat startup script catalina.sh and add bcprov-ext-jdk14-155.jar
>    to the classpath manually it works. But this is not the prefered solution.
>

This bit I can answer.
Tomcat creates a class loader _per_ webapp - jars in WEB-INF/lib are made available
to that web app - but not to other web apps - nor to the general tomcat infrastructure.
This is supposed to prevent classes from one web app leaking into other apps.

HTTPS and certificate validation (via a security provider) are core functions of the tomcat infrastructure
and need to be loaded by the main class loader not on the web app one(s).

Tim.

> Regards
> Cristian
>
>


Loading...