Issues after migrating to a new server

[hbouma]

FYI, if I change the crypto policy to LEGACY and leave it as LEGACY, the "return code: 66 (EE certificate key too weak)" response and my communication with the AD servers works through openssl. However, I still cannot log in through Nagios.

[pbroste]

Hello @hbouma

Thanks for following up, want to update the trust CA Certificates because the web interface/app adds this to the /etc/openldap/ldap.conf:

• TLS_CACERTDIR /etc/openldap/cacerts



• # 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

The fix:

To trust the CA certs system-wide:

Take the CA certs and put them in individual files in this directory:
- NOTE: They must have a .crt extension on the files

Code: Select all

/etc/pki/ca-trust/source/anchors/

Then run these commands:

Code: Select all

update-ca-trust extract

Then edit your /etc/openldap/ldap.conf and uncomment this line:

Code: Select all

#TLS_CACERT     /etc/pki/tls/cert.pem

So it looks like this:

Code: Select all

TLS_CACERT     /etc/pki/tls/cert.pem

Then restart apache/php-fpm and test again and see if that resolves the issue:

Code: Select all

systemctl restart httpd php-fpm

Then test the login and the import is a good test as well.

Thanks,
Perry

[hbouma]

I have made the requested changes.

I can still hit the AD VIP without issue by using echo 'DONE' | openssl s_client -showcerts -connect AD_VIP:636.

However, Nagios does not log in. Instead, it just sits there spinning and trying to log in. I see nothing unusual in the logs.

[pbroste]

Going out on a divagation but want to make sure and rule out time/date/timezone synced across within thresholds with your LDAP server.

Code: Select all

date
ls -l /etc/localtime
php -r 'echo date("D M j G:i:s T Y")."\n";'
grep "date.timezone =" /etc/php.ini
grep date.timezone /etc/php.ini
mysql -h 127.0.0.1 -uroot -pnagiosxi -e 'SELECT NOW(); SELECT @@GLOBAL.time_zone, @@SESSION.time_zone;'


Thanks,
Perry

[hbouma]

Code: Select all

date
ls -l /etc/localtime
php -r 'echo date("D M j G:i:s T Y")."\n";'
grep "date.timezone =" /etc/php.ini
grep date.timezone /etc/php.ini
]mysql -h 127.0.0.1 -uroot -pnagiosxi -e 'SELECT NOW(); SELECT @@GLOBAL.time_zone, @@SESSION.time_zone;'

Code: Select all

[root@SERVERNAME~]# date
Wed Feb 23 08:45:22 EST 2022
[root@SERVERNAME~]# ls -l /etc/localtime
lrwxrwxrwx 1 root root 30 Feb  1 14:08 /etc/localtime -> /usr/share/zoneinfo/US/Eastern
[root@SERVERNAME~]# php -r 'echo date("D M j G:i:s T Y")."\n";'
Wed Feb 23 8:45:22 EST 2022
[root@SERVERNAME~]# grep "date.timezone =" /etc/php.ini
date.timezone = US/Eastern
[root@SERVERNAME~]# grep date.timezone /etc/php.ini
; http://php.net/date.timezone
date.timezone = US/Eastern
[root@SERVERNAME ~]# mysql -h OFFLOADED_DB_SERVER_IP -uroot -pSUPER_SECRET_PASSWORD -e 'SELECT NOW(); SELECT @@GLOBAL.time_zone, @@SESSION.time_zone;'
mysql: [Warning] Using a password on the command line interface can be insecure.
+---------------------+
| NOW()               |
+---------------------+
| 2022-02-23 08:45:23 |
+---------------------+
+--------------------+---------------------+
| @@GLOBAL.time_zone | @@SESSION.time_zone |
+--------------------+---------------------+
| SYSTEM             | SYSTEM              |
+--------------------+---------------------+

[pbroste]

Hello @hbouma

Thanks for verifying that the date/time/timezone are all synced with the LDAP server.

Looking back and going forward, we saw that the 'openssl' command resulted in "verify error:num=66:EE certificate key too weak' so let's verify:

Previously we had you pull the crypto-policies and that results show: FIPS; and want to disable that by: (requires reboot when you get a chance)

Code: Select all

fips-mode-setup --disable && reboot

Then:

Code: Select all

update-crypto-policies --set LEGACY && reboot

After reboot verify:

Code: Select all

update-crypto-policies  --show

Thanks,
Perry

[hbouma]

Made the requested changes.

Code: Select all

fips-mode-setup --disable && reboot

After reboot, I still cannot log in.

Code: Select all

update-crypto-policies --set LEGACY && reboot

Now, I cannot log in, even with the built in NagiosAdmin account.

Code: Select all

update-crypto-policies  --show
LEGACY

[pbroste]

Hello @hbouma

Thanks for following up, let us know what the results:

Code: Select all

echo 'DONE' | openssl s_client -showcerts -connect your.ad_or_ldap.server:636

Please send a copy of the following configs:

Code: Select all

tar -czvf /tmp/sslconfigs.tar.gz /etc/httpd/conf.d/ssl.conf /etc/pki/tls/openssl.cnf

Thanks,
Perry

[hbouma]

I will send you the file via PM.

Code: Select all

echo 'DONE' | openssl s_client -showcerts -connect REDACTED:636
CONNECTED(00000003)
depth=3 CN = REDACTED
verify return:1
depth=2 DC = REDACTED
verify return:1
depth=1 DC = REDACTED
verify return:1
depth=0 CN = REDACTED
verify return:1
---
Certificate chain
REDACTED
-----BEGIN CERTIFICATE-----
REDACTED
-----END CERTIFICATE-----
REDACTED
-----BEGIN CERTIFICATE-----
REDACTED
-----END CERTIFICATE-----
REDACTED
-----BEGIN CERTIFICATE-----
REDACTED
-----END CERTIFICATE-----
---
Server certificate
subject=REDACTED

issuer=REDACTED

---
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1:RSA+SHA512:ECDSA+SHA512
Shared Requested Signature Algorithms: RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1:RSA+SHA512:ECDSA+SHA512
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 5184 bytes and written 475 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: REDACTED
    Session-ID-ctx:
    Master-Key: REDACTED
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1645739946
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes
---
read:errno=104

[pbroste]

Hello @hbouma

Thanks for following up with the info; read:errno=104 indicates the connection was forcibly closed with a TCP RST. To help determine what is going on let's circle back around and get:

Start tcpdump capture:

Code: Select all

tcpdump -s 0 -i any port <yourldapporthere> -w /tmp/output.pcap

Then run through:

Code: Select all

echo 'DONE' | openssl s_client -showcerts -connect your.ad_or_ldap.server:636

Let's get the curl results from the api:

Code: Select all

curl -k --verbose -XPOST "https://yournagioshostaddresshere/nagiosxi/api/v1/system/authserver?apikey=yourapikeyhere&pretty=1" -d "conn_method=ldap&ldap_host=yourldaphostaddresshere&base_dn=fulldistinguished namehere&security_level=ssl"

Please send over the 'tcpdump' command output found in '/tmp/output.pcap' and let us know how things look. Any chances to see what the LDAP server is looking at in the Eventlogs during the auth attempts?

Thanks,
Perry