Das CA/Browser Forum hat abgestimmt, ACME CAA-Erweiterungen ab März 2027 verpflichtend zu machen. Diese Änderung ist einer der letzten fehlenden Bausteine, um eine starke, kryptografisch validierte Domain-Validierung in der Web-PKI zu unterstützen. In diesem Blogbeitrag erläutern wir, warum die Web-PKI für stark exponierte Websites nicht genügend Sicherheit bietet und wie DNSSEC, ACME und CAA kombiniert werden können, um eine starke kryptografische Validierung der Zertifikatsausstellung zu erreichen.
Konvergenz von DNSSEC und Web-PKI
Nicht jeder mag DNSSEC, aber es bietet wichtige Sicherheitsfunktionen, die wir sonst nirgendwo erhalten können. Unternehmen, die es für ihre Domainnamen aktivieren, erreichen Integrität bei der DNS-Auflösung. Manche argumentieren, dass Web-PKI gut funktioniert – und das stimmt, aber nur für den üblichen Anwendungsfall: den Schutz von Websites, die keiner ernsthaften Bedrohung ausgesetzt sind. Kurz gesagt: Stark exponierte Websites benötigen bessere Sicherheit.
Lange Zeit argumentierten Befürworter von DNSSEC, dass es die Web-PKI ersetzen könnte. Ihr Gedanke war: Sobald man Integrität bei der DNS-Auflösung erreicht, erhält man eine Sicherheitseigenschaft, auf der man aufbauen kann, um X.509-Zertifikate ohne CAs funktionieren zu lassen. Das ist richtig, aber nur in der Theorie. In der Praxis hat DNSSEC diverse Design- und Betriebsprobleme, die eine breite Verbreitung erschweren. Deshalb ist die Unterstützung dafür nach vielen Jahren immer noch nicht dort, wo sie sein müsste. Web-PKI und CAs sind gekommen, um zu bleiben.
Dennoch haben Organisationen, die robuste öffentliche X.509-Sicherheit benötigen, keine andere Wahl, als DNSSEC wegen seiner einzigartigen Funktionen einzusetzen.
Im Jahr 2025 entschied das CA/Browser Forum, das Gremium, das die Zertifikatsausstellung regelt, DNSSEC-Validierung einzubeziehen in den Domain-Validierungsprozess. Die Anforderung wurde im März 2026 verpflichtend und ermöglichte erstmals eine starke kryptografische Validierung der Zertifikatsausstellung.
Schwachstellen an der Wurzel der Web-PKI
Die Web-PKI ist die am strengsten verwaltete öffentliche PKI, mit ausgefeilten Regeln und Kontrollen. Es ist ein Ökosystem, das wir über Jahrzehnte hinweg verbessert haben. Im Kern hat es jedoch zwei erhebliche Probleme. Sie machen das System zwar einfacher zu nutzen, aber das bezahlen wir mit gelockerten Sicherheitsanforderungen.
Erstens gibt es keine Authentifizierung des Zertifikatsanforderers. Jeder auf der Welt kann ein Zertifikat für einen beliebigen Domainnamen beantragen; wenn der Validierungsprozess erfolgreich ist, wird das Zertifikat an den Antragsteller ausgestellt – selbst wenn der Domaininhaber ihn nicht dazu autorisiert hat.
Zweitens führt die CA bei der Beantragung eines Zertifikats die Domain-Validierung über ungesicherten BGP-, DNS- und Netzwerkverkehr durch. Jeder, der einen dieser drei Bereiche beeinflussen kann, kann die Domain-Validierung kompromittieren.
Fügen wir DNSSEC zu diesem Mix hinzu, hilft das, das DNS abzusichern, aber die verbleibenden zwei Aspekte (BGP und unverschlüsselter Netzwerkverkehr) bleiben unsicher. Wir müssen hier einen Kunstgriff anwenden: die entscheidenden Entscheidungen über DNSSEC treffen und die Nutzung von allem anderen verhindern.
Certification Authority Authorization
Die Schwachstellen in der Web-PKI können durch einen Standard namens Certification Authority Authorization (CAA), definiert in RFC 8659, behoben werden. CAA soll Domaininhabern ermöglichen, ihre Richtlinien zur Zertifikatsausstellung zu veröffentlichen.
Die Basisversion von CAA ist seit September 2017 verpflichtend, reicht aber für unsere Bedürfnisse nicht aus. Es gibt ein weiteres Dokument (RFC 8657), das eine Brücke zwischen dem ACME-Protokoll für die automatisierte Zertifikatsausstellung und CAA schlägt und Unterstützung für feingranulare Berechtigungen hinzufügt.
Mit den ACME CAA-Erweiterungen können wir beide zuvor beschriebenen Probleme lösen – mithilfe eines einzigen CAA-Resource-Records in unserem DNS, der etwa so aussieht:
example.com. CAA 0 issue "letsencrypt.org;
accounturi=https://acme-v02.api.
letsencrypt.org/acme/acct/1726001367;
validationmethods=dns-01"Was bewirkt das?
Links sehen wir den Domainnamen, für den wir die Zertifikatsausstellung kontrollieren möchten, in diesem Fall example.com. Rechts haben wir drei Kontrollen. Die erste ist die Identität einer CA, die Zertifikate für den Domainnamen ausstellen darf, in diesem Fall letsencrypt.org.
Die zweite Kontrolle ist die Anweisung accounturi, die die Ausstellung ausschließlich auf das genannte ACME-Konto beschränkt. Da ACME für ACME-Konten stets Verschlüsselung und starke kryptografische Authentifizierung verwendet, stellt dieser Abschnitt sicher, dass nur autorisierte Nutzer Zertifikate für diesen Domainnamen beantragen können.
Die dritte Kontrolle ist die Anweisung validationmethods, die die Ausstellung auf die Verwendung nur einer DNS-basierten Domain-Validierungsmethode beschränkt. Wenn DNSSEC für einen Domainnamen aktiviert ist, stellt dieser Abschnitt sicher, dass alle Domain-Validierungsvorgänge kryptografisch abgesichert sind. Damit müssen wir uns nicht mehr um andere unsichere Methoden sorgen; die CA wird diese von vornherein nie akzeptieren.
Können wir ACME CAA-Erweiterungen jetzt schon nutzen?
ACME CAA-Erweiterungen gibt es bereits seit 2019, und einige CAs (z. B. Let's Encrypt, Google Trust Services und andere) unterstützen sie bereits. Theoretisch hätten Sie also seit März 2026, als DNSSEC für die Domain-Validierung verpflichtend wurde, stärkere Ausstellungskontrollen nutzen können. In der Praxis zögern CAs jedoch stets, sich vollständig zu verpflichten, solange ein Feature nicht in den Baseline Requirements verankert ist. Das liegt daran, dass jedes Feature ihren Arbeitsaufwand erhöht und ihre Aufgabe komplexer macht. Ein Verstoß gegen eine schriftliche Richtlinie könnte zur Zertifikatsausstellung führen.
Das Chrome-Team ist seit langem ein Befürworter der Automatisierung. Die Unterstützung von Automatisierung war stets ein zentraler Bestandteil ihrer Root Program Policy und darin enthalten auch Anforderungen für ACME und ACME CAA-Erweiterungen. Im Februar 2026 wurde die Richtlinie geändert, sodass alle CAs, die ACME unterstützen, auch ACME CAA unterstützen müssen.
Im Mai 2026 stimmte das CA/Browser Forum (in Ballot SC-098v2) formell dafür, die Unterstützung von CAA zu erweitern und die ACME CAA-Erweiterungen (RFC 8657) für alle CAs ab März 2027 verpflichtend zu machen.
Sie können die ACME CAA-Erweiterungen schon heute nutzen, wenn Sie mit CAs zusammenarbeiten, die sie unterstützen. Ab nächstem Jahr wird dieses Feature breit unterstützt, und Sie haben die Wahl zwischen mehreren CAs.
Ivan Ristic is the Chief Scientist for Red Sift and former founder of Hardenize. Learn more about how Red Sift helps organizations with their Certificate Monitoring.