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 customer_overrides.properties or authentication.properties.
- 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).
