Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite 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 "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. 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 "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-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.
The ABRT plugin requires that managed hosts talk with the smart-proxy using SSL client authentication.
In upstream Foreman, smart-proxy uses Puppet certificates, and the managed hosts can connect to it and authenticate using their Puppet own certificate. In Sat6, however, a set of certificates dedicated to smart-proxy<->Foreman communication seems to be used, with it's own self-signed CA certificate. This means that the hosts cannot authenticate to smart-proxy as their certificates were signed by different CA (and furthermore they don't trust the smart-proxy's certificate because they don't know the CA in question).
Provided we want to avoid relying on Puppet certificates, one solution is to extend smart-proxy to use multiple CA certificates. Then we can use Puppet (or subscription management) certificates to communicate between smart-proxy and managed hosts.
Comment 1RHEL Program Management
2014-11-06 12:52:58 UTC
Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.
Martin, can you elaborate what do you expect exactly? I was under impression that the only required change for ABRT in Satellite 6 is to configure ABRT clients to use consumer certs instead of puppet.
Right, the consumer certificate can be used instead of the puppet one. No change is required in ABRT as it can be configured to use any certificate in PEM format (although it would be nice if full path doesn't have to be used in the config).
One problem is that the subscription management CA is not among the system-wide CAs, so we need to add it before submitting report to capsule (unless we want to turn off SSL verification) by running "cp /etc/rhsm/ca/katello-server-ca.pem /etc/pki/ca-trust/source/anchors/ && update-ca-trust". Perhaps this could be done as part of the provisioning, together with configuring ABRT to use the right URL and certificates?
Other problem is that the subscription management certificate does not contain FQDN in its CN, but a UUID. The UUID can be mapped to the host on Foreman, however it seems the host does not always exist due to bug #1100284.
Furthermore, smart-proxy->Foreman HTTP communication fails because Foreman does not accept the proxy's certificate. Upstream bug filed: http://projects.theforeman.org/issues/8372