Security Advisor

Cross Certification Trusts

Windows Server 2003 provides a way to implement trusts among Certification Authority hierarchies selectively. Here’s how it works.

• By Roberta Bragg
• 11/01/2003

Today, it’s possible to merge business resources among partners. We realize that we can’t stand alone, that we must work together to be competitive. We create extranets to buy and sell products and to partner on projects. We provide access to our stuff; they provide access to theirs. Our networks can become tangled hubs of interconnectivity. Then suddenly, bittersweet success or abject failure descends and they’re gone. Off chasing another dream, or banished from our strongholds because of something they said or did. Like ex-lovers, we can barely speak, and yet there is this infrastructure to separate, boundaries to rebuild.

What’s that mean? Never enter into any relationship without a plan for separation. Never plan any connections without planning extraction too. Choose technologies that make it easier to do so. And for those of us who sing the virtues of products and tell you how to make them work, we must also tell you how to disengage them.

There’s one new technology that just seems like it was built to do that. It can help you create a trust relationship between two organizations and then ease your job when they need to separate. It’s called cross certification and it’s available with Windows Server 2003 Certification Authority (CA) hierarchies.

CA Hierarchies
It’s become so easy to implement a Public Key Infrastructure (PKI) that many have done so. Certificates are now being issued for smart cards, IPSec authentication, EFS, SSL and other purposes. Part of the process, whether you’ve realized it or not, was creating a CA hierarchy. CAs issue certificates. A CA hierarchy is a collection of CAs whose authorization extends back to a common root.

While you might argue that one CA can’t a hierarchy make, for the purposes of this article, and an explanation of cross certification, a single CA is a hierarchy. Hierarchies are cross certified, and you can do that even if only one CA exists on each side of the proposed trust relationship.

In the next simplest implementation, a CA hierarchy consists of a root (the first CA installed) and one subordinate CA. The root CA produces and signs its own certificate, but the subordinate CA gets its CA certificate—its authority—from the root CA. If anyone agrees to trust the root CA, it’s the same as saying they’ll trust any certificates from the subordinate CA as well. A CA hierarchy, however, can and often does contain multiple levels and many CAs. This way CA hierarchies can be scaled, work well over large geographical distances, and/or split the responsibility for different certificate types over many computers and thus pockets of administrative authority. Still, though, the equation remains basically the same: If you trust the root CA, you trust all certificates that every CA in its hierarchy issues. There are exceptions to this rule, and we’ll address them a little later.

In talking about hierarchies and trusts, I’ll use the fictitious companies Peach Weaver and Star Fruit. Figure 1 shows Peach Weaver’s three-level hierarchy. Note that in the figure, the root CA issues CA certificates for the CAs located in London and New York. These CAs—the intermediary CAs—issue CA certificates for the bottom layer, which are the issuing CAs. The Issuing CAs issue the smart card, EFS and IPSec certificates for the Peach Weaver employees and computers.

Figure 1. A three-tiered Certification Authority hierarchy for sample company Peach Weaver.

Hierarchies are a good thing. You can establish trust in any of the certificates issued by any of the CAs anywhere in the world as long as you trust the root CA. You indicate that trust by placing a copy of the root CA certificate in the Trusted Root Certification Authority certificate store of the computer. Using Active Directory and a properly configured CA hierarchy, smart card certificates issued by the CA in London can be used to log onto computers in New York and vice-versa.

After setting up the hierarchy, you can delegate responsibility for maintenance of the CAs and the certificates they issue to trusted individuals throughout your organization. Or you can maintain centralized control. You can protect the root CA by taking it offline and locking it in a vault.

Removing a Portion of the Hierarchy
You can remove part of the trust, if necessary, by removing a CA from the lowest level or by removing one in the second layer and therefore removing trust from several CAs. The certificates they’ve issued can be revoked and the authority to issue new ones removed, but the rest of the CA infrastructure remains intact.

For example, if the London operations of Peach Weaver were sold, the London portion of the hierarchy could be removed. In the process, the certificates it issued would be revoked, as would be the CA certificates. Figure 2 illustrates this option. In the figure, the London intermediary CA and its portion of the hierarchy are removed after all the certificates they've issued have been revoked. No new certificates can be issued by the London CAs. Old smart cards issued by the London CA won’t work in New York or anywhere else.

Figure 2. The resulting CA hierarchy if the London portion of the hierarchy is removed.

Cross Certification
If Peach Weaver purchases another company, trust can be established by creating a new wing of the CA hierarchy. But what if that company already has a hierarchy? Or what if the relationship isn’t meant to subsume one company in another? What if the relationship is a partnership, some kind of mini-merger or association for the purposes of a project? In this case, the partner should have its own CA hierarchy, if it doesn’t already. What then?

The trust boundaries between CAs aren’t easily crossed. It’s like Windows NT domains or forests all over again. What’s needed is a way to create a trust relationship between CA hierarchies. You could obtain a copy of the root CA certificate from the root CA of the other company’s hierarchy and distribute it to every computer in your company, but that could be an onerous task. There’s an easier way: Create a trust relationship between the two CA hierarchies. That’s what cross certification does. The process of cross-certification of CA hierarchies is called qualified subordination.

Note: To learn more about cross certification, and for configuration details, read the article, “Planning and Implementing Cross Certification and Qualified Subordination Using Windows Server 2003” in TechNet at www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/plan/ws03qswp.asp.

Trust Relationships with Partners
Cross certification allows the administrator of one hierarchy to explicitly limit the use of partner hierarchy certificates in his or her forest. In its simplest form, cross certification means the issuance of a cross certification certificate by each CA hierarchy’s root CA and the installation of this certificate by the other CA hierarchy’s root CA. Figure 3 illustrates this full trust. In the figure the Peach Weaver and Star Fruit CA hierarchies trust each other. In this situation, every computer at Star Fruit trusts every certificate issued by any CA in the Peach Weaver CA hierarchy, and every computer at Peach Weaver trusts every certificate issued by every CA in the Star Fruit hierarchy.

Figure 3. In this example of cross certification, each company's root CA server trusts the other.

Limited Trust
This kind of simple, root-level cross certification isn’t the best thing to do, though. First, it could make both the trust relationship and its ending a messy thing. Without any limits, too much trust between the hierarchies, and thus, their companies, is established. Every relationship should have boundaries. Second, it isn’t a good idea to extend this type of trust from the root. Restricting root CAs to issuing certificates for the company’s intermediary CAs makes it easier to maintain and modify the hierarchy. Some organizations have explicit policies that spell this out.

But you still need a way to limit the trust granted when performing cross certification. One way is to issue the cross certification certificate from an intermediary CA. Trust extends downward from the CA that issues the certificate, limiting the trust to certificates issued by the CA that issues the cross certification certificate and those underneath it in the hierarchy. In Figure 3, cross certification is created between the CA hierarchies, but at the intermediary CA level. Certificates from the no2, no4 and no5 CAs in the Peach Weaver CA hierarchy will be trusted by the Star Fruit CA hierarchy. Certificates issued by the no1, no3 and no6 CAs won’t be. A similar trust is created with a subset of the Star Fruit hierarchy.

The type of cross certification shown in Figure 4 is the best way to go. In this example, the only Peach Weaver employees able to access resources in the Star Fruit company will be those issued certificates by the no4 CA. (The no2 and the no5 CA don’t issue user certificates.)

Figure 4. Limiting cross certification to lower-level CAs, as in this example, reduces security risks.

There’s also another way to limit the trust. The cross certification certificate can be qualified—limited for certain uses. This process, called qualified subordination, is effective in managing and limiting trust. There are four different types of constraints or limitations.

Basic constraints limit the path length of a chain. They specify how many CAs can exist below the CA from which the cross certification is assigned. This prevents the partner company from adding increased levels of CA hierarchies and extending the trust path.

Name constraints designate namespaces that are permitted. You can specify the namespace from the other hierarchy that will be trusted and exclude specific namespaces. A common practice would be to prevent a partner’s hierarchy from issuing certificates that include your namespace. This prevents your partner from elevating the privileges of users with certificates issued in this manner.

Application constraints allow an application to specify certificates it will accept. The information in the certificate must be correct, or it’s not accepted. Typical uses might be to define certificates accepted for authentication, encryption or even device drivers.

Policy constraints are those established in issuance policies. For instance, a certificate might be limited to being used at a specific spending level. (Several different certificates would be mapped to specific levels of spending. A user will be limited to the spending level specified for the certificate he or she holds.)

Note also that cross certification does have its drawbacks. One of them is the increased network traffic due to the extended length of the certificate chain. Certificate chaining traces certificates back to their roots in order to validate them. When cross certification is in place, chaining has to extend between two CA hierarchies.

Breaking Up Doesn’t Have to be Hard to Do
There are no guarantees in a relationship. Business relationships are the same way. Partnerships end, business divisions are sold. Using cross certification to develop the trust relationship between hierarchies will make it easier to dissolve the trust and thus replace the security boundary between partners. Cross certification certificates can also be given short life spans and prevented from automatically renewing, further limiting the relationship. To totally dissolve the relationship, certificates must be revoked and the cross certification certificate removed.