This article was originally published on the Red Hat Customer Portal. The information may no longer be current.


With the introduction of the newer Systems Management tools such as Satellite 6, we introduced a new concept, the Subscription Manifest (which are different from Satellite 5 Entitlement XML certificates), as the means to import Subscriptions into Satellite for the purposes of synchronizing content and attaching subscriptions to systems.

What is a subscription manifest?

A subscription manifest is a digitally signed zip file containing:

  • A listing of subscriptions that can be used by an on-premise subscription management tool (such as Red Hat Satellite)
  • Various entitlement certificates associated with those subscriptions usable to download content from the Red Hat Content Delivery Network (CDN).
  • A listing of Content Sets (directories on the CDN which access is granted to)
  • A x.509 certificate used to authenticate with the Red Hat Customer Portal
    • This is used by the Red Hat Insights tool to authenticate when uploading telemetry data
    • This is used by Red Hat Satellite to authenticate when downloading updated manifests (using the Refresh manifest button in the UI)

Manifests are to Satellite 6 what XML Entitlement certificates were to Satellite 5.

How do I get a subscription manifest?

Subscription manifests can be created/downloaded via the Customer Portal by visiting -> Subscriptions ->
Subscription Management Applications & selecting either

  • Register a Subscription Management Application (for Subscription Asset Manager)
  • Register a Satellite (for Satellite 5 & Satellite 6) (Note: This page only appears if you have a valid Satellite subscription) Figure 1.

What is a 'Subscription Management Application'

A 'Subscription Management Application', (occasionally called a 'distributor') is effectively a 'bucket of subscriptions' which have being selected for usage with an on-premise subscription management tool, such as Satellite. Thus, any subscription you wish to use with Satellite needs to be added to a Subscription Management Application first. After creating a Subscription Management Application, one needs to create the Subscription Manifest, which is a signed (thus authoritative) copy of what is actually in the bucket. (at time of signature).

The relationship between the two is similar to 'cargo' (Subscription Management Application) versus 'bill of lading' (Subscription Manifest)

How many subscription manifests do I need?

There is a pretty big difference between Satellite 5 and Satellite 6 with regards to the number of certificates / manifests needed.

Satellite 5 requires:

  • A single certificate for the Satellite, which provided entitlements for the entire Satellite, which could be divided into logical organizations for systems management.

The upside to this was that a single certificate supported the entire Satellite. The downside was that is was very difficult to support multiple Red Hat Network Accounts. If you have > 1 Red Hat Network Account you wanted to support with Satellite 5, you had two options:

  • Purchase a Satellite for each account.
  • Work with your Red Hat account team to transfer subscriptions into a singular account for management.

Neither of these were usually ideal.

Summary: Satellite 5 requires one certificate per installation of Satellite 5.

Satellite 6 requires:

  • A single manifest for each organization configured on the Satellite.

The upsides to this model is that since each organization maintains completely separate subscriptions, you can:

  • create multiple Subscription Management applications (remember: bucket of sub) supporting multiple organizations.
  • support multiple Red Hat Network Accounts

Example follows: Figure 2. In the example above, there are two fictitious customers, ACME Corp and Example Corp, who each wish to leverage the same Satellite 6 installation. Their subscriptions are in two distinct Red Hat Network accounts. In this scenario, ACME Corp can allocate any subset of their 60 subscriptions (in this example, they've allocated 30) to a Subscription Management Application, which can be imported in Example Corp's Satellite as a distinct Organization. This allows ACME's system administrators the ability to manage their systems leveraging Satellite 6 completely independently of Example Corp's 3 organizations (R&D, Operations, and Engineering)

Summary : Satellite 6 requires one manifest per organization. Manifests can be issued from any Red Hat Network Account that has Smart Management subscriptions for the systems that will be managed via Satellite 6

Examining a subscription manifest

Now that we've created a subscription manifest and downloaded it, let's take a look at it. As mentioned above, the subscription manifest is a .zip file, which can be extracted to inspect the various metadata files within. However, included in Red Hat Enterprise Linux is the rct command, part of the subscription-manager package, which allows you to introspect manifests.

$ rct cat-manifest

        Server Version:
        Date Created: 2016-05-05T18:35:13.818+0000
        Creator: candlepin_admin

        Name: My_Manifest
        UUID: 57641572-27c9-4e98-8713-e6fed967a042
        Type: satellite
        Name: Red Hat Enterprise Linux for Virtual Datacenters, Premium
        Quantity: 50
        Created: 2015-08-06T16:51:40.000+0000
        Start Date: 2015-08-05T04:00:00.000+0000
        End Date: 2016-08-05T03:59:59.000+0000
        Service Level: Premium
        Service Type: L1-L3
        SKU: RH00001
        Contract: [REDACTED]
        Order: [REDACTED]
        Account: [REDACTED]
        Virt Limit: unlimited
        Requires Virt-who: True
        Entitlement File: export/entitlements/8a99f9864efa4a57014f03ece4cf40ee.json
        Certificate File: export/entitlement_certificates/8194328514515623350.pem
        Certificate Version: 3.2
        Provided Products:
        Content Sets:
                <--OUTPUT SNIPPED FOR BREVITY -->

        Name: Red Hat Enterprise Linux Server, Premium (Physical or Virtual Nodes)
        Quantity: 100
        Created: 2015-08-06T16:49:55.000+0000
        Start Date: 2015-08-05T04:00:00.000+0000
        End Date: 2016-08-05T03:59:59.000+0000
        Service Level: Premium
        Service Type: L1-L3
        Architectures: x86_64,ppc64le,ppc64,ia64,ppc,s390,x86,s390x
        SKU: RH00003
        Contract: [REDACTED]
        Order: [REDACTED]
        Account: [REDACTED]
        Virt Limit:
        Requires Virt-who: False
        Entitlement File: export/entitlements/8a99f9894efa4f28014f03eb49ea5a86.json
        Certificate File: export/entitlement_certificates/2073596929533310794.pem
        Certificate Version: 3.2
        Provided Products:
                69: Red Hat Enterprise Linux Server
                70: Red Hat Enterprise Linux Server - Extended Update Support
                84: Red Hat Enterprise Linux High Availability (for RHEL Server) - Extended Update Support
              86: Red Hat Enterprise Linux Load Balancer (for RHEL Server) - Extended Update Support
              91: Red Hat Enterprise Linux Resilient Storage (for RHEL Server) - Extended Update Support
              93: Red Hat Enterprise Linux Scalable File System (for RHEL Server) - Extended Update Support
              127: Red Hat S-JIS Support (for RHEL Server) - Extended Update Support
              133: Red Hat Enterprise Linux High Performance Networking (for RHEL Server) - Extended Update Support
              176: Red Hat Developer Toolset (for RHEL Server)
              180: Red Hat Beta
              182: Red Hat EUCJP Support (for RHEL Server) - Extended Update Support
              201: Red Hat Software Collections (for RHEL Server)
              205: Red Hat Software Collections Beta (for RHEL Server)
              240: Oracle Java (for RHEL Server)
              246: Oracle Java (for RHEL Server) - Extended Update Support
              271: Red Hat Enterprise Linux Atomic Host
              272: Red Hat Enterprise Linux Atomic Host Beta
              273: Red Hat Container Images
              274: Red Hat Container Images Beta
        Content Sets:

Let's take a look at those fields:

General Section

Field Meaning Notes
Server Which server generated the manifest usually
Server version Software version of the server which generated the manifest  
Date Created When the Manifest was generated  

Consumer section

Field Meaning Notes
Name Name of the Subscription management application where this manifest was generated from  
UUID UUID of the Subscription management application pro-tip: visit($UUID to go directly to the Subscription Management app)
Type Type of Subscription Management application usually 'Satellite' or 'Sam'

Subscription Section

Field Meaning Notes
Name Name of the subscription  
Quantity Quantity of this type of subscription attached to the manifest  
Created When the subscription was attached to this manifest  
Start Date When the subscription begins  
End Date When the subscription ends  
Service Level SLA for this subscription Usually Standard, Premium, Self-Support, Layered, etc
Service Type Service Type for the SKU/td>


Usually either 'L1-L3' or 'L3-only'
Architectures What architecture does the SKU provide content for  
SKU Stock Keeping Unit(SKU) number  
Contract Red Hat Contract number that this subscription was purchased under  
Order Order number that the subscription was purchased under  
Account Red Hat Network account that this subscription is from.  
Virt Limit How many virtual guests can be supported per hypervisor with this subscription this field is new in subscription-manager-1.17.10-1
Requires virt-who Does this subscription require [virt-who]( to be used properly this field is new in subscription-manager-1.17.10-1
Entitlement File Which file (if you extract the manifest contains this data )  
Certificate File Which certificate can be used by Satellite to retrieve content provided by this subscription from the CDN  
Certificate Version Version of the Entitlement certificate  
Provided Products Which Red Hat components are provided via this subscription  
Content Sets Which CDN repositories does this subscription have access to (so that content can be synced)  

When do I need a new subscription manifest?

A new subscription manifest is required whenever the contents of the Subscription Management Application changes OR when the content that the subscriptions provided changes. Examples:

  • When Satellite 6.2 was released, updated manifests were required to reflect the new Satellite 6.2 repositories.
  • When renewing subscriptions, your new subscriptions need to be added to the Subscription Management Application.
  • When adding subscriptions to your Subscription Management Application.

Refreshing manifests

When it is necessary to refresh a manifest, you can do this one of two ways:

  • In the UI via the Content->Red Hat Subscriptions->Manage Manifests->Refresh Manifest button.
  • By downloading it from the Customer Portal and uploading it in the Satellite user interface.

Connected customers whose Satellites can connect to the Red Hat Customer Portal can use either option. Disconnected customers, whose Satellites cannot connect to the Red Hat Customer Portal can only use the latter option.

Hopefully this document helps to explain what a manifest is, and how they interact with Red Hat Satellite.

About the author

Rich Jerrido is the Senior Principal Product Manager for Hybrid Cloud Business Services.

Read full bio