V4 - *important* - SSL cert update

[planetf1]

We realised this morning that our self-signed certificates will expire on 15 March.
There is a PR open on odpi/egeria#7504 for core egeria, & further points in issue odpi/egeria#7503

Any repos other than odpi/egeria that contain client/server certificates need to be updated.
The truststore, and the root & intermediate CA are not affected

@davidradl @sarbull I think it’s mostly the UI affected as they include a server & client cert

For react UI the two files under ‘/ssl/*p12’ can be updated from egeria main once the PR above is merged.
However I cannot remember that the server.cert/key are, or how used. They seem old.

[planetf1]

@davidradl @sarbull

The self-signed ssl certs in the UI will expire before release 4 ships.
I am not sure of the impact of this on the UI behaviour, or use in charts/demos. I also am unsure how server.id is used vs the .p12 files (which are old versions from the main egeria codebase, and can be copied over to replace).

The certs expire Mar 26

It may be that no validation is done, but I have not tested the react UI

The react UI would need to be built, and images be created with the change - ie a mini release process

[davidradl]

@planetf1 I am not sure what you mean by server.id- I cannot see that in the Egeria react ui code base.

It seems that the react docs around ssl configuration are out of date ,as one of the links does not work

https://egeria-project.org/user-interfaces/ecosystem/configure-and-run-presentation-server/?h=ssl#5-ssl-configuration

I need to update 4 files.
The server code issues

httpsAgent: new https.Agent({
      ca: truststore,
      pfx: keystore,
      passphrase: passphrase,
    }),

truststore is truststore.p12 and keystone is keystore.p12 in the ssl folder

As documented : https://nodejs.org/api/tls.html#tls_tls_createsecurecontext_options

The client side, refers to the 2 other files in a sample env file.
SSL_CRT_FILE=../../ssl/keys/server.cert\

location of key file in codebase, required to properly use HTTPS locally

SSL_KEY_FILE=../../ssl/keys/server.key

I am not sure what the files mean in planetf1/egeria@8026c6a#diff-e9b7512b3f3193d3de543a4248588c43f77bfa61ba07bf8f7cc15d3d33e6f58f, as I cannot see them documented. I see https://egeria-project.org/guides/admin/configuring-the-omag-server-platform/?h=#example-to-launch-egeria which refers to files including EgeriaCA.p12 which I cannot find.

@planetf1 I am guessing that the following changes need to be made. Can you confirm this is what you expect, then I will test with them.

server.cert => open-metadata-resources/open-metadata-deployment/certificates/EgeriaReactUIClient.cert.pem
server.key => open-metadata-resources/open-metadata-deployment/certificates/EgeriaReactUIClient.key.pem
truststore.p12 => open-metadata-resources/open-metadata-deployment/certificates/EgeriaServerChassis.p12
keystore.p12 => open-metadata-implementation/user-interfaces/ui-chassis/ui-chassis-spring/src/main/resources/keystore.p12

[planetf1]

In the reactui under ssl/keys we have a 'server.id' file. I notice this is already expired:

openssl x509 -enddate -noout -in server.cert                                                        
notAfter=Sep  3 22:01:11 2022 GMT

There's a server.key created at the same time

In the ssl directory we have the certs I'd created last year:

openssl pkcs12 -in EgeriaReactUIServer.p12 -nodes | openssl x509 -noout -enddate

Enter Import Password:
MAC verified OK
notAfter=Mar 26 11:25:19 2023 GMT

and the CA, which remains valid:

openssl pkcs12 -in EgeriaRootCA.p12 -nodes | openssl x509 -noout -enddate

Enter Import Password:
MAC verified OK
notAfter=Mar 13 11:25:17 2032 GMT

(The pass is 'egeria')

The certificates I generated recently are checked into core egeria under open-metadata-resources/open-metadata-deployment/certificates

The 'truststore.p12' file you may see elsewhere in our source tree is EgeriaRootCA.p12 and contains the root certificate authority. This is used for clients to 'trust' the server they receive a certificate from though of course a) these are 'demo'/sample certs so shouldn't be trusted and b) in many causes the configuration is set not to validate.

The 'keystore.p12' is just a copy of one of the application specific certificates. For example in the server chassis it's just a copy of EgeriaServerChassis.p12. This was done initially as those components had already created their own certs by hand, and the .sh script file in the certificates directory copies them in.

This approach was meant to be temporary - with the idea of removing all certs and forcing a user action to generate certs during the install of egeria, but that step has yet to be done.

I agree that the reference in egeria docs is wrong - the EgeriaCA.p12 should be EgeriaRootCA.p12 (and needs testing).

Also the docs for react UI probably should refer to the certificates directory rather than the root - as those files are confusingly named copies.

We created unique certificates per connection to prove config was possible, including for 2 way ssl ,but it does obfuscate the more typical 1 way ssl configuration :-(

In terms of files to use, the reactUI has a client & a server component, so the SOURCE files you need are

• EgeriaReactUIClient .*-- for the client
• EgeriaReactUIServer.* -- for the server

You have a choice of formats - there is a .p12 bundle, or you can use the individual certificate (.cert.pem) and key (.key.pem) . This is what the application would SEND as it's certificate ... Which format you use depends on what libraries/API you are using - whatever is easiest

Some files need a password to access - this is 'egeria'

Then for BOTH client and server, you would use the EgeriaRootCA.p12 as a bundle which contains the root certiication authority certificate. This will be used to validate a received certificate (though often turned off or degraded in our environments!) This can also be found as PEM format under EgeriaRootCA/certs/EgeriaRootCA.cert.pem

[planetf1]

In your SPECIFIC list of files to copy.

server.cert => open-metadata-resources/open-metadata-deployment/certificates/EgeriaReactUIClient.cert.pem

Yes.

server.key => open-metadata-resources/open-metadata-deployment/certificates/EgeriaReactUIClient.key.pem

Yes

truststore.p12 => open-metadata-resources/open-metadata-deployment/certificates/EgeriaServerChassis.p12

Kind-of : The original is ./open-metadata-resources/open-metadata-deployment/certificates/EgeriaRootCA.p12 - though it's been copied from there to the file above, so ultimately it will work..

keystore.p12 => open-metadata-implementation/user-interfaces/ui-chassis/ui-chassis-spring/src/main/resources/keystore.p12

No. This Should be ./open-metadata-resources/open-metadata-deployment/certificates/EgeriaReactUIServer.p12 .

Your proposal probably technically works, but you've taken the cert intended for the ui chassis

This discussion does demonstrate that

• we could, should improve the docs
• it's much cleaner if we remove all of these prebuilt certs, and force users to create their own
• and potentially look at clarifying how to disable in docs for developers - an explicit choice, not default
• if no decision taken, Egeria WILL NOT RUN ootb.

See odpi/egeria#6990

[planetf1]

Also finally, given that your react 'client' (which are named 'server' !) cert is expired, but the react UI still works, it suggests that either it is not configured by default in our charts (which I think may be the case) or is failing and being silently ignored. That's worth checking out, as in theory if configured and expired, it should fail to connect.

Given upcoming UI refactoring, and removal of the additional react ui client/server it may be reasonably not to worry too much about this.

[davidradl]

@planetf1 thanks for the massive amount of detail - that really helps me understand.

[davidradl]

@planetf1 So I gave it a go. I have EgeriaRootCA.p12 for both the ssl files in the React UI - instead of the old keystore.p12 and truststore.p12.
I start the omag platform, I put the truststore.p12 (copied from server-chassis-spring) in the root of the deployment folder.
Did I misinterpret somehting?
The Ui fails to connect with an ECONNECT failure.

[davidradl]

As agreed with @planetf1 I have updated the code to use the new certs.