|
Component |
edoc platform |
|---|---|
|
Version |
23.8.15 |
|
Created on |
|
|
Last modified on |
No Workflow Applied |
|
Review status |
No Workflow Applied |
|
KB article number |
440041595 |
Summary
Many third-party applications, such as web servers or databases, are now TLS-encrypted.
The applications can issue a certificate from a publicly known certification authority or from a local root certification authority.
By default, edoc solutions ag applications only accept certificates from publicly authorized certification authorities. If you use your own PKI (Public Key Infrastructure), the server must trust the root certificate of this PKI in order to establish a secure connection.
Use cases are for example:
-
Connection between edoc workplace and an on-premises system with d.velop documents (d.3one with d.ecs task)
-
Connection between edoc datahub and an on-premises database server with TLS encryption
In order for the certificates to be accepted, they or the associated certification authority certificates must be transferred to the edoc platform server.
When the containers are restarted, these certificates are then transferred to the containers. The edoc applications now accept the connection to the third-party application.
Important requirements
-
edoc platform (edoc agent): at least 01.08.2023 (Commit
15d9327a9397ca2315f12c7a52237e9f06cf856c) -
edoc applications in edoc system control: since release 23.8.15
-
Administrative access to the server with edoc platform
-
Certificate of a certification authority (CA) in PEM format. The file extension of the certificate must be . crt.
-
You must be a member of the sudo group on the Linux server.
-
The servers must be restarted. You should therefore plan to restart the servers in advance.
Solution
Copy the certificate to the server with edoc platform and provide the certificate to the containers.
Here's how
-
Log in to the edoc platform server via SSH as a member of the sudo group.
-
Open an interactive root shell with this command:
sudo -i
-
Copy the certificate with the file extension *.crt to /usr/local/share/ca-certificates/ with the following command:
cp /home/$user/$certificate.crt /usr/local/share/ca-certificates/
-
Update the certificates at operating system level with the following command:
update-ca-certificates
The certificate is now available. In order for the individual services to be able to use the certificate, the individual containers must be restarted.
You can choose one of the procedures:
-
Restart the entire server. The services are not available for the duration of the restart.
reboot -
Restart the Kubernetes server. The services are not available for the duration of the restart.
Bashmicrok8s stop;microk8s start -
Restart individual containers with delete pods. All other containers continue to run as usual. Example for the workflow container:
kns=master service=workflow-deploy kubectl delete pod -n $kns $(kubectl get pods -n $kns --no-headers -o custom-columns=":metadata.name"|grep $service)
After restarting, the certificate is available in the respective container and it is possible to establish an encrypted connection to the third-party applications.