Bug 1265533

Summary: [RFE] katello-certs-check to distinguish between Satellite and Capsule
Product: Red Hat Satellite 6 Reporter: Pavel Moravec <pmoravec>
Component: InstallerAssignee: Chris Roberts <chrobert>
Status: CLOSED ERRATA QA Contact: Jitendra Yejare <jyejare>
Severity: medium Docs Contact:
Priority: high    
Version: 6.1.1CC: bkearney, chrobert, dmoessne, jyejare, stbenjam, sthirugn, swadeley
Target Milestone: 6.4.0Keywords: FutureFeature
Target Release: Unused   
Hardware: All   
OS: Linux   
URL: https://projects.theforeman.org/issues/22694
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-10-16 15:25:56 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 Pavel Moravec 2015-09-23 07:49:40 UTC
Description of problem:
Currently, katello-certs-check checks provided certs and suggest their usage by running katello-installer and/or capsule-certs-generate. Following the output, one can be confused where to use the certificates and there have been attempts to use Satellite's certs for Capsule.

Please remove this ambiguity by printing just katello-installer XOR capsule-certs-generate. It should be enough to compare "CN" part of Subject in the server cert with FQDN of the machine running the script. If those matches, it is assumed the certs are meant for the Satellite and just "katello-installer" part of output shall be printed. If FQDN doesn't match CN of Subject, print just "capsule-certs-generate" part.

(the above is based on assumption that CN of a server's certificate must match the server's FQDN - not sure if this is correct)

Ideally, there should be a line "Provided server's certificate was recognized as a cert for Satellite/Capsule", just to clarify to user the decision the script did.


Version-Release number of selected component (if applicable):
katello-installer-2.3.17-1.el7sat.noarch


How reproducible:
100%


Steps to Reproduce:
1. Have some custom certs and run
/usr/sbin/katello-certs-check


Actual results:
Currently it is ambiguous if I should run katello-installer or capsule-certs-generate.


Expected results:
The tool shall print our either katello-installer example XOR capsule-certs-generate example, not both.


Additional info:

Comment 4 pm-sat@redhat.com 2018-02-26 17:09:41 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/22694 has been resolved.

Comment 5 Jitendra Yejare 2018-08-13 11:26:16 UTC
Verified!

@ Satellite 6.4 snap 17


Steps:
1. Run katello-certs-check utility with certificate and key.
# katello-certs-check -c server.valid.crt -k server.key -b rootCA.pem


Observation:

The utility provides the checks and commands separately to run on satellite and capsule.

# katello-certs-check -c server.valid.crt -k server.key -b rootCA.pem
Checking server certificate's encoding: [OK]
Checking expiration of certificate: [OK]
Checking expiration of CA bundle: [OK]
Checking if server cert has CA:TRUE flag[OK]
Validating the certificate subject= /C=IN/ST=Maharashtra/L=Pune/O=redhat/OU=QE/CN=niks/emailAddress=administrator@example.com
Checking to see if the private key matches the certificate: [OK]
Checking ca bundle against the cert file: [OK]
Checking Subject Alt Name on certificate[OK]
Checking Key Usage extension on certificate for Key Encipherment[OK]

Validation succeeded.

To install the Katello main server with the custom certificates, run:

    satellite-installer --scenario satellite\
                      --certs-server-cert "/root/CustCert/server.valid.crt"\
                      --certs-server-key "/root/CustCert/server.key"\
                      --certs-server-ca-cert "/root/CustCert/rootCA.pem"

To update the certificates on a currently running Katello installation, run:

    satellite-installer --scenario satellite\
                      --certs-server-cert "/root/CustCert/server.valid.crt"\
                      --certs-server-key "/root/CustCert/server.key"\
                      --certs-server-ca-cert "/root/CustCert/rootCA.pem"\
                      --certs-update-server --certs-update-server-ca

To use them inside a NEW $FOREMAN_PROXY, run this command:

    capsule-certs-generate --foreman-proxy-fqdn "$FOREMAN_PROXY"\
                                 --certs-tar  "~/$FOREMAN_PROXY-certs.tar"\
                                 --server-cert "/root/CustCert/server.valid.crt"\
                                 --server-key "/root/CustCert/server.key"\
                                 --server-ca-cert "/root/CustCert/rootCA.pem"\

To use them inside an EXISTING $FOREMAN_PROXY, run this command INSTEAD:

    capsule-certs-generate --foreman-proxy-fqdn "$FOREMAN_PROXY"\
                                 --certs-tar  "~/$FOREMAN_PROXY-certs.tar"\
                                 --server-cert "/root/CustCert/server.valid.crt"\
                                 --server-key "/root/CustCert/server.key"\
                                 --server-ca-cert "/root/CustCert/rootCA.pem"\
                                 --certs-update-server

Comment 7 errata-xmlrpc 2018-10-16 15:25:56 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-2018:2927