Layer7 API Management

  • 1.  GMU Migration - Ilegal Key size

    Posted Jun 14, 2018 01:18 PM

    I found something similar in older post but no clue about solution.

     

    I did somehow all configurations and I can migrate using GMU using my notebook. I can use migrateOut and migrateIn and it's working fine here.

     

    But if I copy everything (GMU, libs, .p12 files, authentication properties - same folder with same configurations) it doesn't work. The error message is:

     

    [root@li2745 GMU]# ./GatewayMigrationUtility.sh migrateOut -z properties/origem.properties --dest usuario.xml --serviceName /GET/usuario
    Warning: TLS hostname verification has been disabled
    Warning: TLS server certificate check has been disabled
    Running........
    Execution failed. Reason: Error creating keystore: exception unwrapping private key - java.security.InvalidKeyException: Illegal key size

     

    Locally, it works fine:

     

    D:\Aplicativos\GMU>GatewayMigrationUtility.bat migrateOut -z properties\origem.properties --defaultAction NewOrUpdate --dest usuario.xml --serviceName /GET/usuario
    Warning: TLS hostname verification has been disabled
    Warning: TLS server certificate check has been disabled
    Running.................................................................................................
    Done

     

    The content of this properties file is:

     

    host=li3384
    port=8443
    clientCert=origem.p12
    password=u2r8pC8YvkY.DaP6pbFb6jBwfXFBk4aQ9Q
    encryptionPassphrase=u2r8pC8YvkY.DaP6pbFb6jBwfXFBk4aQ9Q
    trustCertificate
    trustHostname

     

    All passwords are the same and I'm not using or configure server trust (last topic of Configure GMU and Gateways for Migration - CA API Gateway - 9.3 - CA Technologies Documentation). Any ideas about what am I missing?



  • 2.  Re: GMU Migration - Ilegal Key size

    Posted Jun 14, 2018 02:07 PM

    Check your java version.

    Also,  you may need to install Java Encryption Extension (JCE) .



  • 3.  Re: GMU Migration - Ilegal Key size

    Posted Jun 14, 2018 05:39 PM

    Maybe, but both are Java 1.8. Mine is 1.8.0_171 and the other 1.8.0_144.

     

    By the way, one is Windows and the other is Linux (not working), if this information is relevant.



  • 4.  Re: GMU Migration - Ilegal Key size

    Posted Jun 15, 2018 01:25 AM

    You need to install the JCE.

    It's not installed by default with JRE/JDK.

     

    Download the files from oracle website  Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files for JDK/JRE 8 Download 

    Extract the jar files from the zip and save them in ${java.home}/jre/lib/security/.



  • 5.  Re: GMU Migration - Ilegal Key size

    Broadcom Employee
    Posted Jun 15, 2018 01:45 AM

    Nothing as I just paid my side of it.

     

    Derek Orr

    ca technologies

    Principal Consultant, CA API Management Presales

    m: 778-980-0029

    Email = Derek.Orr@ca.com<mailto:Derek.Orr@ca.com>

     

    CA API Management Community: https://communities.ca.com/community/ca-api-management-community



  • 6.  Re: GMU Migration - Ilegal Key size
    Best Answer

    Broadcom Employee
    Posted Jun 15, 2018 06:47 AM
      |   view attached

    As pointed out by others - that error - usually - means that Java is not allowed to use larger key sizes - and you need the JCE patch.

     

    1) Attached is little test program that will tell you if you have JCE installed.

        testcryptostrength.zip  (attached below)

     

    2) As pointed out here :  The design of JCE patch has shifted a bit recently : 

        https://stackoverflow.com/questions/37741142/how-to-install-unlimited-strength-jce-for-java-8-in-os-x 

     

     

    Java 8 Update 161

    As pointed out in another answer and in Oracle's release notes for Java 8 Update 161, unlimited cryptography is enabled by default since Update 161 and you shouldn't have to do anything if using a fresh installation of this version.

    Java 8 Update 151

    With Java 8 Update 151, Oracle included the same JCE mechanism into Java 8 that they already provided with Java 9. To enable JCE in Java 8 Update 151 or higher, just set the property

    crypto.policy=unlimited

    in $JAVA_HOME/jre/lib/security/java.security.

     

    3) Debugging the SSL 

       I don't think you will need this - but if you do get caught still, then adding this to the .bat file where it runs java 

         -javax.net.debug="all" 

      will give all the SSL details - and can help isolate a problem (say if it was the DHE key size being too small, or something).

     

      But it does look like classic issue with JCE unlimited patch not being active. 

     

    Cheers - Mark

    Attachment(s)

    zip
    testcryptostrength.zip   2 KB 1 version


  • 7.  Re: GMU Migration - Ilegal Key size

    Posted Jun 15, 2018 10:27 AM

    There's no need of installing JCE... updating to version 1.8_171 was enough. Probably is embedded now.



  • 8.  Re: GMU Migration - Ilegal Key size

    Broadcom Employee
    Posted Jun 15, 2018 10:13 PM

    Yes as  per above, in 151 it became a java.security setting, and then in 161 it became enabled by default - that will help us a lot as this was something regularly tripped over in installs, after upgrades etc etc etc. - Yeah ! - Cheers Mark



  • 9.  Re: GMU Migration - Ilegal Key size

    Broadcom Employee
    Posted Jun 16, 2018 07:48 AM

    There is another couple of things to note here:

    • This discussion is about using stream ciphers here - in particular there is an upper limit of AES 128bit (and no further) that is fixed by the JCE update (which comes default in JRE 8 build 171 and above). So, if you are trying to use AES 256bit or higher, that is where the blockage is happening.
    • There is also another lower limit block - this time to do with block ciphers. JREs block things that have 1024 bit keys signing certificates (or less) - as in RSA/DSA signed packages. This was a push to get people to use higher strength keys in certificates (and a general move to SHA2 or SHA256 usage).

    The later problem was common amongst many CA program interfaces/UIs that we have that use signed Java applications (CA Spectrum being one of them). So, if you are using cryptographically weak certificates then you might think about updating them. For example, when you use keytool from newer JREs then you will be pushed into the use of SHA2 signing.



  • 10.  Re: GMU Migration - Ilegal Key size

    Broadcom Employee
    Posted Jun 17, 2018 10:56 PM

    Hi Edward, yes I agree, crypto problem with java used to be mostly problems where stronger crypto was not allowed. - but now and going forward, there will be more issues where minimum requirements are not met - Cheers - Mark