[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-12。"],[[["\u003cp\u003eIAM roles are used to manage user permissions, and custom roles are recommended for assigning a diverse set of permissions to individuals.\u003c/p\u003e\n"],["\u003cp\u003eCertificate Authority (CA) Service offers two tiers, DevOps and Enterprise, with the latter generally recommended for creating CA pools that issue certificates to other CAs and end-entities, while the former is better for short-lived certificates.\u003c/p\u003e\n"],["\u003cp\u003eUsing Google-owned and managed encryption keys is recommended for simplified and secure key management, unless custom requirements dictate otherwise.\u003c/p\u003e\n"],["\u003cp\u003eImporting existing external CAs with previously issued certificates into CA Service is not supported, and instead, new keys should be generated or existing ones should be imported into Cloud KMS/HSM.\u003c/p\u003e\n"],["\u003cp\u003eChoosing the appropriate cryptographic key size and algorithm for CA signing keys is crucial for security and longevity, with ECDSA recommended in modern environments and RSA as a viable alternative for wider compatibility.\u003c/p\u003e\n"]]],[],null,["# Best practices for Certificate Authority Service\n================================================\n\nThis page outlines some of the best practices that can help you use Certificate Authority Service more effectively.\n\nRoles and access control\n------------------------\n\nUsing Identity and Access Management (IAM), you can grant roles to users. Roles are a bundle of one or more permissions. Roles in IAM can either be basic, predefined, or custom.\n\nIndividuals shouldn't be assigned more than one role at any given time. In addition, everyone holding an assigned role should be properly briefed and trained on their responsibilities and security practices. If you want to assign a diverse set of permissions to an individual, we recommend that you create a custom role using IAM. For information about creating a custom role, see [Creating and managing custom roles](/iam/docs/creating-custom-roles).\n\nFor information about permissions and predefined IAM roles, see\n[Access control with IAM](/certificate-authority-service/docs/access-control).\n\nCA Service tiers\n----------------\n\nTiers are set for the certificate authority (CA) pool. All CAs in a CA pool are assigned the same tier. CA Service provides two operational service tiers for CA pools: DevOps and Enterprise. These two tiers provide organizations with a balance of performance and lifecycle management capabilities based on operational requirements.\n\n- We recommend that you carefully consider using the DevOps tier because it doesn't support certificate revocation.\n- For CAs in the DevOps tier, issued certificates are not stored. You can only track certificates by reviewing [Cloud Audit Logs](/logging/docs/audit), if enabled. We recommend that you use the DevOps tier only for short-lived certificates that don't need to be revoked, such as certificates used with microservices, containers, session certificates, non-persistent virtual machines, and other isolated needs.\n- A Public Key Infrastructure (PKI) can consist of a combination of CAs in DevOps and Enterprise tiers to meet various needs.\n- In most cases, we recommend that you use the Enterprise tier to create CA pools that issue certificates to other CAs and end-entities.\n\nFor more information about CA Service tiers, see [Select the operation tiers](/certificate-authority-service/docs/tiers).\n\nFor information about enabling Cloud Audit Logs, see [Configuring Data Access audit logs](/logging/docs/audit/configure-data-access).\n\nCA signing keys\n---------------\n\nThe proper control of the underlying cryptographic key pair for CA certificates determines the security and integrity afforded by the PKI. This section lists some best practices for securing CA signing keys.\n\n### Hardware Security Modules (HSM)\n\nYou can configure CA Service to use Google-owned and Google-managed encryption keys that use\nCloud HSM for generating, storing, and using keys. However, if you want to\nuse an existing Cloud KMS key, you can use the key during the setup of\nthe CA.\n\nFor more information about Cloud HSM, see [Cloud HSM](/kms/docs/hsm).\n| **Note:** After you create or import a key to Cloud HSM, it is not possible to export that key and migrate to another platform.\n\nFor more information about importing a cryptographic key into Cloud HSM or Cloud KMS, see [Importing a key into Cloud KMS](/kms/docs/importing-a-key).\n\n### Google-managed versus customer-managed keys\n\nIf you don't have a custom security or operational requirement that requires\ndirect management of keys outside of CA Service, we recommend that\nyou use Google-owned and Google-managed encryption keys. Google-owned and Google-managed encryption keys provide a simplified and\nsecure-by-default key generation, storage, and utilization system.\n\nGoogle-owned and Google-managed encryption keys use Cloud HSM and aren't accessible or usable by any\nother organization. Access and use of Cloud HSM signing keys are auditable\nthrough Cloud Audit Logs.\n| **Note:** CA keys are only used for signing issued certificates. They are not used for encrypting information on CA Service.\n\nFor more information about lifecycle management models, see [Manage resources](/certificate-authority-service/docs/managed-resources).\n\n### Importing external CAs\n\nIt isn't possible to import previously issued certificates into CA Service. We recommend that you don't import an existing external CA with issued certificates into CA Service.\n\n### Key Escrow\n\nCA Service uses Cloud KMS and Cloud HSM to protect keys from export and extraction. If your organization wants to maintain a copy of its CA keys, you can generate keys using on-premises tools. To use those keys with CA Service, import the keys to Cloud KMS and Cloud HSM. You can then safely escrow the keys and maintain possession until needed in future.\n\nFor information about importing keys into Cloud KMS, see [Importing a key into Cloud KMS](/kms/docs/importing-a-key).\n\n### CA key sizes and algorithms\n\nCryptographic key sizes and algorithms define the type and strength of the asymmetric key-pair that is used to sign certificates and Certificate Revocation Lists (CRLs). CAs can live for a relatively long period. Therefore, it is important that the keys are strong enough to be secure throughout the CA's intended lifetime.\n\nIf you have a well-defined PKI environment with modern devices, [Elliptic Curve Digital Signature Algorithm (ECDSA)](/certificate-authority-service/docs/choosing-key-algorithm#ecdsa) offers the best performance and security. In organizations with a wide range of systems and uncertainty about key support, it could be sufficient to use RSA-based keys.\n\nThere are also other considerations for CA signing keys, such as compliance with certifications, compatibility with other systems, and the specific threat models. Consider your use case when choosing a key size and algorithm.\n\nRegardless of the CA lifetime, or key size and algorithm, we recommend that you set up a process for regular rotation of CA keys.\n\nFor more information about choosing an algorithm for signing keys, see\n[Choose a key algorithm](/certificate-authority-service/docs/choosing-key-algorithm).\n\nWhat's next\n-----------\n\n- [Create a CA pool](/certificate-authority-service/docs/creating-ca-pool)\n- [Create a root certificate authority](/certificate-authority-service/docs/creating-certificate-authorities)\n- [Create a subordinate certificate authority](/certificate-authority-service/docs/create-subordinate-ca)\n- [Create a certificate template](/certificate-authority-service/docs/creating-certificate-template)"]]
