Why you need your own certification authority

Examples of 1) an intermediate CA in an open hierarchy of trust and 2) a private hierarchy that is isolated from an open hierarchy with its own root CA

Public Key Infrastructure (PKI) has traditionally been hierarchical. In it, certification authorities (CAs) are connected by subordination relationships. All users trust the same root (head) CA, and each lower CA submits to a higher one in the hierarchy.

But what if we want to create a private PKI infrastructure with our own CA? Indeed, in some situations, such intermediate or partial hierarchies are very convenient in practice.

Typical reasons for creating an intermediate or private hierarchy

Accommodation and support

A company can host and maintain its own CAs or outsource it. Many companies undertake the deployment of large-scale PKI systems on their own (insourcing), without having the necessary resources for this. Since the process requires investment, it is better to evaluate in advance your material resources and financial capabilities at the moment and in the coming years, the economic effect of using new technology, initial costs and the cost of the system.

Having made such an assessment, some organizations may come to the conclusion that they do not need the public key infrastructure, and in their case it is better to use other security tools: for example, VPN or file encryption programs. Instead of the entire PKI infrastructure, it is sometimes easier to run only a certificate server, which solves the problems of unauthorized access to web content (IntranetSSL, see above).

Intermediate or private hierarchy

In an open hierarchy, all CAs are subordinate to the root CA, whose public key is embedded in a public application, such as a web browser. In this case, the browser can automatically check the validity of certificates issued by all CAs in the entire hierarchy, as well as their publishers, which is an indisputable advantage.

Open hierarchies are usually used in cases where information exchange with non-affiliated parties or their authentication is required. In this case, the outsourcing CA is the third trusted party.

In the case of a private hierarchy, the end user manually adds the public key of the corporate root CA to the list of trusted keys embedded in the application. In this case, all responsibility for using the key lies with the user. Private hierarchies are more suitable for closed communities, for example, users of a corporate portal.

Typical Intermediate or Private Hierarchy Examples

For any of the above examples, CA support can be outsourced. Branding is still possible, but hierarchies are hosted and managed by GlobalSign in secure data centers with proven hardware and software. Non-standard scenarios will be helped by escort engineers.

It seems that giving your hierarchy of trust to outsourcing, you lower the level of security, but in practice it is the other way around. This ensures that all CA components are properly protected and tuned in accordance with the latest industry best practices. An additional benefit is the saving of costs and resource load on internal teams to support PKI. Only in some rare cases (for example, SSL verification / decryption) the intermediate link should be located at the client.

Source: https://habr.com/ru/post/462501/

All Articles