- 1 Candlepin Basics
- 1.1 Overview
- 1.1.1 Glossary
- 1.2 Subscriptions and Engineering Products
- 1.2.1 Subscription Types
- 1.2.2 Subscription Management
- 1.2.3 Storage Band Subscription
- 1.2.4 Constraints
- 1.2.5 Unmapped/Temporary Guest Pool
- 1.3 Entitlements
- 1.3.1 Auto Attach
- 1.3.2 Disabling Auto Attach
- 1.3.3 Server-Side Entitlement Status
- 1.3.4 Expired Entitlements
- 1.3.5 Revoke Entitlements
- 1.4 Virtualization Entitlements
- 1.5 Jobs
- 1.5.1 Active Entitlement Job
- 1.5.2 Certificate Cleanup Job
- 1.5.3 Import Record Cleaner Job
- 1.5.4 Inactive Consumer Cleanup Job
- 1.5.5 Job Cleaner Job
- 1.5.6 Manifest Cleaner Job
- 1.5.7 Orphan Cleanup Job
- 1.5.8 Unmapped Guest Entitlement Cleaner Job
- 2 User Guide
- 2.1 Basic How To
- 2.1.1 Lookup Consumers By Facts
- 2.1.2 JSON Response Filtering
- 2.1.3 Batch binding exact pools
- 2.2 Standalone Deployment
- 2.3 Hosted Deployment
- 2.4 Reporting an Error
- 3 Administration Guide
- 3.1 Setting Up Candlepin
- 3.1.1 Candlepin Configuration
- 3.1.2 Quartz Configuration
- 3.1.3 Configuring Candlepin to Use MySQL
- 3.1.4 Configuring A Remote Artemis Server
- 3.1.5 Allow Remote Connections to embedded Artemis
- 3.2 Migration Validation Tool
- 3.3 Common Problems
- 3.4 High Availability
- 3.5 Manifests
- 3.5.1 Exporting A Manifest
- 3.5.2 Importing A Manifest
- 3.5.3 Extending A Manifest
- 3.6 Data Transfer
- 3.7 Migrating to the Artemis Job System
- 4 Developers
- 4.1 Architecture
- 4.1.1 Candlepin 2.0 Migration
- 4.1.2 Candlepin 2.0 Product Versioning
- 4.1.3 Pinsetter
- 4.1.4 Batch Engine
- 4.1.5 HornetQ Event Model
- 4.1.6 AMQP
- 4.1.7 JavaScript Rules
- 4.1.8 Candlepin DTOs
- 4.1.9 Authentication and Authorization
- 4.1.9.1 OAuth Authentication
- 4.1.10 Fail Fast Mechanism
- 4.2 Development
- 4.2.1 Setting up IntelliJ IDEA
- 4.2.2 Developer Deployment
- 4.2.3 Auto Generating candlepin.conf
- 4.2.4 Coding Conventions
- 4.2.5 Checkstyle
- 4.2.6 Logging in Candlepin
- 4.2.7 Internationalization
- 4.2.8 Paginating Results
- 4.2.9 Database Schema Updates
- 4.2.10 JSON and JAXB
- 4.2.11 The Certificate Revocation List
- 4.2.12 Hibernate Gotchas
- 4.2.13 Ruby Bindings for Candlepin
- 4.2.14 Caching - JCache and Candlepin Second Level Cache
- 4.2.15 What to look for in a Code Review
- 4.3 Implementation details
- 4.3.1 Revoke Entitlements Implementation
- 4.3.2 Bind Time Locks
- 4.3.3 Bind Operation Dependencies
- 4.4 Debugging
- 4.4.1 Using cpc
- 4.4.2 Generating Test Certificates
- 4.4.3 Debugging SSL/TLS with Wireshark
- 4.5 Testing
- 4.5.1 Spec test migration
- 4.5.2 Candlepin Database Validation
- 4.6 Documentation
- 4.7 Useful Queries
- 4.7.1 Clean up database backup
- 4.8 Building RPMs with Tito
- 4.9 Bugzilla process
- 4.10 Standard for Card Sizes
- 5 Reference
- 5.1 REST API
- 5.2 Database Object Names
- 5.3 Product and Pool Attributes
- 5.4 Pre entitlement rules checks
- 6 Design Documents
- 6.1 API Version Design
- 6.2 Compliance Snapshots
- 6.3 Environments Design
- 6.4 Federated Certificate Management
- 6.5 Lazy Certificate Regeneration
- 6.6 Manifest Consumer Association
- 6.7 Multi-Owner Users Design
- 6.8 Multi-Version Product Design
- 6.9 Owner Hierarchy
- 6.10 Plugins
- 6.11 Policy Design
- 6.12 Service Layer Guidelines
- 6.13 Supporting Multiple Servlet Containers
Table of Contents
Overview
This is an overview of the issues around Federated Certificate Generation. This is fancy name for what the On Premises Candlepin will need to do.
Background
RHUI, Hosted Candlepin/CDN, and Katello all follow a similar pattern:
- They have their own Certificate Authority (CA)
- The create certificates using that CA
- They mirror content from Red Hat, and control access to that content using that CA.
In the case of Hosted Candlepin/CDN Red Hat holds the CA. In the case of RHUI and Kalpana, the customer would use their own CA. However, in all cases the CA is used to grant certificates and control access to locally managed Content.
For on premises Candlepin, we would like to have an on premises tool which can manage certificates but not mirror content. The content would be accessed from the upstream CDN.
There are a couple of ways to approach this:
Pre Generate The Certificates
In this model, the hosted environment would generate the certificates using their on CA. Then, the certificates are given in batch out to the on premise tool which in turn gives them to the machines which require them. This allows Red Hat to control the CA, and handle revocation within our own network. However, products such as EUS require that the certificates be unique based on other certificates which are on the box. Therefore, it would be difficult to pre-generate all the valid combination which could be used.
Sub CAs
A second model would be for the on-premises tool to be a sub CA of the upstream CA. Technically this is possible. However, this would mean that anyone with a On premises Candlepin can create certs which can pull content from the upstream CDN. Red Hat would need to create some robust fraud detection tools to ensure that we are not giving away the bits. In addition, to support revocation of certificate, the client would need to send Revoked certificated to the content provider in order to add to the corporate Certificate Revocation List.
Proxy Model
A third approach would be for the on premises tool to generate certificate using a local CA. Some intelligent proxy would need to emit a CDN API, and to transmorgify a content request using a local certificate into a similar request which can be handled by the upstream CDN. This would need to include some sort of certificate replacement.
Content Cert Proxy
One possible solution, following the proxy model, would be be for the On Premises Server to provide 2 bits of data to a Content Proxy. These are:
- The Content Certificates which have been loaded into Candlepin from a Subscription Manifest.
- Certificate Revocation data in the form of either a CRL or OCSPD.
Yum can then be configured to pull content from that proxy. When a request is made, the following would need to be done by the proxy:
- Check that the certificate is value, and has not been revoked.
- Check that the request is a for a url which is allowed by this certificate.
- Check that the proxy is configured with a Content Certificate which is also valid and provides access to that repository on the CDN
- If the above passes, pull down the content from the CDN using the Content Certificate, and provide it back to the requester.