certs added to the ancors and extract run. apache restarted and i'm still getting cert errors when i change it to ssl/tls. per a PM i got from saxx i enabled debug mode (https://support.nagios.com/kb/article/a ... n-600.html) but did not get any errors.
$ ls -l /etc/openldap
total 4
drwxrwxr-x 2 apache nagios 98 Jul 20 11:00 cacerts
drwxrwxr-x. 2 apache nagios 206 Jul 20 11:00 certs
-rw-rw-r-- 1 apache nagios 937 Jul 20 10:21 ldap.conf
$ ls -l /etc/openldap/certs
total 52
-rw-r--r-- 1 apache apache 2495 Jul 20 10:59 5f15bf4d58b59.crt
-rw-r--r-- 1 apache apache 8916 Jul 20 10:59 5f15bf4d58b59.pem
-rw-r--r-- 1 apache apache 2130 Jul 20 10:59 5f15bf5eca462.crt
-rw-r--r-- 1 apache apache 6919 Jul 20 10:59 5f15bf5eca462.pem
-rw-r--r-- 1 apache apache 1968 Jul 20 11:00 5f15bf9bf07e7.crt
-rw-r--r-- 1 apache apache 6717 Jul 20 11:00 5f15bf9bf07e7.pem
-rw-r--r-- 1 apache apache 1517 Jul 20 11:00 5f15bfac6fb94.crt
-rw-r--r-- 1 apache apache 4842 Jul 20 11:00 5f15bfac6fb94.pem
$ ls -l /etc/openldap/cacerts
total 0
lrwxrwxrwx 1 apache apache 37 Jul 20 10:59 5f15bf4d58b59.0 -> /etc/openldap/certs/5f15bf4d58b59.pem
lrwxrwxrwx 1 apache apache 37 Jul 20 10:59 5f15bf5eca462.0 -> /etc/openldap/certs/5f15bf5eca462.pem
lrwxrwxrwx 1 apache apache 37 Jul 20 11:00 5f15bf9bf07e7.0 -> /etc/openldap/certs/5f15bf9bf07e7.pem
lrwxrwxrwx 1 apache apache 37 Jul 20 11:00 5f15bfac6fb94.0 -> /etc/openldap/certs/5f15bfac6fb94.pem
$ cat /etc/openldap/ldap.conf
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
#BASE dc=example,dc=com
#URI ldap://ldap.example.com ldap://ldap-master.example.com:666
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
# When no CA certificates are specified the Shared System Certificates
# are in use. In order to have these available along with the ones specified
# by #TLS_CACERTDIR one has to include them explicitly:
#TLS_CACERT /etc/pki/tls/cert.pem
# System-wide Crypto Policies provide up to date cipher suite which should
# be used unless one needs a finer grinded selection of ciphers. Hence, the
# PROFILE=SYSTEM value represents the default behavior which is in place
# when no explicit setting is used. (see openssl-ciphers(1) for more info)
#TLS_CIPHER_SUITE PROFILE=SYSTEM
# Turning this off breaks GSSAPI used with krb5 when rdns = false
SASL_NOCANON on
TLS_CACERTDIR /etc/openldap/cacerts
[root@vs-nagios ~]# tail -f /var/log/httpd/error_log /var/log/httpd/ssl_error_log
==> /var/log/httpd/error_log <==
[Mon Jul 27 12:37:53.236181 2020] [mpm_event:notice] [pid 243082:tid 140620706941248] AH00492: caught SIGWINCH, shutting down gracefully
[Mon Jul 27 12:37:54.289914 2020] [suexec:notice] [pid 245491:tid 140461624543552] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Mon Jul 27 12:37:54.305815 2020] [lbmethod_heartbeat:notice] [pid 245491:tid 140461624543552] AH02282: No slotmem from mod_heartmonitor
[Mon Jul 27 12:37:54.308107 2020] [mpm_event:notice] [pid 245491:tid 140461624543552] AH00489: Apache/2.4.37 (Red Hat Enterprise Linux) OpenSSL/1.1.1c configured -- resuming normal operations
[Mon Jul 27 12:37:54.308130 2020] [core:notice] [pid 245491:tid 140461624543552] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
[Tue Jul 28 08:16:55.776752 2020] [mpm_event:notice] [pid 245491:tid 140461624543552] AH00492: caught SIGWINCH, shutting down gracefully
[Tue Jul 28 08:17:07.864646 2020] [suexec:notice] [pid 759989:tid 140431901890880] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Tue Jul 28 08:17:07.890614 2020] [lbmethod_heartbeat:notice] [pid 759989:tid 140431901890880] AH02282: No slotmem from mod_heartmonitor
[Tue Jul 28 08:17:07.899292 2020] [mpm_event:notice] [pid 759989:tid 140431901890880] AH00489: Apache/2.4.37 (Red Hat Enterprise Linux) OpenSSL/1.1.1c configured -- resuming normal operations
[Tue Jul 28 08:17:07.899314 2020] [core:notice] [pid 759989:tid 140431901890880] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
==> /var/log/httpd/ssl_error_log <==
[Mon Jul 27 12:33:04.107896 2020] [ssl:warn] [pid 243082:tid 140620706941248] AH01906: vs-nagios.marqnet.mu.edu:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Mon Jul 27 12:33:04.107914 2020] [ssl:warn] [pid 243082:tid 140620706941248] AH01909: vs-nagios.marqnet.mu.edu:443:0 server certificate does NOT include an ID which matches the server name
[Mon Jul 27 12:37:54.290539 2020] [ssl:warn] [pid 245491:tid 140461624543552] AH01906: vs-nagios.marqnet.mu.edu:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Mon Jul 27 12:37:54.290556 2020] [ssl:warn] [pid 245491:tid 140461624543552] AH01909: vs-nagios.marqnet.mu.edu:443:0 server certificate does NOT include an ID which matches the server name
[Mon Jul 27 12:37:54.305392 2020] [ssl:warn] [pid 245491:tid 140461624543552] AH01906: vs-nagios.marqnet.mu.edu:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Mon Jul 27 12:37:54.305407 2020] [ssl:warn] [pid 245491:tid 140461624543552] AH01909: vs-nagios.marqnet.mu.edu:443:0 server certificate does NOT include an ID which matches the server name
[Tue Jul 28 08:17:07.865268 2020] [ssl:warn] [pid 759989:tid 140431901890880] AH01906: vs-nagios.marqnet.mu.edu:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Tue Jul 28 08:17:07.865296 2020] [ssl:warn] [pid 759989:tid 140431901890880] AH01909: vs-nagios.marqnet.mu.edu:443:0 server certificate does NOT include an ID which matches the server name
[Tue Jul 28 08:17:07.890182 2020] [ssl:warn] [pid 759989:tid 140431901890880] AH01906: vs-nagios.marqnet.mu.edu:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Tue Jul 28 08:17:07.890199 2020] [ssl:warn] [pid 759989:tid 140431901890880] AH01909: vs-nagios.marqnet.mu.edu:443:0 server certificate does NOT include an ID which matches the server name
to test/get debug output i switched the ldap server from starttls to ssl/tls and then went to manage users->add from ad/ldap and i got a self signed error. I also tested trying to login as an ad user that was added without ssl/tls being enabled and didn't get any debug output either.
Just to keep this updated. I was able to replicate the behavior on the command line using ldapsearch. On rhel7 the ldapsearch command works no problem, it is JUST on rhel8 where we have a problem. I have opened a case with redhat and will share the solution here once i have resolution.
I haven't heard that, thank you for posting your update! If you end up needing a remote session, just submit the ticket with a link back to this thread.
additionally i did need the incommon cert in the Certificate Authority Management section of the LDAP / Active Directory Integration Configuration page
From RedHat:
The RHEL-8 way is more system wide for a global system policies that applies to all applications, in a more consistent and secure way than RHEL-7:
locate if your root CA is listed with this command:
trust list | less
trust list ca-anchors | less
add the new root CA certificate to trust, in PEM format to update files under /etc/pki/:
trust anchor ~/some.path.to/ca.certificate.crt
( equivalent of add new file to /etc/pki/ca-trust/source/anchors/ and run update-ca-trust extract )
Verify the OpenSSL configuration file /etc/openldap/ldap.conf has either the TLS_CACERTDIR set, or eventually a definition for TLS_CACERT
place the liegitimate CA certerficate in PEM format into the directory pointed by TLS_CACERTDIR, or into the file pointed by TLS_CACERT
if TLS_CACERTDIR is used, either run the command "openssl rehash" or the /usr/bin/c_rehash from the openssl-perl package to update the CA certificates links with hashes into the default OpenSSL directory /etc/openldap/certs, like for example:
either
/usr/bin/c_rehash /etc/openldap/certs
or
/usr/bin/openssl rehash /etc/openldap/certs
So now while i am able to connect, when i connect via ssl all i get is 3 dots pulsing, it never shows any of our users. when i connect with ssl off (none) the users show up quickly. Is this expected behavior (where ssl is much slower?)
Can you please open a ticket for this? There are just too many moving parts for me to be able to diagnose your issue through messages. I believe that a remote session may be necessary at this point so that we can bring this to a resolution more swiftly.
As of May 25th, 2018, all communications with Nagios Enterprises and its employees are covered under our new Privacy Policy.
Be sure to check out our Knowledgebase for helpful articles and solutions!