CentOS 6.x & RH Satellite 6 (certificate fun)

[Voxorg]

Good afternoon all.

I'm looking for help to get a CentOS 6 system (6.5 at the moment, but I have a spectrum of 6.minors) enrolled in Satellite 6.

Background: I'm tasked with fixing up a multi-hundred-system environment that is mostly RHEL and has a Satelllite6 instance (I built the Satellite6). There are a handful of CentOS 6 systems that need to be brought into the fold as well - they need to get their patches/updates/repos from the Satellite 6 since lifecycling is important here and we do not want them updating directly from the internet.

It's probably worth noting that the Satellite 6 SSL cert is self-signed (default).

Getting Satellite 6 to host CentOS 6 repos - done, not a problem.

I have subscription-manager installed, the katello-ca-consumer rpm installed, and the system has been enrolled in Satellite 6 with everything as it should be on the Satellite side.

What's failing is that when I do a "yum makecache", I get "[Errno 14] Peer cert cannot be verified or peer cert invalid" and it's making me pull my hair out.

References:
* https://access.redhat.com/solutions/53905 (requires RH sub obviously)
* viewtopic.php?t=1073

None of these have had any effect:
* I have gone into yum.conf and set "sslverify=false"
* I have updated ca-certificate, and manually placed /etc/pki/tls/certs/ca-bundle.crt and ca-bundle.trust.crt in place as they came in with .rpmnew extensions.
* I have tried pointing yum.conf/sslcacert at both ca-bundle.crt and the katello-server-ca.pem.
* I have verified that the certificate in the 2nd reference above is already present in what appears to be the correct place (ca-bundle.crt)

The only .repo file in /etc/yum.repos.d is redhat.repo, and since that's managed by the rhsm plugin, I don't have any control over what's in it (if I change anything, it changes back the next time I run yum).

Testing on grabbing the repomd.xml manually:
wget https://foo.bar/qux/CentOS6-base-x86_64 ... repomd.xml
- Self-signed certificate encountered.
- To connect to foo.bar insecurely, use --nocheck-certificate

wget --no-check-certificate https://foo.bar/qux/CentOS6-base-x86_64 ... repomd.xml
- Self-signed certificate encountered.
- HTTP request sent, awaiting response... No data received
- and retries ad nauseum

curl https://foo.bar/qux/CentOS6-base-x86_64 ... repomd.xml
- the usual multiple-line output about it can't validate the certificate

curl -k https://foo.bar/qux/CentOS6-base-x86_64 ... repomd.xml
- curl: (56) NSS: client certificate not found (nickname not specified)

curl --cacert /etc/pki/tls/certs/ca-bundle.crt https://foo.bar/qux/CentOS6-base-x86_64 ... repomd.xml
- curl: (60) Peer certificate cannot be authenticated with known CA certificates

curl --cacert /etc/rhsm/ca/katello-server-ca.pem
- curl doesn't like .pem files.

I'm out of ideas. Does anyone have experience or other ideas?

[TrevorH]

You should not run 6.5. It contains numerous high severity security vulnerabilites. You should update to 6.9 ASAP. Also, in later 6.x versions variious SSL related things have changed which may mean that the errors you have talking to https sites could be fixed - 6.5 will not talk the necessary protocols to be able to communicate with newer SSL stacks.

[Voxorg]

Please spare the "should" - I'm well aware of what versions /should/ and /should not/ be in service. They /are/ and that's what I'm trying to get fixed by enrolling them in the local Satellite so they can be patched up to latest-and-greatest.

Your comment on changes in SSL however was useful - although now I have to figure out how to provision the mass of rpms that's on an ISO to these systems so I can update from a file-type repo instead of an https repo. (4.3G may not seem like a lot, but in this environment, making that available is going to be another interesting challenge).

-v

[TrevorH]

You "should" update a lot more often than every 4 years but...

Use /etc/yum.repos.d/CentOS-Media.repo maybe?

[Voxorg]

s/You/This client/g

The challenge is not constructing a local repo, but getting the mass of RPM data available for use. A 4.3G iso doesn't sound like a lot, but in this instance, it is somewhat problematic.

I only started working in this environment a handful of weeks ago, this is one of those where "this environment just happened" and "plan" is a 4-letter word.

I may end up having to figure out to tunnel NFS over a ssh tunnel >_<