Jochen Kellner via FreeIPA-users wrote: > > Hi, > > I've been running IPA on CentOS 7 for some time on two servers with > integrated CA. With the release of CentOS 8.1 I tried upgrading with a > second replica - but scrapped that due to the problem with the wrong > samba libraries linked. Since no fix is in sight I thought about > migrating to Fedora 32 instead - which I've started yesterday. > > Topology: > freeipa1 + freeipa2: CentOS Linux release 7.8.2003 (Core) (upgrade from > older CentOS 7 releases) > DNS, CA, KRA, AD trust > freeipa1 is CA renewal master > > freeipa3: current Fedora 32 with the same services, ipa-replica-install > has chosen freeipa2 to replicate from. I've manually added an aditional > replica agreement betwen freeipa1 and freeipa3. > > WebUI works, ipactl status is RUNNING, I get kerberos tickets, so I > guess we are most likely ok. Replication is also fine. > > Before I start decomissioning freeipa2 I checked ipa-healthcheck: > $ ipa-healthcheck --output-type human --failures-only > > ERROR: > pki.server.healthcheck.meta.csconfig.DogtagCertsConfigCheck.kra_transport: > Certificate 'transportCert cert-pki-kra' does not match the value of > kra.transport.cert in /var/lib/pki/pki-tomcat/kra/conf/CS.cfg > ERROR: > pki.server.healthcheck.meta.csconfig.DogtagCertsConfigCheck.kra_storage: > Certificate 'storageCert cert-pki-kra' does not match the value of > kra.storage.cert in /var/lib/pki/pki-tomcat/kra/conf/CS.cfg > ERROR: > pki.server.healthcheck.meta.csconfig.DogtagCertsConfigCheck.kra_audit_signing: > Certificate 'auditSigningCert cert-pki-kra' does not match the value of > kra.audit_signing.cert in /var/lib/pki/pki-tomcat/kra/conf/CS.cfg > ERROR: ipahealthcheck.dogtag.ca.DogtagCertsConfigCheck.transportCert > cert-pki-kra: Certificate 'transportCert cert-pki-kra' does not match the > value of ca.connector.KRA.transportCert in > /var/lib/pki/pki-tomcat/conf/ca/CS.cfg > WARNING: ipahealthcheck.ipa.dna.IPADNARangeCheck: No DNA range defined. If no > masters define a range then users and groups cannot be created. > > The warning is ok and I know how to deal with that. But for the errors > my expactation was that I shouldn't get any certificate errors on a new > replica. I've checked the certs/log (here for transportCert only): > > args=['/usr/bin/certutil', '-d', 'sql:/etc/pki/pki-tomcat/alias', '-L', '-n', > 'transportCert cert-pki-kra', '-a', '-f', > '/etc/pki/pki-tomcat/alias/pwdfile.txt'] > Process finished, return code=0 > stdout=-----BEGIN CERTIFICATE----- > MIIDdDCCAlygAwIBAgIED/0AUjANBgkqhkiG9w0BAQsFADA1MRMwEQYDVQQKDApK > ... > LjQX6mD/oR3hZnmE920+ABhk8QcJaRoi > -----END CERTIFICATE----- > > And: > > kra.transport.cert= > MIIDdDCCAlygAwIBAgIED/wABTANBgkqhkiG9w0BAQsFADA1MRMwEQYDVQQKDApK > T0NIRU4uT1JHMR4wHAYDVQQDDBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTcx > ^first diff > [other changes...] > Some lines identical > [more differences]. > > So, ipa-healtcheck seems to be right. What's the best way to fix it? And > why is a fresh replica not clean?
I think we'd need a bit more context. Is T0N a new line/entry, separate from MII? If so I'd run that through a base64 decoder to see what you get. I suspect it is a double-encoded cert. And if it is, what cert is it? rob _______________________________________________ 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]
