Stay organized with collections
Save and categorize content based on your preferences.
Trust model
Background
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 example.com 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
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-09-04 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 UTC."],[[["\u003cp\u003eWeb Public Key Infrastructure (PKI) relies on independent certificate authorities (CAs) to verify identities in certificates, using standardized verification processes.\u003c/p\u003e\n"],["\u003cp\u003ePrivate PKI differs from Web PKI by having a smaller, organization-managed CA hierarchy, allowing for more flexible identity validation methods.\u003c/p\u003e\n"],["\u003cp\u003ePrivate PKI offers advantages such as securing internal websites with short domain names and supporting alternative identity formats, unlike Web PKI.\u003c/p\u003e\n"],["\u003cp\u003eCertificate Authority Service simplifies private PKI management by enabling easy creation and management of CAs, without dictating specific identity validation methods.\u003c/p\u003e\n"],["\u003cp\u003eCertificate Authority Service offers policy controls to allow for fine-grained control over CA pools.\u003c/p\u003e\n"]]],[],null,["# Trust model\n===========\n\nBackground\n----------\n\nIn a typical Web Public Key Infrastructure (PKI), millions of clients across the\nworld trust a set of independent certificate authorities (CAs) to assert identities\n(such as domain names) in certificates. As part of their responsibilities, CAs commit\nto only issuing certificates when they have independently validated the identity\nin that certificate. For example, a CA typically needs to verify that\nsomebody requesting a certificate for the domain name `example.com` actually\ncontrols the said domain before they issue a certificate to them. Since those CAs\ncan issue certificates for millions of customers where they might not have an\nexisting direct relationship, they are limited to asserting identities that are\npublicly verifiable. Those CAs are limited to certain well-defined verification\nprocesses that are consistently applied across the Web PKI.\n\nUnlike Web PKI, a private PKI often involves a smaller CA hierarchy, which is\ndirectly managed by an organization. A private PKI sends certificates only to clients\nthat inherently trust the organization to have the appropriate controls (for\nexample, machines owned by that organization). Since the CA admins often have\ntheir own ways of validating identities for which they issue certificates (for\nexample, issuing certificates to their own employees), they aren't limited by\nthe same requirements as for Web PKI. This flexibility is one of the main advantages\nof private PKI over Web PKI. A private PKI enables new use-cases such as securing\ninternal websites with short domain names without requiring unique ownership of\nthose names, or encoding alternative identities formats (such\nas [SPIFFE IDs](https://spiffe.io/docs/latest/spiffe/concepts/#spiffe-id)) into\na certificate.\n\nCertificate Authority Service aims to simplify the process of managing private PKI by\nallowing you to easily create and manage CAs. As such, CA Service\ndoes 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](/certificate-authority-service/docs/policy-controls).\n\nWhat's next\n-----------\n\n- Learn more about [policy controls](/certificate-authority-service/docs/policy-controls).\n- Learn how to [configure IAM policies](/certificate-authority-service/docs/configuring-iam).\n- Learn how to [use an issuance policy](/certificate-authority-service/docs/use-issuance-policy)."]]
