Bug 1754598

Summary: Satellite's registry crane port 5000 presenting incorrect Certificate Chain
Product: Red Hat Satellite Reporter: roarora
Component: CertificatesAssignee: Ewoud Kohl van Wijngaarden <ekohlvan>
Status: CLOSED ERRATA QA Contact: Stephen Wadeley <swadeley>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.5.0CC: chrobert, ekohlvan, pcreech, zhunting
Target Milestone: 6.7.0Keywords: Reopened, Triaged
Target Release: Unused   
Hardware: All   
OS: All   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-14 13:26:00 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:

Description roarora 2019-09-23 16:48:16 UTC
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  
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):

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

Comment 3 Ewoud Kohl van Wijngaarden 2019-10-10 13:25:00 UTC
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.

Comment 4 roarora 2019-10-11 10:09:59 UTC

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"

Comment 5 Ewoud Kohl van Wijngaarden 2019-10-11 12:03:57 UTC
Looks like I was looking at the wrong place for the setup. The actual relevant place is:

This is indeed incorrect since we set up Katello to expect the server CA:

Comment 6 Ewoud Kohl van Wijngaarden 2019-10-11 12:35:26 UTC
Created redmine issue https://projects.theforeman.org/issues/28043 from this bug

Comment 7 Bryan Kearney 2019-10-21 14:05:20 UTC
Upstream bug assigned to ekohlvan

Comment 8 Bryan Kearney 2019-10-21 14:05:21 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/28043 has been resolved.

Comment 12 errata-xmlrpc 2020-04-14 13:26:00 UTC
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.