Skip to main content

Illegal key size or default parameters

When you run the pre-defined security scenarios in the WSO2 ESB most probably you already faced the Illegal key size or default parameters exception

org.apache.axis2.AxisFault: Error in encryption
    at org.apache.rampart.handler.RampartSender.invoke(RampartSender.java:76)
    at org.apache.axis2.engine.Phase.invokeHandler(Phase.java:340)
    at org.apache.axis2.engine.Phase.invoke(Phase.java:313)
    at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:261)
    at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:426)
    at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:398)
    at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:224)
    at org.apache.axis2.client.OperationClient.execute(OperationClient.java:149)
    at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:554)
    at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:530)
    at SecurityClient.runSecurityClient(SecurityClient.java:111)
    at SecurityClient.main(SecurityClient.java:33)
Caused by: org.apache.rampart.RampartException: Error in encryption
    at org.apache.rampart.builder.SymmetricBindingBuilder.doSignBeforeEncrypt(SymmetricBindingBuilder.java:765)
    at org.apache.rampart.builder.SymmetricBindingBuilder.build(SymmetricBindingBuilder.java:86)
    at org.apache.rampart.MessageBuilder.build(MessageBuilder.java:144)
    at org.apache.rampart.handler.RampartSender.invoke(RampartSender.java:65)
    ... 11 more
Caused by: org.apache.ws.security.WSSecurityException: Cannot encrypt data; nested exception is: 
    org.apache.xml.security.encryption.XMLEncryptionException: Illegal key size or default parameters
Original Exception was java.security.InvalidKeyException: Illegal key size or default parameters
    at org.apache.ws.security.message.WSSecEncrypt.doEncryption(WSSecEncrypt.java:608)
    at org.apache.ws.security.message.WSSecEncrypt.doEncryption(WSSecEncrypt.java:461)
    at org.apache.ws.security.message.WSSecEncrypt.encryptForExternalRef(WSSecEncrypt.java:388)
    at org.apache.rampart.builder.SymmetricBindingBuilder.doSignBeforeEncrypt(SymmetricBindingBuilder.java:755)
    ... 14 more


Reason for this issue could be not installed JCE file to your JRE. First you can check after install JCE file on your JRE. To confirm JCE file installed correctly, you can find following Java source.


public class JCETest {

    public static void main(String args[]) {
        int maxKeyLen = 0;
        try {
            maxKeyLen = Cipher.getMaxAllowedKeyLength("AES");
        } catch (NoSuchAlgorithmException e) {
            Assert.fail();
        }

        Assert.assertEquals(2147483647, maxKeyLen);
        System.out.println(maxKeyLen);
    }
}


AES key size should be equal to the 2147483647 if JCE files has been installed sucessfully. 

Comments

Popular posts from this blog

How to enable proxy service security in ESB 4.9.0?

Security is  one of the major concern when we developing API base integrations or application developments. WSO2 supports WS Security , WS-Policy and WS-Security Policy specifications. These specifications define a behavior model for web services. Proxy service security requirements are different from each others. WSO2 ESB providing pre-define commonly used twenty security scenarios to choose based on the security requirements. This functionality is provided by the security management feature which is bundled by default in service management feature in ESB. This configuration can be done via the web console until ESB 4.8.1 release, but this has been removed from the ESB 4.9.0. Even though this feature isn't provided by the ESB web console itself same functionality can be achieved by the new WSO2 Dev Studio . WSO2 always motivate to use dev studio to prepare required artifacts to the ESB rather than the web console. Better way to explain this scenario is by example. Following...

How SSL Tunneling working in the WSO2 ESB

This blog post assumes that the user who reads has some basic understanding of SSL tunneling and the basic message flow of the ESB. If you are not familiar with the concepts of the SSL tunneling you can refer my previous blog post about the SSL tunneling and you can get detail idea about the message flow from this article . I will give brief introduction about the targetHandler for understand concepts easily. As you may already know TargetHandler(TH) is responsible for handling requests and responses for the backend side. It is maintaining status (REQUEST_READY, RESPONSE_READY .. ,etc) based on the events which fired by the IOReactor and executing relevant methods. As the example if a response which is coming from the backend side hits to the ESB, IOReactor fire the responseRecived method in the targetHandler side. Followings are the basic methods contain in the target handler and their responsibilities. Connect: -  This is executed when new outgoing connection needed. ...

Select different backend pools based on the HTTP Headers in Nginx

Some scenarios we need to select different backend pools based on some attributes in the request. Nginx has that capability to selecting different backend pools based on the request header value. To accomplish this in Nginx you can use the following code in your configuration. upstream gold { server 127.0.0.1:8080; server 127.0.0.1:8081; server 127.0.0.1:8082; } upstream platinum { server 127.0.0.1:8083; server 127.0.0.1:8084; server 127.0.0.1:8085; } upstream silver { server 127.0.0.1:8086; server 127.0.0.1:8087; } # map to different upstream backends based on header map $customer_type $pool { default "gold"; platinum "platinum"; silver "silver"; } server { listen 80; server_name localhost; location / { proxy_pass http://$pool; #standard proxy settings proxy_set_header X-Real-IP $remote_addr; proxy_redirect off; p...