Zusammenfassung

  • Eine erfolgreiche DNS-01-Prüfung belegt, dass ein bestimmtes ACME-Konto seinen privaten Kontoschlüssel besitzt und den verlangten Digest unter dem Validierungsnamen sichtbar machen kann, den die Zertifizierungsstelle abfragt. Eine CNAME- oder NS-Delegation kann diese schmale Macht vergeben, ohne Apex-Zone, Anwendung oder Geschäftsmandat zu übertragen.
  • Auftrag, Autorisierung, Wildcard-Umfang, CSR, Ausstellung, Schlüsselverwahrung, Einsatz, CT-Beobachtung und Widerruf sind getrennte Zustände. Das Löschen eines TXT-Eintrags oder Anbieterzugangs beendet nicht alle.

Ein Offboarding ohne DNS-Ende

Das Unternehmen deaktivierte den Identitätszugang des Dienstleisters, löschte sein CI-Geheimnis und entzog seine Rolle im Zertifikatsspeicher. Das Anwendungsverzeichnis zeigte keine aktive Integration. Die übergeordnete Zone verwies _acme-challenge.example jedoch weiterhin auf eine vom früheren Anbieter kontrollierte Zone.

Diese Delegation war eine ausführbare Befugnis. Let's Encrypt dokumentiert, dass seine DNS-01-Auflösung CNAME oder NS in eine andere Zone folgen kann. Wer den passenden ACME-Kontoschlüssel und die endgültige DNS-Antwort kontrolliert, kann eine neue Challenge empfangen, den richtigen Wert berechnen und eine Wildcard-Ausstellung abschließen, ohne den Webserver zu berühren.

Der Fall ist konstruiert und behauptet keinen Vorfall bei einer konkreten Firma oder CA. Er zeigt eine allgemeine Trennung: Ein Anwendungszugang und eine im DNS verankerte Ausstellungsmöglichkeit werden an unterschiedlichen Stellen entzogen.

Was der Digest tatsächlich verbindet

DNS-01 verwendet nach RFC 8555 kein frei wählbares TXT-Passwort. Der ACME-Server liefert ein Token mit mindestens 128 Bit Entropie. Der Client bildet daraus und aus seinem Kontoschlüssel eine key authorization, berechnet SHA-256 und veröffentlicht den base64url-Digest unter _acme-challenge.<Identifier>.

Zwei Voraussetzungen treffen zusammen: Der Antragsteller kann als ACME-Konto signieren, und er kann den erwarteten Wert am Validierungsnamen erscheinen lassen. Ändert sich Token oder Kontoschlüssel, ändert sich der Digest. Ein alter TXT-Wert ist kein übertragbarer Beleg für einen neuen Auftrag.

Eine authorization hält die Serverentscheidung fest, dass ein Konto einen Identifier vertreten darf. Der Zustand valid besitzt ein Ablaufdatum und kann später ablaufen, deaktiviert oder widerrufen werden. Eine belastbare Prüfnotiz nennt deshalb Konto, Autorisierung, Identifier, Methode, beobachteten Pfad und Gültigkeitsfenster statt nur „Domain validiert“.

Eine kleine Zone kann eine große Wirkung haben

Eine eigene Validierungszone oder eng begrenzte DNS-Zugangsdaten können sicherer sein als ein Apex-weiter API-Schlüssel auf einem Anwendungsserver. Die verbleibende Delegation ist trotzdem eine Ausstellungskapazität, bis sie tatsächlich entfernt oder wirksam eingeschränkt wurde.

Zu protokollieren sind jeder CNAME- und NS-Schritt, das Konto hinter der Endzone, DNSSEC-Zustand, TTL sowie Antworten und Zeiten aus relevanten Blickpunkten. DNSSEC kann Delegation und Antwort authentifizieren; es kann nicht entscheiden, ob das Vertragsverhältnis noch gilt. Ein Screenshot der Elternzone beweist ebenfalls nicht den tatsächlich ausgeführten Pfad.

Autoritative Änderung, rekursive Caches und CA-Beobachtung können zeitlich auseinanderfallen. Ein Entzugstest muss daher die TTL-Grenze überschreiten und die Ansichten vergleichen.

Wildcard-Umfang steckt nicht im TXT-Namen

Bei einem Wildcard-Auftrag liefert RFC 8555 eine authorization für den Basisnamen ohne *. und setzt wildcard: true. Der Validierungsname kann wie eine gewöhnliche Basisdomain aussehen, während das Zertifikat einen Wildcard-Identifier umfasst. Ohne das Flag neben Auftrag und CSR unterschätzt eine Prüfung den Umfang.

Let's Encrypt beschreibt DNS-01 als seinen Weg für Wildcard-Zertifikate. Das ist eine Aussage über diese CA, keine universelle ACME-Regel. RFC 9444 definiert zudem ein optionales Modell, in dem Serverpolitik eine Autorisierung einer übergeordneten Domain für Subdomain-Zertifikate akzeptieren kann. Unterstützung darf nicht unterstellt werden; maßgeblich ist der Identifier, den der Server in der authorization tatsächlich ausgab.

Der CSR schließt eine Tür

Die Identifier eines ACME-Auftrags sind unveränderlich. Beim Finalisieren muss der CSR exakt dieselbe Menge enthalten. Ein zusätzlicher SAN lässt sich nach der Validierung nicht einschleusen. Diese Integritätsregel ist wichtig.

Sie bestimmt weder den legitimen Besitzer des Zertifikatsschlüssels noch Einsatzort oder Anwendungsrolle. Auftrag, authorization, CSR, Ausstellung, Speicherung, Installation und erster beobachteter Handshake brauchen getrennte Ereignisse, Eigentümer und Zeitpunkte.

CAA kann eine weitere Oberfläche verengen. RFC 8657 definiert optionale Parameter accounturi und validationmethods für issue und issuewild. Sie wirken nur, wenn die genannte CA sie konsistent unterstützt, und ersetzen die Domainvalidierung nicht. Der RFC warnt zudem, dass delegierte Subdomain-Kontrolle CAA-Einschränkungen überlagern kann. Eine Policy-Zeile ersetzt nicht das Löschen der delegierten Fähigkeit.

Aufräumen ist kein Widerruf

Das Löschen von TXT beendet eine Antwort. Das Entfernen einer CNAME- oder NS-Delegation beendet nach Cache-Konvergenz einen Pfad. Die Deaktivierung einer authorization oder eines ACME-Kontos ändert einen weiteren Zustand. Keine dieser Maßnahmen widerruft allein ein bereits ausgestelltes Zertifikat.

ACME kennt dafür einen eigenen signierten Widerrufsantrag. Der ausstellende Account, ein Konto mit Autorisierungen für alle Zertifikats-Identifier oder der private Zertifikatsschlüssel können protokollseitig Widerrufsautorität liefern. OCSP und CRL bilden wiederum eine eigene Statusfläche, deren Sichtbarkeit bei Clients zeitlich erfasst werden muss.

Certificate Transparency macht unerwartete Ausstellungen sichtbar und prüfbar. Ein SCT ist aber keine normale Zertifikatsvalidierung, und ein Logeintrag macht ein Zertifikat nicht ungültig. CT liefert einen Auslöser; Untersuchung und Widerruf bleiben eigenständige Arbeit.

Jede Grenze gezielt brechen

Negative Tests erklären mehr als ein grünes Verlängerungs-Dashboard. Entfernen Sie den Anwendungszugang, lassen Sie die Challenge-Delegation stehen und prüfen Sie einen neuen Auftrag. Rotieren Sie den ACME-Kontoschlüssel und veröffentlichen Sie einen mit dem alten Schlüssel gebildeten Digest. Ergänzen Sie im CSR einen SAN, der nicht im Auftrag steht. Prüfen Sie Wildcard und exakten Namen parallel. Entfernen Sie die Delegation und beobachten Sie autoritative sowie rekursive Antworten vor und nach der TTL.

Stellen Sie schließlich ein Zertifikat aus, setzen Sie es nicht ein, löschen Sie die Challenge und bestätigen Sie, dass sein Status nicht automatisch wechselt. Jede Kontrolle muss an genau der Grenze scheitern, die sie zu schützen behauptet.