General Page
IBM Semeru Runtimes security migration guide
IBM SDK, Java Technology Edition, version 8 contains the IBM security implementation. However, version 11 of the IBM Semeru RuntimeâÃÂâ Open Edition and IBM Semeru RuntimeâÃÂâ Certified Edition contain the OpenJDK security implementation. Differences between these implementations might require code changes to your applications.
OpenJDK contains a Java cryptographic implementation that includes TLS v1.3 since JDK11. This protocol is enabled by default and contains significant differences to earlier TLS implementations. For more information about TLS v1.3, including which algorithms are no longer allowed, see JEP 332.
IBM Semeru Runtimes can utilize OpenSSL to enhance cryptographic acceleration. For more information related to this acceleration and behavior see OpenSSL.
The security certificates aolrootca1 and aolrootca2 that were present in IBM SDK, Java Technology Edition, V8 are no longer included.
Note: IBM Semeru Runtimes can leverage FIPS 140-3 capabilities for production workloads. Starting with versions 8.0.352, 11.0.16, and 17.0.4, IBM Semeru Runtimes includes FIPS support, by using the NSS library in Red Hat Enterprise Linux 8 or later. For more information, see FIPS certified cryptography in IBM Semeru Runtimes FIPS.
IBM Semeru Runtime Certified Edition for z/OS
Information in this security migration guide does not apply for the IBM Semeru Runtime Certified Edition for z/OS. Refer to these resources:
For SDK downloads, fixes lists, security vulnerabilities and more.
For additional information on installation, troubleshooting and support.
Security providers
The OpenJDK security providers have different names to the IBM Security providers. If your application uses hardcoded IBM provider names, you must update your application code. The following table shows the equivalent OpenJDK provider names, their implementation class, and the Java module in which the class belongs. If you want to learn more about the differences between providers, click the links in the IBM Security provider column.
Note that the ikeyman and ikeycmd tools which were available in IBM SDK, Java Technology Edition, version 8, are not available in versions 11 and above of the IBM Semeru Runtimes. Use the Keytool command to perform certificate and key operations.
Also note that, the IBM Key Certificate Management utility (ibmkeycert.jar) is no longer shipped with the IBM Semeru SDKs. As an alternative, for key and certificate management, use one of the following tools:
- Use zseckeytool utility for JCERACFKS (RACF Software) keystore management
- Use hwkeytool utility to manage keystores, which contain private keys and their associated X.509 certificate chains
- Use keytool utility for general use keystore management
- Use Bouncy Castle for programmatic solutions
| IBM Security provider | OpenJDK/Oracle security provider | Implementation class | Java module |
|---|---|---|---|
| IBM JSSE2 | The SunJSSE provider | ||
| IBM JCE (see Note 1) | The SUN provider | ||
| The SunEC Provider | |||
| The SunJCE provider | |||
| The SunRsaSign provider | |||
| IBM JGSS | The sunJGSS provider | ||
| IBM Certification Path | OpenJDK Certification Path | ||
| IBM SASL | The sunSASL provider | ||
| IBM JAAS | OpenJDK JAAS | ||
| IBMSecureRandom (see Note 2) | - | - | - |
| XML Digital Signature (see Note 3) | The XMLDSig provider | ||
| XML Digital Encryption (see Note 4) | - | - | - |
Table: IBM security provider to OpenJDK security provider mapping
Notes:
- OpenJDK contains an (optional) LGPL native module, which implements part of . For more information, see the file legal/jdk.crypto.ec/ecc.mdd.
- OpenJDK does not have an equivalent version of the IBMSecureRandom provider. For alternative functionality, see IBMSecureRandom.
- The OpenJDK XML Digital Signature provider and implementation class is identical to the IBM provider (JSR105).
- OpenJDK does not implement the Java XML Digital Encryption Specification (JSR 106). If your application uses the IBM security class , you must update your application code to remove it.
- OpenJDK allows the use of unsigned third-party cryptographic providers.
JSSE provider differences
If your application uses hardcoded IBM provider, protocol, or algorithm names, you must update your application code.
The following table shows some key differences for JSSE:
| Aspect of JSSE | IBM SDK, Java Technology Edition, version 8 | IBM Semeru Runtimes, version 11 |
|---|---|---|
| IBM JSSE provider | ||
| IBM HTTPS protocol handler | ||
| KeyManagerFactory algorithm | or | or |
| TrustManagerFactory algorithm | or | or |
Table: Key differences for JSSE
System properties
The following system properties are no longer supported:
To enable PKIX revocation checking, you should now set the system property to true, instead of the system property.
If the DHKeySize is not specified in the property, a minimum is no longer set.
SSL settings
To enable , you no longer need to set the system property to false. However, you still need to remove from in the java.security file.
now enables TLS versions up to 1.3 with the following implications:
- When you specify TLS with , TLS versions 1.0, 1.1, 1.2, and 1.3 are now all enabled. By contrast, in previous releases that use the IBM JSSE2 provider, only TLS version 1.0 is enabled.
- In this release, you can also use to enable TLS versions 1.0 and 1.1. By contrast, in previous releases that use the IBM JSSE2 provider, only TLS version 1.1 is enabled.
Protocol aliases and are no longer supported in this release.
Key managers and key stores
Key managers and key stores are affected in the following ways:
- Certificate chain verification now stops when a trusted certificate is reached, with the following implications:
- The OpenJDK replaces the . When you use the , it verifies the certificate chain up to the trusted certificate. Verification stops when it reaches a trusted certificate. In contrast, the verifies the entire server or client certificate chain, including trusted certificates. For example, if a trusted certificate is expired, then the handshake fails, even though the expired certificate is trusted. This change does not affect the .
When is called with a null array, IBM Java 8 selects a valid from the highest priority in the configured security providers. In contrast, OpenJDK and Semeru create a which never returns any keys. This might cause TLS client authentication to fail silently in Semeru.
When migrating from IBM Java 8 to Semeru, developers must explicitly provide a valid to use TLS client authentication or use to obtain an initialized with a default which respects the and system properties. For more information, see OpenJDK Bug JDK-8292574.
- now handles some exceptions differently. Instead of producing an error, now creates a default or with an empty in the following situations:
- The or that is specified by the system properties does not exist.
- The password is incorrect.
- The type is inappropriate for the .
Ciphers, cipher suites, and certificates
Ciphers, cipher suites, and certificates are affected in the following ways:
- Anonymous cipher suites are now allowed by JSSE .
- Servers with DSA certificates must use specific cipher suites. If the server has a DSA certificate only, then these certificates can only use cipher suites with *_DH*_* in the name. Previously, if the server has a DSA certificate only, and only RSA*.
- The SSL_* or TLS_* prefix in cipher suite names can no longer be used interchangeably. You should update your applications to use the prefix that is specified by OpenJDK. For a complete list of OpenJDK cipher suites, see: SunJSSE Cipher Suites.
JCE provider differences
This release contains the OpenJDK JCE provider, instead of the IBM JCE provider. Differences between these implementations might require code changes to your applications.
Some IBM JCE provider functions do not have an equivalent in the OpenJDK providers. Equivalent functions, if available, come from multiple OpenJDK providers as shown in the following table:
| OpenJDK providers | Functions |
|---|---|
| SUN | CertificateFactory (X.509), KeyStore (PKCS12, JKS, DKS), and MessageDigest (*) |
| SunEC | Elliptic Curve algorithms |
| SunJCE | Diffie-Hellman algorithms, KeyStore (JCEKS), KeyGenerator (*), Mac (*), and SecretKeyFactory (*) |
| SunRSASign | RSA signature algorithms and RSA key generation using KeyFactory or KeyPairGenerator |
Table: Equivalent JCE function for OpenJDK providers
Type AlgorithmParameters
| IBMJCE algorithm or alias | Equivalent OpenJDK algorithm (from the SunJCE provider) |
|---|---|
| 1 | |
| None | |
| None | |
| None | |
| None | |
| None | |
| None | |
| 2 | |
| None | |
| None |
Table: Type AlgorithmParameters
Table notes:
- Non-standard aliases that are available from the IBMJCE provider are not available from OpenJDK providers. Use a standard algorithm name instead.
- The IBMJCE provider maps these object identifiers to PBEWithSHAAnd3KeyTripleDES. The OpenJDK equivalent maps these object identifiers to PBEWithSHA1AndDESede.
Type Cipher
| IBMJCE algorithm or alias | Equivalent OpenJDK algorithm (from the SunJCE provider) |
|---|---|
| 1 | |
| None | |
| None | |
| None | |
| None | |
| None | |
| None | |
| None | |
| 2 | |
| None | |
| None | |
| None |
Table: Type Cipher
Table notes:
- The IBMJCE provider maps these object identifiers to Cipher.AESWrap. The OpenJDK equivalent does not have these object identifiers.
- The IBMJCE provider maps these object identifiers to PBEWithSHAAnd3KeyTripleDES. The OpenJDK equivalent maps these object identifiers to PBEWithSHA1AndDESede.
Type KeyFactory
| IBMJCE algorithm or alias | Equivalent OpenJDK algorithm | OpenJDK provider | Notes |
|---|---|---|---|
| SUN | Non-standard aliases that are available from the IBMJCE provider are not available from OpenJDK providers. Use a standard algorithm name instead. | ||
| SunEC | The IBMJCE provider maps these object identifiers to . OpenJDK does not have these object identifiers. | ||
| SunRsaSign | The IBMJCE provider maps these object identifiers to . OpenJDK does not have these object identifiers. Both the IBMJCE provider and the OpenJDK equivalent have object identifiers for and . |
Table: Type KeyFactory
Type KeyGenerator
| IBMJCE algorithm or alias | Equivalent OpenJDK algorithm (from the SunJCE provider) |
|---|---|
| 1 | |
| 2 | |
| None | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| None | |
| None |
Table: Type KeyGenerator
Table notes:
- IBMJCE maps these object identifiers to . OpenJDK does not have these object identifiers.
- Non-standard aliases that are available from the IBMJCE provider are not available from OpenJDK providers. Use a standard algorithm name instead.
Type KeyPairGenerator
| IBMJCE algorithm or alias | Equivalent OpenJDK algorithm | OpenJDK provider | Notes |
|---|---|---|---|
| SUN | This object identifier maps to KeyPairGenerator.DSA. Alternatively, you can use 1.2.840.10040.4.1 or DSA. | ||
| SunEC | The IBMJCE provider maps these object identifiers to . OpenJDK does not have these object identifiers. | ||
| SunRsaSign | IBMJCE maps these object identifiers to . OpenJDK does not have these object identifiers. Both the IBMJCE provider and the OpenJDK equivalent have object identifiers for and . |
Table: Type KeyPairGenerator
Type KeyStore
| IBMJCE algorithm or alias | Equivalent OpenJDK algorithm | OpenJDK provider | Notes |
|---|---|---|---|
| None | |||
| SUN | The IBM JCE implementation of PKCS12 is the same as the OpenJDK implementation of PKCS12. | ||
| None | |||
| SUN | The IBM JCE implementation of PKCS12S2 is the same as the OpenJDK implementation of PKCS12. |
Table: Type KeyStore
Type Mac
Type MessageDigest
Type SecretKeyFactory
| IBMJCE algorithm or alias | Equivalent OpenJDK algorithm (from the SunJCE provider) |
|---|---|
| None | |
| 1 | |
| None | |
| None | |
| None | |
| None | |
| None | |
| None | |
| 2 | |
| None | |
| None | |
| None | |
| None | |
| None | |
| None | |
| None |
Table: Type SecretKeyFactory
Table notes:
- Non-standard aliases that are available from the IBMJCE provider are not available from OpenJDK providers. Use a standard algorithm name instead.
- The IBMJCE provider maps these object identifiers to . The OpenJDK equivalent maps these object identifiers to .
Type SecureRandom
| IBMJCE algorithm or alias | Equivalent OpenJDK algorithm |
|---|---|
| None | |
| None | |
| None |
Table: Type SecureRandom
Type Signature
| IBMJCE algorithm or alias | Equivalent OpenJDK algorithm | OpenJDK provider |
|---|---|---|
| 1 | SUN | |
| 1 | SunEC | |
| 1 | SunRsaSign | |
| 1 | SunRsaSign | |
| None | ||
| 1 | Usually SunEC 2 | |
| 1 | SUN | |
| 1 | SunEC | |
| 1 | SunRsaSign | |
| 1 | SUN | |
| 1 | SunRsaSign | |
| 1 | SunEC | |
| 1 | SunEC | |
| 1 | SunRsaSign | |
| 1 | SunEC | |
| 1 | SunRsaSign |
Table: Type Signature
Table notes:
- Non-standard aliases that are available from the IBMJCE provider are not available from OpenJDK providers. Use a standard algorithm name instead.
The algorithm is unique in that you supply your own object as the data to be signed. A object that does not compute a message digest is therefore required for a provider to service the algorithm. The OpenJDK class locates a security provider to service the algorithm. If you specify, on your call, a particular provider to service the algorithm, the class returns one of the following objects:
- An instance of a signature object, if the specified provider supports that algorithm
- A special signature object, if the specified provider supports the Cipher
If you do not specify a provider on your call, the class manufactures a signature object from an Cipher object from the first cryptographic provider that offers that cipher algorithm, which is usually SunJCE. The order of preference of providers is determined by the list that is stored in the class. You can get the list by using the method.
Keys
The following differences exist for keys:
- IBM DH and support key sizes between 256 and 2048 bits, that are a multiple of 64. The OpenJDK equivalents support key sizes between 512 and 2048 bits, that are a multiple of 64.
- IBM DH defaults to a key size of 1024 bits. The OpenJDK equivalent defaults to 2048 bits.
- IBM DSA defaults to a key size of 2048 bits. The OpenJDK equivalent defaults to 1024 bits.
- IBM RSA recognizes the property. The corresponding OpenJDK RSA recognizes the property.
- The OpenJDK security implementation does not support RFC5915-encoded EC private keys.
- Before IBM SDK, Java Technology Edition Version 8, service refresh 1, fix pack 10, the IBM PKCS12S2 keystore type was equivalent to the OpenJDK PKCS12 keystore type, but the IBM PKCS12 keystore type was different. In later fix packs, the IBM PKCS12 and PKCS12S2 keystore types are modified to use a shared implementation. This shared implementation is forwards and backwards compatible with older IBM and older OpenJDK PKCS12 implementations. However, the OpenJDK 11 PKCS12 Keystore type is not compatible with these IBM PKCS12 and PKCS12S2 keystore types.
- Oracle recommend that you upgrade your keystores to use the OpenJDK 11 PKCS12 keystore type.
Ciphers
IBM RSA Cipher recognizes the property. When this property is set, the runtime environment checks that RSA public keys are not used for decryption, and that RSA private keys are not used for encryption. There is no equivalent function in the OpenJDK security implementation.
Mask generation
The IBM and OpenJDK implementations differ in the default mask generation function (MGF1) that is used when performing RSA OAEP operations. The OpenJDK implementation always uses SHA-1 whereas the IBMJCE provider uses a mask generation function that corresponds to the OAEP hash algorithm.
Hardware acceleration
The IBMJCE provider supports hardware acceleration for some ciphers, if hardware acceleration is supported on that platform. The OpenJDK JCE implementation does not have this support.
JGSS provider differences
This release contains the OpenJDK JGSS provider, instead of the IBM JGSS provider.
The following table shows the equivalent functionality in the IBM and OpenJDK JGSS providers.
| Attributes and system properties | IBM | OpenJDK |
|---|---|---|
| JGSS provider name | ||
| Package containing the JGSS provider | ||
| Package containing the SPNEGO mechanism | ||
| Package containing the Kerberos mechanism | ||
| System property | The original purpose of the OpenJDK Java property is extended to facilitate undocumented WebSphere support". | No Oracle equivalent |
| Support for Kerberos utilities (kinit, klist, and ktab) | Supported on all platforms. | Supported only on Windows platforms. On other platforms, use native Kerberos utilities. |
| kinit -c FILE | Permits only the owner to access the cache file. | Permits access to the cache file based on the user's umask value. |
| in the JAAS configuration file | ||
| Initiate/accept configuration declaration in the JAAS configuration file | ||
| (WSSKrbToken.jar) | Available only in version 8, not version 11. Used only by WebSphere Application Server. | No Oracle equivalent |
Table: Functional differences between IBM and OpenJDK JGSS providers
System properties
The following table shows the equivalent system properties in the IBM and OpenJDK JGSS providers.
| IBM | OpenJDK |
|---|---|
| , |
Table: Differences in system properties between IBM and OpenJDK JGSS providers
The following table shows the system properties that exist only in the IBM JGSS provider, which have no OpenJDK equivalent.
| System property | IBM |
|---|---|
| Used only by WebSphere Application Server. It is not documented for public consumption. | |
| : Yes | SPNEGO has RFC 2478 behavior |
| Ignore Kerberos config file | |
| Set charset for string-to-key encoding | |
| Used only by WebSphere Application Server. It is not documented for public consumption. | |
| OS400 charset |
Table: System properties that exist only in the IBM JGSS provider
JAAS options for Kerberos login
The following table shows the equivalent functionality in the IBM and OpenJDK JGSS providers.
| IBM | OpenJDK | |
|---|---|---|
| Initiator | credsType = (default) | isInitiator = (default) |
| Acceptor | credsType = | isInitiator = |
| Initiator & acceptor | credsType = | Not available |
| Use default ticket cache | useDefaultCache = (default is ) credsType must be or Search sequence: 1. The file cache location specified by system property KRB5CCNAME. 2. <user_home><file_seperator>krb5cc_<user_name> 3. The local security authority (LSA) on Windows platforms | useTicketCache = (default is ) ticketCache is not set Search sequence: 1. On Linux and Solaris platforms, when useTicketCache is set to , searches /tmp/krb5cc_uid 2. <user_home><file_separator>krb5cc_<user_name> 3. The local security authority (LSA) on Windows platforms |
| Specify ticket cache | useCcache = useDefaultCache must not be set to | useTicketCache = ticketCache = |
| Use default keytab | useDefaultKeyTab = (default is ) credsType must be or Default keytab search sequence: 1. Java property KRB5_KTNAME 2. <default_keytab_name> in libdefaults in the Kerberos configuration file 3. <user_home><file_seperator>krb5.keytab 4. <user_directory><file_seperator>krb5.keytab | useKeyTab = (default is ) keyTab is not set Default keytab search sequence: 1. <default_keytab_name> in libdefaults in the Kerberos configuration file 2. <user_home><file_seperator>krb5.keytab 3. <user_directory><file_seperator>krb5.keytab |
| Specify keytab | useKeytab = useDefaultKeyTab must not be set to | useKeyTab = keyTab = |
| Forwardable, proxiable, or renewable TGT | forwardable|proxiable|renewable = (default is ) | Not available |
| Display login module banner | moduleBanner = (default is ) | Not available |
| Store credentials(principals & ticket & key) in shared state | storeSharedStateCredentials = (default is ) | Not available |
| Store user name and password in shared state | Not available | storePass = (default is ) |
| Clear user name and password in shared state | Not available | clearPass = (default is )) |
| Do not prompt for password | Not available | doNotPrompt = (default is ) |
| Store key in principalâÃÂÃÂs private credentials | Not available | storeKey = |
| Use password saved in shared state | useFirstPass = or tryFirstPass = (defaults are both ) | useFirstPass = or tryFirstPass = (defaults are both ) |
| Renew TGT | renewTGT = (default is ) | renewTGT = (default is ) |
| Refresh Krb5 configuration file | refreshKrb5Config = (default is ) | refreshKrb5Config = (default is ) |
| Output debug messages | debug = (default is ) | debug = (default is ) |
Table: Comparison between IBM and OpenJDK JGSS provider function for Kerberos login
IBM Certification Path provider differences
This release contains the OpenJDK Certification Path provider, instead of the IBM Certification Path provider. Attributes and system properties that are available in IBM Certification Path (CertPath) provider might not be available, or might have different names, in the OpenJDK providers.
| Attributes and system properties | IBM | OpenJDK |
|---|---|---|
| Package containing the CertPath provider | ||
| CertPath provider name | No separate provider for CertPath. It is incorporated into the OpenJDK provider . | |
| System property used to enable CRL Distribution Points extension checking | ||
| System property used for support of processing both complete CRLs and delta CRLs | , set to or
| No OpenJDK equivalent |
| System property used to define a timeout value for the connection to a certificate's CRL distribution point, or to a object | ||
| System property used to set the lifetime of entries in the memory cache of an LDAP CertStore | No OpenJDK equivalent | |
| System property that determines whether CertPath checks revocation only on the end-entity certificate of the certificate chain, or on all the certificates of the certificate chain except for the trusted root certificate (TrustAnchor) | No OpenJDK equivalent. However, the same behavior can be specified within the class for either IBM or OpenJDK. | |
| Strict CRL validation | Supported | Not supported |
| Reverse building | Supported | Not supported |
Table: Functional comparison between IBM and OpenJDK Certification path providers
SASL provider differences
This release contains the OpenJDK SASL provider, instead of the IBM SASL provider. Differences between these providers might require code changes to your applications.
The following table lists IBM SASL classes that are different to equivalent OpenJDK SASL providers.
| IBMSASL class | OpenJDK SASL class |
|---|
Table: Differences for IBM SASL and OpenJDK SASL classes
JAAS provider differences
This release contains the OpenJDK JAAS provider, instead of the IBM JAAS provider. Differences between these providers might require code changes to your applications.
JAAS Active Login
In this release, JAAS Active Login is removed. There is no OpenJDK equivalent.
JAAS equivalent classes
The following table lists IBM JAAS provider classes and equivalent OpenJDK JAAS provider classes.
| IBM JAAS provider class | Oracle JAAS provider class |
|---|---|
| No Oracle equivalents |
Table: Differences for IBM JAAS and OpenJDK JAAS provider classes
IBM SecureRandom provider
The provider is not available in this release. However, most of the functionality is available in the OpenJDK SUN provider.
If your application uses the provider, use the following table to find equivalent OpenJDK SUN functionality.
| IBM SecureRandom function | Equivalent function in the SUN provider |
|---|---|
| algorithm | algorithm |
| None. Use the default algorithm, or specify a different algorithm if required. | |
| and algorithms | and algorithms. The OpenJDK SUN provider also provides matching aliases of SHA and SHA1 for the . |
Table: IBMSecureRandom equivalent function in the SUN provider
Note for Unix systems: The default seed source for the class in Version 8 was the random number generator /dev/urandom. In Version 11, the default changed to /dev/random, which blocks threads until sufficient entropy is available. This new default might therefore be a slower source of random values.
XML Digital Signature services (JSR105)
This release contains the reference implementation of JSR 105 XML Digital Signature services, which is identical to the IBM implementation provided in IBM SDK, Java Technology Edition, version 8.
The implementation class for the JSR105 XML Digital Signature provider is , which can be found in the module.
The IBM implementation is the provider. If your application uses the IBM security class , you must update your application code to use the JSR 105 class instead.
Notice about plans, directions and intent
Statements by IBM regarding its plans, directions, and intent are subject to change or withdrawal without notice at the sole discretion of IBM. Information regarding potential future products is intended to outline general product direction and should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for IBM products remain at the sole discretion of IBM.
Was this topic helpful?
Document Information
Modified date:
21 April 2026
UID
ibm16411285