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
- November 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)
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.
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
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.
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.