Issues after migrating to a new server
Re: Issues after migrating to a new server
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.
Re: Issues after migrating to a new server
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:
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
Then run these commands:
Then edit your /etc/openldap/ldap.conf and uncomment this line:
So it looks like this:
Then restart apache/php-fpm and test again and see if that resolves the issue:
Then test the login and the import is a good test as well.
Thanks,
Perry
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
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/
Code: Select all
update-ca-trust extract
Code: Select all
#TLS_CACERT /etc/pki/tls/cert.pem
Code: Select all
TLS_CACERT /etc/pki/tls/cert.pem
Code: Select all
systemctl restart httpd php-fpm
Thanks,
Perry
Re: Issues after migrating to a new server
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.
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.
Re: Issues after migrating to a new server
Going out on a divagation but want to make sure and rule out time/date/timezone synced across within thresholds with your LDAP server.
Thanks,
Perry
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;'
Perry
Re: Issues after migrating to a new 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;'
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 |
+--------------------+---------------------+
Re: Issues after migrating to a new server
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)
Then:
After reboot verify:
Thanks,
Perry
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
Code: Select all
update-crypto-policies --set LEGACY && reboot
Code: Select all
update-crypto-policies --show
Perry
Re: Issues after migrating to a new server
Made the requested changes.
After reboot, I still cannot log in.
Now, I cannot log in, even with the built in NagiosAdmin account.
Code: Select all
fips-mode-setup --disable && reboot
Code: Select all
update-crypto-policies --set LEGACY && reboot
Code: Select all
update-crypto-policies --show
LEGACY
Re: Issues after migrating to a new server
Hello @hbouma
Thanks for following up, let us know what the results:
Please send a copy of the following configs:
Thanks,
Perry
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
Code: Select all
tar -czvf /tmp/sslconfigs.tar.gz /etc/httpd/conf.d/ssl.conf /etc/pki/tls/openssl.cnf
Perry
Re: Issues after migrating to a new server
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
Re: Issues after migrating to a new server
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:
Then run through:
Let's get the curl results from the api:
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
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
Code: Select all
echo 'DONE' | openssl s_client -showcerts -connect your.ad_or_ldap.server:636
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"
Thanks,
Perry