kasmtech
How do we add additional trusted CA certificates to Docker?
Describe the bug I have Kasm set up successfully and even have it using certificates generated by my local CA, However, I'm finding that from within Kasm it's unable to connect to other services using certificates from the same CA. For example, a Brave workspace could not connect to my Zabbix box because it did not trust the certificate until I added the CA to Brave. Unfortunately this isn't always possible and is quite inconvenient to need to do this to each workspace every time especially as an update will revert changes. It's also causing problems trying to use a Nextcloud as a storage server, as it too gets rejected because its certificate is not trusted in Docker.
To Reproduce Steps to reproduce the behavior:
- Connect to any SSL service using an untrusted CA signed certificate
Expected behavior Connections should be trusted
Screenshots In Terminal workspace:
`default:~$ curl -v https://nextcloud.mydomain.com
- Trying 192.168.1.70:443...
- TCP_NODELAY set
- Connected to nextcloud.mydomain.com (192.168.1.70) port 443 (#0)
- ALPN, offering h2
- ALPN, offering http/1.1
- successfully set certificate verify locations:
- CAfile: /etc/ssl/certs/ca-certificates.crt CApath: /etc/ssl/certs
- TLSv1.3 (OUT), TLS handshake, Client hello (1):
- TLSv1.3 (IN), TLS handshake, Server hello (2):
- TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
- TLSv1.3 (IN), TLS handshake, Certificate (11):
- TLSv1.3 (OUT), TLS alert, unknown CA (560):
- SSL certificate problem: self signed certificate in certificate chain
- Closing connection 0 curl: (60) SSL certificate problem: self signed certificate in certificate chain More details here: https://curl.haxx.se/docs/sslcerts.html `
On the server itself after copying CA cert then using update-ca-certificates:
`root@KODOS:~# curl -v https://nextcloud.mydomain.com
- Trying 192.168.1.70:443...
- Connected to nextcloud.mydomain.com (192.168.1.70) port 443 (#0)
- ALPN: offers h2,http/1.1
- TLSv1.3 (OUT), TLS handshake, Client hello (1):
- CAfile: /etc/ssl/certs/ca-certificates.crt
- CApath: /etc/ssl/certs
- TLSv1.3 (IN), TLS handshake, Server hello (2):
- TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
- TLSv1.3 (IN), TLS handshake, Certificate (11):
- TLSv1.3 (IN), TLS handshake, CERT verify (15):
- TLSv1.3 (IN), TLS handshake, Finished (20):
- TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
- TLSv1.3 (OUT), TLS handshake, Finished (20):
- SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
- ALPN: server accepted http/1.1
- Server certificate:
- subject: CN=nextcloud.mydomain.com
- start date: May 24 10:44:17 2024 GMT
- expire date: May 24 10:44:17 2026 GMT
- subjectAltName: host "nextcloud.mydomain.com" matched cert's "nextcloud.mydomain.com"
- issuer: DC=com; DC=mydomain; CN=mydomain-SELMA-CA
- SSL certificate verify ok.
- using HTTP/1.1
GET / HTTP/1.1 Host: nextcloud.mydomain.com User-Agent: curl/7.88.1 Accept: / `
Workspaces Version 1.15
Workspaces Installation Method Single Server
All the containers have their own cert store, so updating it on the host doen't help a whole lot.
For the session containers (brave, kali etc), you'll have to create a custom image with your CA cert installed. You can build a custom image: https://kasmweb.com/docs/latest/how_to/custom_root_certificate.html Or save a running one after you modify it. https://kasmweb.com/docs/latest/guide/sessions.html#create-image-from-session
The Kasm service containers also have their own cert stores. You can try following this guide to map in your CA cert in to the service containers. I beleive you'll need to do this for the kasm_api container if you are using the Storage Mapping feature with for the nextcloud: https://kasmweb.atlassian.net/servicedesk/customer/portal/3/article/28835845
Hmmm, not a great result as it negates automatic updates of workspaces as they would immediately overwrite any changes to their image, and for ones like browsers that need to be updated veery regularly it'll be a pain. But thanks for the links, I will if just changing the one for the storage mapping feature will be enough.
Perhaps as new "feature" making all containers allow for optional mounts mapped to the host certificate store (or any other location) would provide a solution?
Can you expand on this? I'm not a Docker expert and what I tried has stopped Kasm starting now:
Also add the following line in the kasm_api container’s volume block mount the OS’s ca-certificates file into the kasm_api container.
/etc/ssl/certs/ca-certificates.crt:/srv/ca.crt
root@KODOS:~# /opt/kasm/bin/start Skipping Pull of Kasm Service Images Starting Kasm Services services.kasm_api.environment must be a mapping
I think I found the mistake, the examples for the "environment" variables are wrong, so in my case it's:
environment: REQUESTS_CA_BUNDLE: /srv/ca.crt AWS_CA_BUNDLE: /srv/ca.crt
But I still cannot get the certificates to be trusted when I test in bash of the api container
We’re currently enhancing our GitHub issue tracker to improve organization and efficiency.
As part of this process, we’re closing older issues to help keep the tracker focused on current and active topics.
If this issue is still relevant or you’re still experiencing the problem, please feel free to create a new issue.
Thank you for your understanding!
