Einschränkungen des AWS Certificate Manager: Wo ACM für Enterprise-PKI an seine Grenzen stößt.

AWS Certificate Manager (ACM) ist ein kostenloser, vollständig verwalteter Dienst, der TLS-Zertifikate für AWS-integrierte Dienste wie ELB, CloudFront und API Gateway ausstellt und erneuert. Die Automatisierung, die Bestandsverwaltung und die kostenlose Preisgestaltung enden jedoch an der AWS-Grenze. Unternehmen mit Multi-Cloud-, Hybrid- oder umfangreichen Zertifikatslandschaften benötigen daher eine herstellerneutrale Lösung für das Zertifikatslebenszyklusmanagement (CLM).

AWS Certificate Manager (ACM) ist ein verwalteter Dienst, der TLS/SSL-Zertifikate für in AWS integrierte Dienste bereitstellt, implementiert und erneuert. Er hat sich aus gutem Grund zum Standard für TLS-Zertifikate im AWS-Ökosystem entwickelt: Er ist für integrierte Dienste kostenlos, vollständig verwaltet und nach der Konfiguration praktisch unsichtbar. Die Zertifikatsverwaltung beschränkt sich jedoch selten vollständig auf AWS.

Da Unternehmen ihre Workloads zunehmend über mehrere Clouds, On-Premise-Infrastrukturen und eine wachsende Anzahl von Zertifizierungsstellen verteilen, lautet die Frage nicht mehr „Ist ACM gut?“, sondern „Wo stößt ACM an seine Grenzen?“. Dieser Blogbeitrag beantwortet diese Frage. Er zeigt auf, wo ACM tatsächlich seinen Platz hat, welche praktischen Einschränkungen PKI- Teams begegnen, sobald sie über AWS-native Dienste hinausgehen, welche wirtschaftlichen Faktoren diese Einschränkungen bedingen und wie eine herstellerneutrale CLM-Plattform die Lücken schließt – insbesondere angesichts der sinkenden Gültigkeitsdauern von Zertifikaten und des Übergangs zur Post-Quantum-Technologie, der die Anforderungen erhöht.

Kurzantwort: Wo hat AWS Certificate Manager seine Schwächen?

AWS Certificate Manager ist kostenlos und hervorragend für TLS-Zertifikate auf ACM-integrierten AWS-Services (ELB, CloudFront, API Gateway) geeignet. Die Automatisierung, die Bestandsverwaltung und die kostenlose Preisgestaltung enden jedoch an der AWS-Grenze . Sobald ein Zertifikat auf einem Nicht-AWS-Endpunkt bereitgestellt wird, mehrere Konten oder Regionen umfasst oder revisionssichere Compliance-Berichte erfordert, reicht ACM allein nicht mehr aus und eine herstellerneutrale CLM-Schicht ist notwendig.

Wichtige Erkenntnisse

• ACM ist wirklich leistungsstark für AWS-native Workloads auf ACM-integrierten Diensten, aber es stellt Zertifikate nirgendwo außerhalb dieser Grenze bereit.
• Die Trust Pulse Survey von DigiCert (2. Juli 2025) ergab, dass 45 Prozent der Unternehmen im vergangenen Jahr Ausfallzeiten im Zusammenhang mit Zertifikaten erlebten, und 37.5 Prozent konnten einen Ausfall konkret auf ein abgelaufenes Zertifikat zurückführen – genau das Risiko, das durch die manuelle, nicht AWS-basierte Zertifikatsverwaltung entsteht.
• Der vom CA/Browser Forum vorgelegte Wahlvorschlag SC-081v3 (angenommen am 14. April 2025) sieht eine schrittweise Verlängerung der maximalen Gültigkeitsdauer öffentlicher TLS-Zertifikate von 200 Tagen (März 2026) über 100 Tage (März 2027) auf 47 Tage (März 2029) vor, wodurch jede manuelle Lücke in der Automatisierung von ACM zu wiederkehrenden und steigenden Kosten führt.
• Auf G2 hat AWS Certificate Manager eine Bewertung von 4.5 von 5 Sternen basierend auf 55 Rezensionen, und CertSecure Manager hat eine Bewertung von 4.8 von 5 Sternen basierend auf 3 Rezensionen (Stand: 13. August 2026). AWS Private CA hat keinen unabhängigen Eintrag auf G2 oder Capterra.
• Die Teams für PKI, Sicherheit, Plattform und Compliance sind jeweils für eine bestimmte Aufgabe zuständig; die untenstehende Verantwortlichkeits-/Aufgabenmatrix und die Entscheidungstabelle für den Käufer zeigen genau, was und wer dafür verantwortlich ist.

Direkt zu: Zusammenfassung | Checkliste zur Vorbereitung | Anbietervergleich | Entscheidungstabelle für Käufer | Funktionsmatrix | Verantwortlichkeits-/Aktionsmatrix | Nächste Schritte | FAQ

Zusammenfassung für die Teams PKI, Sicherheit, Plattform und Compliance

Wenn Sie eine dieser Funktionen leiten, finden Sie hier die in diesem Artikel unterstützte Entscheidung und die entsprechende Kurzanleitung.

• PKI-Teams: Behalten Sie ACM für AWS-integrierte Dienste bei und evaluieren Sie eine herstellerneutrale CLM-Plattform, sobald Sie mehr als eine Zertifizierungsstelle, mehr als eine Cloud oder eine nennenswerte On-Premises-Infrastruktur betreiben.
• Sicherheitsteams: Behandeln Sie jedes außerhalb von ACM-integrierten Diensten bereitgestellte Zertifikat als manuellen Prozess, bis das Gegenteil bewiesen ist, und schließen Sie diese Lücke durch eine Automatisierung im geschlossenen Regelkreis.
• Plattform-/DevSecOps-Teams: Erstellen Sie ein einziges Inventar und eine einzige Verlängerungswarteschlange für AWS-Konten, Regionen, andere Clouds und lokale Endpunkte anstatt Tools pro Konto und Region.
• Compliance-Teams: Bestätigen Sie, dass Sie bei Bedarf einen revisionssicheren Bericht auf Zertifikatsniveau für Ihre gesamte IT-Infrastruktur erstellen können, nicht nur für den AWS-nativen Bereich, den ACM abdeckt.

Kurzcheckliste zur Einsatzbereitschaft

Nutzen Sie diese Checkliste, um zu beurteilen, ob ACM allein für Ihre Umgebung noch ausreicht.

• Es wurde geprüft, ob Zertifikate auf nicht in AWS integrierten Endpunkten (EC2 mit NGINX, lokales F5, Azure, GCP, Drittanbieter-CDNs) bereitgestellt werden.
• Es wurde überprüft, ob sich Ihr Zertifikatsbestand über mehr als ein AWS-Konto oder eine Region erstreckt und ob Sie eine einheitliche Ansicht darüber haben.
• Es wurde geprüft, ob ein Konformitätsbericht auf Zertifikatsebene (Inhaber, Algorithmus, Ablaufdatum, Einhaltung der Richtlinien) ohne manuelle Tabellenkalkulation erstellt werden kann.
• Es wurde geprüft, ob Ihre Zertifikatsstrategie auch nach einer Migration von Workloads zu einem anderen Cloud-Anbieter ohne vollständige Neuentwicklung bestehen bleibt.
• Es wurde modelliert, wie die Erneuerungshäufigkeit bei einer Gültigkeitsdauer von 47 Tagen aussieht, nicht nur bei der heutigen maximalen Laufzeit von 13 Monaten.

Wer sollte sich für die Einschränkungen von ACM und die CLM-Entscheidung interessieren?

Die Entscheidung, über ACM hinauszugehen, liegt nicht in der Hand eines einzelnen Teams. PKI-Teams sind zwar für die Architekturentscheidung verantwortlich, aber Sicherheitsteams, Plattformingenieure, Compliance-Teams und CISOs tragen jeweils spezifische Verantwortlichkeiten, um sicherzustellen, dass der Zertifikatsbestand vollständig verwaltet, automatisiert und auditbereit ist, unabhängig davon, wo die Zertifikate bereitgestellt werden oder welche Zertifizierungsstelle sie ausgestellt hat.

Funktion / Rolle (Role) *	Warum es wichtig ist	Aktionselement
PKI- und Zertifikatsteams	Sie tragen die Verantwortung für die Architekturentscheidung: Ist ACM allein für die aktuelle Zertifikatslandschaft ausreichend, oder erfordert die Kombination aus mehreren Zertifizierungsstellen, verschiedenen Clouds, lokalen Endpunkten oder Compliance-Berichtspflichten eine herstellerneutrale CLM-Schicht? Der Zeitplan des CA/Browser Forum SC-081v3 (47 Tage bis März 2029) macht die Entscheidung zeitkritisch, da die Automatisierungslücke für Nicht-AWS-Endpunkte bei hoher Erneuerungsfrequenz betrieblich nicht mehr tragbar ist. Die Preisgestaltung für AWS Private CA pro Zertifizierungsstelle (400 US-Dollar/Monat für allgemeine Zwecke, 50 US-Dollar/Monat für kurzfristige Nutzung) muss ebenfalls im Hinblick auf Volumen und Hierarchiedesign modelliert werden, bevor diese Option gewählt wird.	Ordnen Sie den gesamten Zertifikatsbestand der Entscheidungstabelle und der Merkmalsmatrix des Käufers in diesem Beitrag zu; identifizieren Sie jedes außerhalb von ACM-integrierten Diensten bereitgestellte Zertifikat und bestätigen Sie, dass es sich in einem geschlossenen automatisierten Erneuerungsprozess befindet; modellieren Sie die Kosten von AWS Private CA anhand einer zweistufigen Hierarchie einschließlich regionsübergreifender Hochverfügbarkeit; bewerten Sie CertSecure Manager als CLM-Schicht, die ACM, AWS Private CA, Microsoft AD CS, HashiCorp Vault PKI, DigiCert und Entrust über eine einzige Konsole verbindet; verwenden CBOM Secure um Zertifikate über alle AWS-Konten und -Regionen hinweg zu ermitteln, bevor man sich für eine CLM-Architektur entscheidet
Sicherheitsarchitekten	Eigenverantwortliches Schließen der Automatisierungslücke für Nicht-AWS-Endpunkte und die Krypto-Agilitätsarchitektur: Die architektonische Abhängigkeit von ACM von AWS bedeutet, dass ein CA-Misstrauensereignis, die Abschaffung eines Algorithmus oder ein Wechsel des Cloud-Anbieters den Neuaufbau des CLM-Stacks erfordert, anstatt lediglich die Richtlinien neu zu konfigurieren. NIST FIPS 203/204/205 (finalisiert am 13. August 2024) fordern gemäß NIST IR 8547 den Austausch von RSA- und Elliptische-Kurven-Algorithmen im gesamten Zertifikatsbestand bis 2030. Diese Migration erfordert eine CLM-Plattform, die von Grund auf CA-agnostisch ist. Eine architektonisch an ACM gebundene Plattform kann einen CA- oder Algorithmuswechsel nicht als Richtlinienänderung durchführen.	Die CLM-Schicht sollte herstellerneutral und CA-agnostisch sein, sodass ein CA-Wechsel, eine Algorithmusänderung oder ein Wechsel des Cloud-Anbieters eine Richtlinienrekonfiguration und kein kompletter Neuaufbau erfordert; führen Sie eine PQC-Bereitschaftsbewertung durch PQC-Bereitschaft Dienstleistungen zur Klassifizierung der aktuellen Gefährdung durch Zertifikatsalgorithmen im Hinblick auf die Meilensteine ​​der Abschaffung gemäß NIST IR 8547; Nachverfolgung der Migrationsplanung nach der Quantenmigration durch die PQC Kompetenzzentrum; bestätigen, dass jeder Zertifikatserneuerungspfad für Nicht-AWS-Endpunkte vor der 100-tägigen SC-081v3-Phase im März 2027 vollständig automatisiert ist.
Plattform- und DevSecOps-Teams	Eigene konto-, regions- und cloudübergreifende Inventar- und Erneuerungsautomatisierung: Das Inventar von ACM ist auf ein einzelnes AWS-Konto und eine einzelne Region beschränkt, wodurch 48 logische Inventare für eine Bereitstellung mit 12 Konten und 4 Regionen ohne native Einzelansicht entstehen; die CloudFront-Anforderung, dass sich Zertifikate in us-east-1 befinden müssen, führt zu doppelten Zertifikatsinventaren für Multi-Region-Bereitstellungen ohne automatische Synchronisierung; Kubernetes-Workloads, die sich über mehrere Clouds erstrecken, können ACM nicht für die Zertifikatsverwaltung außerhalb von EKS verwenden; CI/CD-Pipelines, die Zertifikate über DevOps-Tools (cert-manager, certbot) ausstellen, benötigen einen ACME-Endpunkt, der sowohl cloud- als auch lokal funktioniert, nicht nur innerhalb von AWS.	Erstellen Sie ein zentrales Inventar und eine zentrale Erneuerungswarteschlange für alle AWS-Konten und -Regionen, Azure, GCP, lokale Umgebungen und Kubernetes-Cluster mithilfe einer CLM-Plattform mit nativer umgebungsübergreifender Erkennung. Integrieren Sie die ACME-Registrierung in alle Service-Provisioning-Pipelines, sodass Cloud-native und DevOps-Workloads über dasselbe Protokoll an der CLM-Plattform und nicht an kontospezifischen ACM-Endpunkten registriert werden. Testen Sie eine kontoübergreifende Inventaransicht vor der 100-tägigen Phase gemäß SC-081v3 im März 2027. Fügen Sie der Plattform-Observability-Alerting-Funktion die Überwachung des Zertifikatsablaufs für alle Nicht-AWS-Endpunkte hinzu.
Compliance-Teams	Eigene, auditfähige Berichte für den gesamten Zertifikatsbestand: ACM erstellt ohne benutzerdefinierte AWS-Config-Regeln, Lambda-Funktionen und manuelle Tabellenkalkulation keine Compliance-Berichte auf Zertifikatsebene für PCI DSS, HIPAA, SOC 2 oder DORA. Die Diskrepanz zwischen den von ACM bereitgestellten Informationen und den Anforderungen von Auditoren (Details auf Zertifikatsebene, einschließlich Inhaber, Algorithmus, Ablaufdatum, Richtlinienkonformität und ausstellende Zertifizierungsstelle in allen Umgebungen) ist der am häufigsten unterschätzte Betriebskostenfaktor bei der ausschließlichen Nutzung von ACM in regulierten Unternehmen. Die DigiCert Trust Pulse Survey (2. Juli 2025) ergab, dass 45 Prozent der Unternehmen Ausfallzeiten im Zusammenhang mit Zertifikaten verzeichneten, und die Ergebnisse von Audits zur Zertifikatsverwaltung sind eine direkte Folge dieser Bestandslücke.	Bestätigen Sie, dass Konformitätsberichte auf Zertifikatsebene bedarfs- und planmäßig ohne manuelle Tabellenkalkulation erstellt werden können; integrieren Sie die Zertifikatsverwaltung in das vierteljährliche Konformitätsnachweispaket: Algorithmusklassifizierung, Vollständigkeit der Eigentumsverhältnisse, Abdeckung der Ablaufüberwachung und Automatisierungsrate der Erneuerung; ordnen Sie die Phasendaten des CA/B Forum SC-081v3 (200 Tage März 2026, 100 Tage März 2027, 47 Tage März 2029) internen Konformitätsmeilensteinen für die Bereitschaft zur Automatisierung der Erneuerung zu; bestätigen Sie, dass der Audit-Trail der CLM-Plattform die Anforderungen von PCI DSS 4.0 Requirement 10, HIPAA Audit Logging Requirements, SOC 2 Availability Controls und DORA ICT Risk Management Requirements erfüllt.
CISOS	Allein die ACM-Lösung stellt in Multi-Cloud- oder Hybrid-Unternehmen ein Risiko auf Vorstandsebene dar: Laut der DigiCert Trust Pulse Survey (2. Juli 2025) erlebten 45 Prozent der Unternehmen Ausfallzeiten im Zusammenhang mit Zertifikaten, und 37.5 Prozent führten einen Ausfall auf ein abgelaufenes Zertifikat zurück. Die 47-tägige Frist des CA/B Forums führt dazu, dass jeder manuelle Zertifikatsprozess achtmal jährlich statt nur einmal zu einem Ausfall führt. Die architektonische Abhängigkeit von ACM vor dem Übergang zur Post-Quanten-Technologie bedeutet, dass der CLM-Stack nach der Abschaffung von RSA und ECC ab 2030 komplett neu aufgebaut und nicht nur neu konfiguriert werden kann. Der Flexera State of the Cloud Report 2024 ergab, dass 89 Prozent der Unternehmen Multi-Cloud eingeführt haben, wodurch die AWS-Beschränkung für die meisten regulierten Organisationen ein strategisches Risiko darstellt.	Ein herstellerneutrales CLM-Programm sollte als strategische Investition mit Verantwortung auf C-Level-Ebene finanziert werden, nicht als taktische Tool-Entscheidung pro Team; die Vollständigkeit des Zertifikatsbestands und die Abdeckung der Automatisierung von Erneuerungen sollten als KPIs auf Vorstandsebene berichtet werden; evaluieren PKI als Service Für Organisationen, die eine vollständig verwaltete PKI-Schicht mit integrierter Disaster Recovery, Compliance-Unterstützung und Post-Quantum-Migrationsfunktion benötigen; vorschreiben, dass die Planung der Post-Quantum-Algorithmusmigration für alle Zertifikatspopulationen in die jährliche PKI-Programmüberprüfung einbezogen wird; den Fortschritt der PQC-Migration über das PQC Kompetenzzentrum

Wo ACM passt und wo nicht

Wenn Ihre gesamte Arbeitslast hinter einem Application Load Balancer liegt, der von Amazon CloudFront gesteuert und über Amazon API Gateway bereitgestellt wird, ist AWS Certificate Manager (ACM) kaum zu übertreffen. Er stellt kostenlos öffentliche TLS-Zertifikate für diese integrierten Dienste aus, kümmert sich um deren Erneuerung und verursacht nahezu keinen Betriebsaufwand. Für reine AWS-native Teams mit einer begrenzten Infrastruktur ist er einer der besten Managed Services von AWS.

Die Probleme beginnen, sobald Ihre Zertifikatsarchitektur über die Grenzen von AWS hinausgeht. Die meisten Unternehmen, mit denen wir bei Encryption Consulting zusammenarbeiten, sind keine reinen AWS-Anwender. Sie nutzen eine Mischung aus lokalem Microsoft Active Directory (AD CS), Drittanbieter-Zertifizierungsstellen wie DigiCert oder Entrust für öffentlich vertrauenswürdige Zertifikate, HashiCorp Vault PKI für Service Mesh und DevOps-Workloads sowie einer Vielzahl von Workloads auf F5 BIG-IP, NGINX, Apache Tomcat und IIS, die in keiner Verbindung zu AWS stehen.

Laut dem Flexera-Bericht „State of the Cloud 2024“ haben rund 89 % der Unternehmen Multi-Cloud-Lösungen eingeführt, und Gartner prognostiziert, dass bis 2027 über 90 % der Unternehmen Hybrid-Cloud-Lösungen nutzen werden. In diesem Umfeld ist ein CLM-Tool, das nur einen Cloud-Anbieter in einer Region verwalten kann, bestenfalls eine Teillösung.

Dieser Blogbeitrag erläutert die praktischen Einschränkungen von ACM, auf die PKI-Teams bei der Implementierung in Unternehmen stoßen, die damit verbundenen wirtschaftlichen Aspekte und wie eine herstellerneutrale CLM-Plattform wie der CertSecure Manager von Encryption Consulting die Lücken schließt, die ACM hinterlässt.

ACM vs. AWS Private CA: Eine kurze Auffrischung

Bevor wir fortfahren, ist es wichtig, zwei AWS-Dienste zu unterscheiden, die oft verwechselt werden. AWS hat „ACM Private CA“ im September 2022 in „AWS Private CA“ umbenannt, und diese Unterscheidung ist relevant, wenn Sie Preisinformationen lesen oder Registrierungsprozesse entwerfen.

AWS Certificate Manager (ACM) ist der Lebenszyklusdienst. Er stellt öffentliche TLS-Zertifikate von Amazons öffentlicher Zertifizierungsstelle aus, stellt sie bereit und erneuert sie und dient gleichzeitig als Verwaltungsschicht für private Zertifikate, die von AWS Private CA ausgestellt werden. Von ACM ausgestellte öffentliche Zertifikate, die ausschließlich mit integrierten AWS-Services (ELB, CloudFront, API Gateway, App Runner usw.) verwendet werden, sind kostenlos.

AWS Private CA ist die verwaltete private Zertifizierungsstelleninfrastruktur. Sie betreibt Ihre Zertifizierungsstellenhierarchie mit FIPS 140-2 -konformen, hardwaregeschützten Schlüsseln, jedoch zahlen Sie eine monatliche Gebühr pro Zertifizierungsstelle zuzüglich Gebühren pro ausgestelltem Zertifikat.

Die folgenden Einschränkungen gelten für beide, da sie für die meisten Teams als einheitliches Erlebnis bereitgestellt werden.

Die realen Grenzen des AWS Certificate Manager

1. Das kostenlose öffentliche Zertifikat gehörte Ihnen nie wirklich.

Das Hauptmerkmal von ACM ist das kostenlose öffentliche TLS-Zertifikat. Der private Schlüssel für ein „Standard“-ACM-Zertifikat lässt sich jedoch nicht exportieren. Das Zertifikat kann nur an ACM-integrierte AWS-Services gebunden werden. Wenn Ihr TLS-Terminierungsendpunkt etwas anderes ist (z. B. eine EC2-Instanz mit NGINX, ein lokales F5-System, ein Azure App Service, ein GCP Load Balancer, ein Drittanbieter-CDN oder eine Hardware-Appliance), kann das kostenlose ACM-Zertifikat dort nicht eingesetzt werden. Sie müssen daher parallele Workflows ausführen: einen von ACM verwalteten Workflow für AWS-integrierte Services und einen komplett separaten Prozess für alle anderen Services. Dies führt zu einem sich ständig erhöhenden Betriebsaufwand.

AWS hat dieses Problem im Juni 2025 teilweise mit exportierbaren öffentlichen Zertifikaten gelöst, die es ermöglichen, den privaten Schlüssel herunterzuladen und das Zertifikat überall einzusetzen. Die Flexibilität ist real, aber die Wirtschaftlichkeit ändert sich dadurch deutlich:

• 7 US-Dollar pro vollqualifiziertem Domainnamen (FQDN), fällig bei der Ausstellung und erneut bei jeder Verlängerung.
• 79 US-Dollar pro Wildcard-Name (z. B. *.yourdomain.com), jeweils bei der Ausstellung und bei jeder Verlängerung.
• ACM-Zertifikate haben eine maximale Gültigkeitsdauer von 13 Monaten und können nach 11 Monaten verlängert werden, sodass eine Verlängerung heutzutage ungefähr einmal im Jahr erfolgt.

Das klingt bescheiden, bis man die Zahlen für große Unternehmen betrachtet. Durch die schrittweise Reduzierung der Gültigkeitsdauer gemäß der CA/Browser-Forum- Richtlinien (200 Tage ab März 2026, 100 Tage ab März 2027, 47 Tage ab März 2029) werden die Zertifikate innerhalb von drei Jahren von jährlich auf etwa alle sechs Wochen erneuert werden müssen. Multipliziert man das mit 500 oder 5,000 FQDNs, so werden die Kosten für den „kostenlosen Zertifikatsmanager“ zu einem wiederkehrenden Kostenfaktor pro Zertifikat, der linear mit der Anzahl der Zertifikate skaliert.

Die Kernaussage ist nicht, dass exportierbare Zertifikate unvernünftig wären, sondern dass das Preismodell von ACM für die interne Nutzung bei AWS konzipiert wurde. Sobald man es außerhalb dieses Rahmens einsetzt, ändert sich das Kostenmodell grundlegend, und man zahlt nun Gebühren pro Zertifikat zusätzlich zu der Automatisierungsinfrastruktur, die man für die Bereitstellung noch aufbauen muss.

2. Die Automatisierung endet an der AWS-Grenze

Innerhalb von AWS ist ACM hervorragend. Erneuerungen für ELB, CloudFront, API Gateway und ähnliche Dienste werden automatisch durchgeführt. Das Zertifikat wird rotiert, der integrierte Dienst erkennt das neue Zertifikat, und der Administrator muss nichts weiter tun.

Außerhalb von AWS führt ACM keine Bereitstellungen durch. Für exportierbare Zertifikate, die für einen lokalen F5-Server, einen NGINX-Server, einen Citrix ADC, einen Kubernetes-Ingress außerhalb von EKS oder einen anderen Nicht-AWS-Endpunkt bestimmt sind, endet die Verantwortung von ACM mit dem API-Aufruf. Sie können Amazon EventBridge abonnieren, um Benachrichtigungen zur Zertifikatserneuerung zu erhalten. Die eigentliche Bereitstellung, die Schlüsselrotation auf dem Gerät, die Bindung des virtuellen Servers an den Load Balancer, der Neustart des zugehörigen Dienstes und die Validierung des neuen Zertifikats liegen jedoch vollständig in Ihrer Verantwortung.

Das bedeutet benutzerdefinierte Skripte, benutzerdefinierte IAM-Richtlinien, benutzerdefinierte Fehlerbehandlung und ein benutzerdefiniertes Audit-Protokoll. Jedes Team, das wir beim Aufbau dieser Lösung unterstützt haben, musste letztendlich dieselbe Steuerungsebene neu entwickeln: eine Warteschlange für Zertifikatsereignisse, einen Worker, der das neue Zertifikat abruft, eine Konnektorbibliothek für jeden Zielendpunkttyp, einen Wiederholungsmechanismus für Teilfehler und einen Rollback-Plan, falls das neue Zertifikat die Anwendung beeinträchtigt. Genau das sollte eine speziell entwickelte CLM-Plattform leisten, und genau das leistet ACM nicht, sobald man die AWS-Edge-Umgebung verlässt.

3. Der Lagerbestand ist nach Konto und Region fragmentiert.

Die Inventarverwaltung von ACM ist auf ein einzelnes AWS-Konto und eine einzelne Region beschränkt. Wenn Sie mit 12 Konten und 4 Regionen arbeiten, müssen Sie 48 logische Zertifikatsinventare verwalten, und es gibt keine integrierte Übersicht über diese.

Die CloudFront-Beschränkung verschärft das Problem. Selbst wenn Ihre Anwendung vollständig in ap-south-1 oder eu-west-1 läuft, benötigt CloudFront das Zertifikat in us-east-1 . Daher verfügt eine typische Multi-Region-Bereitstellung letztendlich über dasselbe logische Zertifikat in zwei Regionen: eines in us-east-1 für das CDN und eines in der tatsächlichen Anwendungsregion für den Load Balancer. Es gibt keine automatische Synchronisierung, kein gemeinsames Inventar und keine native regionsübergreifende Ansicht. In der Praxis erhalten identische Domains separate Zertifikate, die unabhängig voneinander ausgestellt und erneuert werden, ohne dass ein Inventar diese miteinander verbindet.

Für Sicherheits- und Audit-Teams stellt diese Fragmentierung ein echtes Problem dar. Eine unternehmensweite Richtlinie („Keine RSA-2048-Zertifikate nach dem 1. Januar 2027“ oder „Alle Zertifikate müssen einen registrierten Inhaber haben“) lässt sich nicht durchsetzen, wenn kein zentrales Inventar vorhanden ist, auf das man sich beziehen kann. Auch eine kryptografische Statusanalyse vor der Post-Quantum-Migration ist unmöglich , wenn man den aktuellen Stand der Zertifikate nicht kennt. Und genau diese Schattenzertifikate – jene, die ein Entwickler vor zwei Jahren in einer Region angefordert hat, die heute niemand mehr überwacht – sind es, die nächtliche Ausfälle verursachen.

4. Die Preise für private AWS-Zertifizierungsstellen steigen schnell an.

Die veröffentlichten Preise für AWS Private CA sind zwar einfach, aber die Kosten summieren sich schneller, als die meisten Teams erwarten:

• 400 US-Dollar pro privatem CA pro Monat für den allgemeinen Verwendungszweck (beliebige Gültigkeitsdauer)
• 50 US-Dollar pro privater Zertifizierungsstelle und Monat für den Modus mit kurzfristiger Zertifikatsgültigkeit (maximal 7 Tage Gültigkeit)
• Gebührenstaffelung pro Zertifikatsausstellung durch eine allgemeine Zertifizierungsstelle: 0.75 $ für die ersten 1,000, 0.35 $ für die nächsten 9,000 und 0.001 $ für über 10,000
• 0.06 US-Dollar pro Zertifikat und Monat für OCSP-Antworten (wird nur für Zertifikate berechnet, die tatsächlich OCSP-Anfragen erhalten)

Bei einer typischen zweistufigen Hierarchie (eine Offline-Root- und eine Online-Ausstellungsstelle) belaufen sich die Kosten vor der Ausstellung eines einzigen Zertifikats auf 800 US-Dollar pro Monat. Mit regionsübergreifender Hochverfügbarkeit können die monatlichen Kosten leicht 1,600 bis 2,400 US-Dollar erreichen. Für einen Anwendungsfall in der Fertigung oder im IoT-Bereich, bei dem monatlich 50,000 Gerätezertifikate ausgestellt werden, sind die Kosten pro Zertifikat dank des Mengenrabatts angemessen. Die monatliche Gebühr pro Zertifizierungsstelle ist jedoch nicht skalierbar: Jede regionale Zertifizierungsstelle, jede separate Vertrauenshierarchie und jede Testumgebung kostet pauschal 400 US-Dollar pro Monat.

Im Vergleich dazu ist eine selbstgehostete Microsoft AD CS-Hierarchie deutlich günstiger, da die Grenzkosten pro Zertifikat nach der Erstbereitstellung praktisch null betragen. Auch bei einem Managed-PKI-Angebot werden die Kosten anders verteilt. AWS Private CA ist zwar komfortabel, aber nicht die kostengünstigste Lösung. Das Kostenmodell begünstigt die Konsolidierung in einer einzigen Zertifizierungsstelle anstatt der von vielen Sicherheitsteams gewünschten Funktionstrennung.

5. Das Compliance-Reporting ist eine Angelegenheit, die man selbst gestalten muss.

ACM erstellt keine standardmäßigen Konformitätsberichte auf Zertifikatsebene für PCI DSS , HIPAA, SOC 2 , DORA oder andere Frameworks. AWS bietet zwar ergänzende Funktionen (AWS Config-Regeln erkennen nicht konforme ACM-Zertifikate, Security Hub verfügt über Standardzuordnungen zur Kennzeichnung von Befunden, AWS Artifact liefert Konformitätsberichte auf AWS-Serviceebene), aber keine dieser Lösungen bietet eine Komplettlösung, die den Prüfungsstatus jedes Zertifikats, den Inhaber, den verwendeten Algorithmus, das Ablaufdatum und etwaige Richtlinienverstöße bei der Ausstellung abteilungsweise aufschlüsselt.

Für regulierte Unternehmen wird diese Lücke bei Audits sichtbar. Das Compliance-Team fordert einen Bericht über alle relevanten TLS-Zertifikate mit Schlüssellänge, SAN-Einträgen, Inhaber, ausstellender Zertifizierungsstelle, Ablaufdatum und Einhaltung der Richtlinien. Mit ACM allein muss dieser Bericht aus einer Kombination von describe-certificate-Aufrufen, benutzerdefinierten Lambda-Funktionen, AWS-Config-Exporten und einer manuell bearbeiteten Tabelle erstellt werden. Der ausgereifte CLM-Workflow sieht vor, dass der Bericht per Knopfdruck wöchentlich an den Posteingang des Auditors geliefert wird.

6. Anbieterabhängigkeit beeinträchtigt die Krypto-Agilität

In den nächsten Jahren werden zwei Branchenverschiebungen zusammenlaufen, und beide erfordern Krypto-Agilität:

• Das CA / Browser Forum Stimmzettel SC-081v3Die am 14. April 2025 verabschiedete Regelung reduziert die maximale Gültigkeitsdauer öffentlicher TLS-Systeme von derzeit 398 Tagen auf 200 Tage (März 2026) und 100 Tage (März 2027). 47-Tage-TLS-Zertifikate (März 2029), laut Sectigos Berichterstattung über die CA/Browser Forum-AbstimmungDas Zeitfenster für die Wiederverwendung der Domainvalidierung verkürzt sich bis März 2028 auf 10 Tage.
• NIST's Post-Quanten-Kryptographie Der Übergangsplan sieht vor, dass Unternehmen die älteren RSA- und ECC-Standards bis 2030 abschaffen und bis 2035 vollständig ersetzen. ML-DSA und ML-KEM (FIPS 204 und 203, finalisiert am 13. August 2024) sind die neuen Standards. AWS hat damit begonnen, ML-DSA-Unterstützung in AWS KMS und AWS Private CA zu integrieren. Der umfassendere operative Austausch von Algorithmen in einer gesamten IT-Umgebung ist jedoch komplexer als die Umstellung auf eine einzelne Zertifizierungsstelle.

Krypto-Agilität bedeutet die Fähigkeit, Zertifizierungsstellen, Algorithmen, Schlüssellängen, Gültigkeitsdauern und Bereitstellungsziele auszutauschen, ohne die Steuerungsebene neu strukturieren zu müssen. Wenn Ihre Zertifikatsverwaltung architektonisch an einen einzigen Anbieter gebunden ist, verfügen Sie nicht über Krypto-Agilität, sondern über eine Abhängigkeit. Sobald AWS sein Preismodell ändert, einen Servicevertrag anpasst, eine Funktion einstellt oder sich Ihre Geschäftsanforderungen ändern und Sie Workloads zu Azure oder GCP migrieren müssen, entsprechen die Kosten für die Auflösung dieser Abhängigkeit den Kosten für den Neuaufbau Ihrer CLM-Architektur. Dies ist eine ungünstige Ausgangslage im Hinblick auf die 47-tägige TLS- Zertifikatspflicht und die PQC-Migration.

Das 47-Tage-Mandat verschärft jede Lücke

All das wird schwieriger, je kürzer die Gültigkeitsdauer des Zertifikats wird. Heute wird ein typisches TLS-Zertifikat einmal jährlich erneuert. Im März 2026 wird dies etwa alle sechseinhalb Monate der Fall sein. Im März 2027 alle dreieinhalb Monate. Im März 2029 alle sechseinhalb Wochen.

Das entspricht einer achtfachen Steigerung der Verlängerungshäufigkeit in weniger als drei Jahren. Jede Lücke in der Automatisierung von ACM, jede Region, die separat geprüft werden muss, jeder Endpunkt außerhalb der AWS-Grenzen, der ein manuelles Bereitstellungsskript erfordert, jeder Compliance-Bericht, der manuell erstellt wird – all dies skaliert linear mit der Verlängerungshäufigkeit. Ein Workflow, der bei einer Gültigkeitsdauer von 12 Monaten lästig ist, wird bei 47 Tagen betrieblich nicht mehr tragbar.

Laut der am 2. Juli 2025 veröffentlichten DigiCert Trust Pulse Survey gaben 45 Prozent der Unternehmen an, im vergangenen Jahr aufgrund von Zertifikatsproblemen Ausfallzeiten erlebt zu haben. 37.5 Prozent dieser Unternehmen konnten einen Ausfall nachweislich auf ein abgelaufenes Zertifikat zurückführen . Jede einzelne Sicherheitslücke von ACM – die Endpunkte, auf denen keine Bereitstellung möglich ist, die Konten und Regionen, die nicht abgedeckt werden – entspricht genau der Art von manuell überwachtem Zertifikat, die zu diesen 37.5 Prozent zählt.

Genau deshalb hat sich die Diskussion in der Branche so stark in Richtung geschlossener, herstellerneutraler CLM-Systeme verlagert. Nicht etwa, weil ACM schlecht wäre, sondern weil eine Teilautomatisierung dem hohen Auftragsvolumen einfach nicht standhält.

In diesem Leitfaden werden Anbieter und Dienstleistungen verglichen.

Dieser Leitfaden vergleicht die drei Zertifikatsdienste, zwischen denen ein AWS-zentriertes Unternehmen wählen muss, sobald ACM allein nicht mehr ausreicht: AWS Certificate Manager, AWS Private CA und eine herstellerneutrale CLM-Plattform. Als Referenzimplementierung dient dabei der CertSecure Manager von Encryption Consulting. Diese drei Dienste wurden ausgewählt, da sie gemeinsam die gesamte Bandbreite der Optionen abdecken, die einem Team bei der Standardisierung auf AWS heute zur Verfügung stehen: vollständig AWS-nativ bleiben, die private CA-Schicht von AWS hinzufügen oder eine herstellerneutrale Orchestrierungsschicht über den bereits genutzten Zertifizierungsstellen und Clouds implementieren.

Sofern eine echte, unabhängig überprüfbare Bewertung vorliegt, wird diese unten mit ihrer Quelle und dem Datum der Überprüfung angegeben, damit dieser Vergleich ehrlich bleibt hinsichtlich dessen, was von Dritten verifiziert wurde und was nicht.

• AWS Certificate Manager (ACM): 4.5 von 5 Sternen auf G2, basierend auf 55 Bewertungen, geprüft am 13. August 2026. Auf G2 ansehenEs wurde kein Eintrag auf Capterra gefunden.
• Private AWS-Zertifizierungsstelle: Für diesen Dienst existiert mit Stand vom 13. August 2026 kein unabhängiger Eintrag bei G2 oder Capterra. Er ist auch in keiner der beiden Plattformen separat in der Kategorie Zertifikatslebenszyklusmanagement aufgeführt, daher wird hier keine Bewertung von Drittanbietern angegeben, sondern stattdessen die Nummer von ACM verwendet oder eine Schätzung vorgenommen.
• CertSecure Manager (Verschlüsselungsberatung): 4.8 von 5 Sternen auf G2, basierend auf 3 Bewertungen, geprüft am 13. August 2026. Auf G2 ansehenEs wurde kein Eintrag auf Capterra gefunden.

Wie CertSecure Manager diese Lücken schließt

CertSecure Manager , die CLM-Plattform von Encryption Consulting, wurde von PKI-Experten entwickelt, die täglich mit genau diesen Szenarien in Kundenprojekten konfrontiert sind. Wo ACM an der AWS-Grenze endet, setzt CertSecure Manager an:

• Multi-CA, herstellerneutral von Grund auf. CertSecure Manager verbindet sich über eine einzige Konsole mit Microsoft AD CS, AWS Private CA, HashiCorp Vault PKI, DigiCert, Entrust und anderen öffentlichen und privaten Zertifizierungsstellen. Sie erhalten ein einheitliches Zertifikatsinventar, eine einheitliche Richtlinienebene und eine einheitliche Erneuerungswarteschlange – unabhängig davon, welche Zertifizierungsstelle das Zertifikat ausgestellt hat oder in welcher Cloud die Workload ausgeführt wird.
• Geschlossener Regelkreis Zertifikatsautomatisierung Über AWS hinaus. Erneuerungsagenten für Apache, Tomcat, IIS, F5 BIG-IP, NGINX und kundenspezifische interne Anwendungen übernehmen den Bereitstellungsschritt, den ACM nicht abdeckt. CertSecure Manager Orchestrator für F5, das im Rahmen unserer Partnerschaft im F5 Application Delivery and Security Platform Partner Program entwickelt wurde, ordnet automatisch jedes Zertifikat dem richtigen F5 Virtual Server SSL-Profil zu und eliminiert so den manuellen Bindungsschritt, der die meisten zertifikatsbedingten Ausfälle von F5 verursacht.
• Standardisierte Registrierungsprotokolle. REST-API- und ACME-Endpunkte ermöglichen die automatische Registrierung von Cloud-nativen und DevOps-Workloads, genau wie bei Let's Encrypt oder jedem anderen Standard-ACME-Endpunkt. Das bedeutet, dass cert-manager in Kubernetes, certbot auf einem Linux-Host oder eine benutzerdefinierte CI/CD-Pipeline alle über dasselbe Protokoll registrieren können.
• Zentralisierte Transparenz über Cloud und On-Premise hinweg. Automatisiert Zertifikatserkennung Es scannt Ihre Umgebung, erstellt ein einheitliches Inventar über AWS-Konten und -Regionen, Azure, GCP, lokale Systeme und Kubernetes-Cluster hinweg und stellt Eigentümerschaft, Algorithmus, Gültigkeit und Richtlinienkonformität für jedes Zertifikat in einem Dashboard dar.
• Richtliniendurchsetzung und Genehmigungen. Globale und abteilungsspezifische Richtlinien umfassen die Mindestschlüssellänge, zulässige Algorithmen, FIPS-konforme Beschränkungen, Regeln zur Verwendung von Wildcards, Regeln zur Wiederverwendung von CSRs, DNS-Whitelisting zur Domainvalidierung sowie M-of-N-Genehmigungsworkflows für hochsichere Zertifikatvorlagen. Diese Richtlinien werden zum Zeitpunkt der Ausstellung und nicht nachträglich durchgesetzt.
• Auditfähige Compliance-Berichterstattung. Geplante Berichte, die wöchentlich oder monatlich an den Compliance-Posteingang geliefert werden, mit den für PCI DSS erforderlichen Zertifikatsdetails. HIPAASOC 2- und DORA-Audits fordern dies tatsächlich. Kein manueller Export, kein Zusammenführen von Tabellenkalkulationen.
• Krypto-Agilität Integriert. Da CertSecure Manager CA-agnostisch ist, stellt der Austausch der zugrunde liegenden CA, die Umstellung auf einen neuen Schlüsselalgorithmus oder die Migration von einem Anbieter zu einem anderen eine Richtlinienänderung und keine Neuarchitektur dar. Dies ist sowohl im Hinblick auf die 47-Tage-Frist als auch auf die PQC-Migration von Bedeutung. CBOM Secure Diese Erkenntnis erstreckt sich über Zertifikate hinaus auf Ihren gesamten kryptografischen Bestand, und unsere CBOM: Von der Bestandsaufnahme zur Intelligenz Der Leitfaden beschreibt, wie man dieses Inventar in ein fortlaufendes Programm umwandelt. PQC Kompetenzzentrum und 9-phasig PQC-Bereitschaft Der Fahrplan hilft Ihnen bei der Planung der Migration selbst.

Kaufentscheidungstabelle: Am besten geeignet für, Einschränkungen und Nachweise

Nutzen Sie diese Tabelle, um Ihre Situation dem richtigen Ausgangspunkt zuzuordnen; die Beweise für jede Zeile sind angegeben.

Option	Am besten geeignet für	Einschränkungen	Einsatztauglichkeit	Integrationen	Preistransparenz	Nachweis / Quelle
AWS-Zertifikatsmanager	Einzelkonto-, Einzelregion-, AWS-native Workloads auf ACM-integrierten Diensten	Keine Bereitstellung außerhalb von AWS-integrierten Diensten im kostenlosen Kontingent; Gebühren pro FQDN für exportierbare Zertifikate	AWS-nativ	ELB, CloudFront, API-Gateway, App Runner	Vollständig veröffentlicht; kostenlose Stufe plus 7 $/FQDN und 79 $/Wildcard für exportierbare Zertifikate	4.5/5 auf G2, 55 Bewertungen, geprüft am 13. August 2026
AWS Private CA	Teams, die eine verwaltete private CA-Hierarchie innerhalb von AWS benötigen	Pauschale monatliche Gebühr pro CA unabhängig vom Volumen; AWS-zentriertes Betriebsmodell	AWS-nativ, erweiterbar durch ACM-Integration	Integriert sich in ACM; eingeschränkte Nutzung von Tools außerhalb von AWS	Vollständig veröffentlicht; 400 US-Dollar oder 50 US-Dollar pro CA und Monat zuzüglich Gebühren pro Zertifikat	Es wurde kein unabhängiger Eintrag bei G2 oder Capterra gefunden.
Herstellerneutrales CLM (CertSecure Manager)	Multi-Cloud-, Hybrid- oder über 1,000 Zertifikatsumgebungen, die eine einzige Steuerungsebene benötigen	Erfordert einen gewissen Aufwand bei der Einarbeitung, um bestehende Zertifizierungsstellen und Endpunkte zu verbinden.	Cloud, On-Premises, Kubernetes und Multi-CA	Microsoft AD CS, AWS Private CA, HashiCorp Vault PKI, DigiCert, Entrust, F5, NGINX, Apache, Tomcat, IIS, ACME/REST	Veröffentlicht auf Anfrage; richtlinienorientiert statt pro FQDN	4.8/5 auf G2, 3 Bewertungen, geprüft am 13. August 2026

Merkmals- und Kriterienmatrix

Diese Matrix vergleicht dieselben drei Optionen anhand der Kriterien, die am wichtigsten sind, sobald man über eine einfache AWS-native Infrastruktur hinausgeht.

Eigenschaften	AWS-Zertifikatsmanager	AWS Private CA	Herstellerneutrales CLM (CertSecure Manager)
Automatisierungsumfang	ausschließlich AWS-integrierte Dienste	ausschließlich AWS-integrierte Dienste	Geschlossener Regelkreis über Cloud, On-Premises und Kubernetes hinweg
CA-Unterstützung	Amazons öffentliche CA nur	Ihre eigene private Zertifizierungsstellenhierarchie in AWS	Multi-CA: AD CS, AWS Private CA, HashiCorp Vault PKI, DigiCert, Entrust und andere
Protokollunterstützung	AWS-API	AWS-API	REST-API und ACME, kompatibel mit cert-manager, certbot und CI/CD-Pipelines
Integrationen	ELB, CloudFront, API-Gateway, App Runner	ACM, FIPS 140-2 hardwaregeschützte Schlüssel	F5 BIG-IP (mit dediziertem Orchestrator), NGINX, Apache, Tomcat, IIS, Kubernetes
Reporting	Keine schlüsselfertigen Konformitätsberichte auf Zertifikatsebene	Keine schlüsselfertigen Konformitätsberichte auf Zertifikatsebene	Geplante, auditbereite Berichte für PCI DSS, HIPAA, SOC 2, DORA
PQC-Bereitschaft	ML-DSA-Unterstützung wurde zu AWS KMS hinzugefügt; Kryptoagilität auf Zertifikatsebene wird nicht behandelt	ML-DSA-Unterstützung hinzugefügt; weiterhin Single-CA	CA-agnostisch von Grund auf; Algorithmus- und CA-Austausch sind eine Richtlinienänderung, kein Neuaufbau.
Bereitstellungsmodell	AWS-nativ, einzelner Konto-/Regionsbereich	AWS-native, monatliche Gebühr pro CA	Cloudübergreifend, kontoübergreifend, lokal und Kubernetes
Bewertung / Quelle	4.5/5, 55 Bewertungen, G2, geprüft am 13. August 2026	Es wurde kein unabhängiger Eintrag gefunden.	4.8/5, 3 Bewertungen, G2, geprüft am 13. August 2026

Wann ACM ausreicht und wann nicht

Nicht jedes Team benötigt eine vollständige CLM-Plattform. Hier ein praktischer Überblick darüber, wann ACM allein ausreicht und wann es nicht mehr genügt:

Szenario	ACM allein	Anbieterneutrales CLM
Ein einzelnes AWS-Konto, eine einzelne Region, vollständig AWS-native Workloads	Ja	Nein
Weniger als 100 Zertifikate, alle für ACM-integrierte Dienste	Ja	Nein
Multi-Cloud (AWS + Azure und/oder GCP)	Nein	Ja
Hybrid-Cloud mit On-Premise-Infrastruktur (AD CS, F5, NGINX, Apache, IIS)	Nein	Ja
Mehr als 1,000 Zertifikate über mehrere Zertifizierungsstellen und Umgebungen hinweg	Nein	Ja
Strenge Einhaltung der Vorschriften (PCI DSS, HIPAA, SOC 2, DORA, regulierte Branchen)	Nein	Ja
Kubernetes und containerisierte Workloads über Clouds hinweg	Nein	Ja
Vorbereitung auf eine 47-tägige Gültigkeitsdauer mit beliebigen Nicht-AWS-Endpunkten	Nein	Ja
Annäherung an die PQC-Migration bei heterogener CA-Landschaft	Nein	Ja

Das Muster ist einfach. ACM ist ausreichend, wenn die Zertifikatslage begrenzt, AWS-nativ und klein ist. Sobald eine dieser drei Bedingungen nicht mehr erfüllt ist, schlägt sich die alleinige Verwendung von ACM in höherer betrieblicher Komplexität, aufwändiger Audits und einem erhöhten Ausfallrisiko nieder.

Eigentümer- und Aktionsmatrix des Teams

Team	Verantwortung	Schlüsselaktion
PKI-Team	Trifft die Entscheidung zwischen ACM allein und einer herstellerneutralen CLM-Schicht.	Modellzertifikatsvolumen und CA-Diversität im Vergleich zur obigen Käuferentscheidungstabelle
Sicherheits Team	Verantwortlich für die Schließung der Automatisierungslücke außerhalb der in AWS integrierten Dienste	Inventarisierung aller Zertifikate, die auf einem nicht in AWS integrierten Endpunkt bereitgestellt werden
Plattform-/DevSecOps-Team	Besitzt konto-, regions- und cloudübergreifende Inventardaten	Die Zertifikatsübersicht sollte in einem einzigen Dashboard anstatt in Ansichten pro Konto zusammengefasst werden.
Compliance-Team	Besitzt die revisionssichere Berichtspflicht für das gesamte Zertifikatsportfolio.	Bestätigen Sie, dass Zertifikatsberichte auf Anfrage erstellt und nicht manuell zusammengestellt werden können.

Was macht man als nächstes

• PKI-Teams: Nutzen Sie die obenstehende Matrix aus Funktionen und Kriterien, um zu entscheiden, ob Sie bei ACM bleiben oder in diesem Quartal eine herstellerneutrale CLM-Ebene hinzufügen.
• Sicherheitsteams: Prüfen Sie jedes außerhalb von ACM-integrierten Diensten eingesetzte Zertifikat und bestätigen Sie, dass es sich im automatisierten Erneuerungsprozess befindet.
• Plattformteams: Die Einführung einer einheitlichen, kontoübergreifenden Bestandsansicht vor dem 100-tägigen TLS-Gültigkeitszeitraum im März 2027 erhöht die Erneuerungshäufigkeit zusätzlich.
• Compliance-Teams: Bestätigen Sie, dass Ihre nächste Prüfungsanfrage mit einem geplanten Bericht anstatt mit einer manuell erstellten Tabellenkalkulation beantwortet werden kann.

Weiterführende Lektüre von Encryption Consulting

• Automatisierung der Zertifikatsverwaltung in Azure Key Vault behandelt das gleiche Muster für Azure, bei dem die Orchestrierung über den nativen Tools steht, wie es in diesem Beitrag für AWS beschrieben wird.
• Stärkere Sicherheit durch TLS-Zertifikate mit 47-tägiger Gültigkeit bis 2029 umfasst den gesamten Gültigkeitspfad des CA/Browser-Forums, auf den in diesem Beitrag verwiesen wird.
• Erstellen Sie eine private PKI für mTLS, bevor öffentliche Zertifikate die Clientauthentifizierung verwerfen. behandelt einen weiteren Fall, in dem öffentliche CA-Dienste, einschließlich ACM, an eine harte Grenze stoßen, die durch eine private, herstellerneutrale PKI gelöst wird.
• Warum die Änderungen bei Let's Encrypt vom 13. Mai wichtig sind behandelt, wie die automatisierte, ARI-gesteuerte Erneuerungslogik öffentliche CA-Profiländerungen auf eine Weise aufnimmt, wie es das feste Modell von ACM nicht kann.

Fazit

ACM ist innerhalb seiner vorgesehenen Rahmenbedingungen ein wirklich guter Dienst. Der Fehler liegt in der Annahme, dass diese Rahmenbedingungen der Realität in Unternehmen entsprechen. Die meisten Organisationen arbeiten mit mehreren Clouds, mehreren Zertifizierungsstellen und einer Vielzahl lokaler Endpunkte, die ACM nicht erreichen kann. Die 47-tägige Gültigkeitsdauer von TLS und die Migration zu PQC werden die bestehenden Lücken in der Automatisierung, Transparenz und Richtliniendurchsetzung von ACM deutlich verschärfen.

Der richtige Ansatz besteht darin, ACM dort einzusetzen, wo es seine Stärken hat (kostenlose öffentliche Zertifikate für AWS-integrierte Dienste, unkomplizierte Verlängerungen innerhalb der AWS-Umgebung), und darüber eine herstellerneutrale CLM-Plattform zu implementieren, die alle Aufgaben übernimmt, für die ACM nicht konzipiert wurde. So erhalten Sie die operative Einfachheit von ACM dort, wo es funktioniert, und die umgebungsübergreifende Automatisierung, Governance und Krypto-Agilität, die Sie überall sonst benötigen.

Dieser Leitfaden dient als Anbieter- und Preisvergleich und wird vierteljährlich sowie umgehend aktualisiert, sobald AWS die Preise für ACM oder AWS Private CA ändert, das CA/Browser Forum seinen Gültigkeitsplan aktualisiert oder sich die oben genannten G2-Bewertungen ändern.

Häufig gestellte Fragen

Was ist die wichtigste Erkenntnis aus dem Artikel „Einschränkungen des AWS Certificate Manager: Wo ACM für Enterprise PKI an seine Grenzen stößt“?

ACM ist innerhalb eines einzelnen AWS-Kontos, einer Region und mit AWS-nativen Workloads wirklich leistungsstark, aber seine Bestandsverwaltung, Automatisierung und kostenlose Preisgestaltung enden an der AWS-Grenze. Unternehmen, die Multi-Cloud-, Hybrid- oder Umgebungen mit hohem Zertifikatsvolumen betreiben, stoßen auf Lücken in der Bereitstellungsautomatisierung, der konto- und regionsübergreifenden Transparenz, dem Compliance-Reporting und der Krypto-Agilität – Lücken, die eine herstellerneutrale CLM-Plattform schließen soll.

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

Die Trust Pulse Survey von DigiCert (2. Juli 2025) ergab, dass 45 Prozent der Unternehmen im vergangenen Jahr aufgrund von Zertifikatsproblemen Ausfallzeiten verzeichneten und 37.5 Prozent einen Ausfall nachweislich auf ein abgelaufenes Zertifikat zurückführten. Die Automatisierung von ACM endet an der AWS-Grenze. Daher ist jedes außerhalb von ACM-integrierten Diensten bereitgestellte Zertifikat genau die Art von manuell überwachtem Zertifikat, die diese Ausfallstatistiken verursacht. Gemäß CA/B Forum SC-081v3 (verabschiedet am 14. April 2025) verkürzt sich die Gültigkeit öffentlicher TLS-Zertifikate bis März 2029 auf 47 Tage. Dadurch wird jede manuelle Lücke in der ACM-Automatisierung zu einem Ausfallrisiko von bis zu acht Mal pro Jahr.

Welche Teams sind für die Umsetzung dieser Vorgaben verantwortlich?

PKI-Teams entscheiden über die Verwendung von ACM allein oder einer herstellerneutralen CLM-Schicht; Sicherheitsteams schließen die Automatisierungslücke außerhalb der AWS-integrierten Dienste; Plattform- und DevSecOps-Teams verwalten das konto-, regions- und cloudübergreifende Inventar; und Compliance-Teams erstellen auditfähige Berichte für den gesamten Zertifikatbestand. Die obige Verantwortlichkeits-/Aufgabenmatrix zeigt die Aufschlüsselung nach Teams.

Welche Risiken erhöhen sich, wenn ACM-Beschränkungen manuell gehandhabt werden?

Die manuelle Handhabung dieser Prozesse bedeutet, dass für jeden Nicht-AWS-Endpunkt parallele Zertifikatsworkflows ausgeführt werden, der Bestand über AWS-Konten und -Regionen hinweg fragmentiert ist und es keine einheitliche Sicht gibt, dass ohne manuell erstellte Tabellenkalkulationen keine revisionssicheren Compliance-Berichte erstellt werden können und dass eine architektonische Abhängigkeit entsteht, die die Krypto-Agilität vor dem Übergang zu PQC blockiert.

Wie kann Automatisierung das Risiko von Zertifikatsausfällen verringern?

Die Automatisierung im geschlossenen Regelkreis erweitert Erneuerung, Bereitstellung und Validierung auf F5, NGINX, Apache, Tomcat und IIS, analog zur Automatisierung von AWS-integrierten Diensten durch ACM. Hinzu kommen die kontinuierliche Erkennung über Konten und Clouds hinweg sowie die Durchsetzung von Richtlinien bei der Ausstellung, sodass ein unbemerktes Ablaufen des Zertifikats weitaus unwahrscheinlicher wird.

Wie sollten Organisationen ihren Erfolg messen, nachdem sie ACM hinter sich gelassen haben?

Erfassen Sie den Anteil der Zertifikate, die automatisiert im geschlossenen Regelkreis verwaltet werden, im Vergleich zur manuellen Bearbeitung, die Anzahl der außerhalb des bisherigen zentralen Inventars gefundenen Zertifikate, die Zeit für die Erstellung eines auditfähigen Konformitätsberichts sowie zertifikatsbezogene Vorfälle, die Endpunkte außerhalb des ACM-Abdeckungsbereichs betreffen. Berichten Sie diese Daten vierteljährlich zusammen mit dem Gültigkeitsplan des CA/Browser Forums.

Wie hängt das mit der 47-tägigen TLS-Zertifikatsbereitschaft zusammen?

Die Erneuerungsfrequenz verschiebt sich von derzeit jährlich auf etwa alle sechs Wochen bis März 2029 gemäß dem Zeitplan des CA/Browser Forums. Jede manuelle Lücke in der ACM-Automatisierung, jedes manuell geprüfte Konto oder jede Region, jeder manuell erstellte Compliance-Bericht skaliert linear mit dieser Frequenz, wodurch eine 47-tägige Bereitschaft mit ACM allein außerhalb seiner nativen AWS-Umgebung praktisch unmöglich wird.

Wie sollte dies in Multi-Cloud- oder Hybrid-PKI-Umgebungen gehandhabt werden?

Standardisieren Sie auf eine herstellerneutrale Multi-CA-CLM-Plattform, die über eine einzige Konsole Verbindungen zu Microsoft AD CS, AWS Private CA, HashiCorp Vault PKI, DigiCert, Entrust und anderen Zertifizierungsstellen herstellt, sodass Multi-Cloud- und Hybrid-PKI-Umgebungen über ein einziges Inventar, eine einzige Richtlinienebene und eine einzige Erneuerungswarteschlange verfügen, anstatt separate Tools pro Cloud oder Zertifizierungsstelle zu benötigen.

Welche Option ist die beste für große Unternehmen?

Laut der obigen Tabelle zur Kaufentscheidung sind große Unternehmen mit Multi-Cloud-, Hybrid- oder über 1,000 Zertifikaten durch eine herstellerneutrale CLM-Plattform auf Basis von ACM durchweg besser bedient, da ACM allein nie als einheitliche Steuerungsebene für verschiedene Anbieter konzipiert wurde. ACM und AWS Private CA eignen sich weiterhin nur für begrenzte, AWS-native Umgebungen mit geringem Volumen.

Welche Kriterien sollten Käufer beim Vergleich von Anbietern heranziehen?

Vergleichen Sie die Automatisierungstiefe über native Integrationen hinaus, CA- und Protokollunterstützung (ACME, REST, EST), umgebungsübergreifende Inventarisierung und Erkennung, Richtliniendurchsetzung und Genehmigungsworkflows, auditfähige Compliance-Berichterstattung, PQC- und Krypto-Agilitätsbereitschaft, Bereitstellungsmodell und überprüfbare Drittanbieterbewertungen mit Datumsangabe, genau die Kriterien, die in der obigen Merkmals- und Kriterienmatrix verwendet wurden.

Was sollte vierteljährlich aktualisiert werden?

Vierteljährlich: Überprüfen Sie, ob die in diesem Leitfaden genannten G2-Bewertungen aktuell sind (ACM: 4.5/5 aus 55 Bewertungen; CertSecure Manager: 4.8/5 aus 3 Bewertungen; beide geprüft am 13. August 2026); bestätigen Sie, dass sich die Preise für AWS Private CA und exportierbare ACM-Zertifikate nicht geändert haben; überprüfen Sie, ob der Zeitplan für die Gültigkeitsreduzierung gemäß CA/Browser Forum SC-081v3 eingehalten wird; prüfen Sie den Anteil der Zertifikate, die unter Closed-Loop-Automatisierung stehen; führen Sie einen vollständigen Discovery-Scan durch, um Schattenzertifikate in neuen Konten oder Regionen zu identifizieren; klassifizieren Sie alle Zertifikate anhand der NIST-Meilensteine ​​für die Post-Quantum-Deprecation (FIPS 203/204/205, finalisiert am 13. August 2024). Informationen zur Migrationsplanung nach der Quantum-Deprecation finden Sie im PQC Center of Excellence.