Description of problem: On 5000 crane's port In case of custom certs, satellite presents custom katello-apache.crt but incorrect rest of the chain. Along with the apache cert, it presents the satellite generated internal CA as chain which is katello-default-ca.crt. Rather it should be presenting the custom CA bundle as a chain. This is due to ------------------------- # egrep Cert /etc/httpd/conf.d/03-crane.conf SSLCertificateFile "/etc/pki/katello/certs/katello-apache.crt" SSLCertificateKeyFile "/etc/pki/katello/private/katello-apache.key" SSLCertificateChainFile "/etc/pki/katello/certs/katello-default-ca.crt" --> Wrong? This should be katello-server-ca.crt SSLCACertificateFile "/etc/pki/katello/certs/katello-default-ca.crt" ------------------------- The ssl verification issue can been seen when there is an Intermediate CA along with ROOT CA. If a client connecting satellite's registry only has Root CA in the trust store, ssl verification will fail. Example : ------------------------- openssl s_client -connect sat65.lab.box:5000 -CAfile ./rootCA.pem CONNECTED(00000003) depth=0 C = IN, ST = MH, L = PNQ, O = Satellite, OU = Unix Admins, CN = sat65.lab.box verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = IN, ST = MH, L = PNQ, O = Satellite, OU = Unix Admins, CN = sat65.lab.box verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:C = IN, ST = MH, L = PNQ, O = Sysmgmt, OU = Unix Admins, CN = sat65.lab.box i:C = IN, ST = MH, L = PNQ, O = Intermediate CA, OU = CA Support, CN = Intermediate CA 1 s:C = US, ST = North Carolina, L = Raleigh, O = Katello, OU = SomeOrgUnit, CN = sat65.lab.box i:C = US, ST = North Carolina, L = Raleigh, O = Katello, OU = SomeOrgUnit, CN = sat65.lab.box ------------------------- Version-Release number of selected component (if applicable): 6.5 How reproducible: clients connecting to satellite's registry will face this only in case there is more than 1 CA in chain and client only has root CA in trust store. Steps to Reproduce: 1. Install Custom SSl Certs on Satellite signed by a Root CA - > Intermediate CA > Satellite Cert 2. Put Root CA in a systems's trust store. Do not register it to satellite as it will put full chain in anchors and trust i.e. katello-server-ca.crt 3. Use any Container Software on that system to connect to satellite registry with https and notice ssl verification errors Actual results: Certs cannot be verified Expected results: In SSLCertificateChainFile option of apache configuration, it should have katello-server-ca.crt to serve SSL chain correctly
It's a correct analysis and was fixed in https://github.com/theforeman/puppet-pulp/commit/c9100d26c6e2187570c987dfa4065f4855c934cf. This fix is part of Satellite 6.6.
Reopening The commit seems pretty old and was already a part of Satellite 6.5 . Also checked satellite 6.6 Beta, still Default CA is served as chain # egrep SSLCert /etc/httpd/conf.d/03-crane.conf SSLCertificateFile "/etc/pki/katello/certs/katello-apache.crt" SSLCertificateKeyFile "/etc/pki/katello/private/katello-apache.key" SSLCertificateChainFile "/etc/pki/katello/certs/katello-default-ca.crt"
Looks like I was looking at the wrong place for the setup. The actual relevant place is: https://github.com/theforeman/puppet-foreman_proxy_content/blob/f95a6eef1d510e65e2499367d738935b151cd05c/manifests/init.pp#L190-L197 This is indeed incorrect since we set up Katello to expect the server CA: https://github.com/theforeman/puppet-katello/blob/1b88391eb0b8c76f66104dc67bd0bad7d3292bcc/manifests/application.pp#L35
Created redmine issue https://projects.theforeman.org/issues/28043 from this bug
Upstream bug assigned to ekohlvan
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/28043 has been resolved.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:1454