LBN Originally Published: April 12, 2022
LBN Revised: Dec 7, 2022 :
=========
From:
In practice, this means that EMS Java clients should be running on recent builds of OpenJDK 11 or 17, or Oracle Java 8, 11, or 17.  There is not currently a build of OpenJDK 8 that supports these updated PKCS#12 files. Because FTL Java clients use OpenSSL, the Java version isn’t relevant to compatibility.

To:
In practice, this means that EMS Java clients should be running on recent builds of Java. Because FTL Java clients use OpenSSL, the Java version isn’t relevant to compatibility.
==========

LBN Revised: Dec 8, 2022 :
=========
From:
In upcoming releases, TIBCO Enterprise Message Service, TIBCO FTL/eFTL, and TIBCO Rendezvous will require strengthening ciphers and certificates, and removing older, exploitable protocols. Upcoming releases are introducing a new set of minimum requirements that will affect the backwards compatibility of older certificates, ciphers and keys.

To:
The TIBCO Enterprise Message Service™ 10.2.0, TIBCO FTL® 6.8.0, TIBCO eFTL® 6.8.0, and TIBCO Rendezvous® 8.6.0 releases and later will require strengthening ciphers and certificates, and removing older, exploitable protocols. These releases are introducing a new set of minimum requirements that will affect the backwards compatibility of older certificates, ciphers and keys.
=========

Revised LBN:
[Dec 8, 2022] 

Industry security guidelines are now recommending that certificates, ciphers and keys originally created using older protocols be upgraded to newer, stronger implementations as soon as possible to prevent unauthorized access to applications and systems.  TIBCO Messaging customers are strongly recommended to review and update their current security configurations as soon as possible.

The TIBCO Enterprise Message Service™ 10.2.0, TIBCO FTL® 6.8.0, TIBCO eFTL® 6.8.0, and TIBCO Rendezvous® 8.6.0 releases and later will require strengthening ciphers and certificates, and removing older, exploitable protocols. These releases are introducing a new set of minimum requirements that will affect the backwards compatibility of older certificates, ciphers and keys.  Customers are recommended to review their current configurations and begin updating as soon as possible in order to smooth transitions to the new messaging product releases.  The “openssl” command line utility, version 1.1.1 and later, can be used to update existing installations in advance of this transition.

TIBCO Enterprise Message Service - Clients and servers using encrypted connections (SSL/TLS) may be affected.

• Certificates, whether used in TIBCO Enterprise Message Service PKCS#12 files or copied elsewhere, may need to be updated.  Refer to the TIBCO Enterprise Message Service Users Guide under Digital Certificates for more information on certificates.
• PKCS#12 files specified in TIBCO Enterprise Message Service configurations may need to be converted as specified below.

• Certificates, other than ftl-trust.pem, used in TIBCO FTL/eFTL may need to be updated.
• PKCS#12 files other than ftl-tport.p12 specified in TIBCO FTL/eFTL configurations may need to be converted as specified below.

• Certificates, whether specified in PKCS#12 files or copied into the daemon configurations or elsewhere, may need to be updated as indicated below.
• PKCS#12 files specified in RVRD configurations or used in RVSD/RVSRD connections may need to be converted as specified below.

As part of this strengthening of security, TIBCO is transitioning from OpenSSL 1.1.1 to OpenSSL 3.0. The new version attempts to simplify such things as cipher suite selection and key length choices using a security level setting (SECLEVEL) from 0 to 5.  The default SECLEVEL is 1, and includes the following restrictions, as documented on the OpenSSL site:

• RSA, DSA and DH keys shorter than 1024 bits and ECC keys shorter than 160 bits are prohibited. 
• All export cipher suites are prohibited.
• SSL version 2 is prohibited. 
• Any cipher suite using MD5 for the MAC is also prohibited. 
• Signatures using SHA1 and MD5 are also forbidden.

TIBCO products impose additional restrictions beyond these:

• SSL version 3 is disabled.
• TLS versions 1.0 and 1.1 are disabled.

Additional restrictions may be applied in the future as best practices evolve. Because of these restrictions, many of the cipher suites available in OpenSSL 1.1.1 are, by default, disabled.  Certificates and keys that do not meet these criteria will fail.

The first consequence of this that may be noticed is that PKCS#12 files that were encrypted with older ciphers will no longer be readable.  This is because, by default, older utilities produced files that use RC2 encryption to protect the private key.  RC2 is considered a legacy algorithm in OpenSSL 3.0.  Not only does it not meet the criteria of SECLEVEL 1, it is not actually compiled into the main library.  See below for instructions on converting older PKCS#12 files to a format acceptable to OpenSSL 3.0.

Converting the PKCS#12 file to newer ciphers will, of course, introduce the requirement that all consumers of the file must support the new ciphers. In practice, this means that EMS Java clients should be running on recent builds of Java. Because FTL Java clients use OpenSSL, the Java version isn’t relevant to compatibility.

Even after the file is converted, if the key algorithm or key size are not acceptable by modern standards, OpenSSL will reject any certificate based on that key.  Customers or users will need to replace existing certificates with new ones that meet the requirements of SECLEVEL 1.

There are other reasons that OpenSSL 3.0 may reject a customer generated certificate.  It generally enforces the rules specified in the applicable RFCs much more strictly.  For instance, the following errors may come up:

• Path length given without key usage
• Missing Authority Key Identifier
• Missing Subject Key Identifier
• Basic Constraints of CA cert not marked critical
• CA cert does not include key usage extension

This is not an exhaustive list, but represents a few of the errors we’ve seen in practice.

The restrictions on actual TLS cipher suite selection should be benign, since virtually all clients support at least one cipher mode that meets the criteria.

Converting PKCS#12 Files

To convert a legacy PKCS#12 file to newer algorithms using OpenSSL 1.1, use the following commands:

openssl pkcs12 -in sample.p12  -passin pass:password -nodes > tmp.txt
openssl pkcs12 -in tmp.txt -out fixed_sample.p12 -macalg SHA256 -keypbe AES-256-CBC -certpbe AES-256-CBC -export -passout pass:password

The corresponding commands for OpenSSL 3.0:

openssl pkcs12 -in sample.p12  -passin pass:password -noenc -legacy > tmp.txt
openssl pkcs12 -in tmp.txt -out fixed_sample.p12 -export -passout pass:password

The result can be verified with the following command:

openssl pkcs12 -in fixed_sample.p12 -info -noenc -noout -passin pass:password

If the output contains “RC2” in any of the text, then the p12 file is incompatible with OpenSSL 3.0.