6 Replies Latest reply on Jun 22, 2009 4:44 AM by Daffy Duck

    CXF exception: unsupported signature or encryption algorithm

    Daffy Duck Novice

      Hi there,


      I have developed a simple CXF 2.2 WS client application using WS-Policy and WS-Security to connect to a remote Web Service. It works great and I'm happy with that.


      My issue now:

      I am currently trying to package this as an OSGi bundle. When I deploy it on FUSE ESB 4.1 I get the following exception:


      18:25:36,656 | INFO  | xtenderThread-14 | PhaseInterceptorChain            | g.apache.cxf.endpoint.ClientImpl  469 | Interceptor has thrown exception, unwinding now

      org.apache.cxf.interceptor.Fault: An unsupported signature or encryption algorithm was used (unsupported key transport encryption algorithm: No such algorithm: http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p)

           at org.apache.cxf.ws.security.wss4j.policyhandlers.SymmetricBindingHandler.doSignBeforeEncrypt(SymmetricBindingHandler.java:384)

           at org.apache.cxf.ws.security.wss4j.policyhandlers.SymmetricBindingHandler.handleBinding(SymmetricBindingHandler.java:113)

           at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:130)

           at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:73)

           at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)

           at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:469)

           at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:299)

           at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:251)

           at org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:403)

           at org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:310)

           at org.apache.cxf.ws.security.policy.interceptors.SecureConversationOutInterceptor.issueToken(SecureConversationOutInterceptor.java:156)

           at org.apache.cxf.ws.security.policy.interceptors.SecureConversationOutInterceptor.handleMessage(SecureConversationOutInterceptor.java:68)

           at org.apache.cxf.ws.security.policy.interceptors.SecureConversationOutInterceptor.handleMessage(SecureConversationOutInterceptor.java:43)

           at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)

           at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:469)




      I have installed the JCE for unlimited strength crypto so I think everything is fine here.

      I then try to find differences between my sample application and the bundle and I ask myself if this may be due to BouncyCastle as it seems it is not present/installed as a bundle by default in FUSE ESB 4.1 (bouncycastle is a dependency in my sample application project).


      Is this the solution? Is there a ready to use BouncyCastle bundle somewhere?


      Thanks a lot.


        • 1. Re: CXF exception: unsupported signature or encryption algorithm
          Joe Luo Novice

          I am not sure if the error was caused by missing BouncyCastle bundle but I can confirm that the Fuse ESB 4.1 does not have such bundle pre-installed.


          Therefore, if your project bundle depends on the BouncyCastle, you will need to install it as OSGI bundle into the ESB 4.1.


          You might want to contact BouncyCastle project to see if they have an OSGI bundle ready for use. If not, then This post shows you how to install a non-OSGI jar as an OSGI bundle into the Fuse ESB container.

          • 2. Re: CXF exception: unsupported signature or encryption algorithm
            Daffy Duck Novice



            I have made some progress since my last post. Installing BouncyCastle as a JCE provider in my JDK/JRE fixed the problem so no need to deploy BC as a bundle in fact.


            Now I have another issue: the WSS4J version provided with FUSE ESB 4.1 (1.5.4) has a bug that has been fixed in 1.5.6. Just look at the WSPasswordCallback class source code and you'll see that there is a big typo on method getIdentifier(). In 1.5.4 this method is declared as getIdentifer (yes the 'i' is missing!). If you look at 1.5.6 you will even see that they keep the method with the typo to ensure compatibility with code written against 1.5.4.


            I've lost a valuable amount of time to figure out what the problem was. This also leads me to believe that I am the only one trying to make use of WS-Policy/WS-Security in the ESB as this problem on WSS4J would have been discovered a long time ago.

            Moreover there is no WSS4J 1.5.6 bundle on the fuse maven repo and wrapping the jar as a bundle seems to induce some conflicts (and some hard-wired dependencies on BouncyCastle! So in this case I do have to deploy BC as a bundle).


            I think you, at FUSE, should consider upgrading WSS4J bundle to at least version 1.5.6 in your next patch/release because of this nasty typo.




            • 3. Re: CXF exception: unsupported signature or encryption algorithm
              Daniel Kulp Newbie

              I would suggest updating to WSS4J 1.5.7.   One reason their isn't a WSS4J 1.5.7 bundle in the repo is that 1.5.7 is itself an OSGi bundle.   Thus, we don't need to wrapper/repackage it for use in OSGi.   Just grab it from maven central and it should just work.


              Regarding BC:  we cannot create a BC bundle.   Jars that provide Security providers and such MUST be signed jars for the Security runtime to load them.  We cannot create a new bundle jar and keep the signature.  Since it needs to be signed with BC's keys, only the BC folks could create the OSGi bundle for BC.    The only real option is to "endorse" it into your jre.

              • 4. Re: CXF exception: unsupported signature or encryption algorithm
                Daffy Duck Novice

                Hi Dan,


                Yes WSS4J 1.5.7 is indeed a bundle but by looking at the 1.5.6 manifest it appears it is also a bundle.


                Anyway, if you try to install either 1.5.6 or 1.5.7 you end up with this error:


                smx@root:/> osgi/install -s mvn:org.apache.ws.security/wss4j/1.5.7

                ERROR CommandLineExecutionFailed: org.apache.geronimo.gshell.command.CommandException: org.osgi.framework.BundleException: Unresolved constraint in bundle 253: package; (package=org.bouncycastle.asn1.



                So, just because of this import, I have to deploy BC as a bundle in the ESB. And you are right: trying to do so generate another exception (invalidsignature).


                It seems I am stuck here. Why is there this dependency on BC?


                Thanks in advance.


                • 5. Re: CXF exception: unsupported signature or encryption algorithm
                  Daniel Kulp Newbie

                  Uhg...  Forgot about that.   Can you try the 1.5.8-SNAPSHOT.   I fixed the BC dependency last week.




                  I think Colm is planning on doing the 1.5.8 release the week of July 13th.  You may be able to convince him to do it earlier.

                  • 6. Re: CXF exception: unsupported signature or encryption algorithm
                    Daffy Duck Novice

                    Thanks Dan.


                    I am now able to make my bundle works.


                    As of today and using Fuse ESB 4.1 I have the feeling that all of these steps look like an obstacle course.


                    To sum up:

                    - I had to add missing bundle SAAJ-IMPL 1.3

                    - I had to replace buggy WSS4J 1.5.4 by 1.5.8 (a snapshot) because 1.5.6/1.5.7 have explicit dependencies on BouncyCastle. By doing so I figure out that I have to uninstall bundle WSS4J 1.5.4 since some conflicts arise with newer version.

                    - I had to guess what other bundles/libraries are required by WS-Security/WS-Policy (OpenSAML, Xerces Impl, Xalan...)


                    Not so obvious to implement a CXFWS-SecurityWS-Policy+WS-SecureConversation use case with this release of FUSE ESB.


                    At least I can consider (or hope) that it will be better and better with every new release to come.


                    Thank you again for your support.