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

• Customer authentication
  
  
  
  It is convenient to make client authentication with certificates based on an intermediate CA. If you have an exclusive subordinate CA, you can limit the number of certificates that provide access to the system. In these cases, private trust hierarchies are usually used.
  
  
• Branding
  
  
  
  For companies that offer certificates to their customers or include them in the package of services provided, the presence of their own dedicated CA allows you to offer some additional branding opportunities.
  
  
• SSL / TLS Inspection / Decryption
  
  
  
  For an SSL verifier to decrypt and re-encrypt content, it must be able to issue certificates as needed. This means that you need your own subordinate CA outside the public hierarchy of trust. In this case, the root CA is located at GlobalSign, and the intermediate CA is located on the client’s certificate verification device.
  
  
• Special Purpose Certificates
  
  
  
  Certificates issued within private hierarchies can support legacy applications and unique configurations, such as longer validity periods and smaller key sizes, that are not allowed in public trusted certificates according to the basic requirements of the CA / Browser Forum. However, if you need only private SSL / TLS certificates, without a full-fledged private CA, then you can use the IntranetSSL service.
  
  
• Custom Profiles
  
  
  
  You can configure the subordinate CA for specific tasks by changing the key extension policies, certificate policies, distribution point of certificate revocation lists (CRL) to your needs, making short-term certificates, etc.

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

• Dedicated Private Root CA and Hierarchy (Private PKI)
  
  GlobalSign can create and host private hierarchies, including root and intermediate. They are built on the same secure infrastructure that is used to support their own root CAs in an open hierarchy.
  
  
• Corporate Private Intermediate CA, Certificate Issuing Center
  
  Brand intermediate CAs are created specifically for a particular client, with a chain of trust to the root CA in an open hierarchy. These intermediate nodes can also be hosted and maintained by GlobalSign, which eases the burden of managing PKI and expert knowledge for internal teams.
  
  
• Shared Open Root CA (Managed PKI Platform)
  
  Although in certain situations dedicated root CAs and hierarchies are required, most organizations can fulfill the regulatory requirements for certificates using specialized services on the PKI (Managed PKI) management platform . The all-in-one certificate management portal provides advanced billing, user management, reporting, and more.
  
  
• Shared Private Root CA (IntranetSSL)
  
  IntranetSSL , available through the PKI management platform, provides a cost-effective way to issue and manage SSL / TLS certificates for internal servers and applications. These certificates are issued from a common, non-public GlobalSign Certification Authority, therefore, they may include configurations that the CA / Browser forum prohibits using in public certificates (for example, valid for more than three years, internal server names or reserved IP addresses).
  
  
• IoT Trust Root
  
  IoT Trust Roots have the same flexibility as traditional Trust Roots, but are tailored to specific IoT requirements. Dedicated private hierarchies, proprietary publicly accessible intermediate CAs, root centers in an open or private hierarchy can be used to protect IoT devices, platforms, gateways, and networks depending on the level of trust required.
  
  
• Special Hierarchy of Trust
  
  GlobalSign supports almost any hierarchy configuration. If you need a model different from the one described above, or it is not immediately clear which architecture is best suited for a particular ecosystem, then it is best to discuss with a specialist and consultant to build a trust architecture that meets specific needs.

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.