Did you check out Gluu Server Docker Edition: https://gluu.org/docs/ ? It's quite challenging to get all the components to work on Docker. We've done much of the heavy lifting for you if you can use our distribution. We also have Red Hat certified Linux containers.

Hello Michael, Thanks for your reply. Yes, I'm using the Docker Edition and it works perfectly to deploy a vanilla Gluu with self-signed certs. The issue I'm having is to automatically add an oxauth client configuration, a backend ActiveDirectory, custom login script and custom cacherefresh settings. I'm thinking the easiest way seems to be to insert the necessary values in the included ldif templates in the OpenDJ docker image, create a custom docker image and update the runall.sh to use that custom image as ldap so openDJ contains the configuration I need. I'm still thinking about a possible approach on how to achieve updating the cacert & nginx key/certificates with our own key/cert without breaking everything but I'm not sure which ones I have to update. Thanks for the heavy lifting ;) L

Lars, > The issue I'm having is to automatically add an oxauth client configuration, a backend ActiveDirectory, custom login script and custom cacherefresh settings. For this you could build a custom image or have another container that adds information to the LDAP, which I presume you do already according to "configuring ActiveDirectory (doing that straight into opendj) and configuring the cache-refresh". I think creating a new container job that adds all your necessary clients to a new config as the best option. > I'm still thinking about a possible approach on how to achieve updating the cacert & nginx key/certificates with our own key/cert without breaking everything but I'm not sure which ones I have to update. You can modify the data in Consul to change out your ssl certs. They're saved as `ssl_cert` and `ssl_key`, if I'm remembering correctly. Once you've made those modifications, you can then do a `config-init dump` command to save the `config.json` to disk so you can back it up and use to redeploy at a later time with basically the same configuration with `config-init load`. See [the technical documentation](https://gluu.org/docs/de/technical/#config-init) for further use cases. Note that some of the configuration is "permanently" added to LDAP and changing the `config.json` or Consul configuration directory won't impact those configuration settings.

Hello Chris, Thanks for your reply. The additional container seems like a good approach, I just found out I can set specific base-inum & inum-org for config-init so I think I could get away by just generating an ldif with the configuration I need and copy it to the ldap container and execute it through docker exec and restart. I did try to change the ssl_cert & ssl_key directly in Consul but I think there was a trust error when trying to login to oxtrust but I'm not sure. So adding them to Consul, dumping & running config-init load is sufficient to also add them to the cacerts on each container when the config-init load. I presume I'll have to either delete the ./volumes or spin-up new containers (excluding config-init & consul obviously) Would there perhaps be a way to pass on the ssl_cert & ssl_key during installation? Thanks! Lars

> The additional container seems like a good approach, I just found out I can set specific base-inum & inum-org for config-init so I think I could get away by just generating an ldif with the configuration I need and copy it to the ldap container and execute it through docker exec and restart. Right and you can use the same base configuration across deployments. > I did try to change the ssl_cert & ssl_key directly in Consul but I think there was a trust error when trying to login to oxtrust but I'm not sure. You need to make sure the containers restart as they need to reacquire the certs from the config and add them to their truststore before starting. > So adding them to Consul, dumping & running config-init load is sufficient to also add them to the cacerts on each container when the config-init load. I presume I'll have to either delete the ./volumes or spin-up new containers (excluding config-init & consul obviously) You shouldn't have to remove the volumes and the `/etc/certs` directory and trust store aren't persisted in our default configuration. > Would there perhaps be a way to pass on the ssl_cert & ssl_key during installation? I'm not sure we could pass those directly into a container, but again, you could copy a `config.json` add the necessary certs in there and instead of generating config, start a fresh installation with the `config-init` load command. The only requirement is that the `config.json` exist in the correct spot to be loaded by `config-init`