Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Certificate Authority Service – Übersicht
Certificate Authority Service (CA Service) ist ein hochskalierbarerGoogle Cloud Dienst, mit dem Sie die Bereitstellung, Verwaltung und Sicherheit privater Zertifizierungsstellen (Certificate Authorities, CAs) vereinfachen und automatisieren können.
Private Zertifizierungsstellen stellen digitale Zertifikate aus, die Entitätsidentität, Ausstelleridentität und kryptografische Signaturen enthalten. Private Zertifikate sind eine der gängigsten Methoden, um Nutzer, Computer oder Dienste über Netzwerke zu authentifizieren. Private Zertifikate werden häufig in DevOps-Umgebungen verwendet, um Container, Mikrodienste, virtuelle Maschinen und Dienstkonten zu schützen.
Mit CA Service haben Sie folgende Möglichkeiten:
- Benutzerdefinierte Stamm- und untergeordnete Zertifizierungsstellen erstellen
- Geben Sie das Subjekt, den Schlüsselalgorithmus und den Standort der Zertifizierungsstelle an.
- Wählen Sie die Region einer untergeordneten Zertifizierungsstelle unabhängig von der Region der Stammzertifizierungsstelle aus.
- Wiederverwendbare und parametrisierte Vorlagen für gängige Szenarien zur Ausstellung von Zertifikaten erstellen
- Sie können Ihre eigene Root-Zertifizierungsstelle verwenden und andere Zertifizierungsstellen so konfigurieren, dass sie mit der vorhandenen Root-Zertifizierungsstelle verknüpft werden, die lokal oder an einem anderen Ort ausgeführt wird. Google Cloud
- Speichern Sie Ihre privaten CA-Schlüssel mit Cloud HSM. Dieser Dienst entspricht FIPS 140-2 Level 3 und ist in mehreren Regionen in Amerika, Europa und dem asiatisch-pazifischen Raum verfügbar.
- Cloud-Audit-Logs liefern Ihnen Logs, aus denen Sie genau ersehen können, wer was wann und wo getan hat.
- Definieren Sie detaillierte Zugriffssteuerungen mit Identity and Access Management (IAM) und virtuelle Sicherheitsbereiche mit VPC Service Controls.
- Sie können große Mengen von Zertifikaten verwalten, da der CA-Dienst die Ausstellung von bis zu 25 Zertifikaten pro Sekunde und CA (DevOps-Stufe) unterstützt. Das bedeutet, dass jede Zertifizierungsstelle Millionen von Zertifikaten ausstellen kann. Sie können mehrere Zertifizierungsstellen hinter einem einzigen Ausstell-Endpunkt erstellen, der als CA-Pool bezeichnet wird, und die eingehenden Zertifikatsanfragen auf alle Zertifizierungsstellen verteilen. Mit dieser Funktion können Sie bis zu 100 Zertifikate pro Sekunde ausstellen.
- Sie können private Zertifizierungsstellen so verwalten, automatisieren und einbinden, wie es für Sie am praktischsten ist: über APIs, die Google Cloud CLI, die Google Cloud Console oder Terraform.
Anwendungsfälle für Zertifikate
Sie können Ihre privaten Zertifizierungsstellen verwenden, um Zertifikate für die folgenden Anwendungsfälle auszustellen:
- Integrität der Softwarelieferkette und Codeidentität: Codesignatur, Authentifizierung von Artefakten und Zertifikate für Anwendungsidentitäten.
- Nutzeridentität: Clientauthentifizierungszertifikate, die als Nutzeridentität für Zero-Trust-Netzwerke, VPN, Dokumentensignatur, E-Mail, Smartcard usw. verwendet werden.
- IoT- und Mobilgeräte-Identität: Clientauthentifizierungszertifikate, die als Geräteidentität und Authentifizierung verwendet werden, z. B. für den drahtlosen Zugriff.
- Intraservice-Identität: mTLS-Zertifikate, die von Microservices verwendet werden.
- CI/CD-Kanäle (Continuous Integration und Continuous Delivery): Zertifikate zur Codesignatur, die während des CI/CD-Builds verwendet werden, um die Codeintegrität und -sicherheit zu verbessern.
- Kubernetes und Istio: Zertifikate zum Schützen von Verbindungen zwischen den Kubernetes- und Istio-Komponenten.
Vorteile einer privaten PKI
In einer typischen Web-Public-Key-Infrastruktur (PKI) vertrauen Millionen von Kunden auf der ganzen Welt einer Reihe unabhängiger Zertifizierungsstellen (CAs), um Identitäten (z. B. Domainnamen) in Zertifikaten zu bestätigen. Im Rahmen ihrer Zuständigkeit verpflichten sich Zertifizierungsstellen, nur Zertifikate auszustellen, wenn sie die Identität in diesem Zertifikat unabhängig bestätigt haben. Beispielsweise muss eine Zertifizierungsstelle in der Regel prüfen, ob jemand, der ein Zertifikat für den Domainnamen example.com anfordert, tatsächlich die Kontrolle über die Domain hat, bevor sie ihm ein Zertifikat ausstellt. Da diese Zertifizierungsstellen Zertifikate für Millionen von Kunden ausstellen können, zu denen sie möglicherweise keine direkte Beziehung haben, sind sie auf die Bestätigung von Identitäten beschränkt, die öffentlich nachprüfbar sind. Diese Zertifizierungsstellen sind auf bestimmte, klar definierte Überprüfungsverfahren beschränkt, die in der Web PKI einheitlich angewendet werden.
Im Gegensatz zu Web PKI umfasst eine private PKI oft eine kleinere Zertifizierungsstellenhierarchie, die direkt von einer Organisation verwaltet wird. Eine private PKI sendet Zertifikate nur an Clients, die der Organisation vertrauen, dass sie die entsprechenden Kontrollen hat (z. B. Maschinen, die dieser Organisation gehören). Da die Administratoren der Zertifizierungsstelle häufig eigene Methoden zur Validierung von Identitäten haben, für die sie Zertifikate ausstellen (z. B. Zertifikate für ihre eigenen Mitarbeiter), sind sie nicht durch dieselben Anforderungen wie bei der Web PKI eingeschränkt. Diese Flexibilität ist einer der Hauptvorteile der privaten PKI gegenüber der Web-PKI. Eine private PKI ermöglicht neue Anwendungsfälle, z. B. die Sicherung interner Websites mit kurzen Domainnamen, ohne dass eine eindeutige Inhaberschaft dieser Namen erforderlich ist, oder die Codierung alternativer Identitätsformate (z. B. SPIFFE-IDs) in einem Zertifikat.
Darüber hinaus müssen alle Zertifizierungsstellen gemäß der Web PKI jedes von ihnen ausgestellte Zertifikat in öffentlichen Zertifikatstransparenz-Protokollen erfassen. Dies ist für Organisationen, die Zertifikate für ihre internen Dienste ausstellen, möglicherweise nicht erforderlich. Mit einer privaten PKI können Organisationen ihre interne Infrastrukturtopologie, z. B. die Namen ihrer Netzwerkdienste oder Anwendungen, vor dem Rest der Welt verbergen.
Nächste Schritte
Sofern nicht anders angegeben, sind die Inhalte dieser Seite unter der Creative Commons Attribution 4.0 License und Codebeispiele unter der Apache 2.0 License lizenziert. Weitere Informationen finden Sie in den Websiterichtlinien von Google Developers. Java ist eine eingetragene Marke von Oracle und/oder seinen Partnern.
Zuletzt aktualisiert: 2025-08-12 (UTC).
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-12 (UTC)."],[[["\u003cp\u003eCertificate Authority Service (CA Service) is a scalable Google Cloud service for managing and securing private certificate authorities (CAs), which are used for authenticating users, machines, or services over networks.\u003c/p\u003e\n"],["\u003cp\u003eCA Service allows the creation of custom root and subordinate CAs, and includes features such as customizable templates, bring-your-own root CA, secure key storage with Cloud HSM, audit logging, and granular access controls.\u003c/p\u003e\n"],["\u003cp\u003eCA Service supports high-volume certificate issuance, up to 25 certificates per second per CA, with the ability to create multiple CAs behind one CA pool to issue up to 100 certificates per second.\u003c/p\u003e\n"],["\u003cp\u003ePrivate CAs are advantageous over Web PKI because they allow organizations greater flexibility in validating identities and enable use cases like securing internal sites with short domain names and encoding alternative identity formats.\u003c/p\u003e\n"],["\u003cp\u003ePrivate CAs also offer enhanced privacy, as they do not require public logging of issued certificates, thus allowing organizations to keep their internal network structure confidential.\u003c/p\u003e\n"]]],[],null,["# Certificate Authority Service overview\n======================================\n\nCertificate Authority Service (CA Service) is a highly scalable\nGoogle Cloud service that lets you simplify and automate the\ndeployment, management, and security of private certificate authorities (CA).\nPrivate CAs issue digital certificates that include entity identity, issuer identity,\nand cryptographic signatures. Private certificates are one of the most common\nways to authenticate users, machines, or services over networks. Private\ncertificates are often used in DevOps environments to protect\ncontainers, microservices, virtual machines, and service accounts.\n\nUsing CA Service, you can do the following:\n\n- Create custom root and subordinate CAs.\n- Define the subject, key algorithm, and location of the CA.\n- Select a subordinate CA's region independent of its root CA's region.\n- Create reusable and parameterized templates for common certificate issuance scenarios.\n- Bring your own root CA and configure other CAs to chain up to the existing root CA running on-premises or anywhere else outside Google Cloud.\n- Store your private CA keys using [Cloud HSM](/kms/docs/hsm), which is FIPS 140-2 Level 3 validated and available in several regions across the Americas, Europe, and Asia Pacific.\n- Obtain logs and gain visibility into who did what, when, and where with [Cloud Audit Logs](/audit-logs).\n- Define granular access controls with [Identity and Access Management (IAM)](/iam) and virtual security perimeters with [VPC Service Controls](/vpc-service-controls?hl=en).\n- Manage high volumes of certificates knowing that CA Service supports issuing up to 25 certificates per second per CA (DevOps tier), which means that each CA can issue millions of certificates. You can create multiple CAs behind one issuance endpoint called a CA pool and distribute the incoming certificate requests across all the CAs. Using this feature, you can effectively issue up to 100 certificates per second.\n- Manage, automate, and integrate private CAs in whichever way is most convenient for you: using APIs, the Google Cloud CLI, the Google Cloud console, or [Terraform](https://www.terraform.io/).\n\nCertificate use cases\n---------------------\n\nYou can use your private CAs to issue certificates for the following use cases:\n\n- **Software supply chain integrity and code identity**: Code signing, artifact authentication, and application identity certificates.\n- **User identity**: Client authentication certificates used as user identity for zero trust networking, VPN, document signing, email, smartcard, and more.\n- **IoT and mobile device identity**: Client authentication certificates used as device identity and authentication, for example, wireless access.\n- **Intraservice identity**: mTLS certificates used by microservices.\n- **Continuous integration and continuous delivery (CI/CD) channels**: Code signing certificates used throughout the CI/CD build to improve code integrity and security.\n- **Kubernetes and Istio**: Certificates to secure connections between the Kubernetes and Istio components.\n\nWhy choose a private PKI\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-about/spiffe-concepts/)) into\na certificate.\n\nIn addition, the Web PKI requires all CAs to log every certificate they've\nissued to public [Certificate Transparency](https://certificate.transparency.dev/howctworks/)\nlogs, which may not be required for organizations issuing certificates to their\ninternal services. Private PKI allows organizations to keep their internal\ninfrastructure topology, such as the names of their network services or\napplications, private from the rest of the world.\n\nWhat's next\n-----------\n\n- Understand [CA Service pricing](/certificate-authority-service/pricing).\n- Learn about [security and compliance](/certificate-authority-service/docs/certificate-authority-compliance).\n- Review CA Service [locations](/certificate-authority-service/docs/locations).\n- Get started with the [CA Service](/certificate-authority-service/docs/create-certificate)."]]
