Hey Everyone!
Wondering if anyone could help nudge me along in the right direction on
this one. Getting the following on my FreeIPA master and replica:
Internal Database Error encountered: Could not connect to LDAP server
host idmipa01.nix.mds.xyz port 636 Error netscape.ldap.LDAPException:
Authentication failed (48)
Internal Database Error encountered: Could not connect to LDAP server
host idmipa02.nix.mds.xyz port 636 Error netscape.ldap.LDAPException:
Authentication failed (48)
These appeared after some power outages occurred 2-3 times and both
hosts were affected. Went over a few pages online to try to get to the
bottom of these errors on these VM's however no luck so far:
https://access.redhat.com/solutions/3081821
https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tomcatd-fails-to-start/
and about a dozen other pages with little luck.
Here's what I tried. First, wanted to and did kick off the following on
idmipa02:
ipa-cacert-manage renew
I've read on a few posts that command will cause the running server to
become the renewal master, so was cautious to check first:
[idmipa01]
# ipa config-show | grep 'IPA CA renewal master'
IPA CA renewal master: idmipa02.nix.mds.xyz
[idmipa02]
# ipa config-show | grep 'IPA CA renewal master'
IPA CA renewal master: idmipa02.nix.mds.xyz
Checked the certs and indeed the serial was different:
# ldapsearch -D 'cn=directory manager' -W -b uid=pkidbuser,ou=people,o=ipaca
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <uid=pkidbuser,ou=people,o=ipaca> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# pkidbuser, people, ipaca
dn: uid=pkidbuser,ou=people,o=ipaca
userPassword:: e1NTSEE1MTJ9NUs3N......................................g4
description: 2;26;CN=Certificate Authority,O=NIX.MDS.XYZ;CN=CA
Subsystem,O=NIX
.MDS.XYZ
seeAlso: CN=CA Subsystem,O=NIX.MDS.XYZ
userCertificate:: MIIDdjCCAl6............................IYL9mJQXhHIxpc=
userCertificate:: MIIDcTCCAlmgAwIBAg.........Mdr8SvD9uWfMPwUE4Tf2csf0z+Z
userCertificate:: MIIDcTCCAlmgA..............yShSmujM9PJrJPBBjLmTCIle9Xl
userCertificate:: MIIDdDCCAlygAwIBAg......................cgDVlPYm3LmKk+
userstate: 1
usertype: agentType
mail:
cn: pkidbuser
sn: pkidbuser
uid: pkidbuser
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: cmsuser
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
# certutil -d /etc/pki/pki-tomcat/alias/ -L -n 'subsystemCert
cert-pki-ca' -a
-----BEGIN CERTIFICATE-----
MIIDdDC..........................................dJmcMKreZ7cgDVlPYm3LmKk+
-----END CERTIFICATE-----
# certutil -d /etc/pki/pki-tomcat/alias/ -L -n 'subsystemCert
cert-pki-ca' |grep -i serial
Serial Number: 268369925 (0xfff0005)
So updated it using:
ldapmodify -x -h localhost -p 389 -D "cn=Directory Manager" -W << EOF
dn:uid=pkidbuser,ou=people,o=ipaca
changetype: modify
replace: description
description: 2;268369925;CN=Certificate Authority,O=NIX.MDS.XYZ;CN=CA
Subsystem,O=NIX.MDS.XYZ
EOF
Then verified that only the serial changed (the cert was already in the
list anyway so did not need to change) by comparing the before and after:
# diff 1.txt 2.txt
11a12,13
> description: 2;268369925;CN=Certificate Authority,O=NIX.MDS.XYZ;CN=CA
Subsyste
> m,O=NIX.MDS.XYZ
14,15d15
< description: 2;26;CN=Certificate Authority,O=NIX.MDS.XYZ;CN=CA
Subsystem,O=NIX
< .MDS.XYZ
Confirmed trust attributes are fine:
certutil -d /etc/dirsrv/slapd-NIX-MDS-XYZ/ -L
Certificate Nickname Trust
Attributes
SSL,S/MIME,JAR/XPI
Server-Cert u,u,u
NIX.MDS.XYZ IPA CA CT,C,C
Yet on restart on idmipa02, still the same issue:
# ipactl restart
Restarting Directory Service
Restarting krb5kdc Service
Restarting kadmin Service
Restarting named Service
Restarting httpd Service
Restarting ipa-custodia Service
Restarting ntpd Service
Restarting pki-tomcatd Service
Failed to restart pki-tomcatd Service
Shutting down
Hint: You can use --ignore-service-failure option for forced start in
case that a non-critical service failed
Aborting ipactl
I have dated snapshots of both servers however, they both are with the
above mentioned issue. These hosts were also offline for a couple of
months meaning cert expiration could be an issue. Likewise, I could
have caused a slight mess myself trying various online solutions that
don't always match 100%.
In regards to the certificate expiration, below are the expiration dates
for various certs though admittedly, I can't be sure of how impacting
any of these dates are since I don't yet understand the usage of each of
these certs as much as I would like to, which the exception of the
subsystemCert:
# getcert list|grep -Ei "expires|status|key pair storage"
status: CA_UNREACHABLE
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS Certificate DB',pin set
expires: 2022-09-10 22:14:56 UTC
status: CA_UNREACHABLE
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
cert-pki-ca',token='NSS Certificate DB',pin set
expires: 2022-09-10 22:13:56 UTC
status: CA_UNREACHABLE
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert
cert-pki-ca',token='NSS Certificate DB',pin set
expires: 2022-09-10 22:13:54 UTC
status: MONITORING
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
cert-pki-ca',token='NSS Certificate DB',pin set
expires: 2036-11-21 07:32:02 UTC
status: CA_UNREACHABLE
key pair storage: type=FILE,location='/var/lib/ipa/ra-agent.key'
expires: 2022-09-21 22:13:57 UTC
status: CA_UNREACHABLE
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert
cert-pki-ca',token='NSS Certificate DB',pin set
expires: 2022-08-27 17:23:10 UTC
status: CA_UNREACHABLE
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-NIX-MDS-XYZ',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-NIX-MDS-XYZ/pwdfile.txt'
expires: 2022-09-29 17:22:58 UTC
status: CA_UNREACHABLE
key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
expires: 2022-09-29 17:22:45 UTC
status: MONITORING
key pair storage:
type=FILE,location='/var/kerberos/krb5kdc/kdc.key'
expires: 2023-09-25 02:17:17 UTC
Both hosts are reachable from each other. Verified a couple of ports to
be sure. F/W is off on both, for the moment and both hosts exist on the
same VLAN.
--
Thx,
TK.
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
