SSL - configuration for non-egeria code ie connectors ie JDBC

[planetf1]

trafficstars

When using the JDBC integration connector, the database connection may require the use of SSL.

In this case a variety of parameters may be set (see https://www.ibm.com/docs/en/db2/11.5?topic=SSEPGG_11.5.0/com.ibm.db2.luw.apdv.java.doc/src/tpc/imjcc_r0052038.htm for DB2)

This will typically include certificate information - passwords, types etc, but crucially also PATHS on the local system to

• trust store
• key store

These may not be the same as for the egeria server chassis. Particularly for the key store (the client side certificate) which will be unique.

In order to use these connectors, the relevant certificates need to be present in the local environment where the egeria server chassis is running (in k8s, often through a secret)

This needs documenting as to how to deploy/configure

Additionally in the case of our charts/operator this may need actual deployment code

Opening as a reminder this is part of addressing cert management

[planetf1]

I've been hitting issues even trying to make a 1 way SSL connect to a DB2 cloud service.

Whilst the handling of this particular situation is buggy (10 min timeout instead of immediate failure) by deep debugging, the failing stack is:

I think what may be happening here is that when we launch the server chassis (from our assembly, or in our container) we point to a truststore that ONLY includes our certificate authority.

In my case I was making an SSL connection to a cloud DB2 server, which was returning a server cert signed by a certificate with a public train of trust. That would normally be resolved by the default system level root authority certs/chain (as it is in my standalone test code). However since our custom cert root does not contain these, validation of the server cert fails.

This same issue could affect ANY ssl connection made by the egeria server chassis.

The alternatives are:

• Add standard cert authorities to the egeria truststore (defaults, or as passed by parm)- not good for maintainance, unless this is through an automated process ie built into the generation of our certs
• Create a custom SSL context for connections we manage & allow for application specific properties to configure. This is what many apps do - it avoids JVM level settings which cause the kind of issue we have here. This was an original design thought in egeria but we opted to simplify....
• Where possible provide appropriate parms for the user connection in question. So here for example there are additional properties that can be passed in the jdbc connection string. However as mentioned earlier in this issue, these files will still require deployment onto the machine in question

#1 only requires doc changes, but can be tedious to actually do #2 is cleanest IMO as it gives better isolation, but requries supporting code in egeria (it would be in addition to JVM level configuration which would remain an option). It also avoids 'breaking' default behaviour, but at the same time requires additional egeria knowledge of the custom parms.... #3 is also tedious for deployment

Open for discussion as to docs vs code....

[planetf1]

(I think the hang is likely due to db2 driver seeing this as a potentially transient error)

[planetf1]

Adding sslTrustStoreLocation=/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/lib/security/cacerts; to the JDBC connection string resolved the issue for me -- of course that relies on the relevant CAs being defined there. It's also destination platform specific

At a minimum this needs explaining/docs to cover general cases as well as known examples, such as db2