Bug 1218390
Summary: | CertificateVerificationException on Capsule attempting to sync content from Satellite 6.1 server | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Satellite | Reporter: | Alex Krzos <akrzos> | ||||
Component: | Foreman Proxy | Assignee: | Justin Sherrill <jsherril> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Tazim Kolhar <tkolhar> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 6.1.0 | CC: | bbuckingham, cwelton, jsherril, mmccune, rbarlow, tkolhar | ||||
Target Milestone: | Unspecified | Keywords: | Triaged | ||||
Target Release: | Unused | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
URL: | http://projects.theforeman.org/issues/10387 | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2015-08-12 13:56:57 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: | |||||||
Attachments: |
|
Description
Alex Krzos
2015-05-04 18:48:07 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. Through some IRC discussion, it was determined that the /etc/pki/pulp/ca.crt file was used as the CA for the httpd certificate. This CA is for Pulp's internal usage only (it's used to make client SSL certificates), and should not be used by any outside entities (including Nodes and httpd). I've been lobbying internally for Pulp to stop creating/using this file, but it'll take some time before we can change that. Think of it like a private variable in a C++ class with no getters or setters ☺ Disregard my last comment, I had misread /etc/pki/pulp/server_ca.crt as /etc/pki/pulp/ca.crt. My mistake! jsherril, mhrivnak and I dug into the problem, and we discovered that the issue was that crane's and nodes' httpd config files were using the same name in their ServerName directive[0], but did not specify the (optional) port setting in the ServerName. This caused Pulp to get served with Crane's SSL certificate. Oddly, Crane's SSL certificate was configured to use /etc/pki/tls/certs/localhost.crt as well, which was also an error. [0] https://httpd.apache.org/docs/current/mod/core.html#servername It is possible to work around this issue one of two ways: 1) Configure Crane to use the correct SSL certificate and key by setting: SSLCertificateFile "/etc/pki/pulp/ssl_apache.crt" SSLCertificateKeyFile "/etc/pki/pulp/ssl_apache.key" in /etc/httpd/conf.d/03-crane.conf -or- 2) Configure Crane and Pulp to use different ServerNames by setting: ServerName capsule-r7-001.perf.lab.eng.rdu.redhat.com:5000 in /etc/httpd/conf.d/03-crane.conf, and ServerName capsule-r7-001.perf.lab.eng.rdu.redhat.com:443 in /etc/httpd/conf.d/25-pulp-node-ssl.conf The latter is the long-term correct fix. The former will solve two issues at once. Or you could do both and have it all the way correct! By the way, I suspect that if you don't do solution #2, you might be serving crane on 443 next to Pulp, and you might also be serving Pulp on 5000 next to Crane. I recommend applying both fixes in the installer to ensure they remain separated. Created redmine issue http://projects.theforeman.org/issues/10387 from this bug VERIFIED: # rpm -qa | grep foreman foreman-1.7.2.21-1.el7sat.noarch ruby193-rubygem-foreman_discovery-2.0.0.13-1.el7sat.noarch foreman-libvirt-1.7.2.21-1.el7sat.noarch ruby193-rubygem-foreman_gutterball-0.0.1.9-1.el7sat.noarch foreman-postgresql-1.7.2.21-1.el7sat.noarch ruby193-rubygem-foreman_bootdisk-4.0.2.13-1.el7sat.noarch dell-pem710-01.rhts.eng.bos.redhat.com-foreman-proxy-client-1.0-1.noarch foreman-ovirt-1.7.2.21-1.el7sat.noarch rubygem-hammer_cli_foreman-0.1.4.11-1.el7sat.noarch foreman-selinux-1.7.2.13-1.el7sat.noarch foreman-gce-1.7.2.21-1.el7sat.noarch ruby193-rubygem-foreman-redhat_access-0.1.0-1.el7sat.noarch ruby193-rubygem-foreman-tasks-0.6.12.5-1.el7sat.noarch rubygem-hammer_cli_foreman_tasks-0.0.3.4-1.el7sat.noarch rubygem-hammer_cli_foreman_docker-0.0.3.6-1.el7sat.noarch ruby193-rubygem-foreman_docker-1.2.0.12-1.el7sat.noarch ruby193-rubygem-foreman_hooks-0.3.7-2.el7sat.noarch rubygem-hammer_cli_foreman_bootdisk-0.1.2.7-1.el7sat.noarch foreman-proxy-1.7.2.4-1.el7sat.noarch dell-pem710-01.rhts.eng.bos.redhat.com-foreman-client-1.0-1.noarch dell-pem710-01.rhts.eng.bos.redhat.com-foreman-proxy-1.0-2.noarch foreman-vmware-1.7.2.21-1.el7sat.noarch rubygem-hammer_cli_foreman_discovery-0.0.1.10-1.el7sat.noarch foreman-compute-1.7.2.21-1.el7sat.noarch foreman-debug-1.7.2.21-1.el7sat.noarch steps: 1. Add life-cycle environment to capsule 2. Attempt to sync content to capsule # hammer capsule content synchronize --id 2 --environment KT_Default_Organization_Dev_con_viewA_2 --async [Foreman] Username: admin [Foreman] Password for admin: Capsule content is being synchronized in task f9ef7a50-cecb-4fc1-8bd6-e36080612b15 screenshot attached Created attachment 1025334 [details]
capsule sync
This bug is slated to be released with Satellite 6.1. This bug was fixed in version 6.1.1 of Satellite which was released on 12 August, 2015. |