Sie können die Public Certificate Authority (CA) verwenden, um allgemein vertrauenswürdige X.509-Zertifikate bereitzustellen und bereitzustellen, nachdem Sie bestätigt haben, dass der Antragsteller des Zertifikats die Domains verwaltet. Über eine Public CA können Sie öffentlich vertrauenswürdige TLS-Zertifikate direkt und programmatisch anfordern, die sich bereits im Stamm der Trust Stores befinden, die von gängigen Browsern, Betriebssystemen und Anwendungen verwendet werden. Sie können diese TLS-Zertifikate verwenden, um den Internetverkehr zu authentifizieren und zu verschlüsseln.
Public CA können Sie Anwendungsfälle mit hohem Volumen verwalten, die von herkömmlichen Zertifizierungsstellen nicht unterstützt werden können. Wenn Sie ein Google Cloud Google Workspace-Kunde sind, können Sie TLS-Zertifikate für Ihre Domains direkt bei der Public CA anfordern.
Die meisten zertifikatsbezogenen Probleme sind auf menschliche Fehler oder Nachlässigkeit zurückzuführen. Wir empfehlen daher, den Zertifikatszyklus zu automatisieren. Public CA verwendet das ACME-Protokoll (Automatic Certificate Management Environment) für die automatische Bereitstellung, Verlängerung und den Widerruf von Zertifikaten. Die automatisierte Zertifikatsverwaltung reduziert die Ausfallzeiten, die durch abgelaufene Zertifikate verursacht werden können, und minimiert die Betriebskosten.
Public CA stellt TLS-Zertifikate für mehrere Google Cloud Dienste bereit, z. B. für die App Engine, Cloud Shell, die Google Kubernetes Engine und das Cloud Load Balancing.
Für wen ist Public CA geeignet?
Sie können Public CA aus folgenden Gründen verwenden:
- Wenn Sie einen TLS-Anbieter mit hoher Verbreitung, Skalierbarkeit, Sicherheit und Zuverlässigkeit suchen.
- Wenn Sie die meisten, wenn nicht alle TLS-Zertifikate für Ihre Infrastruktur, einschließlich lokal ausgeführter Arbeitslasten und Cloud-übergreifender Konfigurationen, von einem einzigen Cloud-Anbieter beziehen möchten.
- Wenn Sie die TLS-Zertifikatsverwaltung steuern und flexibel an Ihre Infrastrukturanforderungen anpassen möchten.
- Wenn Sie die TLS-Zertifikatsverwaltung automatisieren möchten, aber keine verwalteten Zertifikate in Google Cloud Diensten wie GKE oder Cloud Load Balancing verwenden können.
Wir empfehlen, öffentlich vertrauenswürdige Zertifikate nur zu verwenden, wenn Ihre Geschäftsanforderungen keine andere Option zulassen. Aufgrund der bisherigen Kosten und Komplexität der Verwaltung von Public-Key-Infrastrukturhierarchien (PKI) verwenden viele Unternehmen öffentliche PKI-Hierarchien, auch wenn eine private Hierarchie sinnvoller wäre.
Die Verwaltung öffentlicher und privater Hierarchien ist mit mehrerenGoogle Cloud Angeboten viel einfacher geworden. Wir empfehlen Ihnen, die richtige Art der PKI für Ihren Anwendungsfall sorgfältig auszuwählen.
Für Anforderungen an nicht öffentliche Zertifikate bietet Google Cloud zwei nutzerfreundliche Lösungen:
Anthos Service Mesh: Cloud Service Mesh bietet eine vollständig automatisierte Bereitstellung von mTLS-Zertifikaten für Arbeitslasten, die in GKE Enterprise ausgeführt werden, mithilfe der Anthos Service Mesh-Zertifizierungsstelle (Anthos Service Mesh Certificate Authority, ASM CA).
Certificate Authority Service: Mit dem Certificate Authority Service können Sie benutzerdefinierte private Zertifizierungsstellen effizient bereitstellen, verwalten und schützen, ohne die Infrastruktur verwalten zu müssen.
Vorteile Public CA
Public CA bietet folgende Vorteile:
Automatisierung: Da Internetbrowser auf vollständig verschlüsselten Traffic und eine Verkürzung der Gültigkeitsdauer von Zertifikaten abzielen, besteht das Risiko, abgelaufene TLS-Zertifikate zu verwenden. Das Ablaufen von Zertifikaten kann zu Websitefehlern und Dienstausfällen führen. Public CA können Sie das Problem des Zertifikatsablaufs vermeiden, indem Sie Ihren HTTPS-Server so einrichten, dass die erforderlichen TLS-Zertifikate automatisch von unserem ACME-Endpunkt abgerufen und verlängert werden.
Compliance: Public CA werden regelmäßig von unabhängigen Stellen auf ihre Sicherheits-, Datenschutz- und Compliance-Kontrollen geprüft. Die Webtrust-Siegel, die im Rahmen dieser jährlichen Audits vergeben werden, belegen die Einhaltung aller relevanten Branchenstandards durch die Public CA.
Sicherheit: Die Architektur und der Betrieb von Public CA entsprechen den höchsten Sicherheitsstandards. Außerdem werden regelmäßig unabhängige Bewertungen durchgeführt, um die Sicherheit der zugrunde liegenden Infrastruktur zu bestätigen. Der Public CA erfüllt alle im Whitepaper zur Sicherheit bei Google genannten Kontrollen, Betriebspraktiken und Sicherheitsmaßnahmen oder übertrifft sie.
Der Schwerpunkt der Public CA auf Sicherheit erstreckt sich auch auf Funktionen wie die mehrdimensionale Domainbestätigung. Die Infrastruktur der öffentlichen Zertifizierungsstelle ist global verteilt. Daher ist für Public CA ein hoher Grad an Übereinstimmung zwischen geografisch unterschiedlichen Perspektiven erforderlich, um vor BGP-Hijacking (Border Gateway Protocol) und DNS-Hijacking (Domain Name Server) zu schützen.
Zuverlässigkeit: Die bewährte technische Infrastruktur von Google macht Public CA zu einem hochverfügbaren und skalierbaren Dienst.
Allgegenwärtigkeit: Die starke Browser-Allgegenwärtigkeit der Google Trust Services trägt dazu bei, dass Dienste, die Zertifikate von öffentlichen Zertifizierungsstellen verwenden, auf möglichst vielen Geräten und Betriebssystemen funktionieren.
Optimierte TLS-Lösungen für hybride Umgebungen: Mit einer Public CA können Sie eine benutzerdefinierte TLS-Zertifikatlösung erstellen, bei der dieselbe Zertifizierungsstelle für verschiedene Szenarien und Anwendungsfälle verwendet wird. Public CA eignen sich gut für Anwendungsfälle, bei denen Arbeitslasten lokal oder in einer Cloud-Umgebung mit mehreren Anbietern ausgeführt werden.
Skalierung: Zertifikate waren oft teuer in der Anschaffung und schwierig bereitzustellen und zu verwalten. Da Public CA Zugriff auf eine große Anzahl von Zertifikaten bieten, können Sie Zertifikate auf eine Weise verwenden und verwalten, die bisher als unpraktisch galt.
Öffentliche Zertifizierungsstelle mit Certificate Manager verwenden
Wenn Sie die Funktion für öffentliche Zertifizierungsstellen des Zertifikatmanagers verwenden möchten, müssen Sie mit den folgenden Konzepten vertraut sein:
ACME-Client Ein ACME-Client (Automatic Certificate Management Environment) ist ein Zertifikatsverwaltungsclient, der das ACME-Protokoll verwendet. Ihr ACME-Client muss die externe Kontobindung (External Account Binding, EAB) unterstützen, um mit der öffentlichen Zertifizierungsstelle zu funktionieren.
Externe Kontobindung (External Account Binding, EAB) Sie müssen jedes ACME-Konto, das Sie mit der öffentlichen Zertifizierungsstelle des Certificate Managers verwenden, über eine externe Kontobindung mit dem Zielprojekt verknüpfen. Google Cloud Dazu müssen Sie jedes ACME-Konto mit einem geheimen Schlüssel registrieren, der mit dem entsprechenden Google Cloud Projekt verknüpft ist. Weitere Informationen finden Sie unter Externe Kontobindung.
Herausforderungen Public CA
Wenn Sie eine Public CA verwenden, um ein Zertifikat anzufordern, werden Sie von Certificate Manager aufgefordert, nachzuweisen, dass Sie die Kontrolle über die in diesem Zertifikat aufgeführten Domains haben. Sie können die Domainkontrolle nachweisen, indem Sie Herausforderungen meistern. Public CA autorisiert die Domainnamen, nachdem Sie nachgewiesen haben, dass Sie die Kontrolle über die Zieldomains haben.
Nachdem Sie die erforderlichen Autorisierungen erhalten haben, können Sie Zertifikate anfordern, die nur für einen bestimmten Zeitraum gültig sind. Nach Ablauf dieser Frist müssen Sie den Domainnamen noch einmal validieren, indem Sie eine der drei Arten von Identitätsbestätigungen durchführen, um weiterhin Zertifikate anfordern zu können.
Typen der Identitätsbestätigung
Public CA unterstützt die folgenden Arten von Bestätigungen:
HTTP-Herausforderung Dazu wird eine Datei an einem bekannten Speicherort auf einem HTTP-Server (Port 80) erstellt, die von Public CA abgerufen und überprüft werden kann. Weitere Informationen finden Sie unter HTTP-Anfrage.
TLS-ALPN-Herausforderung (Application Layer Protocol Negotiation) Erfordert, dass ein Server während einer TLS-Verhandlung auf Port 443 ein bestimmtes Zertifikat zur Verfügung stellt, um die Kontrolle über eine Domain nachzuweisen. Weitere Informationen finden Sie unter ACME TLS-ALPN-Herausforderungserweiterung.
DNS-Herausforderung Es muss ein bestimmter DNS-Eintrag an einer bestimmten Stelle hinzugefügt werden, um die Kontrolle über eine Domain nachzuweisen. Weitere Informationen finden Sie unter DNS-Herausforderung.
Wenn Sie die HTTP- oder TLS-ALPN-Herausforderung zum Validieren eines Domainnamens verwenden, kann der Client nur die validierten Domainnamen anfordern, die in einem Zertifikat enthalten sein sollen. Wenn Sie die DNS-Herausforderung verwenden, kann der Client auch Subdomains dieses Domainnamens anfordern, die in einem Zertifikat enthalten sein sollen.
Wenn Sie beispielsweise *.myorg.example.com mit der DNS-Herausforderung validieren, werden subdomain1.myorg.example.com und subdomain2.myorg.example.com automatisch vom Platzhalterzertifikat abgedeckt. Wenn Sie myorg.example.com jedoch mit einer HTTP- oder TLS-ALPN-Identitätsbestätigung validieren, kann der Client nur anfordern, myorg.example.com in das Zertifikat aufzunehmen. Sie können *.myorg.example.com dann nicht mit den nicht-DNS-Identitätsbestätigungen validieren.
Logik für Lösungsvorschläge
Die Logik für die öffentliche CA-Anfrage ist so:
- Public CA stellt ein zufälliges Token bereit.
- Der Client stellt das Token an einem genau definierten Ort bereit. Der Speicherort hängt von der Challenge ab.
- Der Client teilt der Public CA mit, dass er die Herausforderung vorbereitet hat.
- Public CA prüft, ob das Token an der erwarteten Stelle mit dem erwarteten Wert übereinstimmt.
Der Domainname wird nach Abschluss dieses Vorgangs autorisiert. Der Kunde kann ein Zertifikat mit diesem Domainnamen anfordern. Sie müssen nur eine Bestätigungsaufgabe pro Domainnamen lösen.