Problem: No LDAPS is working with foremanctl and FreeIPA
Expected outcome:everything is fine with Port 636
**Foreman and Proxy versions:**foremanctl-3.0.0.develop-1.20260624145457180956.master.50.g158f016.el9.noarch
Foreman and Proxy plugin versions:
Distribution and version: Rocky Linux 9.8
Other relevant data:
Hi everyone,
I’m running foremanctl version foremanctl-3.0.0.develop-1.20260624145457180956.
Yesterday, I deployed a custom certificate along with the ca.crt using the command: foremanctl deploy --certificate-source=custom_server --certificate-server-certificate /root/certificates/xxx.crt --certificate-server-key /root/certificates/xxx.key --certificate-server-ca-certificate /root/certificates/ca.crt. That all worked fine. The connection to my IPA server via LDAP also worked. However, I’ve run into a problem there: everything works perfectly over port 389, but LDAPS over port 636 fails; for that, I would need to install the IPA server’s ca.crt. See here:
That said, I’m not sure if running update-ca-trust extract inside one of the containers would actually work.
Is there a solution for this, or do I need to be patient a little longer before LDAPS over port 636 becomes available?
Regards,
Dirk
Hi,
this is a known problem with no immediate easy solution. The plan is to allow you to point foremanctl at that cert file and have it be propagated to the right place.
I can’t really recommend doing that. While it might work momentarily, it would break once you updated the images or just recreated the containers.
In theory (and if you’re feeling adventurous) you could build a derived image from the official ones that would add the cert to the right place, run update-ca-trust and then deploy using those derived images. That would probably be the sanest approach right now, but it still is out there in the untested workaround territory.
Thanks for the info. I’ll wait until it’s ready, then. For us, LDAPS is an absolute must for security reasons. Can you estimate when it will be implemented?
The problem is that we designed it around the system store, but containers are isolated.
I wonder what the best solution is: develop a way to manage the trust store within containers or the other direction: avoid the system trust store altogether and build a mechanism in the application itself to provide the certificate?
While currently we’re not targeting anything other than podman with quadlets, in the future I can imagine there’s a demand for Kubernetes / OpenShift. That makes me lean to enhancing Foreman to provide the certificate as part of the authentication source.
