Certificate management in SB2Bi requires a lot of handling because nothing is managed dynamically.
To establish an HTTPS connection, it is necessary to specify the SSL server certificate (CA Certificate) to be used for negotiating the transaction. This requires retrieving the certificate(s) from the remote host beforehand, and at this level, there are many uncertainties that can complicate the task:
-
Network Architecture: The "ssl grabber" utility only negotiates direct connections and does not go through perimeter servers. In our infrastructure, this is prohibited since SB2Bi nodes do not have direct internet access and must go through PS/the DMZ.
-
Certification Chains: There are several scenarios related to certification chains:
- In some cases, it is necessary to retrieve the entire chain of certificates up to the root, requiring 3 to 4 certificates.
- In other cases, only the "half-chain" including the intermediate certificate is needed, requiring 2 certificates.
- In some instances, only the lowest-level certificate suffices, requiring just one certificate.
- Sometimes capturing only the root certificate is sufficient.
-
Specific Ciphers: Occasionally, the remote host uses specific ciphers that necessitate "tweaking" SB2Bi's system configuration:
- Decompiling trustedpoint.jar, adding manual ciphers, recompiling...
- Adding specific parameters in customer_overrides such as "security.FactoryTrustManagerAlgorithm=IbmPKIX" (a recent case in production) whose impact on other non-requiring connections no one seems capable of truly measuring...
-
SNI Configuration: Some remote hosts require a specific "SNI" configuration.
-
Certificate Check-In Options: There are three checkboxes during certificate check-in (validity, auth chain, crl cache), but we never check them. According to a few exchanges with support, "we don't check them."
We exchange via HTTPS with a large number of partners and currently have over 100 "CA" certificates in SB2Bi.
Unfortunately, most of the time certificate renewal is not anticipated or communicated in advance by our partners. Certificates are often renewed well before expiration and we frequently face production incidents when these certificates are renewed. In such cases, we must recapture the certificates, re-import them and then restart all pending BPs.
Some partners (Google, Microsoft...) expose clusters of servers (load balancing) whose certificates may differ. Thus when we launch a certificate capture, we retrieve only one among many; if we then try to connect to this "same" endpoint and end up on another server, the connection fails because the certificate does not match. In this case, you must force a restart until you land on the "right" server...
These manipulations currently represent a considerable waste of time and it will worsen. As of now, most certificates have a validity of about one year. These lifecycles will drastically shorten over the coming years to gradually reach a validity period of 47 days by March 15th, 2029! (source) Given the volume of certificates we currently manage, this means an average certificate renewal every two days! This does not account for potential deployments of other flows with other partners and thus even more certificates over the next four years. It will become critical, time-consuming and prone to incidents.
We wish for IBM to consider the operational constraints associated with this manual certificate management and provide a solution for managing HTTPS transactions flexibly, efficiently and perhaps transparently. For example, completely eliminating the need to pre-retrieve certificates, import them then specify them in the "https client begin session" server and allow SB2Bi to dynamically retrieve/negotiating them during connection?
