Bug 1264208

Summary: Registering to capsule results in: Unable to verify server's identity: tlsv1 alert unknown ca with custom certs
Product: Red Hat Satellite Reporter: Craig Donnelly <cdonnell>
Component: Foreman ProxyAssignee: Katello Bug Bin <katello-bugs>
Status: CLOSED DUPLICATE QA Contact: Katello QA List <katello-qa-list>
Severity: high Docs Contact:
Priority: urgent    
Version: 6.1.2CC: andrew.schofield, bbuckingham, bkearney, ftsiadim, kabbott, kdixon, mmccune, nmiao, sthirugn
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-10-29 12:36:04 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:

Description Craig Donnelly 2015-09-17 21:24:37 UTC
Description of problem:

When installing an isolated capsule on Satellite 6.1.1/6.1.2 with customer certs (custom/non-default), If you register a host to the capsule itself you will receive the error: Unable to verify server's identity: tlsv1 alert unknown ca.
The registration appears to fail, but does not. The host is still visible inside Foreman, but all subscription-manager commands fail with this tlsv1 issue.


Version-Release number of selected component (if applicable):


How reproducible: 100% with custom certs?


Steps to Reproduce: (Full reproduction by Red Hat IT/IS)
The satellite and capsule is configured with custom server certs.

host_1 is configured to talk to capsule_1 in /etc/rhsm/rhsm.conf (via installing the katello-ca-consumer rpm from capsule_1)

This is what happened when registering the host:

[root@host_a ~]# subscription-manager register --org="xxx" --activationkey="default"
The system has been registered with ID: 4d7f696a-827a-49ab-8d41-899c1e92735b
Unable to verify server's identity: tlsv1 alert unknown ca

host_1 actually registered successfully despite the error, because it shows up as a content host in the GUI. However, any subscription-manager commands spits the same unknown ca error consistently. 

The culprit is in /etc/httpd/conf.d/28-katello-reverse-proxy.conf on capsule_1. 

-- snip --
  ## SSL directives
  SSLEngine on
  SSLCertificateFile      "/etc/pki/katello/certs/katello-apache.crt"
  SSLCertificateKeyFile   "/etc/pki/katello/private/katello-apache.key"
  SSLCACertificatePath    "/etc/pki/tls/certs"
  SSLCACertificateFile    "/etc/pki/katello/certs/katello-server-ca.crt"
-- snip --

The unknown ca error goes away after "SSLCACertificateFile" is changed to "/etc/pki/katello/certs/katello-default-ca.crt".

This is how this all happened:

Since 6.1, capsules are able to proxy pass the subscription-management calls from client to satellite via port 8443.  '28-katello-reverse-proxy.conf' is the config file that facilitates the proxy. 

When the satellite and capsule are configured with custom certs,  "/etc/pki/katello/certs/katello-server-ca.crt" and "/etc/pki/katello/certs/katello-default-ca.crt" are no longer the same CA. The "default-ca" is the self generated CA that signs the consumer cert bundle used by the clients (/etc/pki/consumer/bundle.pem), and the "server-ca" is the one you provide via "katello-installer --certs-server-ca-cert" (or "capsule-installer --server-ca-cert")

So, when the client talks to the capsule on 8443, it use a cert signed by default-ca, while the capsule is trying to verify it using server-ca, which is a completely different CA. 

Actual results:
System's sub-mgr commands fail with tlsv1 errors.

Expected results:
Successful sub-mgr commands and correct certs in place.

Comment 4 Bryan Kearney 2015-10-29 12:36:04 UTC
This is a dupe of https://bugzilla.redhat.com/show_bug.cgi?id=1259294 which was delivered with Satellite 6.1.3 on 15 October.

*** This bug has been marked as a duplicate of bug 1259294 ***