Bug 1754598 - Satellite's registry crane port 5000 presenting incorrect Certificate Chain
Summary: Satellite's registry crane port 5000 presenting incorrect Certificate Chain
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Certificates
Version: 6.5.0
Hardware: All
OS: All
unspecified
medium vote
Target Milestone: 6.7.0
Assignee: Ewoud Kohl van Wijngaarden
QA Contact: Stephen Wadeley
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-09-23 16:48 UTC by roarora
Modified: 2020-04-14 13:26 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-14 13:26:00 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Foreman Issue Tracker 28043 Normal Closed Crane port 5000 presenting default Certificate Chain instead of Server Chain 2020-05-15 16:23:50 UTC
Red Hat Product Errata RHSA-2020:1454 None None None 2020-04-14 13:26:11 UTC

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  
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

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
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"

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:
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

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@redhat.com

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.

https://access.redhat.com/errata/RHSA-2020:1454


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