LDAP authentication server does not support Sub CA

[jpawlowski]

Today, configuring an LDAP server with either TLS or StartTLS will only work when the Root CA can be set directly. It will not work when dealing with an issuing / sub CA as the Auth/LDAP.php script currently only writes the sub CA into the file in /var/run/certs.

A workaround today is to create a single entry in System > Trust > Authorities and put both the Root CA and Sub CA certificates into the Certificate data field. Choosing this particular entry in LDAP server configuration will allow to connect to the server. (Hint: It might be required to reboot your device as the trust store somehow seems to get confused when playing with such configuration too much. Rebooting will give you a clean state before actually testing the LDAP server configuration).

I am not sure about the side effects to the trust store to be honest. One is for example a cosmetic one where it will not show the correct issuer:

---

If the Auth/LDAP.php script could include all certificates of this particular trust chain, that would be preferred. Maybe this can be considered in one of the next

[fichtner]

If you have a 19.7.4 can you try to hardcode LDAP to /etc/ssl/cert.pem ? it should have all the CAs and the default ones now.

[jpawlowski]

Indeed, changing

core/src/opnsense/mvc/app/library/OPNsense/Auth/LDAP.php

Line 341 in 7218726

ldap_set_option(null, LDAP_OPT_X_TLS_CACERTFILE, "/var/run/certs/{$this->ldapCAcert}.ca");

to /etc/ssl/cert.pem will make that happen.
That would make quite a lot of stuff obsolete in the code I guess. Also, it would no longer be needed to choose the Peer Certificate Authority in the frontend. Instead, a simple reminder about adding private CAs to the trust store would be sufficient.

[AdSchellevis]

@jpawlowski Sounds like a good idea to me, can you confirm that your issue is solved when LDAP_OPT_X_TLS_CACERTFILE points to /etc/ssl/cert.pem ? I'll gladly remove some code here.

[jpawlowski]

I can confirm this, it is working on 4 devices now.

[AdSchellevis]

ok, thanks, I'll prepare a patch later.

[AdSchellevis]

@jpawlowski can you try b2affd1 ?

I've dropped LDAP_OPT_X_TLS_CACERTDIR as well, since it doesn't seem to be required when pointing to a cacert file.

[jpawlowski]

Just applied the patch to one of the machines, deleted the chain certificate from the trust store, and saved the LDAP server configuration (just to ensure the new XML config file structure).

Afterwards, I was still able to connect to the LDAP server as intended so the patch seems to work fine. Many thanks, Ad!

[AdSchellevis]

@jpawlowski thanks for confirming, can I close the issue? It will move into a production version later.

[jpawlowski]

will just close it myself, thanks for politely asking ;)

[jpawlowski]

@AdSchellevis just to let you know that there are coming up some warning messages in the reporter:

[04-Oct-2019 21:49:18 Europe/Berlin] PHP Warning:  implode(): Invalid arguments passed in /usr/local/www/system_authservers.php on line 245

Everything is working fine, though.

[AdSchellevis]

@jpawlowski not related, but 09c34b2 should fix it.

[jpawlowski]

Too bad this didn’t make it into the new minor release (while other LDAP fixes did) @fichtner

[fichtner]

Too many changes here... we just pushed it 1 release back to give others the opportunity to test with the package mirror shipped opnsense-devel which is our default policy for backports. Exceptions apply, but it’s good to not forget rules completely. 😊

[jpawlowski]

This was not about the package, it was about the patches to Auth/LDAP and stuff in b2affd1

[fichtner]

Yes, I am aware.

…

On 11. Oct 2019, at 18:14, Julian Pawlowski ***@***.***> wrote: This was not about the package, it was about the patches to Auth/LDAP and stuff in b2affd1 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.