August 2020 - FreeIPA-users - Fedora mailing-lists

Re: pki-tomcatd not starting
by Rob Crittenden 10 Aug '20

10 Aug '20

Scott Z. via FreeIPA-users wrote: > On the failing node, the output of "getcert list" does not show any > expired certs.Â I have hand-copied the info info this email below (it's > interesting to note that while the other IdM servers are tracking 9 > certs, the problem server is only tracking 8): The tomcat Server-Cert is not tracked. To confirm: # getcert list -d /etc/pki/pki-tomcat/alias -n 'Server-Cert cert-pki-ca' Running ipa-server-upgrade should detect and fix the missing tracking. To see if it is expired: # certutil -L -d /etc/pki/pki-tomcat/alias -n 'Server-Cert cert-pki-ca' rob > > Number of certificates and requests being tracked: 8 > Request ID '<###>': > status: MONITORING > stuck: no > key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key' > certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt' > CA: SelfSign > issuer: CN=<servername>,O=<domain> > subject: CN=<servername>,O=<domain> > expires: 2020-09-12 19:51:34 UTC > principal name: krbtgt/<domain> > certificate template/profile: KDCs_PKINIT_Certs > pre-save command: > post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert > track: yes > auto-renew: yes > > Request ID '<###>': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert > cert-pki-ca',token=NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert > cert-pki-ca',token=NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=<domain> > subject: CN=CA Audit,O=<domain> > expires: 2021-08-10 17:20:21 UTC > key usage: digitialSignature,nonRepudiation > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "auditSigningCert cert-pki-ca" > track: yes > auto-renew: yes > > Request ID '<###>': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token=NSS > Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token=NSS > Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=<domain> > subject: CN=OCSP Subsystem,O=<domain> > expires: 2021-08-10 17:19:42 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "subsystemCert cert-pki-ca" > track: yes > auto-renew: yes > > Request ID '<###>': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert > cert-pki-ca',token=NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert > cert-pki-ca',token=NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=<domain> > subject: CN=CA Subsystem,O=<domain> > expires: 2021-08-10 17:19:51 UTC > key usage: > digitialSignature,nonRepudiation,keyEnchipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "subsystemCert cert-pki-ca" > track: yes > auto-renew: yes > > Request ID '<###>': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert > cert-pki-ca',token=NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert > cert-pki-ca',token=NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=<domain> > subject: CN=Certificate Authority,O=<domain> > expires: 2037-09-28 14:29:02 UTC > key usage: digitialSignature,nonRepudiation,keyCertSign,cRLSign > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "caSigningCert cert-pki-ca" > track: yes > auto-renew: yes > > Request ID '<###>': > status: MONITORING > stuck: no > key pair storage: type=NSSDB,location='/var/lib/ipa/ra-agent.key' > certificate: type=NSSDB,location='/var/lib/ipa/ra-agent.pem' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=<domain> > subject: CN=IPA RA,,O=<domain> > expires: 2021-08-10 17:20:41 UTC > key usage: > digitialSignature,nonRepudiation,keyEnchipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre > post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert > track: yes > auto-renew: yes > > Request ID '<###>': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-<domain>',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-<domain>/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-<domain>',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=<domain> > subject: CN=<server>,O=<domain> > expires: 2021-09-09 19:53:33 UTC > principal name: ldap/<serverFQDN@domain> > key usage: > digitialSignature,nonRepudiation,keyEnchipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv <domain> > track: yes > auto-renew: yes > > Request ID '<###>': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-<domain>',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=<domain> > subject: CN=<server>,O=<domain> > expires: 2021-09-09 19:51:45 UTC > principal name: HTTP/<serverFQDN@domain> > key usage: > digitialSignature,nonRepudiation,keyEnchipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/libexec/ipa/certmonger/restart_httpd > track: yes > auto-renew: yes > > Thank you so much again! > Scot > > > > ------------------------------------------------------------------------ > *From:* Florence Blanc-Renaud <flo(a)redhat.com> > *Sent:* Thursday, August 6, 2020 2:46 AM > *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> > *Cc:* Scott Z. <sudz28(a)hotmail.com> > *Subject:* Re: [Freeipa-users] Re: pki-tomcatd not starting > Â > On 8/6/20 12:53 AM, Scott Z. via FreeIPA-users wrote: >> Thanks much for the assistance.Ã‚Â Here is where I am with your suggestions: >> 1) Checked on the cert with "certutil -L -d /etc/pki/pki-tomcat/alias -n >> 'Server-Cert cert-pki-ca' and I see that the Validity is indeed old >> (almost a year old actually, I assume IPA only checks it when it first >> starts up so it didn't care that it was expired until the server was >> rebooted?) > > certmonger checks the certificate validity periodically (configurable in > certmonger.conf) and tries multiple times to renew soon-to-expire certs. > The system probably had an issue that was not detected and the cert > reached its expiration date. > >> >> 2) ran ipactl start --ignore-service-failures >>Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â a. most services started, obviously pki-tomcatd did not >> 3) ran "kinit admin" >>Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â a. was forced to change the password, but otherwise nothing happened >> 4) Ran "ipa config-show |grep -i master >>Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â a. I see that the IPA CA renewal master is a different idm machine. >> 5) Ran "getcert list | grep -E "Request|certificate:|expires:" >>Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â a.I see all certs are currently valid (none expired) >> 6) Ran the command "getcert list" on the problem server, but I cannot >> paste the output here because it's on an airgaped environment so while I >> apologize for this and realize it makes things more difficult, perhaps >> if you tell me what I should be looking for or more specifically what >> you're interested in I can pluck that out and manually include it here? >> So in summary, it is indeed an expired "Server-Cert cert-pki-ca' >> certificate on the problem server, and it can theoretically be renew by >> the Master at this time. > The interesting part is the list of expired certs on the failing node > (is the RA cert /var/lib/ipa/ra-agent.pem expired?). Detailed > instructions are available here: > https://access.redhat.com/solutions/3357331 How do I manually renew > Identity Management (IPA) certificates on RHEL7 after they have expired? > (Replica IPA Server) > > flo > >> Many thanks! >> Scott >> >> ------------------------------------------------------------------------ >> *From:* Florence Blanc-Renaud <flo(a)redhat.com> >> *Sent:* Monday, August 3, 2020 9:34 PM >> *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> >> *Cc:* Scott Z. <sudz28(a)hotmail.com> >> *Subject:* Re: [Freeipa-users] pki-tomcatd not starting >> On 8/3/20 10:14 PM, Scott Z. via FreeIPA-users wrote: >>> Not sure I'm sending this to the right place, but here it goes.Ãƒâ€šÃ‚Â I >>> inherited a FreeIPA/Identity Manager setup in an enclave (no internet >>> access) environment that is running into problems.Ãƒâ€šÃ‚Â There are at least 3 >>> different IdM servers running in the environment spread out across >>> different geographical areas.Ãƒâ€šÃ‚Â One of those areas suffered an unschedule >>> power outage recently, and ever since we brought everything back up, the >>> IdM server for this region is having an issue.Ãƒâ€šÃ‚Â Please bear with me as I >>> have zero formal experience, training, or real knowledge with IdM. >>> >>> Logging in to the serverv (it's a VM server, running Centos 7.5), I run >>> "ipactl status" and it shows "Directory Service: STOPPED".Ãƒâ€šÃ‚Â I then run >>> "ipactl restart", and things go fine until it gets to "Starting >>> pki-tomcatd Service", where it hangs for quite some time before failing >>> to start and killing all the other services.Ãƒâ€šÃ‚Â I check the log at >>> /var/log/pki/pki-tomcat/ca/debug and I see various errors such as >>> (forgive any mistypings, I have to manually type these in as I can't >>> import or screen capure the logs and put them in this message): >>> "/java.lang.Exception: Certificate Server-Cert cert-pki-ca is invalid: >>> Invalid certificate: (-8181) Peer's Certificate has expired/" >>> And slightly further down in the same log: >>> "/Cannot reset factory: connections not all returned/" >>> "/CertificateAuthority.shutdown: failed to reset dbFactory: Cannot reset >>> LDAP connection factory because some connections are still outstanding/" >>> ... still further down" >>> "/returnConn:mNumConns now 3 Invalid class name repositorytop/" >>> >>> Assuming I have some weird certificate issue with this server in >>> particular, I try to run a few more commands: >>> "certutil -L -d /etc/httpd/alias"Ãƒâ€šÃ‚Â --> returns a Server-Cert listing >>> with u,u,u as it's trust attributes, and <IDM.domain> IPA CA with CT,C,C >>> for it's attributes.Ãƒâ€šÃ‚Â Comparing to a second IdM server in this >>> environment, it seems to be missing a "Signing-Cert"? >>> >> Hi, >> PKI is using the NSSDB in /etc/pki/pki-tomcat/alias, and its server cert >> has the nickname 'Server-Cert cert-pki-ca'. You should check that this >> one is not expired with: >> # certutil -L -d /etc/pki/pki-tomcat/alias -n 'Server-Cert cert-pki-ca' >> | grep 'Not ' >> >> If the certificate is indeed expired, it will have to be renewed but you >> need first to find which IPA server is the CA renewal master. On your >> server, force a service start and check the CA renewal master: >> # ipactl start --ignore-service-failures >> # kinit admin >> # ipa config-show | grep "renewal master" >>Â Ã‚Â Ã‚Â IPA CA renewal master: server.domain.com >> >> You need to make sure that all the certificates are valid on the CA >> renewal master: >> (on the CA renewal master)# getcert list | grep -E >> "Request|certificate:|expires:" >> >> - if the CA renewal master is not OK, please post the output of "# >> getcert list" (without the grep) on the CA renewal master. This node >> will have to be repaired first. >> - if the CA renewal master is OK, please post the output of "# getcert >> list" (also without the grep) on the failing node. >> >> We'll be able to help based on this information. >> flo >> >>> I also did a "getcert list", and all certs it has show that they expire >>> in the future (nothing shows as bein currently expired). >>> >>> I'm confused; it seems to that it is seeing an expired cert *somewhere*, >>> but how do I track down which 'peer' the log file is talking about that >>> has an expired cert?Ãƒâ€šÃ‚Â Meanwhile none of the linux clients that point to >>> this IdM server are allowing people to log in/authenticate. >>> Many thanks for any help! >>> Scott >>> >>> >>> _______________________________________________ >>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org >>> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org >>> 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/freeipa-users@lists.fedorahost… >>> >> >> >> _______________________________________________ >> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org >> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org >> 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/freeipa-users@lists.fedorahost… >> > > > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org > 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/freeipa-users@lists.fedorahost… >

1 0

Re: pki-tomcatd not starting
by Florence Blanc-Renaud 10 Aug '20

10 Aug '20

On 8/10/20 7:56 PM, Scott Z. via FreeIPA-users wrote: > On the failing node, the output of "getcert list" does not show any > expired certs.Â I have hand-copied the info info this email below (it's > interesting to note that while the other IdM servers are tracking 9 > certs, the problem server is only tracking 8): > It looks like the server is missing the tracking request for 'Server-Cert cert-pki-ca'. You can add tracking for the cert with the nickname 'Server-Cert cert-pki-ca' in /etc/pki/pki-tomcat/alias with a command like this one: getcert start-tracking -n 'Server-Cert cert-pki-ca' -d /etc/pki/pki-tomcat/alias -c dogtag-ipa-ca-renew-agent -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "Server-Cert cert-pki-ca"' -P <pin> and the PIN can be found in /etc/pki/pki-tomcat/password.conf in the line containing internal=<pin> flo > Number of certificates and requests being tracked: 8 > Request ID '<###>': > status: MONITORING > stuck: no > key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key' > certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt' > CA: SelfSign > issuer: CN=<servername>,O=<domain> > subject: CN=<servername>,O=<domain> > expires: 2020-09-12 19:51:34 UTC > principal name: krbtgt/<domain> > certificate template/profile: KDCs_PKINIT_Certs > pre-save command: > post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert > track: yes > auto-renew: yes > > Request ID '<###>': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert > cert-pki-ca',token=NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert > cert-pki-ca',token=NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=<domain> > subject: CN=CA Audit,O=<domain> > expires: 2021-08-10 17:20:21 UTC > key usage: digitialSignature,nonRepudiation > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "auditSigningCert cert-pki-ca" > track: yes > auto-renew: yes > > Request ID '<###>': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token=NSS > Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token=NSS > Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=<domain> > subject: CN=OCSP Subsystem,O=<domain> > expires: 2021-08-10 17:19:42 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "subsystemCert cert-pki-ca" > track: yes > auto-renew: yes > > Request ID '<###>': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert > cert-pki-ca',token=NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert > cert-pki-ca',token=NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=<domain> > subject: CN=CA Subsystem,O=<domain> > expires: 2021-08-10 17:19:51 UTC > key usage: > digitialSignature,nonRepudiation,keyEnchipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "subsystemCert cert-pki-ca" > track: yes > auto-renew: yes > > Request ID '<###>': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert > cert-pki-ca',token=NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert > cert-pki-ca',token=NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=<domain> > subject: CN=Certificate Authority,O=<domain> > expires: 2037-09-28 14:29:02 UTC > key usage: digitialSignature,nonRepudiation,keyCertSign,cRLSign > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "caSigningCert cert-pki-ca" > track: yes > auto-renew: yes > > Request ID '<###>': > status: MONITORING > stuck: no > key pair storage: type=NSSDB,location='/var/lib/ipa/ra-agent.key' > certificate: type=NSSDB,location='/var/lib/ipa/ra-agent.pem' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=<domain> > subject: CN=IPA RA,,O=<domain> > expires: 2021-08-10 17:20:41 UTC > key usage: > digitialSignature,nonRepudiation,keyEnchipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre > post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert > track: yes > auto-renew: yes > > Request ID '<###>': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-<domain>',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-<domain>/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-<domain>',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=<domain> > subject: CN=<server>,O=<domain> > expires: 2021-09-09 19:53:33 UTC > principal name: ldap/<serverFQDN@domain> > key usage: > digitialSignature,nonRepudiation,keyEnchipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv <domain> > track: yes > auto-renew: yes > > Request ID '<###>': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-<domain>',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=<domain> > subject: CN=<server>,O=<domain> > expires: 2021-09-09 19:51:45 UTC > principal name: HTTP/<serverFQDN@domain> > key usage: > digitialSignature,nonRepudiation,keyEnchipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/libexec/ipa/certmonger/restart_httpd > track: yes > auto-renew: yes > > Thank you so much again! > Scot > > > > ------------------------------------------------------------------------ > *From:* Florence Blanc-Renaud <flo(a)redhat.com> > *Sent:* Thursday, August 6, 2020 2:46 AM > *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> > *Cc:* Scott Z. <sudz28(a)hotmail.com> > *Subject:* Re: [Freeipa-users] Re: pki-tomcatd not starting > On 8/6/20 12:53 AM, Scott Z. via FreeIPA-users wrote: >> Thanks much for the assistance.Ã‚Â Here is where I am with your suggestions: >> 1) Checked on the cert with "certutil -L -d /etc/pki/pki-tomcat/alias -n >> 'Server-Cert cert-pki-ca' and I see that the Validity is indeed old >> (almost a year old actually, I assume IPA only checks it when it first >> starts up so it didn't care that it was expired until the server was >> rebooted?) > > certmonger checks the certificate validity periodically (configurable in > certmonger.conf) and tries multiple times to renew soon-to-expire certs. > The system probably had an issue that was not detected and the cert > reached its expiration date. > >> >> 2) ran ipactl start --ignore-service-failures >>Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â a. most services started, obviously pki-tomcatd did not >> 3) ran "kinit admin" >>Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â a. was forced to change the password, but otherwise nothing happened >> 4) Ran "ipa config-show |grep -i master >>Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â a. I see that the IPA CA renewal master is a different idm machine. >> 5) Ran "getcert list | grep -E "Request|certificate:|expires:" >>Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â a.I see all certs are currently valid (none expired) >> 6) Ran the command "getcert list" on the problem server, but I cannot >> paste the output here because it's on an airgaped environment so while I >> apologize for this and realize it makes things more difficult, perhaps >> if you tell me what I should be looking for or more specifically what >> you're interested in I can pluck that out and manually include it here? >> So in summary, it is indeed an expired "Server-Cert cert-pki-ca' >> certificate on the problem server, and it can theoretically be renew by >> the Master at this time. > The interesting part is the list of expired certs on the failing node > (is the RA cert /var/lib/ipa/ra-agent.pem expired?). Detailed > instructions are available here: > https://access.redhat.com/solutions/3357331 How do I manually renew > Identity Management (IPA) certificates on RHEL7 after they have expired? > (Replica IPA Server) > > flo > >> Many thanks! >> Scott >> >> ------------------------------------------------------------------------ >> *From:* Florence Blanc-Renaud <flo(a)redhat.com> >> *Sent:* Monday, August 3, 2020 9:34 PM >> *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> >> *Cc:* Scott Z. <sudz28(a)hotmail.com> >> *Subject:* Re: [Freeipa-users] pki-tomcatd not starting >> On 8/3/20 10:14 PM, Scott Z. via FreeIPA-users wrote: >>> Not sure I'm sending this to the right place, but here it goes.Ãƒâ€šÃ‚Â I >>> inherited a FreeIPA/Identity Manager setup in an enclave (no internet >>> access) environment that is running into problems.Ãƒâ€šÃ‚Â There are at least 3 >>> different IdM servers running in the environment spread out across >>> different geographical areas.Ãƒâ€šÃ‚Â One of those areas suffered an unschedule >>> power outage recently, and ever since we brought everything back up, the >>> IdM server for this region is having an issue.Ãƒâ€šÃ‚Â Please bear with me as I >>> have zero formal experience, training, or real knowledge with IdM. >>> >>> Logging in to the serverv (it's a VM server, running Centos 7.5), I run >>> "ipactl status" and it shows "Directory Service: STOPPED".Ãƒâ€šÃ‚Â I then run >>> "ipactl restart", and things go fine until it gets to "Starting >>> pki-tomcatd Service", where it hangs for quite some time before failing >>> to start and killing all the other services.Ãƒâ€šÃ‚Â I check the log at >>> /var/log/pki/pki-tomcat/ca/debug and I see various errors such as >>> (forgive any mistypings, I have to manually type these in as I can't >>> import or screen capure the logs and put them in this message): >>> "/java.lang.Exception: Certificate Server-Cert cert-pki-ca is invalid: >>> Invalid certificate: (-8181) Peer's Certificate has expired/" >>> And slightly further down in the same log: >>> "/Cannot reset factory: connections not all returned/" >>> "/CertificateAuthority.shutdown: failed to reset dbFactory: Cannot reset >>> LDAP connection factory because some connections are still outstanding/" >>> ... still further down" >>> "/returnConn:mNumConns now 3 Invalid class name repositorytop/" >>> >>> Assuming I have some weird certificate issue with this server in >>> particular, I try to run a few more commands: >>> "certutil -L -d /etc/httpd/alias"Ãƒâ€šÃ‚Â --> returns a Server-Cert listing >>> with u,u,u as it's trust attributes, and <IDM.domain> IPA CA with CT,C,C >>> for it's attributes.Ãƒâ€šÃ‚Â Comparing to a second IdM server in this >>> environment, it seems to be missing a "Signing-Cert"? >>> >> Hi, >> PKI is using the NSSDB in /etc/pki/pki-tomcat/alias, and its server cert >> has the nickname 'Server-Cert cert-pki-ca'. You should check that this >> one is not expired with: >> # certutil -L -d /etc/pki/pki-tomcat/alias -n 'Server-Cert cert-pki-ca' >> | grep 'Not ' >> >> If the certificate is indeed expired, it will have to be renewed but you >> need first to find which IPA server is the CA renewal master. On your >> server, force a service start and check the CA renewal master: >> # ipactl start --ignore-service-failures >> # kinit admin >> # ipa config-show | grep "renewal master" >>Â Ã‚Â Ã‚Â IPA CA renewal master: server.domain.com >> >> You need to make sure that all the certificates are valid on the CA >> renewal master: >> (on the CA renewal master)# getcert list | grep -E >> "Request|certificate:|expires:" >> >> - if the CA renewal master is not OK, please post the output of "# >> getcert list" (without the grep) on the CA renewal master. This node >> will have to be repaired first. >> - if the CA renewal master is OK, please post the output of "# getcert >> list" (also without the grep) on the failing node. >> >> We'll be able to help based on this information. >> flo >> >>> I also did a "getcert list", and all certs it has show that they expire >>> in the future (nothing shows as bein currently expired). >>> >>> I'm confused; it seems to that it is seeing an expired cert *somewhere*, >>> but how do I track down which 'peer' the log file is talking about that >>> has an expired cert?Ãƒâ€šÃ‚Â Meanwhile none of the linux clients that point to >>> this IdM server are allowing people to log in/authenticate. >>> Many thanks for any help! >>> Scott >>> >>> >>> _______________________________________________ >>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org >>> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org >>> 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/freeipa-users@lists.fedorahost… >>> >> >> >> _______________________________________________ >> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org >> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org >> 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/freeipa-users@lists.fedorahost… >> > > > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org > 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/freeipa-users@lists.fedorahost… >

1 0

Re: pki-tomcatd not starting
by Florence Blanc-Renaud 10 Aug '20

10 Aug '20

On 8/6/20 12:53 AM, Scott Z. via FreeIPA-users wrote: > Thanks much for the assistance.Â Here is where I am with your suggestions: > 1) Checked on the cert with "certutil -L -d /etc/pki/pki-tomcat/alias -n > 'Server-Cert cert-pki-ca' and I see that the Validity is indeed old > (almost a year old actually, I assume IPA only checks it when it first > starts up so it didn't care that it was expired until the server was > rebooted?) certmonger checks the certificate validity periodically (configurable in certmonger.conf) and tries multiple times to renew soon-to-expire certs. The system probably had an issue that was not detected and the cert reached its expiration date. > > 2) ran ipactl start --ignore-service-failures > Â Â Â Â Â Â a. most services started, obviously pki-tomcatd did not > 3) ran "kinit admin" > Â Â Â Â Â Â a. was forced to change the password, but otherwise nothing happened > 4) Ran "ipa config-show |grep -i master > Â Â Â Â Â a. I see that the IPA CA renewal master is a different idm machine. > 5) Ran "getcert list | grep -E "Request|certificate:|expires:" > Â Â Â Â Â a.I see all certs are currently valid (none expired) > 6) Ran the command "getcert list" on the problem server, but I cannot > paste the output here because it's on an airgaped environment so while I > apologize for this and realize it makes things more difficult, perhaps > if you tell me what I should be looking for or more specifically what > you're interested in I can pluck that out and manually include it here? > So in summary, it is indeed an expired "Server-Cert cert-pki-ca' > certificate on the problem server, and it can theoretically be renew by > the Master at this time. The interesting part is the list of expired certs on the failing node (is the RA cert /var/lib/ipa/ra-agent.pem expired?). Detailed instructions are available here: https://access.redhat.com/solutions/3357331 How do I manually renew Identity Management (IPA) certificates on RHEL7 after they have expired? (Replica IPA Server) flo > Many thanks! > Scott > > ------------------------------------------------------------------------ > *From:* Florence Blanc-Renaud <flo(a)redhat.com> > *Sent:* Monday, August 3, 2020 9:34 PM > *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> > *Cc:* Scott Z. <sudz28(a)hotmail.com> > *Subject:* Re: [Freeipa-users] pki-tomcatd not starting > On 8/3/20 10:14 PM, Scott Z. via FreeIPA-users wrote: >> Not sure I'm sending this to the right place, but here it goes.Ã‚Â I >> inherited a FreeIPA/Identity Manager setup in an enclave (no internet >> access) environment that is running into problems.Ã‚Â There are at least 3 >> different IdM servers running in the environment spread out across >> different geographical areas.Ã‚Â One of those areas suffered an unschedule >> power outage recently, and ever since we brought everything back up, the >> IdM server for this region is having an issue.Ã‚Â Please bear with me as I >> have zero formal experience, training, or real knowledge with IdM. >> >> Logging in to the serverv (it's a VM server, running Centos 7.5), I run >> "ipactl status" and it shows "Directory Service: STOPPED".Ã‚Â I then run >> "ipactl restart", and things go fine until it gets to "Starting >> pki-tomcatd Service", where it hangs for quite some time before failing >> to start and killing all the other services.Ã‚Â I check the log at >> /var/log/pki/pki-tomcat/ca/debug and I see various errors such as >> (forgive any mistypings, I have to manually type these in as I can't >> import or screen capure the logs and put them in this message): >> "/java.lang.Exception: Certificate Server-Cert cert-pki-ca is invalid: >> Invalid certificate: (-8181) Peer's Certificate has expired/" >> And slightly further down in the same log: >> "/Cannot reset factory: connections not all returned/" >> "/CertificateAuthority.shutdown: failed to reset dbFactory: Cannot reset >> LDAP connection factory because some connections are still outstanding/" >> ... still further down" >> "/returnConn:mNumConns now 3 Invalid class name repositorytop/" >> >> Assuming I have some weird certificate issue with this server in >> particular, I try to run a few more commands: >> "certutil -L -d /etc/httpd/alias"Ã‚Â --> returns a Server-Cert listing >> with u,u,u as it's trust attributes, and <IDM.domain> IPA CA with CT,C,C >> for it's attributes.Ã‚Â Comparing to a second IdM server in this >> environment, it seems to be missing a "Signing-Cert"? >> > Hi, > PKI is using the NSSDB in /etc/pki/pki-tomcat/alias, and its server cert > has the nickname 'Server-Cert cert-pki-ca'. You should check that this > one is not expired with: > # certutil -L -d /etc/pki/pki-tomcat/alias -n 'Server-Cert cert-pki-ca' > | grep 'Not ' > > If the certificate is indeed expired, it will have to be renewed but you > need first to find which IPA server is the CA renewal master. On your > server, force a service start and check the CA renewal master: > # ipactl start --ignore-service-failures > # kinit admin > # ipa config-show | grep "renewal master" > Â Â IPA CA renewal master: server.domain.com > > You need to make sure that all the certificates are valid on the CA > renewal master: > (on the CA renewal master)# getcert list | grep -E > "Request|certificate:|expires:" > > - if the CA renewal master is not OK, please post the output of "# > getcert list" (without the grep) on the CA renewal master. This node > will have to be repaired first. > - if the CA renewal master is OK, please post the output of "# getcert > list" (also without the grep) on the failing node. > > We'll be able to help based on this information. > flo > >> I also did a "getcert list", and all certs it has show that they expire >> in the future (nothing shows as bein currently expired). >> >> I'm confused; it seems to that it is seeing an expired cert *somewhere*, >> but how do I track down which 'peer' the log file is talking about that >> has an expired cert?Ã‚Â Meanwhile none of the linux clients that point to >> this IdM server are allowing people to log in/authenticate. >> Many thanks for any help! >> Scott >> >> >> _______________________________________________ >> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org >> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org >> 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/freeipa-users@lists.fedorahost… >> > > > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org > 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/freeipa-users@lists.fedorahost… >

2 1

IPA Server with multiple Networks with different Domains
by julian jost 07 Aug '20

07 Aug '20

Hi, I already found a few threads with people with the similar issue but i was not able to find one pointing to the right solution. Maybe someone can give me a direction in case there is one that i overlooked: We run a Datacenter with lots of vlans and different networks. Each network has a different (sub)Domain. (I replaced our domain with tld in this thread) The IPA Servers reside in a infrastructure network: "back.inf.tld.de". The REALM is called "auth.tld.de" (and the hostnames of the ipa servers is also *.auth.tld.de That works very well, i can connect clients from all networks with all kinds of fqdns as long as they can reach the IP associated with that name. But i have I few networks that can not reach this network (intentional) so I added a second network card to the ipa servers with a new set of hostnames -> "*.store.tld.de" I added the kerberos config / SRV Records into the zone that is managed by one of our dns servers (not managed by ipa) so discovery works fine. First Problem was the missing SANs for the services like ldap,httpd etc. That was easy to solve by adding principal aliases and use the ipa-getcert tool to re-issue the certificates. Now when running ipa-client-install --mkhomedir --domain=store.tld.de --realm=AUTH.TLD.DE it looks okay until it tries to communicate with the http service to POST data to ipa01.store.tld.de/ipa/xml. It answers with: <?xml version='1.0' encoding='UTF-8'?>\n <methodResponse>\n <fault>\n <value><struct>\n <member>\n <name>faultCode</name>\n <value><int>911</int></value>\n </member>\n <member>\n <name>faultString</name>\n <value><string>Missing or invalid HTTP Referer, https://ipa01-ka.tld.d0m.de/ipa/xml</string></value>\n </member>\n </struct></value>\n </fault>\n </methodResponse>\n RPC failed at server. Missing or invalid HTTP Referer, https://ipa01-ka.tld.d0m.de/ipa/xml I tried rewriting the request on the ipa server via mod-rewrite but failed. Does somebody managed to get this to work ? This has to be a common thing to archive, right ? There are always protected networks (like those you put the SPs in) that you don't want to route into other networks. Greetings Ju

2 2

Migrate data from a containerised IPA
by Pierre-Marie Besserer 07 Aug '20

07 Aug '20

Hi everybody! I'm trying to migrate data from a containerised IPA to a freshly new installed "standard" IPA, like you would do with the backup/restore tools. Naively I thought I could just copy the files from my /data binded directory in the /etc/ dir of the standard IPA, but I'm not sure it's the best way (or if even it will work) after reading the scripts and patches in the freeipa-container' GitHub. Maybe it would be better to mimic the behaviour of the containerised IPA (leaving my files in a /data dir and modification of SYSCONFDIR in authconfig). Maybe an other way could be to declare my new IPA as a replica of the containerised one.. Did someone has an idea how I can do this? Thank you for your inputs ! Pierre-Marie

2 2

CLI commands to unprovision a host, then set one time password?
by Bo Lind 07 Aug '20

07 Aug '20

We have a workflow where we sometimes reinstall enrolled hosts. The role of the host does not change, IP, hostname etc. stay unchanged. Our current workflow is to enter the GUI, select unprovision, set a one time password, and then enroll the freshly installed host. Do command line tools exist that can handle these two steps? Alternatively, is there a better way to achieve what we want?

2 1

rlm_ldap fails to extract user groups but ldapsearch succeeds
by Victor 06 Aug '20

06 Aug '20

Hello, Everything is set up on the same machine as described here: https://www.freeipa.org/page/Using_FreeIPA_and_FreeRadius_as_a_RADIUS_based… I'm trying to check whether a user belongs to a group or not: (0) if (LDAP-Group == "someusers") { (0) Searching for user in group "someusers" rlm_ldap (ldap): Reserved connection (6) (0) Using user DN from request "uid=common_user,cn=users,cn=accounts,dc=domain,dc=local" (0) Checking for user in group objects (0) EXPAND (&(cn=someusers)(|(&(uid=%{%{Stripped-User-Name}:-%{User-Name}})(memberOf=cn=someusers,cn=groups,cn=accounts,dc=domain,dc=local)))) (0) --> (&(cn=someusers)(|(&(uid=common_user)(memberOf=cn=someusers,cn=groups,cn=accounts,dc=domain,dc=local)))) (0) Performing search in "uid=common_user,cn=users,cn=accounts,dc=domain,dc=local" with filter "(&(cn=someusers)(|(&(uid=common_user)(memberOf=cn=someusers,cn=groups,cn=accounts,dc=domain,dc=local))))", scope "sub" (0) Waiting for search result... (0) Search returned no results (0) Checking user object's memberOf attributes (0) Performing unfiltered search in "uid=common_user,cn=users,cn=accounts,dc=domain,dc=local", scope "base" (0) Waiting for search result... (0) No group membership attribute(s) found in user object rlm_ldap (ldap): Released connection (6) but ldapsearch -b "dc=domain,dc=local" "(&(cn=someusers)(member=uid\3dcommon_user\2ccn\3dusers\2ccn\3daccounts\2cdc\3ddomain\2cdc\3dlocal))" -D uid=common_user,cn=users,cn=accounts,dc=domain,dc=local -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=domain,dc=local> with scope subtree # filter: (&(cn=someusers)(member=uid\3dcommon_user\2ccn\3dusers\2ccn\3daccounts\2cdc\3ddomain\2cdc\3dlocal)) # requesting: ALL # # someusers, groups, accounts, domain.local dn: cn=someusers,cn=groups,cn=accounts,dc=domain,dc=local objectClass: top objectClass: groupofnames objectClass: nestedgroup objectClass: ipausergroup objectClass: ipaobject description: Default group for all users cn: someusers ipaUniqueID: ebca3046-a5a0-11ea-8166-9a6e275fb41f member: uid=common_user,cn=users,cn=accounts,dc=domain,dc=local member: uid=very_special_user,cn=users,cn=accounts,dc=domain,dc=local # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 and ldapsearch -b "uid=common_user,cn=users,cn=accounts,dc=domain,dc=local" -D uid=common_user,cn=users,cn=accounts,dc=domain,dc=local -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base <uid=common_user,cn=users,cn=accounts,dc=domain,dc=local> with scope subtree # filter: (objectclass=*) # requesting: ALL # # common_user, users, accounts, domain.local dn: uid=common_user,cn=users,cn=accounts,dc=domain,dc=local displayName: utilisateur banal uid: common_user krbCanonicalName: common_user(a)DOMAIN.LOCAL objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry objectClass: ipauserauthtypeclass loginShell: /bin/bash initials: ub gecos: utilisateur banal sn: banal homeDirectory: /home/common_user mail: common_user(a)domain.local krbPrincipalName: common_user(a)DOMAIN.LOCAL givenName: utilisateur cn: utilisateur banal ipaUniqueID: some_unique_ID uidNumber: theSameNumber gidNumber: theSameNumber krbPasswordExpiration: the_pass_exp krbLastPwdChange: the_pass_exp memberOf: cn=someusers,cn=groups,cn=accounts,dc=domain,dc=local memberOf: cn=manyemoreusers,cn=groups,cn=accounts,dc=domain,dc=local ipaUserAuthType: o_type ipaSshPubKey: some_pubkey # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Some of the configuration: /etc/raddb/sites-enabled/default ... user { base_dn = "${..base_dn}" filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})" sasl { } } group { base_dn = 'uid=common_user,cn=users,cn=accounts,dc=domain,dc=local' scope = 'sub' membership_filter = "(|(&(uid=%{%{Stripped-User-Name}:-%{User-Name}})(memberOf=${..ldapgroup})))" membership_attribute = 'memberOf' } /etc/raddb/mods-enabled/ldap ... post-auth { update { &reply: += &session-state: } -sql exec remove_reply_message_if_eap Post-Auth-Type REJECT { -sql attr_filter.access_reject eap remove_reply_message_if_eap } Post-Auth-Type Challenge { } if (LDAP-Group == "someusers") { update { reply:Class := "OKOKOKOKOK" } } else { update { reply:Class := "NONONONONO" } } } Where to go from here? Kind regards

3 5

Re: pki-tomcatd not starting
by Florence Blanc-Renaud 05 Aug '20

05 Aug '20

On 8/3/20 10:14 PM, Scott Z. via FreeIPA-users wrote: > Not sure I'm sending this to the right place, but here it goes.Â I > inherited a FreeIPA/Identity Manager setup in an enclave (no internet > access) environment that is running into problems.Â There are at least 3 > different IdM servers running in the environment spread out across > different geographical areas.Â One of those areas suffered an unschedule > power outage recently, and ever since we brought everything back up, the > IdM server for this region is having an issue.Â Please bear with me as I > have zero formal experience, training, or real knowledge with IdM. > > Logging in to the serverv (it's a VM server, running Centos 7.5), I run > "ipactl status" and it shows "Directory Service: STOPPED".Â I then run > "ipactl restart", and things go fine until it gets to "Starting > pki-tomcatd Service", where it hangs for quite some time before failing > to start and killing all the other services.Â I check the log at > /var/log/pki/pki-tomcat/ca/debug and I see various errors such as > (forgive any mistypings, I have to manually type these in as I can't > import or screen capure the logs and put them in this message): > "/java.lang.Exception: Certificate Server-Cert cert-pki-ca is invalid: > Invalid certificate: (-8181) Peer's Certificate has expired/" > And slightly further down in the same log: > "/Cannot reset factory: connections not all returned/" > "/CertificateAuthority.shutdown: failed to reset dbFactory: Cannot reset > LDAP connection factory because some connections are still outstanding/" > ... still further down" > "/returnConn:mNumConns now 3 Invalid class name repositorytop/" > > Assuming I have some weird certificate issue with this server in > particular, I try to run a few more commands: > "certutil -L -d /etc/httpd/alias"Â --> returns a Server-Cert listing > with u,u,u as it's trust attributes, and <IDM.domain> IPA CA with CT,C,C > for it's attributes.Â Comparing to a second IdM server in this > environment, it seems to be missing a "Signing-Cert"? > Hi, PKI is using the NSSDB in /etc/pki/pki-tomcat/alias, and its server cert has the nickname 'Server-Cert cert-pki-ca'. You should check that this one is not expired with: # certutil -L -d /etc/pki/pki-tomcat/alias -n 'Server-Cert cert-pki-ca' | grep 'Not ' If the certificate is indeed expired, it will have to be renewed but you need first to find which IPA server is the CA renewal master. On your server, force a service start and check the CA renewal master: # ipactl start --ignore-service-failures # kinit admin # ipa config-show | grep "renewal master" IPA CA renewal master: server.domain.com You need to make sure that all the certificates are valid on the CA renewal master: (on the CA renewal master)# getcert list | grep -E "Request|certificate:|expires:" - if the CA renewal master is not OK, please post the output of "# getcert list" (without the grep) on the CA renewal master. This node will have to be repaired first. - if the CA renewal master is OK, please post the output of "# getcert list" (also without the grep) on the failing node. We'll be able to help based on this information. flo > I also did a "getcert list", and all certs it has show that they expire > in the future (nothing shows as bein currently expired). > > I'm confused; it seems to that it is seeing an expired cert *somewhere*, > but how do I track down which 'peer' the log file is talking about that > has an expired cert?Â Meanwhile none of the linux clients that point to > this IdM server are allowing people to log in/authenticate. > Many thanks for any help! > Scott > > > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org > 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/freeipa-users@lists.fedorahost… >

2 1

trouble running ipa-server-update
by Fujisan 05 Aug '20

05 Aug '20

I upgraded my FreeIPA server to F31 and when running ipa-server-update, I get and error message: # ipa-server-upgrade Upgrading IPA:. Estimated time: 1 minute 30 seconds [1/11]: stopping directory server [2/11]: saving configuration [3/11]: disabling listeners [4/11]: enabling DS global lock [5/11]: disabling Schema Compat [6/11]: starting directory server [7/11]: updating schema [8/11]: upgrading server [9/11]: stopping directory server [10/11]: restoring configuration [11/11]: starting directory server Done. Update complete Upgrading IPA services Upgrading the configuration of the IPA services Disabled p11-kit-proxy [Verifying that root certificate is published] [Migrate CRL publish directory] CRL tree already moved [Verifying that KDC configuration is using ipa-kdb backend] [Fix DS schema file syntax] Syntax already fixed [Removing RA cert from DS NSS database] RA cert already removed [Enable sidgen and extdom plugins by default] [Updating HTTPD service IPA configuration] [Updating HTTPD service IPA WSGI configuration] [Migrating from mod_nss to mod_ssl] Already migrated to mod_ssl [Moving HTTPD service keytab to gssproxy] [Removing self-signed CA] [Removing Dogtag 9 CA] [Checking for deprecated KDC configuration files] [Checking for deprecated backups of Samba configuration files] [Remove FILE: prefix from 'dedicated keytab file' in Samba configuration] [Update 'max smbd processes' in Samba configuration to prevent unlimited SMBLoris attack amplification] [Add missing CA DNS records] IPA CA DNS records already processed [Removing deprecated DNS configuration options] [Ensuring minimal number of connections] [Updating GSSAPI configuration in DNS] [Updating pid-file configuration in DNS] [Checking global forwarding policy in named.conf to avoid conflicts with automatic empty zones] Changes to named.conf have been made, restart named [Upgrading CA schema] CA schema update complete (no changes) [Verifying that CA audit signing cert has 2 year validity] [Update certmonger certificate renewal configuration] Certmonger certificate renewal configuration already up-to-date [Enable PKIX certificate path discovery and validation] PKIX already enabled [Authorizing RA Agent to modify profiles] [Authorizing RA Agent to manage lightweight CAs] [Ensuring Lightweight CAs container exists in Dogtag database] [Adding default OCSP URI configuration] [Disabling cert publishing] [Ensuring CA is using LDAPProfileSubsystem] [Migrating certificate profiles to LDAP] IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. Unexpected error - see /var/log/ipaupgrade.log for details: RemoteRetrieveError: Failed to authenticate to CA REST API The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information The end of file /var/log/ipaupgrade.log shows the following: [...] 2020-08-04T08:46:11Z DEBUG request body '' 2020-08-04T08:46:12Z DEBUG response status 500 2020-08-04T08:46:12Z DEBUG response headers Content-Type: text/html;charset=utf-8 Content-Language: en Content-Length: 2234 Date: Tue, 04 Aug 2020 08:46:12 GMT Connection: close 2020-08-04T08:46:12Z DEBUG response body (decoded): b'<!doctype html><html lang="en"><head><title>HTTP Status 500 \xe2\x80\x93 Internal Server Error</title><style type="text/css">body {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b {color:white;background-color:#525D76;} h1 {font-size:22px;} h2 {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {color:black;} .line {height:1px;background-color:#525D76;border:none;}</style></head><body><h1>HTTP Status 500 \xe2\x80\x93 Internal Server Error</h1><hr class="line" /><p><b>Type</b> Exception Report</p><p><b>Message</b> CA subsystem unavailable. Check CA debug log.</p><p><b>Description</b> The server encountered an unexpected condition that prevented it from fulfilling the request.</p><p><b>Exception</b></p><pre>javax.ws.rs.ServiceUnavailableException: CA subsystem unavailable. Check CA debug log.\n\tcom.netscape.cms.tomcat.ProxyRealm.validateRealm(ProxyRealm.java:81)\n\tcom.netscape.cms.tomcat.ProxyRealm.findSecurityConstrai nts(ProxyRealm.java:149)\n\torg.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:530)\n\tcom.netscape.cms.tomcat.ExternalAuthenticationValve.invoke(ExternalAuthenticationValve.java:82)\n\torg.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)\n\torg.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:690)\n\torg.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)\n\torg.apache.coyote.http11.Http11Processor.service(Http11Processor.java:373)\n\torg.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)\n\torg.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)\n\torg.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1590)\n\torg.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)\n\tjava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tjava.util.concurrent.T hreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\torg.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)\n\tjava.lang.Thread.run(Thread.java:748)\n</pre><p><b>Note</b> The full stack trace of the root cause is available in the server logs.</p><hr class="line" /><h3>Apache Tomcat/9.0.36</h3></body></html>' 2020-08-04T08:46:12Z ERROR IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. 2020-08-04T08:46:12Z DEBUG File "/usr/lib/python3.7/site-packages/ipapython/admintool.py", line 179, in execute return_value = self.run() File "/usr/lib/python3.7/site-packages/ipaserver/install/ipa_server_upgrade.py", line 54, in run server.upgrade() File "/usr/lib/python3.7/site-packages/ipaserver/install/server/upgrade.py", line 2280, in upgrade upgrade_configuration() File "/usr/lib/python3.7/site-packages/ipaserver/install/server/upgrade.py", line 2149, in upgrade_configuration ca_enable_ldap_profile_subsystem(ca) File "/usr/lib/python3.7/site-packages/ipaserver/install/server/upgrade.py", line 414, in ca_enable_ldap_profile_subsystem cainstance.migrate_profiles_to_ldap() File "/usr/lib/python3.7/site-packages/ipaserver/install/cainstance.py", line 1943, in migrate_profiles_to_ldap _create_dogtag_profile(profile_id, profile_data, overwrite=False) File "/usr/lib/python3.7/site-packages/ipaserver/install/cainstance.py", line 1949, in _create_dogtag_profile with api.Backend.ra_certprofile as profile_api: File "/usr/lib/python3.7/site-packages/ipaserver/plugins/dogtag.py", line 1315, in __enter__ raise errors.RemoteRetrieveError(reason=_('Failed to authenticate to CA REST API')) 2020-08-04T08:46:12Z DEBUG The ipa-server-upgrade command failed, exception: RemoteRetrieveError: Failed to authenticate to CA REST API 2020-08-04T08:46:12Z ERROR Unexpected error - see /var/log/ipaupgrade.log for details: RemoteRetrieveError: Failed to authenticate to CA REST API 2020-08-04T08:46:12Z ERROR The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information I check the certificate in the NSS database (as I've seen in this thread https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost…) but got an error as well. # certutil -L -d /etc/httpd/alias -n ipaCert certutil: function failed: SEC_ERROR_BAD_DATABASE: security library: bad database. And retrieving the certificate with ldapsearch gives the following (redacted): # ldapsearch -D "cn=directory manager" -W -b o=ipaca -LLL -o ldif-wrap=no "(uid=ipara)" usercertificate description Enter LDAP Password: dn: uid=ipara,ou=people,o=ipaca usercertificate:: MIIDazCCAlOgAwIBAgIBBzANBgkqhkiG9w0... description: 2;7;CN=Certificate Authority,O=MYDOMAIN.LOCAL;CN=IPA RA,O=MYDOMAIN.LOCAL Is the ipa-server-update error message linked to the certutil error? How can I import the correct certificate in the /etc/httpd/alias NSS database?

3 7

pack two exisiting ipa server on one system
by Boris Behrens 05 Aug '20

05 Aug '20

Hi, upfront: please don't judge our setup. I know that the concept is an issue :-( I have two freeipa servers which are running on an old operating system (Fedora26) and I want to migrate it to centos8. Because there are not enough resources in our mgmt cluster I need to shut one of them down and reinstall with the new OS (while keeping the name), let them sync and so on. But here is the issue: We have systems that talk only to ipa1 and systems that talk only to ipa2. I would like to add the IP address of ipa2 to ipa1 and then proceed with the migration. There is no option to make changes to those systems. They will get removed from our infrastructure but this may take another year, and I don't want to wait any longer with the migration. Is this even possible? I can think of problems with certificates that say "I am ipa1" when a systems asks expects ipa2 to answer. I would be really nice if someone could help me solve the problem. -- Die Selbsthilfegruppe "UTF-8-Probleme" trifft sich diesmal abweichend im groÃƒ¼en Saal.

2 3

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users August 2020