Certificate Hierarchies

Every license or certificate on your computer is actually a chain of certificates leading back to one certificate (sometimes called the root of trust). This system where all certificates lead back to a single certificate is called a certificate hierarchy. Microsoft has built two distinct hierarchies for use with AD RMS-enabled applications: Pre-production and Production. The Pre-production hierarchy is provided by Microsoft for the express purpose of developing and testing AD RMS-enabled applications. The Production hierarchy is intended for the production and consumption of released AD RMS-enabled applications and content.

Rights account certificates and end-user licenses lead back to one of these two root certificates. Issuance licenses are slightly different because they lead back to the AD RMS server that the content is published against, not the root certificate. The lockbox is also tied to one of these two roots. For an application to consume content, all the necessary certificates and the lockbox must lead back to the same root. Therefore, while you are developing and testing applications, your account, your computer, and your content must all use the Pre-production root. Anyone hoping to consume this content must be activated against the Pre-production root. When you prepare your product for release, or when you use a commercially produced AD RMS-enabled application, your account and your computer must be activated against the production root (that is, the root certificate for the user and computer must be the Production certificate).

The purpose of a certificate chain is to guarantee each component's integrity (for example, an authentic, unaltered version of Win32.dll) and identity (for example, Jim's computer or Win32.dll created by Microsoft). Integrity is guaranteed by providing a signed hash of the library, application, or machine in each certificate. Identity is guaranteed by a signed chain of certificates leading back to the root of trust. Everything used by an AD RMS-enabled application must have a certificate chain that leads back to an Authenticode certificate, or the Pre-production or Production root.

The following diagram shows an example of an end-user license chain for RMS 1.0 SP2, RMS 1.0 SP1, and RMS 1.0. For information about the AD RMS certificate hierarchy in Windows Server 2008 and Windows Vista, see Server Self-Enrollment.

For an AD RMS-enabled application to run, every element (library or executable) in its process space must have a certificate chain that leads back to the same root of trust as the user's computer. The exception to this is Authenticode-signed elements, which do not have to have the same root. These are modules you create and sign yourself. You can Authenticode-sign your modules as described in Authenticode Signing a DLL.

A programmer must have their application's certificate signed into one of the two chains of trust for it to work. The resulting chain, which identifies their application, is called a manifest. For more information about manifests, see Creating the Application Manifest. For more information about how licenses and certificates are acquired, see Licenses and Certificates.

To learn which hierarchy a user, computer, or license is issued to, open the license in a text editor and look at the <ISSUER> element of the root certificate, which should be either Production or Pre-production. To learn where your licenses are stored, see License Management.

See Also

Activation
Creating the Application Manifest
Licenses and Certificates
About Active Directory Rights Management Services

Send comments about this topic to Microsoft

Build date: 3/13/2008