PKI

End to end, X509 public key infrastructure is critical to subscription management. Critically, there are a range of extensions that contain specific product and content information for the end user’s repository configuration and access.

In order to understand how to deploy client certificate(s) the following must be appreciated.

If your certificate infrastructure gets screwed up; clients will no longer be able to DNF against your repositories; and the ability to fix the problem via dnf update will not be available.

Authority

The rhsmd is by design an intermediate CA. It may self-sign if the server and authority certificate paths reference the same cert. The full CA certificate chain must be deployed to the client in order for host verification to succeed.

Products

Products are defined by X509 certificates in /etc/pki/products/<name>.pem. Product information is embedded in the certificate extensions.

Consumer

The consumer receives their /etc/pki/consumer/cert.pem and /etc/pki/consumer/key.pem upon registration in order to authenticate and identify themselves with the entitlements service into the future.

Entitlement

Entitlement certificate(s) are in /etc/pki/entitlements and these have extensions with content information; this provides the basis for generating /etc/yum.repos.d/redhat.repo - to authenticate and download RPM package updates.

Entitlements Authority certificates may be individually placed into /etc/rhsm/ca as subscription-manager bundles these when connecting to the entitlements server.

Content

Content is the Yum repository hosted end point(s) that are in /etc/yum.repos.d/redhat.repo.

It is generally expected that the content will be serviced via a CDN-style infrastructure where a high volume of traffic is expected; whereas each client only touches the entitlements server a few times a day. Usually this would also be set up as TLS; configured in /etc/rhsm/rhsm.conf.

This CA certificate must be able to host-verify the content server(s). The content server(s) need to be able to verify the entitlement certificate(s) - that is, they must also be aware of the Authority infrastructure here that created/signed these certs.

Connecting to the content server is done via libdnf and curl: it expects certificate chains to be in system paths.

Considerations

• sslverify may be turned on/off in redhat.repo using the configuration setting: FEATURES.SSL_VERIFY_STATUS

• include both entitlements domain and content domain in SAN extension of server certificates so they can ship for both contexts

• update-ca-trust adds certificates to system certs. We ship certs via RPM and a post step triggers this