Trust model


In a typical Web Public Key Infrastructure (PKI), millions of clients across the world trust a set of independent certificate authorities (CAs) to assert identities (such as domain names) in certificates. As part of their responsibilities, CAs commit to only issuing certificates when they have independently validated the identity in that certificate. For example, a CA typically needs to verify that somebody requesting a certificate for the domain name actually controls the said domain before they issue a certificate to them. Since those CAs can issue certificates for millions of customers where they might not have an existing direct relationship, they are limited to asserting identities that are publicly verifiable. Those CAs are limited to certain well-defined verification processes that are consistently applied across the Web PKI.

Unlike Web PKI, a private PKI often involves a smaller CA hierarchy, which is directly managed by an organization. A private PKI sends certificates only to clients that inherently trust the organization to have the appropriate controls (for example, machines owned by that organization). Since the CA admins often have their own ways of validating identities for which they issue certificates (for example, issuing certificates to their own employees), they aren't limited by the same requirements as for Web PKI. This flexibility is one of the main advantages of private PKI over Web PKI. A private PKI enables new use-cases such as securing internal websites with short domain names without requiring unique ownership of those names, or encoding alternative identities formats (such as SPIFFE IDs) into a certificate.

Certificate Authority Service aims to simplify the process of managing private PKI by allowing you to easily create and manage CAs. As such, CA Service does not define how identities in certificates must be validated. However, CA Service provides a robust set of policy controls that allows fine-grained configuration of CA pools. For more information, see Policy controls.

What's next