Prior to WebSphere Application Server Version 5.0, the use of i5/OS *SYSTEM certificate stores (.kdb files) is supported for WebSphere applications that use the JSSE and SSL program interfaces. With Version 5.0, only Java keystores (.jks files) are fully supported. It is recommended that you migrate your applications to use Java keystores.
With Version 5.0, i5/OS *SYSTEM certificate stores can only be used by applications that are deployed within an administrative domain where global security is disabled. To continue using i5/OS *SYSTEM certificate stores with your applications, perform these steps:
Ensure that security is disabled for the administrative domain where your application is deployed. Use the WebSphere administrative console to disable global security.
Note: If you disable WebSphere security, your WebSphere resources may no longer be protected. Carefully assess your security needs before you disable security. If you decide that security must remain enabled, migrate your applications to use Java keystores.
In the java.security file for your WebSphere instance, set the os400.jdk13.jst.factories property to false. The integrated file system pathname of the java.security file for an instance is /QIBM/UserData/WebASE/ASE5/instance/properties/java.security.
Restart all servers within your administrative domain.
To migrate your applications to use Java keystores (.jks files), perform these steps:
Create Java keystores for your certificates. If your application uses a digital certificate to authenticate to itself to a server, use the iKeyman utility to create a Java keystore to contain the certificate. For more information, see The iKeyman utility.
Note: When you are working with iKeyman, you may find it convenient to map a drive to access keystores and certificate files that are located in the integrated file system of your iSeries system. Otherwise, you can copy the files to your workstation from your iSeries system (for example, by using file transfer protocol), modify them with iKeyman, and then copy the files to the iSeries system.
Typically, you use one keystore to contain the certificate authority certificates (CA or signer certificates) for your application (a trust keystore) and another keystore to contain the client or server certificate. If you have multiple applications, you use a keystore for each application (to contain the client or server certificate), and you use a single trust keystore for all of the applications.
If your application uses commercial certificate authority certificates (signer or CA certificates), you may be able to use the cacerts keystore (the default trust keystore) with your application. The integrated file system path for cacerts is /QIBM/ProdData/Java400/jdk13/lib/security/cacerts. However, in no case should you attempt to modify the cacerts keystore. Rather, you should create a private copy of the cacerts file, and then add or remove certificates. The password for cacerts is changeit. Be sure to change the password that protects your private copy of the cacerts file. Also, note that initially, all keystores created using iKeyman contain a number of commercial CA certificates.
You may create your Java keystores in any iSeries integrated file system directory. However, it may be convenient to place them in the same directory as those that are used by your WebSphere instance. This may make it easier to include them in your backup and restore procedure. WebSphere Application Server - Express provides an initial set of Java keystores that are used to secure connections between WebSphere components. These keystores are found in the etc directory of your WebSphere instance, for example, /QIBM/UserData/WebASE/ASE5/myInstance/etc.
For an example of how to create a Java keystore, see Using Java keystore files.
Use the Digital Certificate Manager (DCM) to export certificates from your i5/OS *SYSTEM certificate stores. Export both the client and server certificates that are used by your applications. Additionally, export the certificate authority (CA) certificates. For more information about DCM, see these topics in the iSeries Information Center:
Note: DCM uses PKCS12 format to export client and server certificates, and it uses base64 encoded format to export certificate authority certificates. These formats are compatible with iKeyman. However, you must to convert the base64 encoded data from EBCDIC to ASCII format before you use it with iKeyman. To convert the data, perform these steps:
touch -C 819 myCA.arm; cat myCA > myCA.arm
To import certificates into your Java keystores, perform these steps:
Start iKeyman on your workstation. For more information, see The iKeyman utility.
Note: You may use separate keystores to contain your client or server certificates and your CA certificates.
Select Exit from the Key Database File menu.
Grant Read and Execute (*RX) authority to your Java keystores for the i5/OS user profile under which your application runs. For example, enter the Change Authority (CHGAUT) command to grant *RX authority to the QEJBSVR user profile for the myKeys.jks (where myKeys.jks is accessed by a servlet that is deployed on your default instance):
CHGAUT OBJ('/QIBM/UserData/WebASE/ASE5/instance/etc/myKeys.jks') USER(QEJBSVR) DTAAUT(*RX)
Make the code changes that are required for using your Java keystores. The changes that are required for your applications to use your Java keystores vary, depending on your implementation. See Using Java keystore files for code examples.
Test your applications.
After you are convinced that your applications are working correctly, you may want to clean up files, authorities, and properties that your application no longer needs.
Note: This cleanup applies to both stand-alone Java client applications and to applications that are deployed on your application server.
One or more of the following properties may be set and should be removed from your application's runtime environment. If the application is running on your application server, the properties are set as custom properties in the runtime configuration of your application server:
os400.certificateContainer
If your application used the os400.certificateContainer property, also delete the certificate container (.kdb file), but only if it is no longer used by any other application.
os400.certificateLabel
os400.secureApplication
If your application used the os400.secureApplication property, also use Digital Certificate Manager (DCM) to delete the secure application from the *SYSTEM certificate store.
Use Operations Navigator to remove authority to the *SYSTEM certificate store for the i5/OS user profile under which your server or client application runs. The user profile that you use to run Operations Navigator must have *SECADM special authority to perform this task.
Note: This step applies only if your application previously used certificates that were contained in the *SYSTEM certificate store, and the user profile does not require access to the *SYSTEM certificate store for any other application.
For example, if the user profile the application runs under is QEJBSVR, perform these tasks: