Question & Answer
Question
IBM Java for AIX HowTo: Java Security Checklist
Answer
This document provides a list of well known exceptions and step-by-step details to confirm and resolve them. After completing all of these steps, if the problem continues, then it is recommended that you open a new IBM support call with the IBM AIX Java Support team for a more in-depth analysis into the issue. Prior to any additional analysis, the IBM AIX Java Support team will confirm that all of these steps have been completed since some of these are well known and documented issues.
The list that follows identifies the Java security situations that have been reported to IBM Software Support while using IBM Java for AIX.
1. Strong jurisdiction policy files are used for key lengths exceeding the default key size.
2, Non-IBM policy files are used, unrestricted policy files are not in the correct path or the Java application doesn't have permission to access the policy files.
3. The /JAVA_SECURITY_DIR/ has both renamed old and new policy files.
4. Java install is not at the latest Service Refresh level.
5. Order of security providers in the /JAVA_SECURITY_FILE/ file is different from the default security providers list.
6. Third party security providers are specified in the /JAVA_SECURITY_FILE/ file.
7. Third party security provider is used either programmatically or with a jar file added to the Java CLASSPATH variable.
8. Third party security providers are used with IBM unrestricted policy files.
9. Disabled algorithms are used.
10. Policy files and/or the trust store is overwritten by Java upgrade.
11. The key table to obtain the key for the ticket principal is not specified when the "-k" option is used with the "kinit" command.
12. Incorrect password is used with "ktpass" command.
13. Keys are not regenerated and redistributed after the password change even when the password is reset to the same password.
14. The keytab file is not copied to the server machine after it has been regenerated.
15. The Kerberos configuration points to the incorrect keytab file.
16. The SPN (Service Principal Name) is defined to Active Directory more than once.
17. SPN (Service Principal Name) is not registered.
18. Keys not supported by IBM JCE are used.
19, Key generated using one provider is deserialized using another provider implementation.
20. RC4 cipher suites used with the fix for Bar Mitzvah security vulnerability, CVE-2015-2808.
21. IP address of the server not in the hosts file or the Application server not recycled after loading the new hosts file.
The instructions that follow provide the details to identify the root cause and the corrective actions that must occur to resolve failures due to the above list of items.
The exceptions listed below will be written to standard output (stdout), standard error (stderr), or to an application log file, depending on the configuration used.
--------------------------
Incorrect/inaccessible policy files or use of third party security provider with IBM policy files:
Caused by: java.lang.SecurityException: Cannot set up certs for trusted CAs
at javax.crypto.b.
.....
Caused by: java.lang.SecurityException: Jurisdiction policy files are
not signed by trusted signers!
at javax.crypto.b.a(Unknown Source)
at javax.crypto.b.a(Unknown Source)
.....
---------------
-------------------------------------------------
illegal key size or default parameters:
java.security.InvalidKeyException: Illegal key size or default parameters
at javax.crypto.Cipher.a(Unknown Source)
at javax.crypto.Cipher.a(Unknown Source)
.......
-----------------------------------------------------------------------
-------------------------------
Use of disabled protocol (like SSLv3) or corrupted certificate cache for SSH certificate:
SSL handshake failed
javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.j: No trusted
certificate found.
------------------------------
------------------
SSL handshake failure due to unsupported protocol:
main, RECV TLSv1 ALERT: fatal, handshake_failure
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLHandshakeException: Received
fatal alert: handshake_failure
javax.net.ssl.SSLHandshakeException: Received fatal alert:
handshake_failure
at com.ibm.jsse2.j.a(j.java:9)
at com.ibm.jsse2.j.a(j.java:6)
--------------
---------------------
Provider is either missing from the "java.security" file or specified incorrectly:
major string: Unsupported mechanism minor string: No factory available to create name for mechanism 1.3.6.1.5.5.2 at com.ibm.security.jgss.i18n.I18NException.throwGSSException(I18NException.java:30)
make sure that the java.security file contains the IBMSPNEGO security provider and is defined correctly. It should contain a line similar to the following:
security.provider.6=com.ibm.security.jgss.mech.spnego.IBMSPNEGO
----------------------------------------------------
-----------------------------------------------------
Ticket encoded using one key and then an attempt is made to decode the ticket using another key:
major string: General failure, unspecified at GSSAPI level
minor string: Kerberos error while decoding and verifying token: com.ibm.security.krb5.internal.KrbException, status code: 31 message: Integrity check on decrypted field failed
---------------------------------------------------
-------------------------------------------------
Invalid/wrong password used with "ktpass" command:
com.ibm.security.krb5.internal.crypto.KrbCryptoException, status code: 0
message: Checksum error; received checksum does not match
computed checksum
--------------------------------------------------
-------------------------------------------------
The "java.security" file shows third party security providers:
#JsafeJCE Provider - RSA BSAFE CryptoJ module provider for FIPS
compliancy
security.provider.1=com.rsa.jsafe.provider.JsafeJC
..
-------------------------------------------------------
-----------------------------
IP address of the server missing from the hosts file:
major string: Invalid credentials
minor string: Cannot get credential from JAAS Subject for principal: HTTP/192.168.0.4@168.0.4
[11/11/03 1:42:29:876 EST] 1d01b21e TraceNLS u No message text associated with key SpnegoTAI.exits.due.to.an.exception.
in bundle com.ibm.ejs.resources.security
---------------------
------------------------------------------------------------
Disabled signature algorithm or key lengths:
java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
--------------------------------------------------
The information in this section provides useful information to aid in the resolution of commonly reported security issues while using IBM Java for AIX.
1. Use correct version of the policy files:
Unlimited jurisdiction policy files can be downloaded from:
https://www-01.ibm.com/marketing/iwm/iwm/web/preLogin.do?source=jcesdk
There are two versions of the unrestricted policy files - one for the old JVMs and one for the new JVMs,
For latest Java versions/SRs, download policy files for:
Java 5.0 SR16 and above, Java 6 SR13 and above, Java 6 SR5 (J9 VM2.6) and above, Java 7 SR4 and above, Java 8 GA and above, and all later releases
and for all the prior Java version/SRs, download policy files for:
Files for older versions of the SDK
Policy files in /JAVA_SECURITY_DIR/ are used by default. To avoid overwriting the files when Java gets upgraded, without renaming the files, place the files outside default installation directory for the SDK. Specify the location of the files using Java command line system property:
-Dcom.ibm.security.jurisdictionPolicyDir=
2. Make sure the Service Refresh (SR) with the fix is installed:
The security components are the same for both the IBM SDK with J9 2.4 VM and IBM SDK with J9 2.6 VM, although the service refresh levels are not equivalent.
3. Install fixes for known security vulnerabilities:
http://www.ibm.com/developerworks/java/jdk/alerts/
4. Enable/disable algorithms:
Add to disable or remove to enable the protocol name from the list of specified protocols for the following system property in the /JAVA_SECURITY_FILE/.
for example:
jdk.tls.disabledAlgorithms=SSLv3, RC4, DH keySize < 768
The SSL V3.0 algorithm can also be enabled using command line setting. When the above system property is used in conjunction with the following Java command line setting for SSLv3, the system property has precedence over the command line setting:
-Dcom.ibm.jsse2.disableSSLv3=false
If the application hard codes the protocol label "SSLv3", use the property below to automatically match the behavior for protocol label SSL without modifying the source code by setting the property to "true". The default value is "false":
-Dcom.ibm.jsse2.convertSSLv3=[true|false]
Property com.ibm.jsse2.disableSSLv3 always takes effect based on its value, regardless of the setting for com.ibm.jsse2.convertSSLv3.
If your application uses javax.net.ssl.HttpsURLConnection, set the https.protocols system property explicitly to disallow SSL V3.0, which otherwise defaults to allow SSL V3.0. For example, use the following command line option:
For the initial release of Java 6.0.1 (J9 VM2.6), Java 6 service refresh 9 and Java 5.0:
-Dhttps.protocols=TLSv1
For Java 6.0.1 service refresh 1 (J9 VM2.6), Java 6 service refresh 10, and all later releases:
-Dhttps.protocols="TLSv1,TLSv1.1,TLSv1.2"
With the following system property setting in /JAVA_SECURITY_FILE/, any certificate signed with MD2, MD5, or with a RSA key of less than 1024 bits in length is not considered valid:
jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
To disable further algorithms, add to the list above, separating algorithm names with a comma.
Certain specific cipher suites are disabled during TLS handshaking in /JAVA_SECURITY_FILE/ file with system property:
For example:
jdk.tls.disabledAlgorithms=MD5wthRSA
If none of the above actions have resolved the issue, then complete the following steps:
1. Collect and upload data as per instructions in URL:
http://www-01.ibm.com/support/docview.wss?uid=isg3T1022547
2. Open a new IBM support call with the "IBM AIX Java" team.
The "IBM AIX Java" team will confirm and require that scenarios listed in the "Cause(s)" section of this technote have been eliminated as potential causes for this issue:
When the IBM support call is created, answers to the following questions must be provided:
a. Was the application restarted? If not, when was the last time the application was restarted?
b. Does the impacted system have security vulnerability fixes installed?
c. Is data collected as per instructions in the technote "IBM Java for AIX MustGather: Data collection procedure for Java security issues"?
3. Upload the packaged data
Using one of the IBM secure upload methods listed on the "IBM Java for AIX MustGather: How to upload diagnostic data and testcases to IBM" web page, upload data:
http://www-01.ibm.com/support/docview.wss?uid=isg3T1022619
,
ACTION
ACTION
ACTION
ACTION
ACTION
ACTION
ACTION
ACTION
ACTION
ACTION
ACTION
ACTION
Was this topic helpful?
Document Information
Modified date:
17 June 2018
UID
isg3T1023713