CAA-Einträge erklärt: Definition der Zertifizierungsstellen, die für Ihre Domain ausstellen können

In der Welt der Public-Key-Infrastruktur (PKI) ist Vertrauen von höchster Bedeutung. Unternehmen investieren viel Zeit und Geld in die Absicherung ihrer Domains mit SSL/TLS-Zertifikaten , doch viele vernachlässigen die Frage, wer diese Zertifikate tatsächlich ausstellen darf. Diese Lücke kann schwerwiegende Probleme verursachen. CAA-Einträge sind ein einfaches DNS-Werkzeug, mit dem Domaininhaber klar festlegen können, welche Zertifizierungsstellen Zertifikate für ihre Domain ausstellen dürfen.

Falls Ihr Sicherheitsprogramm noch keine DNS-CAA-Einträge verwendet, erklärt Ihnen dieser Leitfaden, was sie sind, wie sie funktionieren und warum jede Organisation sie verwenden sollte.

Kurzantwort: Was ist ein CAA-Datensatz?

Ein CAA-Eintrag (Certification Authority Authorization) ist ein DNS-Ressourceneintrag (RFC 6844, aktualisierter RFC 8659), der Zertifizierungsstellen mitteilt, welche berechtigt sind, SSL/TLS-Zertifikate für Ihre Domain auszustellen. Seit September 2017 müssen alle öffentlich vertrauenswürdigen Zertifizierungsstellen CAA-Einträge vor der Zertifikatsausstellung prüfen. Eine Domain ohne CAA-Einträge erlaubt es jeder Zertifizierungsstelle, Zertifikate dafür auszustellen . Drei Tags steuern die Zertifikatsausstellung: `issue` , `issuewild` und `iodef`.

Wichtige Erkenntnisse

• CAA-Einträge sind ein in RFC 6844 (aktualisierter RFC 8659) standardisierter DNS-Zertifikatskontrollmechanismus, der die Zertifizierungsstellen einschränkt, die SSL/TLS-Zertifikate für eine Domain ausstellen dürfen. Seit September 2017 schreiben die Baseline Requirements des CA/Browser Forums vor, dass alle öffentlich vertrauenswürdigen Zertifizierungsstellen die CAA-Einträge prüfen müssen, bevor sie ein Zertifikat ausstellen. Eine nicht aufgeführte Zertifizierungsstelle muss die Ausstellung verweigern; ein SERVFAIL-Fehler während der Namensauflösung führt ebenfalls zur Ablehnung (ausfallsicheres Verhalten).
• Eine Domain ohne CAA-Einträge auf irgendeiner Ebene der DNS-Hierarchie ermöglicht es jeder öffentlich vertrauenswürdigen Zertifizierungsstelle (CA), Zertifikate für sie auszustellen. Da Browser-Root-Zertifikatspeicher über 100 vertrauenswürdige Root-CAs enthalten, ist die Zulassung der Zertifikatsausstellung durch jede beliebige CA gleichbedeutend damit, die Tür unverschlossen zu lassen. CAA-Einträge schließen diese Lücke mit einem einzigen DNS-Eintrag auf der obersten Domain, der an alle Subdomains vererbt wird.
• Die DigiCert Trust Pulse-Umfrage (2. Juli 2025) ergab, dass 45 Prozent der Unternehmen im Vorjahr aufgrund von Zertifikatsproblemen Ausfallzeiten verzeichneten. Fehlkonfigurierte CAA-Einträge, insbesondere solche, die eine aktive Zertifizierungsstelle (CA) auslassen, führen zu Fehlern bei der Zertifikatserneuerung und damit zu genau diesen Ausfallzeiten: Das Zertifikat läuft ab, da die Erneuerung bei der CAA-Prüfung der CA blockiert wurde. Bei einer maximalen TLS-Gültigkeit von 47 Tagen ab März 2029 (CA/B Forum SC-081v3, genehmigt im April 2025) verursacht ein fehlkonfigurierter CAA-Eintrag achtmal pro Jahr und betroffenem Zertifikat Erneuerungsfehler anstatt nur einmal.
• CAA-Einträge verwenden drei Eigenschaften-Tags. Das Tag „issue“ steuert, welche Zertifizierungsstelle (CA) Standardzertifikate ausstellen darf. Das Tag „issuewild“ steuert unabhängig davon, welche CA Wildcard-Zertifikate ausstellen darf. Das Tag „iodef“ gibt an, wohin CAs Verstöße melden sollen. Die Tags „issue“ und „issuewild“ sind unabhängig; wird nur eines der beiden gesetzt, bleibt die Hälfte des Zertifikatsnamensraums unkontrolliert.
• DNSSEC schützt CAA-Einträge vor DNS-Cache-Poisoning-Angriffen, die es Angreifern andernfalls ermöglichen würden, gefälschte CAA-Einträge einzufügen, die ihre gewählte Zertifizierungsstelle autorisieren. Ohne DNSSEC gewährleistet ein CAA-Eintrag die Durchsetzung von Richtlinien nur gegenüber ehrlichen Zertifizierungsstellen, die legitime Anfragen prüfen, nicht aber gegenüber aktiven Angreifern, die DNS-Antworten manipulieren.

Wen sollten die Aufzeichnungen der CAA interessieren?

Die Konfiguration und Pflege von CAA-Einträgen ist eine gemeinsame Aufgabe der Bereiche DNS-Betrieb, PKI-Management, Sicherheitsarchitektur und Compliance-Governance. Jedes Team ist für einen bestimmten Teilbereich zuständig, und Lücken in einem dieser Bereiche führen entweder zu offenen Ausstellungsrisiken (fehlende CAA-Einträge) oder zu Fehlkonfigurationen, die die Erneuerung blockieren (veraltete oder unvollständige CAA-Einträge).

Funktion / Rolle (Role) *	Warum es wichtig ist	Aktionselement
PKI- und Zertifikatsteams	Sie sind verantwortlich für die Zuordnung von Zertifikaten zu Zertifizierungsstellen (CAs), die festlegt, welche CAs in CAA-Einträgen aufgeführt werden müssen. Die Veröffentlichung von CAA-Einträgen ohne vorherige Prüfung der aktiv ausstellenden CAs führt zu Verlängerungsfehlern. Gemäß dem Zeitplan des CA/Browser Forum SC-081v3 (maximale Gültigkeitsdauer 47 Tage bis März 2029) verursacht jeder falsch konfigurierte CAA-Eintrag etwa acht Verlängerungsfehler pro Jahr und betroffenem Zertifikat. Das Zertifikatsinventar muss stets aktuell sein, da sich CA-Beziehungen ändern, Zertifikate zwischen CAs migrieren und neue Domänen bereitgestellt werden.	Prüfen Sie den gesamten Zertifikatsbestand mit CertSecure Manager Um vor der Veröffentlichung oder Aktualisierung von CAA-Datensätzen eine aktuelle Zuordnung von Zertifikaten zu Zertifizierungsstellen zu erstellen; verwenden CBOM Secure Alle Zertifikate in Cloud-, On-Premises- und Multi-Cloud-Umgebungen ermitteln und alle Zertifizierungsstellen identifizieren, die aktiv für jede Domain Zertifikate ausstellen; bestätigen, dass die CLM-Plattform die Erneuerungen über die im CAA-Datensatz aufgeführten Zertifizierungsstellen automatisiert, sodass Erneuerungsfehler erkannt werden, bevor sie zu Ausfällen führen.
DNS- und Infrastrukturteams	Eigene CAA-Eintragsveröffentlichung und DNS-Zonenpflege; CAA-Einträge können nur von Teams mit Schreibzugriff auf die DNS-Zone veröffentlicht und aktualisiert werden; DNSSEC-Signatur ist Voraussetzung für den Schutz von CAA-Einträgen vor Spoofing, und die Signatur muss kontinuierlich aufrechterhalten werden (das Ablaufen der RRSIG führt zu DNSSEC-Validierungsfehlern, die CAA-Einträge ungültig machen); Cloud-bereitgestellte DNS-Zonen und Entwickler-Self-Service-Subdomains befinden sich möglicherweise nicht im Inventar des DNS-Teams, wodurch CAA-Abdeckungslücken entstehen.	Stellen Sie sicher, dass DNSSEC für jede Zone, in der CAA-Einträge veröffentlicht werden, implementiert und gewartet wird. Veröffentlichen Sie CAA-Einträge in der Stammdomäne, um die Vererbungsabdeckung für alle Subdomains zu gewährleisten. Pflegen Sie ein DNS-Zoneninventar, das alle Cloud- und Entwickler-Subdomains umfasst, um die vollständige CAA-Abdeckung sicherzustellen. Testen Sie CAA-Einträge nach der Veröffentlichung und nach jedem Update mit dig, MX Toolbox oder dem SSLMate CAA Record Generator. Planen Sie die Migration des DNSSEC-Zonensignierungsalgorithmus. PQC Kompetenzzentrum
Sicherheitsarchitekten	Sie sind verantwortlich für das Governance-Modell der CAA: Definition der Richtlinie zur Trennung von Issue- und Issuewild-Tags, Festlegung der DNSSEC-Bereitstellungsanforderungen, Spezifizierung des iodef-Endpunkts und der Überwachungsintegration sowie Definition des Verhaltenskodex für die Reaktion auf unautorisierte Zertifikatsausstellungen beim Empfang von iodef-Meldungen. Ohne ein definiertes Governance-Modell werden CAA-Einträge inkonsistent über verschiedene Domänen hinweg veröffentlicht und reaktiv statt proaktiv aktualisiert, wenn sich CA-Beziehungen und Zertifikatsbestände ändern.	Definieren Sie die Governance-Richtlinie für CAA: Welche Zertifizierungsstellen sind für Standard- bzw. Wildcard-Zertifikate autorisiert (Trennung von Issue- und Issue-Wildcard-Zertifikaten)? Ist DNSSEC eine obligatorische Voraussetzung für alle Domains mit CAA-Einträgen? Ist ein iodef-Endpunkt mit SIEM oder einem Ticketsystem verbunden? Wie sieht ein vierteljährlicher CAA-Audit aus? Definieren Sie das Vorgehen bei unautorisierter Zertifikatsausstellung: SLA für die Überprüfung von iodef-Berichten, Benachrichtigungsprozess für Zertifizierungsstellen und Eskalationspfad für bestätigte Fehlausstellungen. Planen Sie die Migration des DNSSEC-Algorithmus auf Post-Quantum-Standards. PQC-Bereitschaft Leistungen
Compliance-Teams	CAA-Einträge sind eine dokumentierbare Ausstellungskontrolle, die direkt den Anforderungen an die Zertifikatsverwaltung gemäß SOC 2, ISO 27001 und PCI DSS 4.0 entspricht. Auditnachweise müssen bestätigen, dass CAA-Einträge für alle relevanten Domänen vorhanden sind, die autorisierte Nutzung der Zertifizierungsstelle korrekt widerspiegeln und iodef-Meldungen überwacht und beantwortet werden. Die DigiCert Trust Pulse Survey (2. Juli 2025) ergab, dass 37.5 Prozent der zertifikatsbezogenen Ausfälle auf abgelaufene Zertifikate zurückzuführen sind. Fehlkonfigurationen von CAA-Einträgen, die Verlängerungen blockieren, sind eine direkte Ursache für dieses Ablaufmuster in Umgebungen, in denen Zertifizierungsstellen gewechselt, die CAA-Einträge aber nicht aktualisiert wurden.	Fügen Sie die Präsenz und Genauigkeit der CAA-Einträge in das vierteljährliche Compliance-Nachweispaket ein: Prozentsatz der relevanten Domänen mit CAA-Einträgen, Prozentsatz der CAA-Einträge, die der aktuellen Zertifikat-zu-CA-Zuordnung entsprechen, und Reaktionszeiten der iodef-Berichte. Stellen Sie sicher, dass die CAA-Einträge im Rahmen des dokumentierten CA-Onboarding- und Offboarding-Prozesses aktualisiert werden. 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) den internen Compliance-Meilensteinen zur Anpassung der CAA-Eintragsprüfungsfrequenz zu.
CISOS	Domains ohne CAA-Einträge sind der Zertifikatsausstellung durch jede der über 100 öffentlich vertrauenswürdigen Zertifizierungsstellen ausgesetzt. Ein betrügerisch ausgestelltes Zertifikat, das einen Man-in-the-Middle-Angriff oder Markenmissbrauch ermöglicht, führt zu einer Sicherheitslücke, die den Vorstand erreicht. CAA-Einträge gehören zu den einfachsten und kostengünstigsten präventiven Maßnahmen im PKI-Sicherheitstoolkit. Der Gültigkeitsreduzierungsplan des CA/B Forum SC-081v3 bedeutet, dass die Pflege von CAA-Einträgen mit der Erneuerungshäufigkeit skaliert, wodurch genaue CAA-Einträge zu einer immer wichtigeren betrieblichen Anforderung werden, da die Zertifikatslebensdauer auf 47 Tage sinkt.	Verlangen Sie, dass jede extern auflösbare Domain als grundlegenden Sicherheitsstandard über einen CAA-Eintrag verfügt; finanzieren Sie das Zertifikatserkennungs- und CLM-Programm, das erforderlich ist, um genaue CAA-Einträge im Zuge der Weiterentwicklung des Zertifikatbestands und der Beziehungen zu Zertifizierungsstellen zu pflegen; evaluieren Sie PKI als Service Für private PKI-Infrastrukturen, bei denen die interne CA-Nutzung zusammen mit der öffentlichen CA-Nutzung in CAA-Einträgen erfasst werden muss; fordern, dass die Abdeckung und Genauigkeit der CAA-Einträge vierteljährlich als KPIs auf Vorstandsebene zusammen mit der Überwachung des Zertifikatsablaufs gemeldet werden.

Was ist ein CAA-Datensatz?

Ein CAA-Eintrag (Certification Authority Authorization) ist ein DNS-Ressourceneintrag, der gemäß RFC 6844 standardisiert und durch RFC 8659 aktualisiert wurde. Er teilt der Welt mit, welche Zertifizierungsstellen (CAs) berechtigt sind, SSL/TLS-Zertifikate für Ihre Domain oder Subdomain auszustellen. Man kann ihn sich als einfache Regel in Ihrem DNS vorstellen, die jede CA anweist, die Berechtigung zu prüfen, bevor sie ein Zertifikat ausstellt.

Ein typischer CAA-Datensatz sieht folgendermaßen aus:

Dieser Eintrag signalisiert allen Zertifizierungsstellen (CAs): Nur Let's Encrypt darf Zertifikate für example.com ausstellen. Jede andere CA, die eine Zertifikatsanfrage für diese Domain erhält, ist gemäß den CA/Browser Forum Baseline Requirements verpflichtet, die CAA-Einträge zu prüfen und die Regeln zu befolgen oder die Ausstellung zu verweigern. CAA-Einträge folgen der DNS-Hierarchie. Verfügt eine Subdomain nicht über einen eigenen CAA-Eintrag, prüft die CA die Regeln der übergeordneten Domain und wendet diese stattdessen an. Dies vereinfacht die Richtlinienverwaltung für eine große Anzahl von Domains.

Wie CAA-Aufzeichnungen autorisierte Zertifizierungsstellen definieren

CAA-Einträge verknüpfen spezifische Zertifizierungsstellen-Kennungen (CA-Kennungen) mit Ihrer Domain im DNS. Erhält eine Zertifizierungsstelle eine Zertifikatsanfrage, prüft sie die CAA-Einträge für diese Domain. Existiert ein CAA-Eintrag, die Zertifizierungsstelle ist aber nicht aufgeführt, muss die Anfrage abgelehnt werden. Existiert gar kein CAA-Eintrag, kann jede Zertifizierungsstelle Zertifikate für Ihre Domain ausstellen – genau diese Sicherheitslücke müssen Sicherheitsteams schließen.

Sie können in Ihren CAA-Einträgen mehrere Zertifizierungsstellen (CAs) auflisten. Dies ist nützlich für Organisationen, die verschiedene CAs für unterschiedliche Zwecke verwenden, beispielsweise eine öffentliche CA für Kundendienste und eine private CA für interne Systeme. Jede autorisierte CA erhält einen eigenen CAA-Eintrag, und die CA muss mit mindestens einem Eintrag übereinstimmen, damit die Zertifikatsausstellung fortgesetzt werden kann.

Das Problem verstehen: issuewild und iodef Tags

Die CAA-Datensätze verwenden drei Hauptmerkmale, um die Zertifikatsausstellung zu steuern. Jedes Merkmal hat eine andere Funktion, und das Verständnis aller drei ist wichtig für die korrekte Einrichtung Ihrer Datensätze.

Issue: Dieses Tag gibt an, welche Zertifizierungsstelle (CA) berechtigt ist, Standardzertifikate für Ihre Domain auszustellen. Beispielsweise erteilt „ 0 issue „digicert.com“ DigiCert die Berechtigung, Zertifikate für diese Domain auszustellen.

Issuewild: Dieses Tag steuert, welche Zertifizierungsstellen Wildcard-Zertifikate wie z. B. *.example.com ausstellen dürfen . Es ist vom Issue-Tag getrennt, sodass Sie je nach Ihren Sicherheitsanforderungen eine offenere Richtlinie für Standardzertifikate und eine strengere für Wildcard-Zertifikate festlegen können.

Iodef: Dieses Tag teilt Zertifizierungsstellen mit, wohin sie einen Bericht senden sollen, wenn sie eine Zertifikatsanfrage erhalten, die gegen Ihre Richtlinien verstößt. Sie können es auf eine E-Mail-Adresse oder eine URL verweisen lassen, zum Beispiel so:

0 iodef "mailto:[email protected]"

Wichtig: Wenn Sie nur ein Issuewild-Tag ohne Issue-Tag festlegen, kann jede Zertifizierungsstelle weiterhin Standardzertifikate für Ihre Domain ausstellen. Die beiden Tags sind unabhängig voneinander. Konfigurieren Sie daher immer beide, um sicherzustellen, dass Ihre Richtlinie vollständig ist.

CAA-Tag-Referenz: issue, issuewild und iodef

Diese Tabelle dient als Kurzübersicht für die Konfiguration und Prüfung von CAA-Datensätzen. Jede Zeile beschreibt die Funktion des jeweiligen Tags, ein Syntaxbeispiel, die Anwendungsfälle und die Folgen einer fehlenden oder fehlerhaften Konfiguration. Alle drei Tags sollten vierteljährlich anhand der aktuellen Zertifikat-zu-CA-Zuordnung aus dem CLM-Inventar überprüft werden.

Etikett	Was es steuert	Beispielsyntax	Wann zu verwenden	Fehlermodus bei Auslassung oder Fehlkonfiguration
Problem	Welche Zertifizierungsstellen (CAs) dürfen Standard-SSL/TLS-Zertifikate (ohne Wildcards) für die Domain ausstellen? Mehrere Einträge sind zulässig, einer pro autorisierter CA. Wird der Wert auf eine leere Zeichenkette gesetzt (0 issue “”), ist die Ausstellung von Standardzertifikaten durch alle CAs untersagt.	Ausgabe 0 „digicert.com“ 0 Probleme „letsencrypt.org“	Immer. Jede Domain sollte mindestens ein Issue-Tag besitzen, das alle Zertifizierungsstellen (CAs) explizit auflistet, die zur Ausstellung von Standardzertifikaten für diese Domain berechtigt sind. Ohne dieses Tag kann jede CA Standardzertifikate ausstellen, unabhängig von anderen vorhandenen Tags.	Fehlend: Jede Zertifizierungsstelle kann Standardzertifikate ausstellen. Falsche Zertifizierungsstelle angegeben: Die Verlängerung schlägt fehl, wenn die aktive Zertifizierungsstelle den CAA-Eintrag prüft und feststellt, dass sie nicht aufgeführt ist; bei einer Gültigkeitsdauer von 47 Tagen führt dies zu etwa 8 Verlängerungsfehlern pro Jahr und betroffenem Zertifikat.
Ausgabewild	Welche Zertifizierungsstellen (CAs) dürfen Wildcard-SSL/TLS-Zertifikate (*.domain.com) für die Domain ausstellen? Unabhängig vom Issue-Tag. Fehlt das Issue-Tag, gelten für die Ausstellung von Wildcard-Zertifikaten die Beschränkungen des Issue-Tags.	0 issuewild “digicert.com” 0 issuewild “” (blockiert die Ausgabe aller Wildcards)	Für jede Domain, für die Wildcard-Zertifikate ausgestellt werden oder werden könnten. Legen Sie explizit fest, ob bestimmte Zertifizierungsstellen zur Ausstellung von Wildcard-Zertifikaten autorisiert werden sollen oder ob die Ausstellung von Wildcard-Zertifikaten für Domains, die keine Wildcards benötigen, vollständig verboten ist (0 issuewild “”).	Fehlend: Bei der Ausstellung von Wildcards wird auf das Issue-Tag zurückgegriffen, was unter Umständen weniger restriktiv ist als beabsichtigt. Falsch konfiguriert (führt eine Zertifizierungsstelle auf, die nicht für Wildcards verwendet wird): Die Wildcard-Erneuerung schlägt fehl. Es ist akzeptabel, issuewild nicht zu setzen, wenn es nicht benötigt wird und die Kontrollen des Issue-Tags ausreichend sind.
iodef	Hierhin sollen Zertifizierungsstellen einen Bericht senden, wenn sie eine Zertifikatsausstellungsanfrage erhalten, die gegen die CAA-Richtlinie der Domain verstößt. Akzeptiert eine E-Mail-Adresse (mailto:) oder einen URL-Endpunkt. Blockiert die Ausstellung nicht; es wird lediglich eine Benachrichtigung versendet.	0 iodef “mailto:[E-Mail geschützt] " 0 iodef “https://example.com/caa-report”	Jede Domain mit Issue- oder Issuewild-Einträgen. Das iodef-Tag ist der Benachrichtigungsmechanismus, der die Durchsetzung der CAA-Richtlinien sichtbar macht. Ohne dieses Tag bleiben Richtlinienverstöße unbemerkt: Die Zertifizierungsstelle lehnt ab, aber der Domaininhaber wird nicht benachrichtigt.	Fehlend: Richtlinienverstöße bleiben unbemerkt; es wird keine Benachrichtigung versendet, wenn eine nicht autorisierte Zertifizierungsstelle eine Zertifikatsanforderung für die Domäne erhält. Endpunkt nicht überwacht: Benachrichtigungen treffen zwar ein, werden aber nicht bearbeitet, wodurch der operative Nutzen des iodef-Tags verloren geht.

Warum CAA-Einträge für die Domänensicherheit unerlässlich sind

Die unbefugte Ausstellung von Zertifikaten stellt ein ernstzunehmendes Problem dar. Ob durch Social Engineering, einen Fehler der Zertifizierungsstelle oder ein kompromittiertes System – es wurden bereits fälschlicherweise Zertifikate für bekannte Domains ausgestellt. In solchen Fällen können Angreifer verschlüsselten Datenverkehr abfangen, Man-in-the-Middle-Angriffe durchführen oder sich als legitime Dienste ausgeben.

CAA-Einträge schützen nicht vor jedem Angriff, da sie auf deren Überprüfung und Einhaltung durch Zertifizierungsstellen (CAs) beruhen. Die Einhaltung dieser Vorgaben wird vom CA/Browser Forum geregelt. Seit September 2017 sind jedoch alle öffentlich vertrauenswürdigen CAs gemäß den Baseline Requirements des CA/Browser Forums verpflichtet, CAA-Einträge vor der Zertifikatserteilung zu überprüfen. Eine CA, die dies ignoriert, riskiert den Verlust ihres Vertrauensstatus, was schwerwiegende Folgen hat.

CAA-Einträge unterstützen auch die Einhaltung gesetzlicher Bestimmungen. Im Rahmen von Frameworks wie SOC 2, ISO 27001 und PCI DSS ist der Nachweis, dass Sie die Zertifizierungsstellen kontrollieren, die Zertifikate für Ihre Domain ausstellen, eine solide und dokumentierbare Sicherheitsmaßnahme. Dies erleichtert Audits und belegt, dass Ihr Unternehmen die Domain-Sicherheit ordnungsgemäß verwaltet.

Wie Zertifizierungsstellen CAA-Einträge validieren

Wenn eine Zertifizierungsstelle (CA) eine Zertifikatsanfrage erhält, führt sie eine DNS-Abfrage nach CAA-Einträgen für den vollqualifizierten Domänennamen (FQDN) der Anfrage durch. Werden Einträge gefunden und die CA ist nicht aufgeführt, verweigert sie die Ausstellung. Schlägt die DNS-Abfrage aufgrund eines SERVFAIL-Fehlers, eines Timeouts oder einer Fehlkonfiguration fehl, muss die CA die Anfrage ebenfalls ablehnen. Dieser ausfallsichere Ansatz stellt sicher, dass eine fehlerhafte Konfiguration Sie schützt, anstatt Sie angreifbar zu machen.

DNSSEC bietet hier eine zusätzliche Schutzebene. Ohne DNSSEC können CAA-Einträge durch DNS-Cache-Poisoning gefälscht werden. Dabei fügt ein Angreifer falsche Einträge ein, die es der von ihm gewählten Zertifizierungsstelle ermöglichen, ein Zertifikat auszustellen. Wenn Ihre DNS-Zonen mit DNSSEC signiert sind, sind die Genauigkeit und Integrität Ihrer CAA-Einträge auf kryptografischer Ebene gewährleistet.

Existiert kein CAA-Eintrag für einen bestimmten FQDN, durchsucht die Zertifizierungsstelle den DNS-Baum bis zur übergeordneten Domäne und dann zur Großelterndomäne, bis sie einen passenden Eintrag findet. Das bedeutet, dass ein einziger CAA-Eintrag in Ihrer Stammdomäne Ihren gesamten Domänennamensraum abdecken kann – eine sehr effiziente Methode zur Durchsetzung von Richtlinien in großem Umfang.

CAA-Konfiguration: Anforderungen, Fehlermodi und Überwachungssignale

Anhand dieser Tabelle können Sie jede CAA-Konfigurationsanforderung ihrer Validierungsmethode, dem Fehlermodus bei Nichterfüllung der Anforderung, dem Überwachungssignal, das den Fehler meldet, und der maßgeblichen Richtlinienquelle zuordnen. CAA-Einträge und die CA/Browser Forum Baseline Requirements werden vierteljährlich überprüft und können unabhängig voneinander aktualisiert werden.

Anforderung	Validierungsmethode	Fehlermodus	Überwachungssignal	Richtlinienquelle
Für jede extern auflösbare Domain sind CAA-Einträge vorhanden.	DNS-Lookup (dig TYPE257 domain.com oder dig CAA domain.com); MX Toolbox CAA-Prüfung; SSLMate CAA Record Generator; CLM-Plattform-Domain-Audit	Kein CAA-Eintrag: Jede öffentlich vertrauenswürdige Zertifizierungsstelle kann Zertifikate für die Domain ausstellen; unautorisierte Ausstellungen bleiben unentdeckt, bis sie durch einen CT-Log-Monitor oder einen iodef-Bericht aufgedeckt werden.	CLM-Plattform-Domänenprüfung zeigt Domänen ohne CAA-Einträge an; CT-Protokollüberwachungsalarm über unerwartet ausgestelltes Zertifikat für eine ungeschützte Domäne	RFC 6844 (CAA-Standard); RFC 8659 (CAA-Aktualisierung); CA/Browser Forum Baseline Requirements Abschnitt 3.2.2.8 (CAA-Prüfpflicht, gültig ab September 2017)
Die Tags „issue“ und „issuewild“ kennzeichnen alle Zertifizierungsstellen, die aktiv für die Domain ausstellen.	Vergleichen Sie das CLM-Zertifikatsinventar (welche Zertifizierungsstelle welches Zertifikat für welche Domain ausgestellt hat) mit den im CAA-Eintrag für diese Domain aufgeführten Zertifizierungsstellen; bestätigen Sie, dass jede aktive Zertifizierungsstelle aufgeführt ist; testen Sie dies, indem Sie bei jeder autorisierten Zertifizierungsstelle eine Zertifikatserneuerung beantragen und bestätigen, dass die CAA-Prüfung erfolgreich ist.	Der CAA-Eintrag enthält keine aktive Zertifizierungsstelle: Die Zertifikatserneuerung schlägt bei der CAA-Prüfung fehl; bei einer maximalen Gültigkeitsdauer von 47 Tagen (SC-081v3, März 2029) führt dies zu etwa 8 Verlängerungsfehlern pro Jahr und betroffenem Zertifikat; der Fehler wird als Ablehnungsmeldung der Zertifizierungsstelle und nicht als Ablaufwarnung angezeigt.	Fehlermeldungen bei der Zertifikatserneuerung in der CLM-Plattform korrelieren mit Fehlern bei der CAA-Abfrage; CA-Fehlerantworten verweisen während der Erneuerung auf die CAA-Richtlinie; CLM-Inventarvergleich zeigt Diskrepanzen zwischen Zertifikatsaussteller und CAA-Datensatzinhalten auf	RFC 6844 Abschnitt 4 (CAA-Eigenschaftskennzeichnungen); CA/Browser Forum Baseline Requirements Abschnitt 3.2.2.8; CA/B Forum SC-081v3 (genehmigt im April 2025) für den Kontext der Erneuerungshäufigkeit
Der iodef-Endpunkt ist konfiguriert und wird überwacht	Prüfen Sie, ob das iodef-Tag im CAA-Eintrag für alle Domänen vorhanden ist; testen Sie, ob der iodef-Endpunkt erreichbar und korrekt formatiert ist; prüfen Sie, ob iodef-Berichte an das SIEM- oder Ticketsystem weitergeleitet und innerhalb der vereinbarten Service-Level-Vereinbarung (SLA) geprüft werden; Hinweis: Nicht alle Zertifizierungsstellen (CAs) unterstützen die iodef-Berichterstattung; klären Sie die iodef-Unterstützung mit jeder autorisierten CA ab.	Fehlendes Iodef-Tag: Richtlinienverstöße bleiben unbemerkt; eine nicht autorisierte Zertifizierungsstelle erhält eine Zertifikatsanforderung, der Domaininhaber wird jedoch nicht benachrichtigt; der Verstoß ist nur durch die Überwachung des CT-Protokolls erkennbar. Iodef-Endpunkt wird nicht überwacht: Benachrichtigungen treffen ein, werden aber nicht bearbeitet.	SIEM- oder Ticketsystem-Alarm bei Eingang eines neuen IODEF-Berichts; Lücke im IODEF-Berichtsprüfungsprotokoll bei vierteljährlicher Prüfung festgestellt; CT-Protokollüberwachungsalarm für ein unerwartetes Zertifikat, das einen IODEF-Bericht hätte auslösen sollen	RFC 6844 Abschnitt 5.4 (iodef-Eigenschaftstag); CA/Browser Forum Baseline Requirements Abschnitt 3.2.2.8
DNSSEC-Signatur für alle Domains mit CAA-Einträgen	Externer DNSSEC-Validator (DNSViz, Verisign DNSSEC Analyzer); bestätigen, dass das AD-Flag in den CAA-Record-Antworten von DNSSEC-validierenden Resolvern gesetzt ist; bestätigen, dass RRSIG-Records für die Zone vorhanden und nicht abgelaufen sind	Kein DNSSEC: CAA-Einträge sind anfällig für DNS-Cache-Poisoning; ein Angreifer kann gefälschte CAA-Einträge einfügen, die seine gewählte Zertifizierungsstelle zur Ausstellung eines gefälschten Zertifikats autorisieren; der CAA-Eintrag gewährleistet die Durchsetzung von Richtlinien nur gegenüber ehrlichen Zertifizierungsstellen, nicht aber gegenüber aktiven Angreifern, die das DNS manipulieren.	DNSSEC-Validierungsfehler durch externe Validatoren; AD-Flag in DNS-Antworten für CAA-Einträge nicht gesetzt; RRSIG-Ablaufwarnungen aus der DNS-Überwachung; Zertifikat für eine Domäne mit gefälschtem CAA-Eintrag ausgestellt (erkannt durch CT-Protokollüberwachung)	RFC 4033-4035 (DNSSEC); RFC 6844 Abschnitt 3 (empfiehlt DNSSEC für CAA); NIST SP 800-81-2 (Leitfaden zur DNSSEC-Implementierung)
CAA-Datensätze werden aktualisiert, wenn sich CA-Beziehungen ändern	Stellen Sie sicher, dass die Prozesse zur Registrierung und zum Ausschluss von Zertifizierungsstellen (CA) einen Aktualisierungsschritt der CAA-Datensätze beinhalten; prüfen Sie die CAA-Datensätze vierteljährlich anhand der aktuellen Zertifikat-zu-CA-Zuordnung; testen Sie die Erneuerung über jede seit der letzten Prüfung hinzugefügte oder entfernte CA, um die Korrektheit der CAA-Datensätze zu bestätigen.	Der CAA-Eintrag führt eine nicht mehr genutzte Zertifizierungsstelle auf: Es tritt kein unmittelbarer Fehler auf, jedoch besteht weiterhin ein unnötiges Risiko für autorisierte Aussteller. Der CAA-Eintrag führt keine neu hinzugekommene Zertifizierungsstelle auf: Zertifikatserneuerungen schlagen sofort für alle Zertifikate fehl, die zur neuen Zertifizierungsstelle migriert werden.	Fehlermeldungen bei der Zertifikatserneuerung in der CLM-Plattform während der CA-Migration; CLM-Inventarvergleich zeigt neu integrierte CAs, die nicht im CAA-Datensatz aufgeführt sind; vierteljährliche CAA-Prüfung identifiziert veraltete CA-Einträge in CAA-Datensätzen für Domains, für die diese CA keine Zertifikate mehr ausstellt.	RFC 8659 Abschnitt 4 (CAA-Datensatzverwaltung); CA/Browser Forum Baseline Requirements Abschnitt 3.2.2.8; interne CA-Richtlinie zum Änderungsmanagement für Onboarding und Offboarding

Bewährte Verfahren für die Konfiguration und Verwaltung von CAA-Datensätzen

Das Anlegen von CAA-Datensätzen ist unkompliziert, erfordert aber etwas Planung, um es optimal umzusetzen. Hier sind die wichtigsten Vorgehensweisen:

• Prüfen Sie zunächst Ihr Zertifikatsinventar: Bevor Sie CAA-Einträge hinzufügen, ermitteln Sie, welche Zertifizierungsstellen (CAs) bereits Zertifikate für Ihre Domains ausstellen. Tools wie crt.sh können Ihnen dabei helfen. Wenn Sie die Ausstellung auf eine CA beschränken, die Sie tatsächlich nicht verwenden, schlagen Zertifikatserneuerungen fehl.
• Setzen Sie sowohl die Issue- als auch die Issuewild-Tags explizit: Gehen Sie nicht davon aus, dass das eine das andere abdeckt. Stellen Sie sicher, dass Sie genau wissen, welche Zertifizierungsstellen Standard- und Wildcard-Zertifikate ausstellen dürfen, und dokumentieren Sie, warum jede Zertifizierungsstelle autorisiert ist.
• Füge ein iodef-Tag hinzu und überwache es auch tatsächlich: Berichte sind nur dann hilfreich, wenn sie auch gelesen werden. Verbinden Sie Ihren iodef-Endpunkt mit dem Ticketsystem oder SIEM Ihres Sicherheitsteams und nehmen Sie alle Warnmeldungen zu Sicherheitsverletzungen ernst.
• Verwenden Sie CAA-Einträge zusammen mit DNSSEC: DNSSEC stellt sicher, dass Ihre CAA-Richtlinie auf DNS-Ebene nicht gefälscht werden kann. Wenn Ihre Zonen noch nicht DNSSEC-signiert sind, ist dies ein guter Grund, damit zu beginnen.
• Prüfen Sie Ihre CAA-Aufzeichnungen nach der Veröffentlichung: Verwenden Sie Tools wie dig, den SSLMate CAA Record Generator oder die MX Toolbox, um zu überprüfen, ob Ihre Datensätze von mehreren Standorten aus korrekt aufgelöst werden.
• Aktualisieren Sie die CAA-Einträge immer dann, wenn sich Ihre CA-Beziehungen ändern: Bei jedem Wechsel der Zertifizierungsstelle, jedem neuen Vertragspartner oder jeder Fusion sollten Sie Ihre CAA-Einträge entsprechend aktualisieren. Veraltete Einträge können genauso riskant sein wie fehlende.

Wie Verschlüsselungsberatung helfen kann

Die korrekte Einrichtung von CAA-Einträgen beginnt damit, genau zu wissen, welche Zertifizierungsstellen bereits Zertifikate für Ihre Domains ausstellen. Ohne diese Übersicht riskieren Sie, eine Zertifizierungsstelle, die aktiv Zertifikate erneuert, auszusperren, was zu Ausfällen führt, sobald eine Erneuerung fehlschlägt. Genau bei dieser Überprüfung scheitern die meisten Unternehmen, und genau hier bietet CertSecure Manager den entscheidenden Vorteil.

CertSecure Manager ist die Plattform für das Zertifikatslebenszyklusmanagement von Encryption Consulting. Sie bietet Ihrem Team ein vollständiges, stets aktuelles Inventar aller SSL/TLS-Zertifikate in Ihrer Umgebung, einschließlich der ausstellenden Zertifizierungsstelle (CA), des Ablaufdatums und des Einsatzortes. Diese Transparenz ist unerlässlich, bevor Sie auch nur einen einzigen CAA-Eintrag erstellen. Für umfassende Transparenz Ihrer kryptografischen Infrastruktur erweitert CBOM Secure die Erkennung auf Algorithmen, Schlüssel und kryptografische Abhängigkeiten in Cloud-, On-Premises- und Hybridumgebungen.

So geht CertSecure Manager mit diesen Herausforderungen um:

Zertifikatserkennung und -inventarisierung: Unser CertSecure Manager scannt Ihre Netzwerk- und Cloud-Umgebungen, um jedes verwendete Zertifikat zu ermitteln, unabhängig von der ausstellenden Zertifizierungsstelle. Bevor Sie die Ausstellung über CAA-Einträge einschränken, müssen Sie wissen, welche Zertifikate bereits vorhanden sind. Dieser Schritt erfolgt automatisch.

CA-Beziehungsverfolgung: Da Ihre CAA-Richtlinie nur so genau ist wie Ihr Wissen darüber, welche CAs Sie tatsächlich verwenden, hält CertSecure Manager Ihr Zertifikatsinventar auf dem neuesten Stand, sodass Ihre CAA-Aufzeichnungen der Realität entsprechen, selbst wenn Ihre Umgebung wächst oder sich Ihre CA-Beziehungen ändern.

Automatisierte Zertifikatserneuerung: Sobald Ihre CAA-Einträge eingerichtet sind, schlägt jede Zertifikatserneuerung, die an eine nicht autorisierte Zertifizierungsstelle gerichtet wird, fehl. CertSecure Manager automatisiert die Erneuerungen über Ihre autorisierten Zertifizierungsstellen, sodass es keine Überraschungen in letzter Minute gibt, wenn ein Zertifikat abläuft.

Audit-Trail für Compliance: Für Frameworks wie SOC 2, ISO 27001 und PCI DSS ist der Nachweis der Kontrolle über die Zertifikatsausstellung eine dokumentierbare Sicherheitsmaßnahme. CertSecure Manager protokolliert jedes Zertifikatsereignis und liefert Ihrem Compliance-Team so die benötigten Nachweise.

CAA-Einträge definieren Ihre Richtlinien. CertSecure Manager bietet Ihnen die nötige Transparenz und Automatisierung, um diese Richtlinien in Ihrer gesamten Zertifikatsumgebung konsistent anzuwenden. Für Organisationen, die eine private PKI-Infrastruktur aufbauen oder erweitern, bietet PKI as a Service eine vollständig verwaltete CA-Hierarchie, in der die interne CA-Nutzung nahtlos in die CAA-Eintragsverwaltung integriert ist. Für die Planung der Migration von DNSSEC-Zonensignierungsalgorithmen, die zusammen mit CAA verwendet werden, nach der Quantenmigration können Sie die Anforderungen über das PQC Center of Excellence verfolgen.

Fazit

CAA-Einträge werden leicht übersehen, da sie unauffällig im Hintergrund arbeiten. Ihr Weglassen führt jedoch zu einer echten Sicherheitslücke. Da die missbräuchliche Ausstellung von Zertifikaten im Internet weiterhin ein Risiko darstellt, müssen Domaininhaber die Kontrolle darüber übernehmen, wer in ihrem Namen Zertifikate ausstellen darf. CAA-Einträge ermöglichen diese Kontrolle auf einfache und standardisierte Weise.

Wenn CAA-Einträge korrekt eingerichtet und mit DNSSEC, einem überwachten iodef-Endpunkt und einem soliden Zertifikatsverwaltungsprozess kombiniert werden, werden sie zu einem wichtigen Bestandteil Ihrer PKI-Strategie. Ihre Implementierung ist unkompliziert, sie müssen jedoch bei Änderungen Ihrer Umgebung stets aktualisiert werden.

Dieser Leitfaden wird vierteljährlich überprüft und sofort aktualisiert, sobald das CA/Browser Forum seine CAA-Prüfregeln für die Baseline Requirements aktualisiert oder neue CAA-Eigenschafts-Tags einführt.

Häufig gestellte Fragen

Was ist die wichtigste Erkenntnis aus „CAA-Einträge erklärt: Welche Zertifizierungsstellen können Zertifikate für Ihre Domain ausstellen?“

CAA-Einträge sind eine DNS-Zertifikatskontrollmaßnahme (RFC 6844, aktualisierter RFC 8659), die einschränkt, welche Zertifizierungsstellen SSL/TLS-Zertifikate für Ihre Domain ausstellen dürfen. Sie werden seit September 2017 durch die Baseline Requirements des CA/Browser Forums durchgesetzt. Eine Domain ohne CAA-Einträge erlaubt es jeder öffentlich vertrauenswürdigen Zertifizierungsstelle, Zertifikate für sie auszustellen. Drei Tags steuern die Zertifikatsausstellung: `issue` (Standardzertifikate), `issuewild` (Wildcard-Zertifikate) und `iodef` (Verletzungsmeldung). DNSSEC schützt CAA-Einträge vor Spoofing. Die Tags `issue` und `issuewild` sind unabhängig; wird nur einer der beiden gesetzt, bleibt die Hälfte des Zertifikatsnamensraums unkontrolliert.

Warum sind CAA-Einträge für PKI-Teams in Unternehmen wichtig?

PKI-Teams in Unternehmen sind zwei Risiken im Zusammenhang mit Zertifizierungsstellen (CAA) ausgesetzt. Domains ohne CAA-Einträge können von jeder der über 100 öffentlich vertrauenswürdigen Zertifizierungsstellen (CAs) Zertifikate erhalten, von denen jede kompromittiert oder manipuliert werden kann. Die DigiCert Trust Pulse Survey (2. Juli 2025) ergab, dass 45 Prozent der Unternehmen aufgrund von Zertifikatsausfällen zu Ausfallzeiten neigten. Falsch konfigurierte CAA-Einträge, die eine aktive CA auslassen, führen zu Verlängerungsfehlern und damit genau zu diesen Ausfallzeiten. Bei einer maximalen TLS-Gültigkeit von 47 Tagen ab März 2029 (CA/B Forum SC-081v3, genehmigt im April 2025) verursacht ein falsch konfigurierter CAA-Eintrag pro betroffenem Zertifikat etwa acht Verlängerungsfehler pro Jahr.

Welche Risiken erhöhen sich, wenn CAA-Datensätze nicht konfiguriert oder manuell verwaltet werden?

Drei Risikokategorien erhöhen sich: Offene Ausstellungsgefährdung (ohne CAA-Einträge kann jede öffentlich vertrauenswürdige Zertifizierungsstelle Zertifikate für die Domain ausstellen); Fehlkonfigurationen, die Verlängerungen blockieren (ein CAA-Eintrag, der eine aktive Zertifizierungsstelle auslässt, führt zu Verlängerungsfehlern, achtmal pro Jahr bei einer Gültigkeit von 47 Tagen); und Wildcard-Lücke (die Konfiguration von issue ohne issuewild oder issuewild ohne issue lässt die Hälfte des Zertifikatsnamensraums unkontrolliert).

Welche Teams sollten für die Konfiguration und Pflege der CAA-Datensätze verantwortlich sein?

Die DNS- und Infrastrukturteams sind für die Veröffentlichung der CAA-Einträge und die DNSSEC-Wartung zuständig. Die PKI- und Zertifikatsteams verantworten die Zuordnung von Zertifikaten zu Zertifizierungsstellen (CAs), die festlegt, welche CAs gelistet werden müssen. Die Sicherheitsarchitekten sind für das Governance-Modell verantwortlich: Richtlinien für die Behandlung von Problemen (Issue vs. Issuewild), die Überwachung von iodef-Endpunkten und ein Handbuch für die Reaktion auf unautorisierte Zertifikatsausstellungen. Die Compliance-Teams sind für die Audit-Nachweise verantwortlich, die bestätigen, dass die CAA-Einträge für alle relevanten Domänen vorhanden, korrekt und aktuell sind.

Wie hängen CAA-Datensätze mit dem Zertifikatslebenszyklusmanagement zusammen?

CAA-Einträge sind eine Abhängigkeit im Lebenszyklus eines Zertifikats: Jede Zertifikatserneuerung löst eine CAA-Abfrage bei der ausstellenden Zertifizierungsstelle (CA) aus. Fehlt die CA im CAA-Eintrag, schlägt die Erneuerung fehl. CertSecure Manager stellt das erforderliche Zertifikatsinventar bereit, um zu bestätigen, welche CAs vor der Veröffentlichung von CAA-Einträgen aufgeführt werden müssen, und automatisiert Erneuerungen über autorisierte CAs, sodass CAA-Abweichungen keine Ausfälle verursachen.

Wie sollten Organisationen den Erfolg bei der Implementierung von CAA-Datensätzen messen?

Wichtige Kennzahlen: 100 Prozent der unternehmenseigenen Domains verfügen über CAA-Einträge; 100 Prozent der CAA-Einträge stimmen mit der aktuellen Zertifikat-zu-CA-Zuordnung aus dem CLM-Inventar überein; keine Zertifikatserneuerungsfehler aufgrund von CAA-Fehlkonfigurationen; iodef-Berichte werden innerhalb der definierten SLA geprüft (Ziel: 100 Prozent innerhalb von 24 Stunden); und DNSSEC-Signaturabdeckung für 100 Prozent der Domains mit CAA-Einträgen.

Was sollte regelmäßig geprüft oder überwacht werden?

Kontinuierliche Überwachung: iodef-Berichte aller autorisierten Zertifizierungsstellen mit automatisierter Benachrichtigung; Ereignisse, bei denen Zertifikatserneuerungen fehlschlagen und CAA-Lookup-Fehler auftreten. Vierteljährliche Prüfung: Vorhandensein von CAA-Einträgen für alle unternehmenseigenen Domains; Genauigkeit der CAA-Einträge im Vergleich zur aktuellen Zertifikat-zu-CA-Zuordnung; DNSSEC-Signaturstatus für alle Domains mit CAA-Einträgen; und Einhaltung der CA/B-Forum-Baseline-Anforderungen hinsichtlich aller CAA-bezogenen Aktualisierungen.

Wie wirken sich CAA-Einträge auf Cloud-, Hybrid- oder Multi-CA-PKI-Umgebungen aus?

In Umgebungen mit mehreren Zertifizierungsstellen (CAs) werden CAA-Einträge besonders komplex: Jede Domain kann mehrere autorisierte CAs haben (öffentliche CA für kundenseitiges TLS, private CA für interne Dienste, Cloud-Provider-CA für Cloud-native Workloads), und der CAA-Eintrag muss alle korrekt auflisten. Cloud-bereitgestellte Subdomains, die nicht im DNS-Inventar enthalten sind, führen zu Abdeckungslücken. Eine CLM-Plattform mit umgebungsübergreifender Erkennung ist Voraussetzung für korrekte CAA-Einträge in einer Multi-CA- und Multi-Cloud-Umgebung.

Welche häufigen Fehler sollten Teams vermeiden?

Die häufigsten Fehler: Veröffentlichung von CAA-Einträgen vor der Prüfung, welche Zertifizierungsstellen aktiv Zertifikate ausstellen (führt zu Verlängerungsfehlern, wenn eine aktive Zertifizierungsstelle ausgelassen wird); Festlegen von issuewild ohne gleichzeitiges Festlegen von issue (lässt die Standardzertifikatsausstellung für jede beliebige Zertifizierungsstelle offen); Nichtberücksichtigen aller über Subdomains hinweg verwendeten Zertifizierungsstellen; Nichtkonfigurieren von DNSSEC (macht CAA-Einträge anfällig für DNS-Cache-Poisoning); und Nichtüberwachen von iodef-Berichten (eliminiert den Benachrichtigungswert des iodef-Tags).

Was sollte vierteljährlich aktualisiert werden?

Vierteljährlich: Vergleichen Sie die CAA-Einträge mit der aktuellen Zertifikat-zu-CA-Zuordnung aus dem CLM-Inventar; bestätigen Sie, dass DNSSEC alle Domains mit CAA-Einträgen signiert; prüfen Sie die iodef-Berichte des Vorquartals; bestätigen Sie, dass neu hinzugefügte Domains seit dem letzten Audit über CAA-Einträge verfügen; und vergewissern Sie sich, dass die CA/B-Forum-Baseline-Anforderungen keine neuen CAA-Prüfregeln eingeführt haben. Informationen zur Planung der DNSSEC-Algorithmusmigration nach der Quantenintegration finden Sie im PQC Center of Excellence . Dieser Beitrag wird vierteljährlich überprüft.