After my last post
https://lists.apache.org/thread/3s14rh6mhz0rys2477sz7xzxb6z0qmqw I realized
that I was running into a similar issue with the guacd container. I was
getting certificate errors connecting to the RDS server. I ended up fixing
this issue in a similar way, but it was more than just adding the CA
certificates to the guacd container. Something I never realized before was
Windows uses self-signed certs for Terminal Services, so I also had to get
proper certs on the RDS server Terminal Services service. By default, the
Windows Remote Desktop client happily ignores these cert errors. I'm not
really sure what the answer is to add proper support for custom CA certs.
Understandably, updating the CA certs require root execution on both containers
so unless you build your own image or change the user to root, which is not
what we want, the only way to add the certs I have found is to create a "run
once" service with a shared volume that executes after the guacd/guacamole
services are running to inject the CA certs. I would be happy to hear
suggestions on a better way to do this. For the Guacamole container, the certs
need to be added to the keystore at /opt/java/openjdk/lib/security/cacerts, and
for the guacd container, the container root certs need to be updated with the
update-ca-certificates command. These CA cert updates both really only need to
run once. After the CA certs on the shared volumes are set up it will work
until the files are updated which shouldn't happen unless the volume is deleted
and recreated. That said, I still have it set up to run on every start to
ensure the certs are up to date. The only problem I found with
update-ca-certificates is that it doesn't support full chain certs, so every
cert file in /usr/local/share/ca-certificates can only contain one certificate.
In my case I had to add the offline root and the issuing CA certs
individually. One issue I can see coming up with this solution is if the CA
certs are updated in the container image the volume will have to be deleted and
recreated to be updated. For me I don't think this will be an issue as these
containers should only be communicating with internal servers anyway. The
services I ended up creating to do this are below. The volumes are also
mounted to the guacamole/guacd containers.
guacd_ca_certs:
user: root
depends_on:
- guacd
image: guacamole/guacd
volumes:
- ./${CA_CERT_OFFLINE_ROOT_FILENAME}:${CA_CERT_OFFLINE_ROOT_PATH}:Z
- ./${CA_CERT_ISSUING_CA_FILENAME}:${CA_CERT_ISSUING_CA_PATH}:Z
- ca_certs_guacd:/etc/ssl/certs
entrypoint: [ "sh", "-c" ]
command: [ "update-ca-certificates" ]
guacamole_ca_certs:
user: root
depends_on:
- guacamole
image: guacamole/guacamole
volumes:
- ./${CA_CERT_FULL_CHAIN_FILENAME}:${CA_CERT_FULL_CHAIN_PATH}:Z
- ca_certs_guacamole:/opt/java/openjdk/lib/security
entrypoint: [ "sh", "-c" ]
command: [ "keytool -importcert -alias ${CA_CERT_FULL_CHAIN_ALIAS} -file
${CA_CERT_FULL_CHAIN_PATH} -keystore /opt/java/openjdk/lib/security/cacerts
-storepass changeit -noprompt" ]
volumes:
ca_certs_guacamole:
ca_certs_guacd:
Note: The message and attachment(s) to this email are intended for the use of
the individual or entity to which it is addressed, and may contain information
that is privileged, confidential and exempt from disclosure under applicable
law. If the reader of this message is not the intended recipient, you are
hereby notified that any dissemination, distribution, printing or copying of
this communication is strictly prohibited. If you received this in error,
please contact the sender and delete the original message, any attachment(s)
and copies. Thank you for your cooperation.
