Sie können Public Certificate Authority verwenden, um weitgehend vertrauenswürdige X.509-Zertifikate bereitzustellen und zu implementieren, nachdem Sie bestätigt haben, dass der Zertifikatsanfragesteller die Domains kontrolliert. Mit Public CA können Sie öffentlich vertrauenswürdige TLS-Zertifikate direkt und programmatisch anfordern, die sich bereits im Stamm von Trust-Stores befinden, die von wichtigen Browsern, Betriebssystemen und Anwendungen verwendet werden. Sie können diese TLS-Zertifikate verwenden, um den Internet-Traffic zu authentifizieren und zu verschlüsseln.
Mit Public CA können Sie Anwendungsfälle mit hohem Volumen verwalten, die von anderen Zertifizierungsstellen nicht unterstützt werden. Als Google Cloud Kunde können Sie TLS-Zertifikate für Ihre Domains direkt bei Public CA anfordern.
Die meisten Probleme im Zusammenhang mit Zertifikaten sind auf menschliche Fehler oder Versäumnisse zurückzuführen. Daher empfehlen wir, die Lebenszyklen von Zertifikaten zu automatisieren. Public CA uses the Automatic Certificate Management Environment (ACME) protocol for the automated provisioning, renewal, and revocation of certificates. Die automatisierte Zertifikatsverwaltung reduziert Ausfallzeiten, die durch abgelaufene Zertifikate verursacht werden können, und minimiert die Betriebskosten.
Public CA stellt TLS-Zertifikate für verschiedene Google Cloud Dienste bereit, z. B. App Engine, Cloud Shell, Google Kubernetes Engine und Cloud Load Balancing.
Wer sollte Public CA verwenden?
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 oder alle TLS-Zertifikate für Ihre Infrastruktur, einschließlich lokaler Arbeitslasten und Setups mit mehreren Cloud-Anbietern, von einem einzigen Cloud-Anbieter beziehen möchten.
- Wenn Sie die TLS-Zertifikatsverwaltung kontrollieren und flexibel anpassen möchten, um sie an Ihre Infrastrukturanforderungen anzupassen.
- 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äftlichen Anforderungen keine andere Option zulassen. Angesichts der historischen Kosten und Komplexität der Wartung von Public-Key-Infrastruktur-Hierarchien (PKI) verwenden viele Unternehmen öffentliche PKI-Hierarchien, auch wenn eine private Hierarchie sinnvoller wäre.
Die Wartung öffentlicher und privater Hierarchien ist mit mehreren Google Cloud Angeboten viel einfacher geworden. Wir empfehlen, den richtigen PKI-Typ für Ihren Anwendungsfall sorgfältig auszuwählen.
Für nicht öffentliche Zertifikatsanforderungen, Google Cloud bietet zwei einfach zu verwaltende Lösungen:
Anthos Service Mesh: Cloud Service Mesh umfasst die vollständig automatisierte Bereitstellung von mTLS-Zertifikaten für Arbeitslasten, die in GKE Enterprise ausgeführt werden, mit der Cloud Service Mesh-Zertifizierungsstelle.
Certificate Authority Service: Certificate Authority Service ermöglicht Ihnen die effiziente Bereitstellung, Verwaltung und Sicherung benutzerdefinierter privater Zertifizierungsstellen, ohne die Infrastruktur verwalten zu müssen.
Vorteile von Public CA
Public CA bietet die folgenden Vorteile:
Automatisierung: Da Internetbrowser auf vollständig verschlüsselten Traffic und die Verkürzung der Gültigkeitsdauer von Zertifikaten abzielen, besteht das Risiko, dass abgelaufene TLS-Zertifikate verwendet werden. Abgelaufene Zertifikate können zu Websitefehlern und Dienstausfällen führen. Mit Public CA können Sie das Problem abgelaufener Zertifikate vermeiden, indem Sie Ihren HTTPS-Server so einrichten, dass er die erforderlichen TLS-Zertifikate automatisch von unserem ACME-Endpunkt abruft und verlängert.
Compliance: Public CA wird regelmäßig strengen unabhängigen Audits der Sicherheits-, Datenschutz- und Compliance-Kontrollen unterzogen. Die Webtrust Siegel, die im Rahmen dieser jährlichen Audits verliehen werden, belegen die Konformität von Public CA mit allen relevanten Branchenstandards.
Sicherheit: Die Architektur und der Betrieb von Public CA sind auf höchstem Sicherheitsniveau ausgelegt. Regelmäßig werden unabhängige Bewertungen durchgeführt, um die Sicherheit der zugrunde liegenden Infrastruktur zu bestätigen. Public CA erfüllt oder übertrifft alle die Kontrollen, betrieblichen Praktiken und Sicherheitsmaßnahmen, die im Whitepaper zur Sicherheit bei Google erwähnt werden.
Der Fokus von Public CA auf Sicherheit erstreckt sich auch auf Funktionen wie die mehrperspektivische Domainvalidierung. Die Infrastruktur von Public CA ist global verteilt. Daher erfordert Public CA ein hohes Maß an Übereinstimmung über geografisch unterschiedliche Perspektiven hinweg, was Schutz vor BGP-Hijacking (Border Gateway Protocol) und DNS-Hijacking-Angriffen (Domain Name Server) bietet.
Zuverlässigkeit: Durch die Verwendung der bewährten technischen Infrastruktur von Google ist Public CA ein hochverfügbarer und skalierbarer Dienst.
Verbreitung: Die hohe Verbreitung von Google Trust Services in Browsern trägt dazu bei, dass Dienste, die von Public CA ausgestellte Zertifikate verwenden, auf möglichst vielen Geräten und Betriebssystemen funktionieren.
Optimierte TLS-Lösungen für hybride Setups: Mit Public CA können Sie eine benutzerdefinierte TLS-Zertifikatslösung erstellen, die für verschiedene Szenarien und Anwendungsfälle dieselbe Zertifizierungsstelle verwendet. Public CA eignet sich effektiv für Anwendungsfälle, in denen Arbeitslasten lokal oder in einer Umgebung mit mehreren Cloud-Anbietern ausgeführt werden.
Skalierung: Zertifikate waren oft teuer in der Anschaffung und schwer zu bereitzustellen und zu verwalten. Durch den Zugriff auf große Mengen von Zertifikaten ermöglicht Public CA die Nutzung und Verwaltung von Zertifikaten auf eine Weise, die bisher als unpraktisch galt.
Public CA mit Certificate Manager verwenden
Um die Public CA-Funktion von Certificate Manager zu verwenden, müssen Sie mit den folgenden Konzepten vertraut sein:
ACME-Client. Ein ACME-Client (Automatic Certificate Management Environment) ist ein Client für die Zertifikatsverwaltung , der das ACME-Protokoll verwendet. Ihr ACME-Client muss die externe Kontoverknüpfung (External Account Binding, EAB) unterstützen, um mit Public CA zu funktionieren.
Externe Kontoverknüpfung (EAB). Sie müssen jedes ACME-Konto, das Sie mit Certificate Manager Public CA verwenden, mit dem Ziel Google Cloud projekt verknüpfen. Dazu müssen Sie jedes ACME-Konto mit einem Secret registrieren, das mit dem entsprechenden Google Cloud Projekt verknüpft ist. Weitere Informationen finden Sie unter Externe Kontoverknüpfung.
Herausforderungen bei Public CA
Wenn Sie mit Public CA ein Zertifikat anfordern, 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 Aufgaben lösen. 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 dieses Zeitraums müssen Sie den Domainnamen neu validieren, indem Sie eine der drei Aufgabenarten lösen, um weiterhin Zertifikate anfordern zu können.
Aufgabenarten
Public CA unterstützt die folgenden Arten von Aufgaben:
HTTP-Aufgabe. Bei dieser Aufgabe muss eine Datei an einem bekannten Speicherort auf einem HTTP-Server (Port 80) erstellt werden, damit Public CA sie abrufen und überprüfen kann. Weitere Informationen finden Sie unter HTTP-Aufgabe.
TLS-ALPN-Aufgabe (Application Layer Protocol Negotiation). Erfordert, dass ein Server während einer TLS-Verhandlung auf Port 443 ein bestimmtes Zertifikat bereitstellt, um die Kontrolle über eine Domain nachzuweisen. Weitere Informationen finden Sie unter ACME TLS-ALPN-Aufgabenerweiterung.
DNS-Aufgabe. Erfordert, dass an einem definierten Speicherort ein bestimmter DNS-Eintrag hinzugefügt wird, um die Kontrolle über eine Domain nachzuweisen. Weitere Informationen finden Sie unter DNS-Aufgabe.
Wenn Sie die HTTP-Aufgabe oder die TLS-ALPN-Aufgabe verwenden, um einen Domainnamen zu validieren, kann der Client nur die validierten Domainnamen anfordern, die in ein Zertifikat aufgenommen werden sollen. Wenn Sie die DNS-Aufgabe verwenden, kann der Client auch anfordern, dass Subdomains dieses Domainnamens in ein Zertifikat aufgenommen werden.
Wenn Sie beispielsweise *.myorg.example.com mit der DNS-Aufgabe validieren, werden subdomain1.myorg.example.com und subdomain2.myorg.example.com automatisch vom Platzhalterzertifikat abgedeckt. Wenn Sie jedoch myorg.example.com mit einer HTTP- oder
TLS-ALPN-Aufgabe validieren, kann der Client nur anfordern, dass myorg.example.com in
das Zertifikat aufgenommen wird. Sie können *.myorg.example.com nicht mit den Nicht-DNS-Aufgaben validieren.
Logik für die Aufgabenlösung
Die Aufgabenlogik von Public CA funktioniert so:
- Public CA stellt ein zufälliges Token bereit.
- Der Client stellt das Token an einem genau definierten Speicherort zur Verfügung. Der Speicherort hängt von der Aufgabe ab.
- Der Client teilt Public CA mit, dass er die Aufgabe vorbereitet hat.
- Public CA prüft, ob das Token am erwarteten Speicherort mit dem erwarteten Wert übereinstimmt.
Der Domainname wird autorisiert, nachdem dieser Vorgang abgeschlossen ist. Der Client kann ein Zertifikat mit diesem Domainnamen anfordern. Sie müssen nur eine Aufgabe pro Domainnamen lösen.