Unterschied zwischen verschiedenen Public Key Infrastructure (PKIs)

Einführung

Microsoft PKI, AWS Certificate Manager, AWS ACM Private CA und Google Cloud Certificate Authority Service lösen alle dasselbe grundlegende Problem – die Ausstellung und Verwaltung vertrauenswürdiger digitaler Zertifikate – jedoch auf sehr unterschiedliche Weise. Die Wahl der falschen Lösung oder der gleichzeitige Einsatz aller Lösungen ohne dokumentierten Entscheidungsprozess führt dazu, dass Unternehmen redundante CA-Hierarchien, inkonsistenten Schlüsselschutz und unerwartete Zertifikatsausfälle riskieren. Dieser Beitrag erläutert die Bestandteile einer PKI, die Implementierung der vier Plattformen, einen umfassenden Vergleich in elf Kategorien sowie eine praktische Entscheidungsmatrix und Checkliste zur Auswahl (oder Überprüfung) der passenden Lösung für den jeweiligen Anwendungsfall.

Kurzantwort: Worin besteht der Unterschied zwischen diesen PKI-Plattformen?

Die Anbieter von Public-Key-Infrastrukturen (PKI) unterscheiden sich hauptsächlich darin, wo die CA-Schlüssel gespeichert sind und wer die Hierarchie verwaltet: Microsoft PKI (ADCS) läuft lokal mit einer Offline-Root-CA, AWS Certificate Manager automatisiert öffentliche TLS-Zertifikate, und AWS ACM Private CA und Google Cloud CAS betreiben private CA-Hierarchien nativ in der Cloud mit HSM-gestützten Schlüsseln und integrierter Audit-Protokollierung.

Wichtige Erkenntnisse

• Microsoft PKI, AWS Certificate Manager, AWS ACM Private CA und Google Cloud CAS lösen unterschiedliche Probleme: die Kontrolle lokaler Zertifizierungsstellen, automatisiertes öffentliches TLS, Cloud-native private Zertifizierungsstellenhierarchien bzw. in GCP integrierte Zertifizierungsstellenpools.
• Alle vier Plattformen setzen auf die gleichen grundlegenden Sicherheitspraktiken: Offline- oder geschützte Root-CAs, HSM-gestützte private Schlüssel, SHA-256- oder besser-Hashing und Audit-Protokollierung.
• AWS hat den HSM-Schutz von ACM Private CA auf FIPS 140-3 Level 3 umgestellt. NIST stellt die Validierungen nach FIPS 140-2 am 21. September 2026 auf den Status „Historisch“ ein, daher benötigt jede Microsoft PKI- oder On-Premises-Bereitstellung, die noch auf 140-2 verweist, einen Aktualisierungsplan.
• Die Verkürzung der Gültigkeit öffentlicher TLS-Zertifikate auf nur noch 47 Tage bis 2029 gemäß CA/Browser Forum Ballot SC-081v3 macht automatisierungsfreundliche Plattformen wie ACM und Cloud-native CAS auch für Organisationen, die mit Microsoft PKI begonnen haben, immer wichtiger.
• Die richtige Wahl ist selten eine einzelne Plattform. Die meisten Unternehmen nutzen einen hybriden Ansatz und benötigen eine dokumentierte Entscheidungsmatrix, keine Ad-hoc-Auswahl, um doppelte CA-Hierarchien und inkonsistenten Schlüsselschutz zu vermeiden.

Warum das jetzt wichtig ist

Die am 2. Juli 2025 veröffentlichte DigiCert Trust Pulse Survey ergab, dass fast die Hälfte aller Unternehmen im vergangenen Jahr einen Zertifikatsausfall erlitten hat. 37.5 % dieser Vorfälle waren direkt auf abgelaufene Zertifikate zurückzuführen, und 18.5 % der betroffenen Organisationen meldeten Verluste von über 250,000 US-Dollar. Der parallele Betrieb von Microsoft PKI-, AWS- und Google Cloud CA-Hierarchien ohne einheitlichen Überwachungs- und Erneuerungsprozess ist genau die Art von Inkonsistenz, die solche Ausfälle verursacht.

Der Spielraum für manuelle Fehler schrumpft rapide. Gemäß der CA/Browser Forum-Abstimmung SC-081v3 vom 11. April 2025 sinkt die Gültigkeitsdauer öffentlich vertrauenswürdiger TLS-Zertifikate ab dem 15. März 2026 von 398 auf 200 Tage, ab dem 15. März 2027 auf 100 Tage und ab dem 15. März 2029 auf 47 Tage. Eine Plattform, die auf manueller Ausstellung basiert – wie sie bei älteren Microsoft-PKI-Implementierungen üblich war –, kann mit diesem Zeitplan nicht mithalten, wie es beispielsweise AWS Certificate Manager oder die CAS-Automatisierung von Google Cloud ermöglichen.

Längerfristig hat das NIST am 13. August 2024 seine Post-Quanten-Kryptographiestandards FIPS 203, 204 und 205 finalisiert. Alle in diesem Beitrag verglichenen Plattformen signieren Zertifikate weiterhin mit RSA oder ECDSA. Daher sollte unabhängig vom Anbieter, für den sich eine Organisation heute entscheidet, ein Plan für Krypto-Agilität im Hinblick auf den späteren Übergang zu PQC auf der Roadmap stehen, unabhängig von der bestehenden CA-Hierarchie.

Was ist eine Public-Key-Infrastruktur (PKI)?

PKI ( Public Key Infrastructure ) ist ein System aus Rollen, Verfahren und Richtlinien, das für die Erstellung, Verteilung, Verwaltung, Nutzung und den Widerruf digitaler Zertifikate sowie für die Verwaltung der Public-Key-Verschlüsselung erforderlich ist. Die PKI bestätigt die Identität eines Nutzers durch Überprüfung des Besitzes eines privaten Schlüssels und fungiert als vertrauenswürdiger Dienst, der sicherstellt, dass Sender und Empfänger von Daten tatsächlich die Person sind, für die sie sich ausgeben.

Was sind die Kernkomponenten einer PKI?

PKI basiert auf Komponenten und Verfahren zur Verwaltung von Schlüsselpaaren (öffentlichen und privaten Schlüsselpaaren). Eine typische PKI besteht aus folgenden Komponenten:

1. Zertifizierungsstelle (CA): Ein vertrauenswürdiger CA Die Zertifizierungsstelle (CA) ist die einzige Instanz in der PKI, die vertrauenswürdige digitale Zertifikate ausstellen kann. Die CA nimmt Zertifikatsanträge entgegen und überprüft die von den Antragstellern bereitgestellten Informationen anhand von … Zertifikatsverwaltung Die Richtlinie wird dann angewendet, anschließend werden die Zertifikate mit dem privaten Schlüssel signiert und, falls die Informationen gültig sind, ausgestellt.
2. Registrierungsstelle (RA): Eine Registrierungsstelle (RA) ist für den Empfang von Zertifikatsignierungsanfragen für die Erstbeantragung oder Verlängerung von Zertifikaten von Benutzern, Servern und anderen Anwendungen zuständig. Die RA überprüft die Identität eines Endbenutzers und leitet die Anfrage an eine Zertifizierungsstelle (CA) weiter.
3. Öffentlicher Schlüssel: Ein öffentlicher Schlüssel kann weit verbreitet werden und benötigt keine sichere Speicherung. Der zugehörige private Schlüssel kann Nachrichten oder Daten entschlüsseln, die mit dem öffentlichen Schlüssel verschlüsselt wurden.
4. Privat Schlüssel: Der Empfänger verwendet den privaten Schlüssel, um die mit dem zugehörigen öffentlichen Schlüssel verschlüsselte Nachricht oder die Daten zu entschlüsseln. Dadurch wird die Eigentümerschaft des Schlüsselpaares (privater und öffentlicher Schlüssel) sichergestellt und gewährleistet, dass die Nachricht nur von autorisierten Personen gelesen werden kann.
5. Stammzertifizierungsstelle (Root CA): Ein Zertifikat gilt als gültig, wenn es von einer vertrauenswürdigen Stammzertifizierungsstelle (Root CA) signiert wird. Eine Stammzertifizierungsstelle ist berechtigt, die Identität einer Person zu überprüfen und signiert das Stammzertifikat, das an den Benutzer verteilt wird.
6. Zertifizierungsstelle für mittlere Qualifikationen: Eine Zwischenzertifizierungsstelle (Intermediate CA) ist ebenfalls eine vertrauenswürdige Zertifizierungsstelle und dient als Bindeglied zwischen der Stammzertifizierungsstelle (Root CA) und dem Clientzertifikat, für das sich der Benutzer registriert. Da die Stammzertifizierungsstelle die Zwischenzertifizierungsstelle signiert hat und ihr vertraut, gelten auch die von der Zwischenzertifizierungsstelle generierten Zertifikate als vertrauenswürdig.
7. Hardware-Sicherheitsmodul (HSM): A Hardware-Sicherheitsmodul Es ist keine obligatorische Komponente einer PKI, verbessert aber die Sicherheit, wenn es implementiert wird. Dieses Gerät schützt und verwaltet digitale Schlüssel und dient als Grundlage für den Aufbau einer sicheren PKI. Unternehmens-PKI Infrastruktur, Verwaltung des gesamten Lebenszyklus kryptografischer Schlüssel, einschließlich Erstellung, Rotation, Löschung, Prüfung und Unterstützung für APIs zur Integration mit verschiedenen Anwendungen.

Wie implementieren die großen PKI-Anbieter diese Komponenten?

Nachdem die Kernkomponenten der PKI nun klar sind, wird im Folgenden erläutert, wie vier weit verbreitete Plattformen diese implementieren, zusammen mit den jeweils empfohlenen Best Practices.

Microsoft PKI

Nachfolgend finden Sie einige empfohlene Best Practices für die effektive Nutzung von Microsoft PKI (Active Directory Certificate Services).

• Erstellen Sie vor der Bereitstellung einen detaillierten Plan Ihrer PKI-Infrastruktur.
• Vermeiden Sie die Installation von ADCS auf einem Domänencontroller.
• Die Stammzertifizierungsstelle sollte eigenständig und offline sein.
• Von einer Stammzertifizierungsstelle dürfen keine Zertifikate an Endbenutzer ausgestellt werden.
• Aktivieren Sie Überwachungsereignisse sowohl für die Stammzertifizierungsstelle als auch für die ausstellende Zertifizierungsstelle.
• Sichern Sie den privaten Schlüssel mit einem HSM (FIPS 140-3 Stufe 3(Die Validierungen gemäß FIPS 140-2 werden am 21. September 2026 in den historischen Status versetzt).
• Installieren Sie Enterprise CA nur, wenn Ihre Zertifizierungsstelle Zertifikate für Geräte oder Benutzer ausstellt.
• Es wird nicht empfohlen, Standardzertifikatvorlagen zu verwenden.
• Der CRL-Verteilerpunkt sollte hochverfügbar sein.
• Veröffentlichen Sie die Root CA CRL in Active Directory.
• Der Hash-Algorithmus sollte mindestens SHA-2 (SHA-256 oder höher).
• Die Gültigkeitsdauer des Endbenutzerzertifikats sollte maximal zwei Jahre betragen.

AWS-Zertifikatsmanager

Hier sind die wichtigsten Best Practices für AWS Certificate Manager (ACM):

• Überprüfung des Ablaufs von ACM-Zertifikaten: Sicherstellen, dass abgelaufene Zertifikate entfernt werden SSL/TLS-Zertifikate Verwaltet von ACM. Dadurch wird das Risiko eliminiert, ein ungültiges Zertifikat auf Ressourcen einzusetzen, die mit dem Frontend in Kontakt stehen, was auch die Glaubwürdigkeit des Unternehmens beeinträchtigen kann.
• ACM-Zertifikatgültigkeitsprüfung: Sicherstellen, dass Anfragen, die während des SSL/TLS-Zertifikatausstellungs- oder -erneuerungsprozesses eingehen, regelmäßig validiert werden.
• Nutzung der Stammzertifizierungsstelle (Root-CA): Es empfiehlt sich, die Nutzung der Stammzertifizierungsstelle so gering wie möglich zu halten. AWS rät dazu, ein separates Konto für die Stammzertifizierungsstelle anzulegen.
• Der Schutz der Transportschicht ist für die Sicherheit unerlässlich. Verwenden Sie ausschließlich TLS Version 1.2 oder höher; SSL bietet keine ausreichende Sicherheit mehr.
• Beim Importieren von Zertifikaten anstelle der Verwendung von ACM-ausgestellten Zertifikaten ist darauf zu achten, dass die zur Generierung von SSL/TLS-Privatschlüsseln verwendeten Schlüssel eine hohe Schlüsselstärke aufweisen, um einen Datenverlust zu vermeiden.
• Vermeiden Sie Wildcard-Domainzertifikate. Stellen Sie stattdessen für jede Domain und Subdomain ein Single-Domain-ACM-Zertifikat mit eigenem privaten Schlüssel aus.
• Importierte Zertifikate sollten nur von authentifizierten und vertrauenswürdigen Partnern Ihrer Organisation zugelassen werden. In ACM importierte Wildcard-Zertifikate bergen ein Sicherheitsrisiko, da ein Benutzer möglicherweise eine unverschlüsselte Kopie des privaten Schlüssels des Zertifikats besitzt.
• Verwenden Sie in SSL/TLS-ACM-Zertifikaten immer einen vollqualifizierten Domänennamen (FQDN).
• Um einen Missbrauch der generierten Zertifikate zu vermeiden, sollten Sie regelmäßig die AWS-Umgebung auf vertrauenswürdige Zertifikate überprüfen und die Prüfberichte validieren.
• Aktivieren Sie AWS CloudTrail- und CloudWatch-Alarme: CloudTrail protokolliert den Verlauf von AWS-API-Aufrufen und überwacht AWS-Bereitstellungen. Es lässt sich zur automatisierten Protokollierung in Anwendungen integrieren. CloudWatch-Alarme benachrichtigen Sie, wenn konfigurierte Metrik-Schwellenwerte überschritten werden.

AWS ACM Private CA (ACM PCA)

Nachfolgend finden Sie empfohlene Best Practices, die Ihnen helfen können, AWS ACM Private CA effektiver zu nutzen.

• AWS empfiehlt, alle Richtlinien und Verfahren für den Betrieb Ihrer Zertifizierungsstelle (CA) zu dokumentieren, einschließlich der CA-Hierarchie, des Architekturdiagramms und der Richtlinien für den CA-Gültigkeitszeitraum. Dies kann in einer Zertifikatsrichtlinie (CP) und einer Zertifikatspraxisbeschreibung (CPS) festgehalten werden; ein Rahmenwerk zur Erfassung dieser Informationen finden Sie in RFC 3647.
• Die Root-CA sollte im Allgemeinen nur zur Ausstellung von Zertifikaten für Zwischen-CAs verwendet werden.
• Die Erstellung einer Stammzertifizierungsstelle und einer untergeordneten Zertifizierungsstelle in zwei verschiedenen AWS-Konten ist eine empfohlene Best Practice.
• Die Rolle des CA-Administrators sollte von der Rolle der Benutzer getrennt sein, die Zugriff nur zum Ausstellen von Endentitätszertifikaten benötigen.
• Aktivieren Sie die CloudTrail-Protokollierung, bevor Sie eine private Zertifizierungsstelle erstellen und in Betrieb nehmen, damit Sie einen Verlauf der AWS-API-Aufrufe abrufen und Ihre Bereitstellungen überwachen können.
• Aktualisieren Sie den privaten Schlüssel Ihrer privaten Zertifizierungsstelle regelmäßig, indem Sie entweder ein neues Zertifizierungsstellenzertifikat importieren oder die private Zertifizierungsstelle durch eine neue ersetzen.
• Nicht verwendete private Zertifizierungsstellen sollten dauerhaft gelöscht werden.
• Verwenden Sie die Amazon S3-Funktion „Öffentlichen Zugriff blockieren“ (BPA) für Buckets, die CRLs enthalten, um die unnötige Offenlegung von Details Ihrer privaten PKI zu vermeiden. BPA ist eine bewährte Methode für S3 und ist für neue Buckets standardmäßig aktiviert.

Google Cloud-Zertifizierungsstellendienst

Dieser Abschnitt beschreibt einige der besten Vorgehensweisen, die Ihnen helfen, den Zertifizierungsstellendienst (CAS) von Google Cloud effektiver zu nutzen.

• Rollen- und Zugriffskontrolle: Einzelpersonen sollten nicht gleichzeitig mehrere Rollen zuweisen, und jeder Rolleninhaber sollte über seine Verantwortlichkeiten umfassend informiert sein. Um unterschiedliche Berechtigungen zu vergeben, erstellen Sie mithilfe von IAM eine benutzerdefinierte Rolle.
• In den meisten Fällen verwenden Sie die Enterprise-Ebene, um einen CA-Pool zu erstellen, der Zertifikate an andere CAs und Endbenutzer ausstellt.
• Bei der Erstellung eines CA-Pools sollte die DevOps-Ebene sorgfältig berücksichtigt werden, da diese den Zertifikatswiderruf nicht unterstützt.
• Sichern Sie CA-Signaturschlüssel durch Nutzung von Cloud HSM.
• Aktivieren Sie Cloud-Audit-Protokolle, um den Zugriff auf und die Verwendung von Cloud-HSM-Signaturschlüsseln zu überwachen.
• Vermeiden Sie den Import einer bestehenden externen Zertifizierungsstelle mit bereits ausgestellten Zertifikaten in den CA-Dienst.
• Für eine Root-CA und eine Subordinate-CA sollte die größtmögliche Schlüssellänge der jeweiligen Algorithmenfamilie verwendet werden: Bei RSA beträgt die maximal unterstützte Schlüssellänge 4096 Bit, bei ECDSA 384 Bit. Subordinate-CAs mit kürzerer Lebensdauer können kleinere Schlüssellängen verwenden, z. B. 2048 Bit. RSA oder 256 Bit für ECDSABitte beachten Sie, dass Ed25519-Signaturschlüssel für den CA-Dienst nicht unterstützt werden und dass zum jetzigen Zeitpunkt kein Post-Quantum-Signaturalgorithmus für CA-Schlüssel unterstützt wird.
• Weisen Sie die CA-Dienstbenutzerrolle nur Organisationsmitgliedern zu, die eine bestimmte Zertifikatvorlage verwenden müssen.

Anbietervergleich auf einen Blick

Die nachfolgende Tabelle vergleicht alle vier Plattformen anhand von elf Kategorien, die bei der Auswahl oder Prüfung eines PKI-Anbieters von größter Bedeutung sind.

#	Kategorie	Microsoft PKI	AWS Certificate Manager (ACM)	AWS ACM Private CA (ACM PCA)	Google Cloud Zertifizierungsstellendienst (CAS)
1	Stammzertifizierungsstelle	Die Root-CA wird lokal bereitgestellt und offline gehalten.	AWS Certificate Manager ist ein Dienst zum Bereitstellen, Verwalten und Einbinden von öffentlichen/privaten SSL/TLS-Zertifikaten für AWS-Dienste und verbundene Ressourcen.	Die Root-CA kann in der AWS-Cloud bereitgestellt werden, oder der Issuing CA CSR kann von einer externen Root-CA signiert werden.	Die Root-CA kann in Google Cloud CAS bereitgestellt werden, oder der Issuing CA CSR kann von einer externen Root-CA signiert werden.
2	Zertifikatsvorlage	Die Verwendung von Standardzertifikatvorlagen wird nicht empfohlen; Vorlagen können konfiguriert werden.	Verwenden Sie AWS CloudFormation-Vorlagen, um private Zertifikate mit ACM auszustellen.	ACM Private CA unterstützt vier Zertifikatvorlagenvarianten: Base, CSRPassthrough, APIPassthrough und APICSRPassthrough.	In Google Cloud CAS kann für jedes Projekt und jeden Standort eine neue Zertifikatvorlage erstellt werden.
3	Schlüsselalgorithmus und Schlüsselgröße	Unterstützt Schlüssellängen gemäß NIST SP 800-57. Die minimale Schlüssellänge beträgt 2048 Bit; für Zertifizierungsstellen mit einer Gültigkeitsdauer des Zertifikats von mehr als 15 Jahren muss RSA mindestens 4096 Bit lang sein, oder ECC-Schlüssel müssen die P-384- oder P-521-Kurve verwenden.	Unterstützt 2048-Bit-RSA, 3072-Bit-RSA, 4096-Bit-RSA sowie ECDSA P-256 und P-384.	Unterstützt RSA 2048, RSA 4096, ECDSA P-256 und ECDSA P-384 für Zertifikate, die direkt von ACM Private CA ausgestellt werden.	Unterstützt 2048-Bit-RSA, 3072-Bit-RSA, 4096-Bit-RSA, ECDSA P-256 und ECDSA P-384. Für langlebige Root- oder Subordinate-CAs empfiehlt Google die größtmögliche Schlüssellänge für die gewählte Algorithmenfamilie. Ed25519 und Post-Quantum-CA-Signaturschlüssel werden derzeit nicht unterstützt.
4	Hashing-Algorithmus	Für Neuinstallationen und bestehende PKI wird SHA-256 oder höher empfohlen.	Die von ACM verwalteten Zertifikate verwenden RSA-Schlüssel mit einem 2048-Bit-Modulus und SHA-256; ACM verwaltet derzeit keine ECDSA-Zertifikate.	Unterstützt SHA256WITHECDSA, SHA384WITHECDSA, SHA512WITHECDSA, SHA256WITHRSA, SHA384WITHRSA und SHA512WITHRSA für Zertifikate, die direkt von einer privaten ACM-Zertifizierungsstelle ausgestellt werden.	Unterstützt SHA-256 und SHA-384.
5	RFC-Konformität	CA-Zertifikate müssen X.509 v3 sein und RFC 5280 (immer noch das aktuelle Basis-X.509/PKIX-Zertifikatsprofil) sowie den aktuellen CA/Browser Forum Baseline Requirements entsprechen.	AWS schützt die Infrastruktur, auf der ACM in der AWS-Cloud läuft; die Wirksamkeit wird von externen Prüfern im Rahmen der AWS-Compliance-Programme getestet.	Setzt ausgewählte Einschränkungen gemäß RFC 5280 durch, allerdings werden nicht alle in RFC 5280 definierten Einschränkungen durchgesetzt.	Verwendet das ZLint-Tool zur Validierung von X.509-Zertifikaten anhand von RFC 5280, setzt jedoch nicht jede Anforderung von RFC 5280 durch.
6	CRL-Verteilungspunkt	Microsoft PKI hinterlegt die CRL unter LDAP und HTTP.	Die Aufhebung des Zertifikatswiderrufs für ACM erfolgt über den AWS-Support; hierfür muss ein Supportfall eröffnet werden.	ACM Private CA hinterlegt die CRL automatisch in einem dafür vorgesehenen Amazon S3-Bucket.	Die CRL-Veröffentlichung muss für einen CA-Pool explizit aktiviert werden, was bei der Pool-Erstellung erfolgen kann.
7	Speicherung privater Schlüssel	Es wird empfohlen, private Schlüssel in einem FIPS 140-3 Level 3-konformen HSM zu speichern (FIPS 140-2-Validierungen werden am 21. September 2026 in den historischen Status versetzt).	ACM speichert das Zertifikat und den dazugehörigen privaten Schlüssel und verwendet dabei den AWS Key Management Service (KMS) zum Schutz des privaten Schlüssels.	Standardmäßig werden private Schlüssel für private Zertifizierungsstellen in von AWS verwalteten HSMs gespeichert, die den FIPS PUB 140-3 Level 3 Sicherheitsanforderungen für kryptografische Module entsprechen.	Die CA-Schlüssel werden in Cloud HSM gespeichert, sind FIPS 140-2 Level 3-validiert und in Nord- und Südamerika, Europa und im asiatisch-pazifischen Raum verfügbar.
8	Prüfberichte	Die Überwachung kann auf einer Zertifizierungsstelle in Windows Server aktiviert werden, um ein Überwachungsprotokoll für alle Verwaltungsaufgaben der Zertifikatsdienste bereitzustellen.	ACM ist in AWS CloudTrail integriert, das Aktionen von Benutzern, Rollen oder AWS-Diensten aufzeichnet und standardmäßig aktiviert ist.	In den Prüfberichten werden alle Zertifikate aufgelistet, die die private Zertifizierungsstelle ACM ausgestellt oder widerrufen hat und die in einem neuen oder bestehenden S3-Bucket gespeichert wurden.	Die Cloud-Audit-Logs umfassen Protokolle zu Administratoraktivitäten, Datenzugriffen, Systemereignissen und Richtlinienverweigerungen für jedes Projekt, jeden Ordner und jede Organisation.
9	Bewährte Verfahren (Überblick)	Planen Sie vor der Bereitstellung, halten Sie die Root-CA offline, vermeiden Sie die Ausstellung von Endbenutzerzertifikaten von der Root-CA, aktivieren Sie die Überwachung und sichern Sie die Schlüssel mit einem FIPS 140-3 Level 3 HSM.	Überprüfen Sie regelmäßig Ablaufdatum und Gültigkeit der Zertifikate, minimieren Sie die Verwendung von Root-CAs und erzwingen Sie TLS 1.2 oder höher.	Dokumentieren Sie die CA-Struktur und -Richtlinien, minimieren Sie die Verwendung von Root-CAs, trennen Sie Administrator- und Ausstellerrollen, aktivieren Sie CloudTrail und rotieren Sie die privaten CA-Schlüssel regelmäßig.	Wenden Sie das Prinzip der minimalen Rechtevergabe an, nutzen Sie die Enterprise-Stufe für Multi-CA-Pools, sichern Sie Signaturschlüssel mit Cloud HSM und aktivieren Sie die Audit-Protokollierung.
10	CA-Hierarchie	Hierarchische PKI-Implementierungen verwenden typischerweise ein-, zwei- oder dreistufige Hierarchien.	ACM stellt Zertifikate für AWS-Dienste und verbundene Ressourcen bereit, verwaltet und implementiert diese, anstatt eine eigene CA-Hierarchie zu betreiben.	Unterstützt die Gestaltung einer Hierarchie von Zertifizierungsstellen mit bis zu fünf Ebenen.	Wenn eine untergeordnete Zertifizierungsstelle (CA) eine Kette zu einer externen Stammzertifizierungsstelle (Root CA) bildet, müssen die im von CAS generierten CSR enthaltenen Eigenschaften im signierten CA-Zertifikat erhalten bleiben, einschließlich etwaiger Pfadlängenbeschränkungen.
11	Redundanz und Notfallwiederherstellung	Redundanz- und Notfallwiederherstellungspläne sollten bereits in der Planungsphase der Konzeption und Implementierung einer PKI-Implementierung berücksichtigt werden.	ACM selbst verfügt über keine dedizierte SLA, der verwaltete Dienst der ACM Private Certificate Authority hingegen schon.	Verfügbar in mehreren AWS-Regionen für redundante Zertifizierungsstellen, Betrieb unter einem SLA-Ziel von 99.9 % Verfügbarkeit.	Verfügbar in mehreren Google Cloud-Regionen für Redundanz, Betrieb unter einem SLA-Ziel von 99.9% Verfügbarkeit.

Vor- und Nachteile der einzelnen Plattformen

Microsoft PKI (ADCS)

Vorteile: volle Kontrolle über die CA-Hierarchie und -Richtlinien, enge Active Directory-Integration, keine wiederkehrenden Cloud-Servicegebühren für die CA selbst, gut verstanden von den meisten Windows-Administratoren in Unternehmen.

Nachteile: Erfordert die interne Beschaffung von HSMs und Offline-Root-CA-Zeremonien, manuelle Zertifikatslebenszyklusprozesse, sofern keine separate Automatisierung erfolgt, und die operative Belastung liegt vollständig beim internen Personal.

AWS Certificate Manager (ACM)

Vorteile: kostenlose öffentliche TLS-Zertifikate zur Verwendung mit integrierten AWS-Diensten, automatische Verlängerung, minimaler Betriebsaufwand, enge CloudTrail-Integration für Audit-Transparenz.

Nachteile: beschränkt auf AWS-integrierte Ressourcen und öffentliche/importierte Zertifikate, keine eigene native private CA-Hierarchie und keine dedizierte SLA für den kostenlosen öffentlichen Zertifikatsdienst.

AWS ACM Private CA

Vorteile: vollständig verwaltete private CA-Hierarchie bis zu fünf Ebenen tief, standardmäßig FIPS 140-3 Level 3 HSM-gestützte Schlüssel, native CloudTrail-Überwachung, 99.9 % SLA.

Nachteile: laufende Kosten pro Zertifizierungsstelle und pro Zertifikat, AWS-zentriert und setzt nicht alle RFC 5280-Beschränkungen automatisch durch.

Google Cloud-Zertifizierungsstellendienst

Vorteile: flexible Enterprise- und DevOps-Ebenen, Cloud-HSM-gestützte Signaturschlüssel, granulare IAM-basierte Rollenzuweisung, hervorragende Eignung für GCP-zentrierte Infrastrukturen.

Nachteile: Die DevOps-Ebene unterstützt keine Zertifikatswiderrufung, die CRL-Veröffentlichung muss explizit aktiviert werden, und sie setzt nicht alle Anforderungen von RFC 5280 durch.

Auswahl der richtigen PKI: Entscheidungsmatrix

Luftüberwachung	Auswirkungen auf die Sicherheit	Operativer Aufwand	Automatisierungsanpassung	Empfohlener Eigentümer
TLS-Zertifikate für öffentlich zugängliche Websites/Apps auf der AWS-Infrastruktur	Mittel – öffentliche Vertrauenskette, kurze Gültigkeitsfenster	Niedrig, sobald konfiguriert	Hoch – AWS Certificate Manager verlängert sich automatisch	Plattform-/DevOps-Teams
Vollständig offline, vom Luftspalt getrennte interne Root-CA für regulatorische oder Hochsicherheitsanforderungen	Hoch – die wichtigste Vertrauensbasis für die gesamte interne PKI.	Hoch — manuelle Zeremonien, HSM-Management	Gezielt niedrig (absichtlich offline)	PKI-Administratoren, Sicherheitsarchitekten
Die private CA-Hierarchie wird vollständig in AWS für interne Dienste und Geräteidentität gehostet.	Hoch – schützt das interne Vertrauen zwischen den Diensten	Mittel – verwaltetes HSM, aber Richtlinien- und Hierarchiegestaltung weiterhin erforderlich	Hoch – AWS ACM Private CA-Automatisierung und CloudTrail	PKI-Administratoren, Plattformteams
Multi-Cloud- oder GCP-zentrierte Infrastruktur, die CA-Pools pro Projekt benötigt	Hoch – regelt das Vertrauen in GCP-Projekten	Mittel – IAM-Rollendesign und CA-Pool-Tiering	Hoch – Google Cloud CAS mit Cloud HSM	Plattformteams, Sicherheitsarchitekten
Hybride On-Premises- und Multi-Cloud-PKI, die eine einzige Governance-Ebene benötigt.	Hoch — umfasst alle Plattformen darüber	Mittel, bei Verwendung einer verwalteten Schicht; hoch bei Selbstintegration.	Hochwertig mit einer verwalteten PKI-as-a-Service- und Zertifikatslebenszyklusverwaltungsschicht	CISOs, Sicherheitsarchitekten, Compliance

Praktische Checkliste: Prüfung einer Multi-Vendor-PKI

Problem	Auswirkungen auf das Geschäft	Empfohlene Maßnahme	Eigentümer
Es gibt keinen dokumentierten Entscheidungsprozess, welche Plattform welche Zertifikate ausstellt.	Doppelte CA-Hierarchien, inkonsistenter Schlüsselschutz in verschiedenen Teams	Vor der Bereitstellung einer neuen Zertifizierungsstelle sollte eine dokumentierte Entscheidungsmatrix (Anwendungsfall, Sicherheitsauswirkungen, Aufwand, Automatisierungseignung, Verantwortlicher) verwendet werden.	Sicherheitsarchitekten, CISOs
Jede CA-Hierarchie, die noch auf FIPS 140-2 validierten HSMs basiert	Validierungen werden am 21. September 2026 in den historischen Status versetzt.	Planen Sie eine Migration zu FIPS 140-3 Level 3 validierten HSMs, sofern die Plattform dies unterstützt.	PKI-Administratoren, Compliance
Manuelle Zertifikatsausstellung oder -verlängerung auf jeder Plattform	Kann mit dem immer kürzer werdenden Gültigkeitszeitraum des CA/Browser-Forums nicht mehr mithalten.	Wechseln Sie zu plattformnativer Automatisierung (ACM, ACM Private CA oder Google Cloud CAS) oder einer verwalteten PKI/CLM-Schicht.	Plattformteams, PKI-Administratoren
Keine einheitliche Audit-Protokollierung über Microsoft PKI, AWS und Google Cloud-Zertifizierungsstellen hinweg	Compliance-Lücken treten erst im Falle eines Vorfalls oder einer externen Prüfung zutage.	Aktivieren und zentralisieren Sie CloudTrail, Cloud-Audit-Logs und Windows Server-Auditierung in einer einzigen Überwachungsansicht	Compliance, Sicherheitsarchitekten
Kein Plan für Krypto-Agilität im Hinblick auf den eventuellen PQC-Übergang	Alle vier Plattformen arbeiten auch heute noch mit RSA oder ECDSA zusammen.	Ergänzen Sie die PKI-Roadmap um eine PQC-Bereitschaftsbewertung und eine Krypto-Agilitätsplanung.	Sicherheitsarchitekten, CISOs

Wen sollte das interessieren?

Die Wahl zwischen verschiedenen PKI-Plattformen ist nicht nur eine Architekturentscheidung. Hier die wichtigsten Erkenntnisse für alle Beteiligten.

PKI-Administratoren

Eigenverantwortlicher, täglicher Betrieb der jeweiligen Plattform(en), die das Unternehmen einsetzt. Maßnahmenpunkt: Sicherstellen, dass jede verwendete Zertifizierungsstellenhierarchie (Microsoft PKI, AWS oder Google Cloud) auf der FIPS 140-3 Level 3 HSM-Roadmap steht und über eine automatische Erneuerung verfügt, sofern die Plattform dies unterstützt.

Sicherheitsarchitekten

Verantwortlich für die Entscheidungsmatrix und das Hierarchiedesign plattformübergreifend. Maßnahmen: Dokumentieren Sie, warum sich jede bestehende CA-Hierarchie an ihrem jeweiligen Standort befindet, und kennzeichnen Sie alle Hierarchien, die nur aufgrund historischer Gepflogenheiten und nicht aufgrund einer bewussten Anpassung an den Anwendungsfall existieren.

Plattformteams

Verantwortlich für die Automatisierungsebene, die die Ausstellung und Erneuerung von Zertifikaten von manuellen Prozessen entkoppelt. Handlungsempfehlung: Ermitteln Sie, welche Ihrer AWS-, Google Cloud- oder Microsoft PKI-Zertifikate noch die manuelle Eingabe über eine Konsole erfordern, anstatt eines automatisierten Protokolls.

Compliance-Teams

Für jede verwendete CA-Hierarchie existieren eigene, bestätigende Audit-Protokolle und CP/CPS-Dokumentationen. Maßnahmenpunkt: Sicherstellen, dass der FIPS-Validierungsstatus (140-2 vs. 140-3) pro HSM und Plattform erfasst und nicht einfach vorausgesetzt wird.

CISOS

Übernehmen Sie die Verantwortung für die Entscheidung zwischen Eigenentwicklung, Kauf oder Multi-Cloud-Lösung für Ihre PKI. Handlungsempfehlung: Wägen Sie die Betriebskosten für den unabhängigen Betrieb von Microsoft PKI, AWS und Google Cloud CAs gegen die Kosten einer Konsolidierung unter einer verwalteten PKI-as-a-Service-Lösung und einem Zertifikatslebenszyklusmanagement ab.

Unsere Einschätzung: Wie Verschlüsselungsberatung die Auswahl von PKI-Anbietern unterstützt

Bei Encryption Consulting sind wir auf die Konzeption und Migration von PKI-Infrastrukturen spezialisiert, die optimal auf die individuellen Sicherheitsanforderungen Ihres Unternehmens zugeschnitten sind – unabhängig davon, welche Plattform oder Plattformkombination am besten geeignet ist. Wir bieten umfassende Dienstleistungen für die Konzeption und Implementierung von PKI -Infrastrukturen, sowohl für bestehende als auch für neue. Unsere On-Premises-Lösungen umfassen Microsoft PKI, während unsere Cloud-basierten PKI-Lösungen mit führenden Cloud-Service-Anbietern wie AWS Certificate Manager, AWS ACM Private CA, Azure PKI und Google Cloud Certificate Authority Service kompatibel sind.

Für Organisationen, die diese Entscheidung und die daraus resultierende Hierarchie nicht vollständig intern verwalten möchten, bietet unsere PKI-as-a-Service -Plattform eine vollständig verwaltete, cloudbasierte PKI mit FIPS 140-3 HSM-gestützten Schlüsseln vom ersten Tag an. Der oben genannte Plattformvergleich wird somit von uns übernommen. Unsere CertSecure Manager- Schicht kümmert sich anschließend um das Zertifikatslebenszyklusmanagement und die automatisierte Erkennung über die bestehende Kombination von Microsoft PKI, AWS und Google Cloud-Zertifizierungsstellen hinweg und schließt damit die in der Checkliste erwähnte Lücke bei der manuellen Zertifikatsausstellung. Bezüglich der zuvor angesprochenen Frage der Krypto-Agilität unterstützen unser PQC Center of Excellence und die PQC Readiness Assessment Teams bei der Planung des schrittweisen Umstiegs von RSA und ECDSA. Unsere CBOM Secure- Plattform zur kryptografischen Erkennung und Inventarisierung liefert Sicherheitsarchitekten das benötigte Maschinenidentitätsinventar, um genau zu wissen, welche Systeme aktuell in der jeweiligen Zertifizierungsstellenhierarchie ausgeführt werden. Weitere Informationen zur Automatisierung des Zertifikatslebenszyklusmanagements nach der Plattformauswahl finden Sie in unserem zugehörigen Beitrag darüber, wie CLM zur Abwehr gängiger SSL/TLS-Angriffe beiträgt.

Weiterführende Literatur

AWS ACM Private CA Benutzerhandbuch

Google Cloud-Zertifizierungsstellendienst

Microsoft PKI-Dienste-Zertifikatrichtlinie

Fazit

Die Public-Key-Infrastruktur (PKI) spielt eine entscheidende Rolle für die sichere Kommunikation mittels digitaler Zertifikate. Zertifizierungsstellen und Registrierungsstellen arbeiten zusammen, um Entitäten zu authentifizieren und den Zertifikatslebenszyklus zu verwalten. Verschiedene Anbieter stellen maßgeschneiderte PKI-Lösungen mit jeweils unterschiedlichen Stärken für verschiedene Anwendungsfälle bereit: Microsoft PKI setzt auf sicheres, lokales Schlüsselmanagement mit Offline-Root-CAs und HSMs, AWS Certificate Manager und ACM Private CA bieten automatisiertes, Cloud-natives Zertifikatsmanagement mit FIPS 140-3 Level 3 HSM-Schutz, und der Certificate Authority Service von Google Cloud legt Wert auf rollenbasierte Zugriffskontrolle und Cloud-HSM-gestützte Signaturschlüssel. Die optimale Lösung ist selten eine einzelne Plattform; vielmehr ist eine dokumentierte Entscheidung erforderlich, die auf Anwendungsfall, Sicherheitsauswirkungen, Betriebsaufwand und Zuständigkeiten abgestimmt ist und regelmäßig aktualisiert wird, wenn sich die Gültigkeitsdauer verkürzt und die Branche auf Post-Quanten-Technologien vorbereitet ist.

Häufig gestellte Fragen

Was ist die wichtigste Erkenntnis aus dem Vergleich dieser PKI-Plattformen?

Microsoft PKI, AWS Certificate Manager, AWS ACM Private CA und Google Cloud CAS stellen alle vertrauenswürdige digitale Zertifikate aus und verwalten diese. Sie unterscheiden sich jedoch darin, wo die CA-Schlüssel gespeichert sind, wie automatisiert die Ausstellung erfolgt und wer die operative Verantwortung trägt. Die richtige Wahl hängt vom jeweiligen Anwendungsfall ab; es gibt keine allgemeingültige „beste“ Plattform.

Warum ist das für PKI-Teams in Unternehmen wichtig?

PKI-Teams in Unternehmen betreiben zunehmend mehrere dieser Plattformen gleichzeitig. Ohne einen dokumentierten Entscheidungsprozess führt diese Kombination zu doppelten CA-Hierarchien, inkonsistenten Schlüsselschutzstufen und Lücken in der Audit-Protokollierung, die erst im Falle eines Vorfalls sichtbar werden.

Welche Risiken steigen, wenn die Auswahl des PKI-Anbieters ohne dokumentierten Prozess erfolgt?

Die willkürliche Auswahl von Anbietern birgt das Risiko, dass Zertifikate auf Basis inkonsistenter HSM-Schutzebenen, undurchschaubarer CA-Hierarchien und manueller Erneuerungsprozesse ausgestellt werden, die mit dem immer kürzer werdenden Gültigkeitszyklus des CA/Browser-Forums nicht Schritt halten können.

Welche Teams sollten die Entscheidung über die Auswahl des PKI-Anbieters treffen?

In der Regel sind Sicherheitsarchitekten für die Entscheidungsmatrix und die Hierarchiegestaltung verantwortlich, PKI-Administratoren für den täglichen Betrieb der jeweiligen Plattformen, Plattformteams für die Automatisierungsschicht, die Compliance-Abteilung prüft die Dokumentation und den FIPS-Status, und der CISO trägt die Gesamtverantwortung für die Entscheidung zwischen Eigenentwicklung, Kauf oder Multi-Cloud.

Wie hängt die Wahl des PKI-Anbieters mit dem Zertifikatslebenszyklusmanagement zusammen?

Alle in diesem Vergleich betrachteten Plattformen benötigen weiterhin eine zuverlässige Ausstellung, Verlängerung und Widerrufung von Zertifikaten. Tools für das Zertifikatslebenszyklusmanagement, die Microsoft PKI, AWS und Google Cloud umfassen, gewährleisten diese Zuverlässigkeit unabhängig davon, welche Plattform das jeweilige Zertifikat ausgestellt hat.

Wie können Organisationen messen, ob ihre Wahl des PKI-Anbieters erfolgreich ist?

Verfolgen Sie Ausfälle im Zusammenhang mit Zertifikaten und Vorfälle im Zusammenhang mit abgelaufenen Zertifikaten, ob die Ausstellung und Erneuerung automatisiert oder manuell erfolgt, ob die Audit-Protokollierung plattformübergreifend zentralisiert ist und ob der HSM-Schutzlevel jeder CA-Hierarchie aktuell ist.

Was sollte in einer Multi-Vendor-PKI regelmäßig geprüft oder überwacht werden?

Überprüfen Sie regelmäßig die Dokumentation der CA-Hierarchie (CP/CPS), den FIPS-Validierungsstatus pro HSM, das Ablaufdatum der Zertifikate auf allen verwendeten Plattformen sowie die Frage, ob CloudTrail, Cloud-Audit-Logs und die Windows Server-Überwachung tatsächlich aktiviert und überwacht werden.

Wie wirkt sich die Wahl des PKI-Anbieters auf Cloud-, Hybrid- oder Multi-CA-Umgebungen aus?

Hybrid- und Multi-Cloud-Umgebungen setzen häufig Microsoft PKI lokal neben AWS- und Google Cloud-Zertifizierungsstellen ein, jeweils mit eigener Konsole, eigenem Automatisierungsmodell und eigenem Audit-Trail. Eine einheitliche Governance-Ebene oder eine verwaltete PKI/CLM-Plattform sorgt in der Regel für Konsistenz und verhindert eine Fragmentierung dieser Infrastruktur.

Welche häufigen Fehler sollten Teams bei der Auswahl zwischen diesen Plattformen vermeiden?

Zu den häufigsten Fehlern gehören die Auswahl einer Plattform basierend darauf, auf welcher Cloud der Rest der Arbeitslast ausgeführt wird, anstatt auf dem eigentlichen Anwendungsfall, die jahrelange Nichtüberprüfung des FIPS-Validierungsstatus einer Root-CA und die Ausführung paralleler CA-Hierarchien über verschiedene Plattformen hinweg ohne dokumentierten Grund für jede einzelne.

Was sollte bei einer Multi-Vendor-PKI vierteljährlich aktualisiert werden?

Überprüfen Sie die Dashboards zum Ablauf von Zertifikaten, bestätigen Sie den Fortschritt der FIPS 140-3-Migration für alle HSMs, die noch auf 140-2 laufen, überprüfen Sie die Entscheidungsmatrix für alle neuen Anwendungsfälle, die seit der letzten Überprüfung hinzugefügt wurden, und stellen Sie sicher, dass Änderungen der Gültigkeitsdauer des CA/Browser Forums in der Erneuerungsautomatisierung berücksichtigt werden.