IBM Sterling Ideas

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:

Post your ideas

IBM is transforming its request for enhancement (RFE) process. The purpose of the transformation is to provide a more consistent experience for you to submit requests and to enable IBM product owners to respond to your requests more quickly. For more information click here.

Start by posting ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,
1. Post an idea
2. Upvote ideas that matter most to you
3. Get feedback from the IBM team to refine your idea

Help IBM prioritize your ideas and requests

The IBM team may need your help to refine the ideas so they may ask for more information or feedback. The offering manager team will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at IBM works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.

Receive notifications on the decision

Some ideas can be implemented at IBM, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas which cannot be implemented in a reasonable time.

Key Certificate Management

  • Guest
  • Jun 22 2019
  • Future consideration
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).

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.