HTTP-01 vs. DNS-01: die passende ACME-Challenge wählen

HTTP-01 vs. DNS-01 ist die erste Entscheidung, wenn du Zertifikate mit ACME (RFC 8555) automatisierst. Bei HTTP-01 ruft die Zertifizierungsstelle ein Token über Port 80 von deinem Webserver ab; bei DNS-01 fragt sie einen TXT-Eintrag in deiner Zone ab. Beide sind Methoden der Domain-Validierung nach den Baseline Requirements, und beide liefern identische Zertifikate. Die beiden unterscheiden sich aber darin, was sie validieren können, wo sie laufen können und was schiefgehen kann.

Auf einen Blick

Was die CA tatsächlich prüft

Beide Challenges verwenden eine Schlüsselautorisierung (Key Authorization): das Challenge-Token, per Punkt verkettet mit dem JWK-Thumbprint (RFC 7638) des Schlüssels deines ACME-Kontos. Weil der Kontoschlüssel Teil des Nachweises ist, kann jemand, der das Token sieht, die Challenge nicht für ein eigenes Konto abschließen. HTTP-01 liefert die Schlüsselautorisierung unverändert aus; DNS-01 veröffentlicht ihren SHA-256-Digest, der in einen TXT-Eintrag passt. Das folgende Skript reproduziert beide Werte für den Beispiel-Kontoschlüssel aus RFC 7638 und die Beispiel-Tokens aus RFC 8555 (Node.js 26).

import { createHash } from "node:crypto";

// Account public key: the RSA example JWK from RFC 7638 §3.1
const accountJwk = {
  kty: "RSA",
  e: "AQAB",
  n: "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMstn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbISD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqbw0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
};

const b64url = (buf) => buf.toString("base64url");
const sha256 = (s) => createHash("sha256").update(s).digest();

// RFC 7638: hash the required members in lexicographic order
const { e, kty, n } = accountJwk;
const thumbprint = b64url(sha256(JSON.stringify({ e, kty, n })));
console.log("account key thumbprint:", thumbprint);

// http-01 (RFC 8555 §8.3): serve the key authorization itself
const httpToken = "LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0";
console.log("\nhttp-01");
console.log(`  GET http://www.example.org/.well-known/acme-challenge/${httpToken}`);
console.log(`  body: ${httpToken}.${thumbprint}`);

// dns-01 (RFC 8555 §8.4): publish base64url(SHA-256(key authorization))
const dnsToken = "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA";
const txt = b64url(sha256(`${dnsToken}.${thumbprint}`));
console.log("\ndns-01");
console.log(`  _acme-challenge.www.example.org. 300 IN TXT "${txt}"`);

account key thumbprint: NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs

http-01
  GET http://www.example.org/.well-known/acme-challenge/LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0
  body: LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0.NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs

dns-01
  _acme-challenge.www.example.org. 300 IN TXT "ZTRx1Ckl1-tM05o5zaizTTA0yUy5AGereMgSNWC6Ll8"

Der Thumbprint stimmt mit dem in RFC 7638 §3.1 veröffentlichten Wert überein, was die Berechnung bestätigt. Clients erledigen all das für dich; die Werte zu kennen hilft aber, wenn du eine fehlschlagende Challenge von Hand mit curl oder dig analysierst.

Prüfung aus mehreren Netzwerkperspektiven und DNSSEC

Seit 2025 müssen öffentliche CAs jede Validierung von mehreren Netzwerkstandorten aus bestätigen (Baseline Requirements §3.2.2.9). Seit dem 15. Juni 2026 sind mindestens vier entfernte Perspektiven beteiligt, die mindestens 500 km auseinanderliegen und aus den Gebieten von mindestens zwei Regional Internet Registries stammen; nur eine davon darf abweichen. Am 15. Dezember 2026 steigt das Minimum auf fünf. Für HTTP-01 heißt das: Jeder Anycast-Knoten, jede GeoDNS-Antwort und jede IPv4- oder IPv6-Adresse des Namens muss das Token ausliefern. Für DNS-01 muss jeder autoritative Nameserver den Eintrag bereits haben, wenn du die CA um die Validierung bittest.

Seit dem 15. März 2026 müssen CAs außerdem DNSSEC validieren, wenn sie DNS-Abfragen für die Domain-Validierung und für CAA stellen (Ballot SC-085v2). Unsignierte Zonen sind davon nicht betroffen, doch eine signierte Zone mit abgelaufener Signatur oder fehlerhaftem DS-Eintrag blockiert jetzt die Ausstellung bei beiden Challenge-Typen; der DNSSEC-Inspektor zeigt dir die Kette so, wie die CA sie prüfen wird.

DNS-Zugangsdaten eng begrenzen

Das Hauptrisiko von DNS-01 sind die Zugangsdaten, die es braucht: Ein DNS-API-Token auf einem Webserver kann oft die ganze Zone umschreiben. Weil CAs den TXT-Eintrag per gewöhnlicher DNS-Auflösung abfragen, die CNAME- und NS-Delegierungen folgt, kann der Name _acme-challenge in eine separate Zone zeigen, in die der Server schreiben darf, und nirgendwo sonst:

_acme-challenge.example.com.  3600  IN  CNAME  example-com.acme.example.net.

Tools wie acme-dns oder Tokens des DNS-Anbieters, die auf einen Eintrag oder eine Zone beschränkt sind, begrenzen dann, was gestohlene Zugangsdaten anrichten können. Ergänze das um CAA-Einträge mit den Parametern aus RFC 8657, die CAs ab dem 15. März 2027 verarbeiten müssen:

example.com.  IN  CAA  0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890; validationmethods=dns-01"
example.com.  IN  CAA  0 issuewild "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890; validationmethods=dns-01"

Mit validationmethods kann ein Angreifer, der kurzzeitig Port 80 oder einen Webpfad auf deinem Server unter Kontrolle hat, über HTTP-01 kein Zertifikat mehr erhalten. Der CAA-Eintragsgenerator erstellt diese Einträge.

TLS-ALPN-01 und dauerhafte DNS-Einträge

TLS-ALPN-01 (RFC 8737) validiert auf Port 443 innerhalb des TLS-Handshakes, mit dem Protokoll acme-tls/1 und einem selbstsignierten Zertifikat, das den Digest der Schlüsselautorisierung enthält. Diese Challenge eignet sich für TLS-terminierende Proxys und Load Balancer, bei denen Port 80 geschlossen ist; wie HTTP-01 kann sie IP-Adressen validieren, aber keine Wildcards.

DNS-PERSIST-01 macht die DNS-Änderung bei jeder Erneuerung überflüssig. Ballot SC-088v3 (Oktober 2025) hat „DNS TXT Record with Persistent Value“ als §3.2.2.4.22 in die Baseline Requirements aufgenommen: Ein langlebiger TXT-Eintrag unter _validation-persist.name nennt die CA und die URI deines ACME-Kontos, optional mit policy=wildcard. Die ACME-Challenge dazu ist noch ein IETF-Entwurf. Google Trust Services unterstützt Version 01 des Entwurfs seit dem 28. September 2026; Let's Encrypt bietet sie bisher nur in der Staging-Umgebung an und hält die Freigabe für den Produktivbetrieb mit Stand Oktober 2026 zurück, bis ein offener Punkt im Entwurf geklärt ist. Der Preis dafür ist, dass der Kontoschlüssel zu einer dauerhaften Autorisierung wird; schütze ihn deshalb wie DNS-Zugangsdaten.

Bald wird bei jeder Erneuerung validiert

Mit den Zertifikatslaufzeiten schrumpft auch der Zeitraum, in dem Autorisierungen wiederverwendet werden dürfen. Die Baseline Requirements begrenzen die Wiederverwendung einer Domain-Validierung derzeit auf 200 Tage, ab März 2027 auf 100 Tage und ab März 2029 auf 10 Tage. Das Standardprofil von Let's Encrypt verwendet Autorisierungen heute 30 Tage lang wieder, ab dem 10. Februar 2027 noch 10 Tage und ab dem 16. Februar 2028 nur noch 7 Stunden. Welche Challenge du auch wählst, sie muss ohne manuelles Eingreifen laufen; TXT-Werte von Hand zu kopieren, ist 2028 nicht mehr praktikabel.

Wann welche Challenge passt

• Ein öffentlicher Webserver, auf dem der ACME-Client läuft: HTTP-01.
• Wildcard-Zertifikate: DNS-01 (oder DNS-PERSIST-01, wo deine CA es anbietet).
• Interne Hosts mit öffentlichen Namen, nur per VPN erreichbare Dienste, Entwicklungsumgebungen: DNS-01; denk daran, dass die Namen in CT-Logs erscheinen.
• Serverflotten hinter Load Balancern, Bereitstellungen über mehrere Regionen oder per Anycast: DNS-01 oder HTTP-01, wobei jeder Knoten /.well-known/acme-challenge/ per Proxy an einen zentralen Responder weiterleitet.
• CDNs und verwaltete Plattformen: Lass die Plattform validieren (meist per HTTP-01 über ihre Edge oder über einen CNAME-Eintrag, den du einmal anlegst).
• Zertifikate für IP-Adressen: HTTP-01 oder TLS-ALPN-01; bei Let's Encrypt nur im sechstägigen Profil shortlived.
• Port 80 per Richtlinie geschlossen: DNS-01 oder TLS-ALPN-01.

Hinweise zur Migration

1. Umstieg von HTTP-01 auf DNS-01: Lege eine eigene Challenge-Zone an, verweise jeden Namen _acme-challenge per CNAME dorthin, gib dem ACME-Client ein auf diese Zone beschränktes Token und stelle den Challenge-Typ des Clients um; bestehende Zertifikate funktionieren weiter.
2. Prüfe die Propagation, bevor du die Challenge beantwortest: Die meisten Clients können warten, bis alle autoritativen Server den Eintrag liefern; aktiviere das statt einer festen Wartezeit.
3. Räum auf: Clients sollten TXT-Einträge nach der Validierung löschen (RFC 8555 §8.4); übrig gebliebene Einträge sammeln sich an und verlangsamen Abfragen.
4. Schränke die Ausstellung per CAA ein, mit accounturi und validationmethods, jeweils für issue und issuewild.
5. Erneuere nach dem Zeitplan der CA: Nutze ACME Renewal Information (ARI, RFC 9773), wo es unterstützt wird, und erneuere sonst nach etwa zwei Dritteln der Laufzeit; der Rechner für Zertifikatslaufzeiten zeigt die Grenzen nach Datum.
6. Beobachte die Ausstellung in den Certificate-Transparency-Logs (Certificate Transparency für Entwickler), damit Zertifikate sichtbar werden, ganz gleich, über welche Methode sie bezogen wurden.

Quellen

• RFC 8555 §8, Challenges zur Validierung von ACME-Identifiern
• RFC 8737, TLS-ALPN-01 und RFC 8738, IP-Adressen als ACME-Identifier
• RFC 8657, CAA-Parameter accounturi und validationmethods
• RFC 7638 §3.1, Beispiel für einen JWK-Thumbprint
• RFC 9773, ACME Renewal Information
• Baseline Requirements des CA/Browser Forum, §3.2.2.4, §3.2.2.9, §4.2.2
• Ballot SC-085v2, DNSSEC-Validierung bei CAA- und DCV-Abfragen
• Let's Encrypt: Challenge-Typen
• Let's Encrypt: DNS-PERSIST-01
• Let's Encrypt: Zertifikatslaufzeiten sinken auf 45 Tage