New CA Certificate Not Taking Effect for LDAPS?

[amoss24]

Hi,

We are changing out the certificate on our Windows Domain Controllers used for LDAPS auth as the underlying root/CA certificate is expiring in August. We uploaded the new CA certificate under Admin > LDAP/AD Integration > Add Certificate ahead of time and all looked fine there. Our security team attempted to replace the certificate on the DCs with the one issued from the new CA today. When we tried to log in to XI with the new certificate active, logins fail. When I turn on the additional debugging under advanced, run tail -f /var/log/httpd/error_log /var/log/httpd/ssl_error_log I am getting the following error:

Code: Select all

[Tue Jun 18 17:29:20.822392 2024] [:error] [pid 27793] [client 10.151.76.9:62220] PHP Warning:  ldap_bind(): Unable to bind to server: Can't contact LDAP server in /usr/local/nagiosxi/html/includes/components/ldap_ad_integration/adLDAP/src/adLDAP.php on line 714, referer: https://nagiosxi.<ourCustomDomain>.com/nagiosxi/login.php
 

Is there additional logging that we can enable to see why it is not working? Where are the LDAP certificates stored on the XI server? After we reverted the certificate on the DCs, I checked the logs again when logging in to XI. I found and disabled an old component that was also attempting AD auth, "Active Directory Integration
Uses Active Directory as a user authentication source. Experimental." After disabling that component, the duplicate errors disappear in the logs but the new certificate still does not work. We've imported the new root certificate on other Linux-based appliances and they work fine.

[amoss24]

I did some more looking around the forums and found viewtopic.php?p=357033. We're on 2024R1.1.2 currently.

I'll attach a screenshot of what is in /etc/openldap/certs and /etc/openldap/cacerts

[jmichaelson]

I'm going to guess that you're not using a Debian/Ubuntu system based on finding the certificates in /etc/openldap. In that case, you can find addiitonal logs from the php-fpm logs under /var/log/php-fpm. Check if anything relevant is logged there, and we can go forward with more diagnostics.

[amoss24]

Ah yes, sorry I forgot to include the distribution we're running.

Code: Select all

cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.9 (Maipo)

Does the debug toggle on the LDAP screen in the XI interface also trigger the php-fpm logs or do those need to be enabled separately? I'm not seeing anything under /var/log/php-fpm

[jsimon]

Hi @amoss24,

The debug toggle on that screen does put logs into the php-fpm logs, that is correct. You'll need to turn that on, and then try to log into the LDAP server via XI in order to actually prompt errors, however. Per the thread that you linked, it may be advisable to upgrade your XI instance to the latest version, and see if that resolves your issue.

[amoss24]

Interesting, we are running 2024R1.1.4 now and we don't seem to be getting any files created under /var/log/php-fpm with the debug toggle on. I re-uploaded both our old CA cert back in the 18th (expiring in August) and the new one (uploaded today) via the XI GUI and the contents of /etc/openldap/cacerts and /etc/openldap/certs look right to me:

Code: Select all

[root@nagios myuser@**********]# ls -l /etc/openldap/cacerts
total 0
lrwxrwxrwx 1 apache apache 37 Dec 17  2020 5fdaa85e43503.0 -> /etc/openldap/certs/5fdaa85e43503.pem
lrwxrwxrwx 1 apache apache 37 Jun 18 17:30 6671c446245d4.pem -> /etc/openldap/certs/6671c446245d4.pem
lrwxrwxrwx 1 apache apache 37 Jul  2 18:23 6684459472cd1.pem -> /etc/openldap/certs/6684459472cd1.pem
lrwxrwxrwx 1 apache apache 37 Jul  2 18:23 b265a356.0 -> /etc/openldap/certs/6684459472cd1.pem
lrwxrwxrwx 1 apache apache 37 Jun 18 17:30 b265a356.1 -> /etc/openldap/certs/6671c446245d4.pem
[root@nagios myuser@***********]# ls -l /etc/openldap/certs
total 100
-rw-r--r--  1 apache apache  1631 Sep 24  2020 5f6cde350bd3b.crt
-rw-r--r--  1 apache apache  5105 Sep 24  2020 5f6cde350bd3b.pem
-rw-r--r--  1 apache apache  1321 Jun 18 17:30 6671c446245d4.crt
-rw-r--r--  1 apache apache  4523 Jun 18 17:30 6671c446245d4.pem
-rw-r--r--  1 apache apache  1321 Jul  2 18:23 6684459472cd1.crt
-rw-r--r--  1 apache apache  4523 Jul  2 18:23 6684459472cd1.pem
-rw-r--r--. 1 root   root   65536 Aug  1  2019 cert8.db
-rw-r--r--. 1 root   root   16384 Aug  1  2019 key3.db
-r--------. 1 root   root      45 Aug  1  2019 password
-rw-r--r--. 1 root   root   16384 Aug  1  2019 secmod.db

The version of OpenSSL appears to be OpenSSL 1.0.2k-fips 26 Jan 2017, if that helps any. The result when running check_ldap against one of our AD DCs with the newer certificate is also the same. It works on 02 and 03, but 01 (which has a cert issued by the newer CA cert) does not. Should we open a support case at this point?

[jmichaelson]

As a long shot, you can see if anything is in the apache error logs (which should be under /var/log/httpd). If not then your best bet might be a support ticket.

[amoss24]

Opened a Support case and they were quick with what appears to be the right answer.

1. Add the CA cert to the system trust store under /etc/pki/ca-trust/source/anchors/
2. Run 'update-ca-trust extract'
3. Optionally run 'trust list --filter=ca-anchors' and verify your CA is in the list
4. Restart the affected services with 'systemctl restart httpd php-fpm'

I've now been able to log in with no errors from the Domain controller with the cert issued by our current CA certificate AND the check_ldap plugin can now bind to said DC on port 636.

[cnorell]

amoss24,

Glad to hear Support could help you out quickly; thanks for posting the fix here for others. As your issue has been resolved, I'm going to lock this thread. Don't hesitate to reach out if you run into any more issues.

Best Regards,

Cory Norell