Bug 1264208 - Registering to capsule results in: Unable to verify server's identity: tlsv1 alert unknown ca with custom certs
Registering to capsule results in: Unable to verify server's identity: tlsv1 ...
Status: CLOSED DUPLICATE of bug 1259294
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Capsule (Show other bugs)
6.1.2
All Linux
urgent Severity high (vote)
: 6.1.5
: --
Assigned To: Katello Bug Bin
Katello QA List
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-17 17:24 EDT by Craig Donnelly
Modified: 2017-02-23 14:46 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-29 08:36:04 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Craig Donnelly 2015-09-17 17:24:37 EDT
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 08:36:04 EDT
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 ***

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