Lesson 4: Understanding CA Trust Models
For a CA solution to scale to support any size enterprise, there must be a structure in place to allow the CAs to validate certificates provided by other CAs. Trusts and trust models allow this to happen.
Understand what a trust is between CAs
Understand what a mesh trust model is
Understand what a hierarchical trust model is
Understand what a bridge CA is used for
Trust Models
When multiple CAs are implemented in an infrastructure, there must be a way for one CA to accept the certificates issued by another CA. They must be able to rely on each other's certificates for the CA structure to scale to any size deployment. For a PKI, a trust is a relationship that allows a CA to trust a certificate issued by another CA. A trust path links several CAs together so that the trust relationship can extend beyond the two CAs that have formed a trust.
For a CA to form a trust relationship with another CA, each issues a certificate for the other CA. For instance, if CA1 and CA2 want to trust the certificates that each has issued, both CAs would issue a certificate for each other. When a user or process issued a certificate by CA1 authenticates with CA2, CA2 validates that it issued a certificate to CA1. If it does have a valid certificate, CA2 trusts the certificate issued by CA1. Two common ways to configure trust paths that provide a scalable solution involve using a mesh architecture or a hierarchical architecture.
Mesh Architecture
With a mesh architecture, multiple peer CAs issue certificates to each other. To certify, they create certificates for each other. Figure 3-6 shows a peer CA arrangement with users and computers on two different CAs. Use this figure to follow the example given here.
Figure 3-6. Mesh CA infrastructure
UserA has a certificate issued by CA1 and needs access to data on ServerA. ServerA has a certificate issued by CA5.
The process follows like this:
UserA presents its certificate to ServerA.
ServerA verifies UserA certificate with CA1.
ServerA verifies CA1 certificate with CA3.
ServerA verifies CA3 certificate with CA5.
Because ServerA relies on CA5 and CA5 trusts CA3, CA3 trusts CA1, and CA1 issued the certificate for UserA, the certificate is valid with ServerA.
Hierarchical Architecture
With a hierarchical architecture, there is a top-level CA known as a root CA, which issues certificates to subordinate CAs. Those CAs can then issue certificates to other CAs, and so on. The CAs at each level can issue certificates to subordinate CAs or users. All certificate holders in the hierarchy know the root CA; therefore the certification path need only be from subordinate CAs to the CA directly up the hierarchy. Figure 3-7 shows a hierarchical CA arrangement with users and computers on two different CAs. Use this figure to follow the example given here.
UserA has a certificate issued by CA1 and needs access to data on ServerA. ServerA has a certificate issued by CA5.
The process follows like this:
UserA presents its certificate to ServerA.
ServerA verifies UserA certificate with CA1.
ServerA verifies CA1 certificate with CA3.
ServerA verifies CA3 certificate with RootCA.
Because all certificate holders know the root CA, ServerA relies on RootCA, RootCA trusts CA3, CA3 trusts CA1, and CA1 issued the certificate for UserA, the certificate is valid with ServerA.
Figure 3-7. Hierarchical CA infrastructure
Bridge CA Architecture
A bridge CA connects mesh and hierarchical architectures together. This allows different companies to have their own trust architecture, and then have a single connection using a bridge CA. If the trust relationship needs to be broken, there is only a single point to manage.
If the bridge is connecting to a hierarchical structure, then the trust is with the root CA.
If the bridge is connecting with a mesh structure, then the trust is with a single CA.
The CA that connects with a bridge CA is known as a principal CA. Figure 3-8 shows a bridge CA arrangement with users and computers on two different CA architectures. Use this figure to follow the example given here.
UserA has a certificate issued by CA1 and needs access to data on ServerA. ServerA has a certificate issued by CA5.
The process follows like this:
UserA presents its certificate to ServerA.
ServerA verifies UserA certificate with CA1.
ServerA verifies CA1 certificate with RootCA.
ServerA verifies RootCA with BridgeCA.
ServerA verifies BridgeCA with CA3.
ServerA verifies CA3 with CA5.
A bridge CA does not issue certificates to end users, but does issue certificates to other CAs.
Figure 3-8. Bridge CA
The following questions are intended to reinforce key information presented in this lesson. If you are unable to answer a question, review the lesson and then try the question again. Answers to the questions can be found in Appendix A, "Questions and Answers."
You are the security specialist for your company and you have just installed a third CA. Each CA supports three different geographical locations. You are attempting to access a server that was issued a certificate by the new CA, but your certificate is not being accepted. Which is the best way to solve the problem?
Have the new CA issue you a certificate
Have the new CA and each of the old CAs issue a certificate to each other
Reinstall the software on the new CA
Make the new CA a bridge CA
Which statements are true of a mesh architecture? Select all that apply.
Connects mesh and hierarchical architectures together.
There is a top-level CA known as a root CA.
Multiple peer CAs issue certificates to each other.
Does not issue certificates to end users.
Which statements are true of a hierarchical architecture? Select all that apply.
Connects mesh and hierarchical architectures together.
There is a top-level CA known as a root CA.
Multiple peer CAs issue certificates to each other.
Does not issue certificates to end users.
Which statements are true of a bridge CA? Select all that apply.
Connects mesh and hierarchical architectures together.
There is a top-level CA known as a root CA.
Multiple peer CAs issue certificates to each other.
Does not issue certificates to end users.
Lesson Summary
To create a scalable solution, you have to design a CA architecture so that CAs can validate certificates issued by other CAs by establishing trusts between CAs.
Trusts are established between CAs by having each CA issue a certificate to the other CA.
With mesh trust architectures, all CAs issue certificates for all other CAs. This provides multiple trust paths that can be used for certificate validation.
Hierarchical trusts establish a top-level CA known as a root CA. Subordinate CAs can be created below that. All users issued certificates in the hierarchy know the root CA, so certificate validation across multiple arms of the hierarchical structure validate through the root CA.
Bridge CAs connect mesh and hierarchical architectures together. They do not issue certificates to end users, only to other CAs.