RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 750529 - Doc CS replication errors to avoid user from facing unexpected problems
Summary: Doc CS replication errors to avoid user from facing unexpected problems
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Martin Kosek
QA Contact: IDM QE LIST
URL:
Whiteboard:
Depends On:
Blocks: 750596 756082
TreeView+ depends on / blocked
 
Reported: 2011-11-01 13:52 UTC by Namita Soman
Modified: 2015-01-19 20:51 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 750596 (view as bug list)
Environment:
Last Closed: 2015-01-16 12:09:52 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Namita Soman 2011-11-01 13:52:48 UTC
Description of problem:
After CS replication is removed, replica can see a new host is issued a cert, but doesn't have a copy of it, and throws a serial number error.

In response to a test case to do this, Rob's response:
I wonder if we should doc this. What is happening is the host is
replicating through a different channel, so we can see it. Because the
CS replication was removed we can see that the host has been issued a
valid certificate from our CA but our local install doesn't have a copy
of it, hence the serial # error.

This and a few others point out some pretty scary problems related to
certificate replication, this isn't something people should take lightly.

Version-Release number of selected component (if applicable):
ipa-server-2.1.3-6.el6.x86_64


How reproducible:
always

Steps to Reproduce:
1.Install master, replica
2.Install CS server on replica
3.Delete the replication agreement, and the data from replica
# ipa-csreplica-manage del ipa-replica1.testrelm -p XXX
4. Add a host, add cert to a host from master
5. Check settings for this host from replica
  
Actual results:
Error that host’s cert cannot be found:
Certificate operation cannot be completed: EXCEPTION (Certificate serial number 0x2d not found)

Expected results:
if this is doc'd, the user will know to check CS replication, and be prepared.

Additional info:

Comment 2 Dmitri Pal 2011-11-01 17:47:53 UTC
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/2047

Comment 3 Rob Crittenden 2011-11-01 19:04:44 UTC
Here is a clearer way than I explained earlier.

You have IPA server A and server B, both have a dogtag CA installed.

There is a replication agreement between A and B for user, group, host, etc.
data

There is also a replication agreement between A and B because they both have a
CA. This link shares the certificates issued between the two CAs.

If you break the dogtag replication agreement between the two they will still
share the other IPA data.

So if you issue a certificate for a host or service on host A then host B will
not know about that certificates by serial number. The reverse is true as well.
This is because there is no replication agreement between the CAs.

Comment 7 Martin Kosek 2015-01-16 12:09:52 UTC
ipa-csreplica-manage and ipa-replica-manage already warn if last replication link is being created. I thus do not think this is no longer an issue.

Some of the fixes were done for example in
https://fedorahosted.org/freeipa/ticket/2858

I am thus closing thus bug.


Note You need to log in before you can comment on or make changes to this bug.