Re: pki-tomcatd not starting
by Rob Crittenden
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.fedoraho...
>>>
>>
>>
>> _______________________________________________
>> 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.fedoraho...
>>
>
>
> _______________________________________________
> 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.fedoraho...
>
3 years, 9 months
Re: pki-tomcatd not starting
by Florence Blanc-Renaud
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.fedoraho...
>>>
>>
>>
>> _______________________________________________
>> 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.fedoraho...
>>
>
>
> _______________________________________________
> 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.fedoraho...
>
3 years, 9 months
Re: pki-tomcatd not starting
by Florence Blanc-Renaud
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.fedoraho...
>>
>
>
> _______________________________________________
> 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.fedoraho...
>
3 years, 9 months
IPA Server with multiple Networks with different Domains
by julian jost
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
3 years, 9 months
Migrate data from a containerised IPA
by Pierre-Marie Besserer
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
3 years, 9 months
CLI commands to unprovision a host, then set one time password?
by Bo Lind
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?
3 years, 9 months
rlm_ldap fails to extract user groups but ldapsearch succeeds
by Victor
Hello,
Everything is set up on the same machine as described here:
https://www.freeipa.org/page/Using_FreeIPA_and_FreeRadius_as_a_RADIUS_bas...
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 years, 9 months
Re: pki-tomcatd not starting
by Florence Blanc-Renaud
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.fedoraho...
>
3 years, 9 months
trouble running ipa-server-update
by Fujisan
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.fedoraho...) 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 years, 9 months
pack two exisiting ipa server on one system
by Boris Behrens
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.
3 years, 9 months