Design and build a privately hosted Public Key Infrastructure

A separate, intermediate CA, should be used per technology or organisational function. Technology functions include such things a VPN or a web application. Organisational functions include user authentication, machine authentication, or service authentication.

For smaller deployments, having too many CAs may add an unacceptable level of administration overhead. There is a balance to be struck between the number of CAs used in an environment, the administration overhead and the required security level.

Separating CAs in this way will reduce the impact of compromise of a single CA and provide a separation of duty between each CA.

You should also keep your CA hierarchy simple, we don't recommend going beyond 3 tiers as too many levels will make management of your PKI difficult.

Enforcing hierarchical structure

There is a set of fields with in a certificate called basic constraints which determines whether it's a CA certificate and it also describes the path length which states how many intermediate CA's need to be checked in a certificate path. This will determine if a CA can issue another CA certificate or can only issue end entity certificates. Consider using path lengths as this will help reduce the likelihood of an unauthorised CA certificate being issued.

If supported by your PKI provider or software, name constraints can also help enforce which subject names - Domain or IP address - a CA can issue a certificate to.

Path length

The Path length field in a certificate describes the maximum depth of a valid certification path. They are important as they describe the number of intermediate CA's in a hierarchy that need to be checked when checking the certificate path. The last certificate in the chain is not an intermediate certificate and is normally a Root CA. Therefore, the last certificate in the chain which is normally the root CA is not part of the path length count and the field is set to unspecified.

If an intermediate CA requires to sign another CA, the path length constraint should be set to its position in the CA hierarchy. For example, in a 3 tier hierarchy the Root CA path length will be unspecified, the next intermediate CA will have a length of one as its required to sign another CA and the last CA will have a value of zero.

It’s important for the CA that issues end entity certificates to have a path length of zero. This will ensure the last CA can only sign end entity certificate and cannot create a new unauthorised CA’s.

>

Name Constraints

Name constraints can be used by a CA administrator to limit which subject names can be issued on a certificate by a given CA. This helps to enforce a level of segmentation of duty. 

For example, the cert could be configured so it can only issue certificates for sub domains of “.example.com”. This acts a bit like an allow list.

Alternatively, you could deny a CA from issuing certificates for certain subject names. For example do not allow a CA to issue certificates for a domains ending ".com".

Separation and root CAs

In larger deployments, you may also want to consider separate root CAs for certain functions. For example, a separate root for web applications, because you happen to host many applications. Then you can use a separate intermediate CA per type of web application.

There needs to be a balance between a tolerable amount of administration overhead and the separation of root CAs.