Skip to Main Content
IBM Sterling

This portal is to open public enhancement requests for IBM Sterling products and services. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Future consideration
Created by Guest
Created on Jun 22, 2019

Key Certificate Management

No description provided
What is your industry? Non-Industry Specific
How will this idea be used?

IBM's Managed File Transfer suite of products, comprised of Secure Proxy, Control Center, External Authentication Server, B2B Integrator, File Gateway and Connect:Direct require integration with other applications to perform their functions, whether that is an operating system, directory service like Active Directory for authentication, and communication/transmissions in an interoperable way between each of these components, internal applications and the outside world.  As the suite respirates files to and from a variety of locations, it can do so in a secure manner, whether it involves SSH or TLSvX.  A fundamental part of securing these components and their sub-components involves key certificates.


Over the years, the strategy for maintaining key certificates among these products continues to vary, even within products (see B2B Integrator) as evidenced by the points below:

  - B2Bi

     - System, Trusted and CA key certificate stores which can accept PKCS#12 key stores for system certificates or Java-produced key stores (not .pem, the common OpenSSL standard).

        - Passphrases are secured in B2Bi's database for System key certificates by hashing them as-stored.

     - Java-based trust store (.jks) for LDAP

       - Passphrase is in-the-clear unless intentionally encrypted within or

     - Java-based hybrid key/trust store for Liberty (REST API, etc.) and Command Line Adapter server components.

       - Passphrase is in-the-clear both in server.xml (Liberty) and Command Line Adapter component (server property file) unless intentionally encrypted by entirely different tools.

  - SP

    - System and CA key certificates are placed in respective stores with passphrases obscured and encrypted.

    - Can accept PKCS#12 or Java-produced key stores (again, not .pem).

    - Key certificates must be manually exported from CM and imported to engines individually (across all engines this CM has discourse).

  - CC and EA

    - Both these products use Java key stores (.jks) for their trust and key components separated by those functions (not key/trust hybrid).

  - For Connect:Direct the process can vary depending on the OS; the most commonly-encouraged method is to use IKeyMan to create and manage key databases and transfer key certificates, roots and intermediates between them as necessary.  Mainframes can employ different methods depending on how their key rings and overall security strategy is established.


By looking at the variety of key stores and and management styles above, it is clear that key certificate management becomes a highly complex and diverse (and confusing for our customers) task.  Volumes are written for our customers on how best to maintain key certificates in each product.  Those of us in the field that design, implement, deploy and test both within IBM and IBM's service partners understand the daunting task of key certificate management but with nuances at each site, despite our recommendations, there are always important differences between customers, which encourages us for the sake of our customers to write up detailed information on how to maintain key certificates for the products they purchased.  Many IBM Support hours are devoted to assisting customers with key certificate issues such as replacement in such a way as to avoid disruption of service.  Having guided a globally-deployed, multi-data center customer (8 data centers, three environments each of four regions), it took 6 months to fully replace all root and intermediate as well as key certificates for all these regions for all products when VeriSign sold to DigiCert.


This needs to change.


I propose this solution:  A central key certificate management tool that can deploy key/system certificates, roots and intermediates to any of our MFT products in the format needed.  Additionally, deploy them when appropriate to adapters (which is the most tedious task when there are over 100 proxies that require them, similar number of server adapters for one environment!  With REST APIs now available for most if not all our MFT products, this seems like a plausible option, whether updating a CM, SEAS, ICC, C:D, B2Bi.  Of course this would require some standardization of storage for key certificates (Java key store?  Database?  Encrypted File?)  It would inevitably lead to changes in UI function as well based on standardized key certificate deployment.


The idea is that key certificates can continue to be generated per discretion of the customer, i.e. Venafi, IKeyMan, OpenSSL (with conversion to JKS or PKCS12 perhaps), etc. but key certificates, roots and intermediates would be checked into a common repository by product with instructions for best practices regarding key certificate handling (different key certificates for different products, common name and alternate name use (product-specific), etc.)  This common UI framework could reside in ICC or be a separate component altogether.  The important thing here is to standardize key certificate management and deployment to make MFT key certificate management less of a multi-month task.  Even scheduled deployments should be considered (push certs on June 25th to Secure Proxy, for example).