If you have a website that provides a service to clients outside of your organization, chances are it has a digital certificate that is publicly rooted. This means that the chain of trust leads to a root certificate issued by a well-known Certificate Authority (CA) already trusted by your users’ browsers and other major application technologies (e.g., Java). Leveraging a public root enables you to instantly achieve universal trust across your user base.

You may also have a number of other servers that are not external facing and will not need publicly rooted certificates. These servers, however, may still need authentication and signing capabilities to establish a secure TLS session with other internal servers or applications. The root of trust for these servers would be a private Certificate Authority CA; a CA of your own.

With a Private CA (or “Private PKI”) solution, you can brand the certificates for your servers, devices, and users. Since the purpose of this CA is to serve your organization only, it will provide a tighter control when its Public Key Infrastructure (PKI) is used for internal user authentication. For this reason, Private PKI is immensely popular for deployment in enterprise IT, as well as cloud-native DevOps and Internet of Things (IoT) environments.

While a Root CA acts as the root of trust, an Issuing CA is responsible for dispensing certificates to end entities, such as, a device or user.

Here are three deployment architectures to consider when looking to maximize security for your internal communications.

Three Deployment Scenarios

  1. Security vendor hosts the Private Root CA as well as Issuing CA(s) for you on the cloud,
  2. Your organization hosts the Private Root CA of your choosing and the security vendor hosts the Issuing CA(s) for you,
  3. The security vendor hosts the Private Root CA and your organization hosts issuing CA(s) of your own

Some organizations prefer Option 1 above as all PKI operational aspects, including hosting, maintenance, security, and compliance, are taken care of by the security vendor (Fig 1). You simply obtain and install certificates from them and deploy them into your environment.

 

sectigo 1

Figure 1

However, some organizations may already have a Private Root CA in-house, or their enterprise security policy may dictate that the Root CA reside in their environment. In this case, the security vendor (Fig 2) may host and manage the issuing CA(s), which will be signed by their on-premise Root CA. Since the bulk of the work is done at the Issuing CA, it offloads the customer from a lot of day-to-day overhead.

 

sectigo 2

Figure 2

 

In the third scenario (Fig 3), an organization may have a CA such as Microsoft CA, HashiCorp Vault PKI instance, or Kubernetes CA, running in their environment and integrated with their applications.

You can greatly improve your security posture by having a security vendor host an offline Root CA with keys stored in a Hardware Security Module (HSM) in an industry-standard compliant, audited data center, and sign your existing CA, which will then issue and manage the end entity certificates to users and devices.

sectigo 3

Figure 3

 

IT and DevOps Friendly Private PKI

For container-to-container and application-to-application authentication and secure communication between them, you will likely leverage privately trusted certificates in your AWS, Azure, or other cloud environments.

Some vendors have integrated their Private PKI with the most popular DevOps tools so that when you are rolling out your infrastructure and applications in an automated fashion, you can seamlessly enroll certificates from their Private PKI and manage certificate lifecycles. In addition, to ensure that your software is not tampered with, you would want to code sign your container and other applications, which could be issued from the same PKI infrastructure as well.

With the advent of the cloud-friendly micro-service architecture, your services may come and go, which will require high-volume, short-lived certificates. This reality makes it important to select a Private PKI solution that is capable of issuing and managing certificates with a short lifecycle. The vendor’s licensing scheme should support this business model as well, making it cost-efficient.

 

Automation Essentials

Automation plays a prominent role in certificate management. Certificate lifecycle management, including, issuance, renewal, replacement and revocation, is expensive unless automation is in place. Some vendors support industry standard protocols, such as, Enrollment over Secure Transport (EST), Simple Certificate Enrolment Protocol (SCEP), etc., which provide automation. These protocols easily integrate with third-party tools, such as Kubernetes cert-manager, HashiCorp Terraform and Vault, Ansible, Puppet, Chef, and other DevOps tools.

In Microsoft Windows environments, you can leverage an auto-enrollment capability to automatically issue certificates from a Microsoft CA. Some vendors leverage this capability to enable issuance from their own Private CA.

 

Centralizing Management

Most organizations prefer to not rely on two different vendors to obtain their public and private certificates. With that in mind, some vendors have designed their certificate management platforms to enable security and operations teams to manage all certificates from a central management console.

Centralized consoles provide a consistent experience for every possible certificate being managed and make the status and expiry dates of every certificate clearly visible, helping to prevent costly disruptions. In addition, some certificate management systems can discover all your certificates and report on them.

The industry is heading toward more automated PKI management systems that provide a single pane of glass view of every public and private certificate in an enterprise—and organizations are embracing this approach. After all, who doesn’t want to reduce operational costs and prevent human errors that could result in a service outage?