search

freeipa / freeipa-healthcheck

Check the health of a freeIPA installation
GNU General Public License v3.0
50 stars 28 forks source link

Certificate 'caSigningCert cert-pki-ca' does not match the value of ca.signing.cert in /var/lib/pki/pki-tomcat/ca/conf/CS.cfg #154

Closed jimr6007 closed 2 years ago

jimr6007 commented 4 years ago

CentOS Linux release 8.2.2004 (Core) ipa-server.x86_64 4.8.4-7.module_el8.2.0+374+0d2d74a1 ipa-healthcheck.noarch 0.4-4.module_el8.2.0+374+0d2d74a1

Two servers in the topology

I have a couple of questions, maybe issues, not sure if something is broken and I need to fix?

For one of the them: CRL generation: disabled And the other: CRL generation: enabled Last CRL update: 2020-10-27 17:00:00 Last CRL Number: 12207

Question 1: Should I have a different/separate/multiple caSigningCert cert-pki-ca Requests being tracked, shouldn't there just be one in the whole topology/cluster?

Question 2: Why is "ipa-healthcheck --failures-only" saying this when I have a default self signed setup:

Getting signing cert info for ca from CS.cfg PLACEIQ.NET IPA CA not found, assuming 3rd party Directory Server CA certificate not found, assuming 3rd party PLACEIQ.NET IPA CA not found, assuming 3rd party Directory Server CA certificate not found, assuming 3rd party

Question 3: Why am I getting these TWO errors and how should I clean them up?

[ { "source": "pki.server.healthcheck.meta.csconfig", "check": "DogtagCertsConfigCheck", "result": "ERROR", "uuid": "85239fcf-31bb-409e-8f8d-c550384ab23a", "when": "20201027204653Z", "duration": "0.190002", "kw": { "key": "ca_signing", "nickname": "caSigningCert cert-pki-ca", "directive": "ca.signing.cert", "configfile": "/var/lib/pki/pki-tomcat/ca/conf/CS.cfg", "msg": "Certificate 'caSigningCert cert-pki-ca' does not match the value of ca.signing.cert in /var/lib/pki/pki-tomcat/ca/conf/CS.cfg" } },

"source": "ipahealthcheck.dogtag.ca", "check": "DogtagCertsConfigCheck", "result": "ERROR", "uuid": "f675a1d1-d497-454f-8eaf-3527219b8613", "when": "20201027204653Z", "duration": "0.084322", "kw": { "key": "caSigningCert cert-pki-ca", "directive": "ca.signing.cert", "configfile": "/var/lib/pki/pki-tomcat/conf/ca/CS.cfg", "msg": "Certificate 'caSigningCert cert-pki-ca' does not match the value of ca.signing.cert in /var/lib/pki/pki-tomcat/conf/ca/CS.cfg" }

"getcert list" shows the following when run on each server.

server 1:

Request ID '20201025194015': 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=PLACEIQ.NET subject: CN=Certificate Authority,O=PLACEIQ.NET expires: 2040-10-27 04:24:15 UTC key usage: digitalSignature,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

server 2:

Request ID '20201027055643': 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=PLACEIQ.NET subject: CN=Certificate Authority,O=PLACEIQ.NET expires: 2040-10-27 04:24:15 UTC key usage: digitalSignature,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

rcritten commented 4 years ago

  1. One of those tracking requests, on the renewal master, will do the actual renewal. The others will fetch the updates certificates over LDAP. The CA's are all clones of one another and must have the same set of keys and certificates to work.

  2. I'd guess that your Apache and 389 certificates are not issued by IPA. healthcheck is determining that two certificates aren't signed by the PLACEIQ.NET CA.

  3. The CA server is working on providing its own set of healthchecks that can be run independently of IPA and there is some overlap. They are both reporting the same thing.

I don't know why but the CA stores a copy of the public certificate in its configuration file. This is healtcheck determining that it doesn't match. I'm not completely sure if this is an issue for the CA certificate itself.

@cipherboy, @edewater should he update CS.cfg with current value?

rcritten commented 2 years ago

We seem to have lost traction on this. It is my understanding that the certificates not matching the values in CS.cfg is not a critical problem. It is checked to ensure consistency.