Bug 1417766

Summary:	ipa-replica-install fails on CA import "java.lang.Exception: Certificate caSigningCert cert-pki-ca is invalid: Invalid certificate: (-8179) Peer's Certificate issuer is not recognized"
Product:	Red Hat Enterprise Linux 8	Reporter:	Amy Farley <afarley>
Component:	pki-core	Assignee:	Fraser Tweedale <ftweedal>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	Asha Akkiangady <aakkiang>
Severity:	urgent	Docs Contact:
Priority:	urgent
Version:	8.3	CC:	ascheel, bugsredhat, edewata, f.giannoccaro, frenaud, gparente, mharmsen, mrhodes, msauton, pvoborni, rcritten, tscherf
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-02-26 13:27:27 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Amy Farley 2017-01-30 22:25:08 UTC

Description of problem:

After having a cert renewal failure on 7.2 master (due to loss of tracking on all certs), this replica was promoted and then used to renew its own certs.

It has been failing to install replicas, with issues stemming from what seems to be an extra ldap certificate?

Version-Release number of selected component (if applicable):

ipa-server-dns-4.4.0-14.el7_3.4.noarch
ipa-server-common-4.4.0-14.el7_3.4.noarch
ipa-common-4.4.0-14.el7_3.4.noarch
ipa-client-common-4.4.0-14.el7_3.4.noarch
sssd-ipa-1.14.0-43.el7_3.11.x86_64
ipa-admintools-4.4.0-14.el7_3.4.noarch
ipa-client-4.4.0-14.el7_3.4.x86_64
ipa-server-4.4.0-14.el7_3.4.x86_64

# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.2 (Maipo)
-- This was updated to latest IPA packages, but it did not update the base RHEL as part of the yum update ipa-server

Comment 22 Endi Sukma Dewata 2017-02-07 16:07:53 UTC

https://fedorahosted.org/pki/ticket/2587

Comment 23 Francesco Giannoccaro 2017-02-08 18:45:51 UTC

Thanks for the clarification about the change on the DN encoding.

From our prospective the troubleshooting process we went through in the last few weeks made clear that taking the faulty IPA systems to a stable and reliable status is very difficult if even not possible at all.
 
We have decided to perform an installation from scratch of a new IPA environment to reduce the risk in future of having same issue or other related issues. 

A short summary of the step we are currently following is:

1. perform a fresh install of IdM/IPA, and instead of setting the Winsync using Trust configuration 

2. create new domain as a subdomain of our corporate Windows AD (unix.phe.gov.uk)

3. sign the IdM/IPA root CA cert with the PHE AD root CA cert, so that clients can have a valid trust path for IdM/IPA issues certs

4. create a one way trust from the IdM/IPA to the PHE AD so that existing AD users can authenticate to IDM

5. run both IPA systems in parallel (the faulty and new one) and migrate things over in a controlled manor

Once we'll complete all the above step and all clients will be successfully migrated to the new IPA, we are keen to help - if you think it could be any how useful to resolve this bug - with performing further tests or apply patch to our faulty IPA system to test possible solution (maybe useful for other users).

Comment 24 Marc Sauton 2017-02-10 23:18:47 UTC

for the workaround the the CA's CS.cfg, note the order may be important:
X500Name.directoryStringEncodingOrder=UTF8String,PrintableString,T61String,BMPString,UniversalString
versus
X500Name.directoryStringEncodingOrder=PrintableString,UTF8String,T61String,BMPString,UniversalString
may not have the same effect

Comment 25 Petr Vobornik 2017-02-17 16:55:55 UTC

*** Bug 1415852 has been marked as a duplicate of this bug. ***

Comment 26 Matthew Harmsen 2017-10-25 21:13:49 UTC

[20171025] - RHEL 7.5 pre-Alpha Offline Triage ==> 7.6

Comment 27 Matthew Harmsen 2018-04-27 01:30:02 UTC

Per RHEL 7.5.z/7.6/8.0 Triage:  7.6

alee: looks like it was tied to a customer case.  Need to confirm if this case is active.