Hi, On Tue, Sep 17, 2024 at 8:23 PM Dungan, Scott A. <[email protected]> wrote:
> Found some more information. On the server with the warning, the > certificate is found in ipa-getcert list: > > > > Request ID '20210406002321': > > status: MONITORING > > stuck: no > > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-IPA-DOMAIN-COM',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd- IPA-DOMAIN-COM/pwdfile.txt' > > certificate: type=NSSDB,location='/etc/dirsrv/slapd- > IPA-DOMAIN-COM ',nickname='Server-Cert',token='NSS Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=IPA.DOMAIN.COM > > subject: CN=idm3.id.gps.caltech.edu,O=IPA.DOMAIN.COM > > issued: 2022-10-15 17:49:50 PDT > > expires: 2024-10-15 17:49:50 PDT > > dns: ipa3.ipa.domain.com > > principal name: ldap/[email protected] > > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > eku: id-kp-serverAuth,id-kp-clientAuth > > profile: caIPAserviceCert > > pre-save command: > > post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv > IPA-DOMAIN-COM > > track: yes > > auto-renew: yes > > > > The other two servers have “Server-Cert” in their ipa-getcert list output, > but they have different expiration dates and request IDs. I am not sure if > this is expected. Since the above is set to auto-renew, can we ignore it? > Can we force renew now to clear the healthcheck error? > The Server-Cert for LDAP is specific to each replica (the subject contains the hostname), it's perfectly normal that each server has a different one with a different expiration date. You can either wait for certmonger to automatically renew this cert (by default it will try 28 days before expiration, unless you specified a different value in /etc/certmonger/certmonger.conf) or trigger the renewal in advance using "getcert resubmit -i 20210406002321". Please note that the renewal will restart the LDAP server. If you decide to force the renewal, you can check if everything went smoothly with "getcert list -i 20210406002321". The "status" field will transition to various states (see https://pagure.io/certmonger/blob/master/f/doc/design.txt) before it goes back to MONITORING. flo > > > Thanks! > > > > *From:* Dungan, Scott A. > *Sent:* Tuesday, September 17, 2024 9:09 AM > *To:* Florence Blanc-Renaud <[email protected]> > *Cc:* FreeIPA ([email protected]) < > [email protected]> > *Subject:* RE: [Freeipa-users] Heathcheck error: expiring unused external > CA > > > > Thank you, Flo. The “ipa-cacert-manage delete …” command, followed by > “ipa-certupdate” removed the invalid CA entries from the IPA servers > (verified by looking at /etc/ipa/ca.crt). We also ran ipa-cartupdate on all > enrolled clients. > > > > One issue: We have three IPA servers. On two, healthcheck completes > without error or warnings, but on one server healthcheck reports: > > > > [ > > { > > "source": "ipahealthcheck.ds.nss_ssl", > > "check": "NssCheck", > > "result": "ERROR", > > "uuid": "2537646d-88d9-4d26-8a38-dd445f1250bd", > > "when": "20240917154901Z", > > "duration": "0.390482", > > "kw": { > > "key": "DSCERTLE0001", > > "items": [ > > "Expiring Certificate" > > ], > > "msg": "The certificate (Server-Cert) will expire in less than 30 > days" > > } > > } > > ] > > > > ipa-cacert-manage list on that server only shows the single internal CA as > expected, and /etc/ipa/ca.crt has one entry. Can you advise how to find > this ghost “Server-Cert” that healthcheck finds on only one server? > > > > > > > > *From:* Florence Blanc-Renaud <[email protected]> > *Sent:* Tuesday, September 17, 2024 12:02 AM > *To:* FreeIPA users list <[email protected]> > *Cc:* Dungan, Scott A. <[email protected]> > *Subject:* Re: [Freeipa-users] Heathcheck error: expiring unused external > CA > > > > Hi, > > > > On Mon, Sep 16, 2024 at 11:36 PM Dungan, Scott A. via FreeIPA-users < > [email protected]> wrote: > > Running ipa-server version 4.9.13-12 on RHEL8 we are getting the following > error/warning with ipa-healthcheck: > > [ > > { > > "source": "ipahealthcheck.ds.nss_ssl", > > "check": "NssCheck", > > "result": "ERROR", > > "uuid": "1a2798fd-7fa5-4132-a288-7975f2c32b60", > > "when": "20240916211906Z", > > "duration": "0.498443", > > "kw": { > > "key": "DSCERTLE0001", > > "items": [ > > "Expiring Certificate" > > ], > > "msg": "The certificate (CN=InCommon RSA Server > CA,OU=InCommon,O=Internet2,L=Ann Arbor,ST=MI,C=US) will expire in less than > 30 days" > > } > > }, > > { > > "source": "ipahealthcheck.ipa.certs", > > "check": "IPACAChainExpirationCheck", > > "result": "WARNING", > > "uuid": "7c1317a8-fbf6-46c4-98a1-15b62f655df8", > > "when": "20240916211911Z", > > "duration": "0.014042", > > "kw": { > > "path": "/etc/ipa/ca.crt", > > "key": "CN=InCommon RSA Server CA,OU=InCommon,O=Internet2,L=Ann > Arbor,ST=MI,C=US", > > "days": 19, > > "msg": "CA '{key}' in {path} is expiring in {days} days." > > } > > } > > ] > > > > This is the external commercial CA that I believe was added at the > inception of the domain to allow for trusted user connections to the web UI > for self-service. That was reverted back to using an internal certificate > for the web UI more than three years ago, so the InCommon CA is no longer > required. > > > > The tool "ipa-cacert-manage delete NICKNAME" can help you remove this CA. > You can start with "ipa-cacert-manage list" which will print out the > nicknames, identify the nickname used for your CA to remove, then use > "ipa-cacert-manage delete NICKNAME". > > Note: after the removal, ipa-certupdate needs to be run on each machine > enrolled in the IPA domain in order to update the trusted CA list (for > instance in /etc/ipa/ca.crt or in the NSS databases). > > > > flo > > > > > > Running getcert list shows that certmonger is not tracking either the CA > (which makes sense), nor any certificates issued by the CA. ipa cert-find > shows 50 certificates all issued by the internal IPA CA. > > > > I would like to remove all references to the old CA from IPA and resolve > the healthcheck error. Any help would be appreciated. > > > > > > -- > _______________________________________________ > FreeIPA-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/[email protected] > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > >
-- _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
