Egeria self-signed certificates expired

[planetf1]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

When running FVTs, they are failing with an error such as

Error:  org.odpi.openmetadata.viewservices.glossaryauthor.fvt.junit.SubjectAreaDefinitionCategoryIT.testSubjectAreaDefinitionCategory(String)[1]  Time elapsed: 0.816 s  <<< FAILURE!
[59564](https://github.com/odpi/egeria/runs/5567811394?check_suite_focus=true#step:5:59564)
org.opentest4j.AssertionFailedError: Unexpected exception thrown: org.odpi.openmetadata.frameworks.connectors.ffdc.PropertyServerException: OMAG-COMMON-400-016 An unexpected org.odpi.openmetadata.viewservices.glossaryauthor.services.GlossaryAuthorViewGlossaryRESTServices exception was caught by find for Glossary; error message was OMAG-COMMON-503-001 A client-side exception was received from API call getConfig to OMAG Server serverinmem at https://localhost:10454.  The error message was CLIENT-SIDE-REST-API-CONNECTOR-503-002 A client-side exception org.springframework.web.client.ResourceAccessException was received by method getConfig from API call https://localhost:10454/servers/serverinmem/open-metadata/access-services/subject-area/users/garygeeke/configs/current to server serverinmem on platform https://localhost:10454.  The error message was I/O error on GET request for "https://localhost:10454/servers/serverinmem/open-metadata/access-services/subject-area/users/garygeeke/configs/current": PKIX path validation failed: java.security.cert.CertPathValidatorException: validity check failed; nested exception is javax.net.ssl.SSLHandshakeException: PKIX path validation failed: java.security.cert.CertPathValidatorException: validity check failed
[59565](https://github.com/odpi/egeria/runs/5567811394?check_suite_focus=true#step:5:59565)
	at [email protected]

Expected Behavior

FVTs work ok

Steps To Reproduce

Submit a PR, review results of build

Environment

- Egeria:
- OS:
- Java:
- Browser (for UI issues):
- Additional connectors and integration:

Any Further Information?

I had a hunch the certs may have expired - though this isn't explicit in the log.
Looking at our cert creation scripts, the default lifetime for the server certs is 375 days, and they were created on Mar 5 2021 ....

[planetf1]

The certs can be updated by going to open-metadata-resources/open-metadata-deployment/certificates and running gensamplecerts.sh (linux only - not windows or mac)

[planetf1]

Affected releases

• master is now fixed
• 3.6 will fail to build due to an FVT failure in glossary-author
• All 3.x releases have expired self-signed certificates which will cause issues if they are used without disabling cert checking

Remaining Tasks

• Post notice on slack announce channel
• Fix certs in master to unblock PR build
• test PR
• Investigate impact to prior releases
• Fix prior releases - code? Workaround recommentation?
• update slack channel
• Review process / Add process to update certs each release
• All FVTs should use certs properly (not disabling)
• demos/charts should use certs properly
• dojos should use certs properly

[planetf1]

Master has been updated with new certs as per the script above. Note that it must be run on Java 11 (our minimum java level) as one step uses a java tool, and some formats have changed... If run on Java 17, the certs will not work correctly with Java 11 ....

This unblocks the PR pipeline.

I've also checked release 3.6 -> fails in glossary-author-fvt only on the gradle & maven build. This is probably because there is a client->view server platform->egeria platform communication going on there, with tls used on both of those hops. Need to check further, but it maybe this test is not disabling cert checking, and doing proper validation ...!

[planetf1]

release 3.5 does not fail to build -- since the new FVT was not present, and the previous FVTs all disable cert checking.

However the certs are expired in 3.5, which could cause issues in environments where the cert checking is enabled, and the self-signed certs are correctly set up.

The coco labs (run via helm charts) work ok, since certificate checking is disabled.

--

As such the main expose is that release 3.6 can not be built as FVTs fail
Additionally if users have their own clients, checking certs, these could fail with 3.6 code

Moving forward, we should ensure our FVTs DO proper checking, and that we properly setup those tests -- and our demos -- with our self signed certs

The main followup actions would seem to be

• Decide if we need to ship an update to 3.6 containing new certs, as that release will be there for another few weeks
• Write a longer article/post explaining the issue, options, workarounds

• also updating checklist above

[planetf1]

Agreed in developer call 20220317 to:

• NOT ship a 3.6 update
• update the slack announce explaining issue
• add a blog entry with further clarification
• ensure reactUI is also update with short term fix (new certs)
• keep issue open to look at long term process

[davidradl]

@planetf1 It looks like the glossary author FVT specifies
<argument>-Djavax.net.ssl.keyStore=${fvt.distdir}/keystore.p12</argument>. that is different from all of the other FVTs I assume this is what is forcing the validation.

Ae we going to continue to widely use truststore.p12 and keystore.p12 or are we going use more specific artifacts , as we are discussing for the react ui.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[planetf1]

@dwolfson This is part of what you hit when changing the certs.
The immediate issue was resolved - the fundamental change needed is to remove certs from the build entirely