ACME-Challenges erklärt: DNS-01, HTTP-01 und TLS-ALPN-01 im Vergleich

Jede ACME-basierte SSL-Verlängerung beginnt mit einer Challenge: dem Nachweis, dass Sie tatsächlich Kontrolle über die Domain besitzen, für die Sie ein Zertifikat beantragen. Der ACME-Standard (RFC 8555) definiert dafür drei Verfahren – HTTP-01, DNS-01 und TLS-ALPN-01. Welche Challenge sich für welche Umgebung eignet, entscheidet maßgeblich über Komplexität und Sicherheit Ihres Setups. Dieser Guide vergleicht die drei Methoden und zeigt, wie sich die DNS-01-Validierung mit dem DCV-Zonen-Konzept besonders sicher umsetzen lässt.

Sie suchen eine fertige Lösung statt Eigenbetrieb?

Werfen Sie einen Blick auf unser automatisiertes Zertifikatsmanagement

LEMARIT Certificate Automation
Inhalte

Was ist eine ACME-Challenge?

Eine ACME-Challenge ist ein vom ACME-Standard definiertes Verfahren, mit dem ein Client gegenüber der Certificate Authority (CA) nachweist, dass er die Kontrolle über die Domain besitzt, für die ein SSL-/TLS-Zertifikat ausgestellt werden soll. Ohne diesen Nachweis stellt keine seriöse CA ein Zertifikat aus – die Challenge ersetzt damit den Validierungsprozess, der bei manuellen Beantragungen aus E-Mail-Bestätigungen, Datei-Uploads oder DNS-Einträgen besteht.

Der ACME-Standard kennt aktuell drei produktiv genutzte Challenge-Typen: HTTP-01, DNS-01 und TLS-ALPN-01. Eine vierte Variante (TLS-SNI-01) wurde aus Sicherheitsgründen abgekündigt und wird nicht mehr unterstützt.

HTTP-01 – die häufigste ACME-Challenge

Wie HTTP-01 funktioniert

Bei HTTP-01 stellt die CA dem Client ein Token zur Verfügung. Der Client legt dieses Token unter einem definierten Pfad auf dem Webserver ab – konkret unter 
http://example.com/.well-known/acme-challenge/{token}
. Die CA ruft anschließend diesen Pfad über Port 80 (HTTP) auf und prüft den Inhalt. Stimmt er, gilt die Challenge als bestanden.

Wann sich HTTP-01 eignet

HTTP-01 ist die einfachste Methode für klassische Webserver, die auf Port 80 erreichbar sind und auf denen der Client direkten Schreibzugriff auf das Webroot hat. Für Single-Server-Setups, kleine Webhosting-Umgebungen und CI/CD-Pipelines mit klarer Webserver-Topologie ist HTTP-01 in der Regel die schnellste Variante.

Vorteile

  • Sehr einfach einzurichten – funktioniert mit nahezu jedem ACME-Client out of the box.
  • Keine Anpassung der DNS-Konfiguration notwendig.
  • Validierung passiert auf demselben Host, der das Zertifikat ausstellt.

Nachteile

  • Port 80 muss aus dem öffentlichen Internet erreichbar sein – in vielen Enterprise-Umgebungen ist genau dieser Port geschlossen oder gehärtet.
  • Funktioniert nicht für Wildcard-Zertifikate (
    *.example.com
    ) – diese sind ausschließlich über DNS-01 möglich.
  • Bei Load-Balancer-Umgebungen mit mehreren Backend-Servern muss das Token konsistent auf allen Knoten verfügbar sein.
  • Probleme mit IP-basierten Firewall-Regeln, weil die validierenden IP-Adressen der CA wechseln können.

DNS-01 – die Enterprise-Challenge

Wie DNS-01 funktioniert

Bei DNS-01 erhält der Client ein Token, das als TXT-Eintrag im DNS publiziert werden muss – unter dem Namen 
_acme-challenge.example.com
. Die CA löst diesen Eintrag anschließend rekursiv über das DNS auf und vergleicht den Wert. Stimmt er, gilt die Challenge als bestanden.

Wann sich DNS-01 eignet

DNS-01 ist die Methode der Wahl für Enterprise-Umgebungen, weil sie unabhängig vom konkreten Web-Endpunkt funktioniert. Sie validiert die Kontrolle über die gesamte Domain – nicht über einen einzelnen Host. Damit funktioniert sie auch für interne Anwendungen, die gar nicht aus dem öffentlichen Internet erreichbar sind, sowie für Wildcard-Zertifikate.

Vorteile

  • Einzige Challenge-Methode, die Wildcard-Zertifikate unterstützt.
  • Funktioniert auch für Server, die aus dem öffentlichen Internet nicht erreichbar sind.
  • Kein offener Port 80 erforderlich – ideal für hardened Enterprise-Setups.
  • Zentralisiert die Validierungslogik im DNS – statt sie auf jedem einzelnen Server zu duplizieren.
  • Erlaubt sauber getrennte Rollen: Webserver-Admin und DNS-Admin können unabhängig arbeiten.

Nachteile

  • Setzt einen Zugriffspfad auf DNS-Updates voraus – sonst keine Automatisierung möglich.
  • DNS-Propagation kann je nach Provider und TTL einige Minuten dauern und Renewals verzögern.
  • Falsch verwaltete API-Tokens für DNS sind ein attraktives Angriffsziel – sauberes Secret-Management ist Pflicht.

Das DCV-Zonen-Konzept – Sicherheits-Architektur für DNS-01

Eine elegante Lösung für das Sicherheitsproblem rund um DNS-API-Tokens ist die CNAME-Delegation, in der LEMARIT-Terminologie als DCV-Zonen-Konzept bezeichnet. Statt dem ACME-Client Schreibrechte auf Ihre produktive DNS-Zone zu geben, setzen Sie einmalig einen CNAME-Eintrag vom

_acme-challenge

-Subnamespace Ihrer Domain auf einen dedizierten Validierungs-Namespace. Alle ACME-Validierungs-Einträge werden dann ausschließlich dort gesetzt – Ihre eigentliche DNS-Zone wird über die ACME-Schnittstelle nie schreibend angefasst.

Die Konsequenzen für die Sicherheit sind erheblich: Selbst bei einem kompromittierten API-Token oder TSIG-Key kann ein Angreifer maximal Einträge im Delegations-Namespace setzen, nicht aber Ihre Hauptzone manipulieren. DNSSEC-Signaturen, MX-Records, SPF, DKIM und sonstige produktive DNS-Records bleiben architektonisch unerreichbar. Diese Architektur ist Voraussetzung für jede Zertifikatsautomatisierung in regulierten Branchen.

Wie wird der DCV-TXT-Eintrag gesetzt?

Für das Setzen der 
_acme-challenge
-TXT-Einträge stehen typischerweise drei Wege offen:
  • DNS-Provider-API: Der ACME-Client spricht direkt mit der API Ihres DNS-Anbieters (AWS Route 53, Cloudflare DNS, Azure DNS, Google Cloud DNS, Hetzner DNS, DigitalOcean, OVH, Gandi etc.). Voraussetzung: API-Token mit ausreichend granularer Rechtevergabe.
  • RFC 2136 mit TSIG: Klassisches Dynamic DNS Update für on-premise BIND-Setups und Enterprise-DNS-Infrastrukturen. Die Authentifizierung erfolgt über TSIG-Keys mit modernen Algorithmen (HMAC-SHA256, HMAC-SHA512).
  • Plattform-Schnittstellen: Spezialisierte Zertifikatsautomatisierungs-Plattformen wie LEMARIT Certificate Automation bieten eigene REST-API- und RFC-2136-Endpunkte, die das DCV-Zonen-Konzept architektonisch erzwingen und damit das Sicherheitsmodell auf der Plattform-Ebene umsetzen.

Eine ausführliche Bewertung der CA-Auswahl und der Plattform-Optionen: ACME-Anbieter im Vergleich.

TLS-ALPN-01 – die Spezialisten-Challenge

Wie TLS-ALPN-01 funktioniert

TLS-ALPN-01 nutzt die Application-Layer Protocol Negotiation (ALPN) während des TLS-Handshakes auf Port 443. Der Client beantwortet eine spezielle ALPN-Anfrage der CA mit einem berechneten Zertifikat. Die CA prüft den Handshake direkt – ohne über HTTP zu gehen oder DNS-Einträge zu lesen.

Wann sich TLS-ALPN-01 eignet

TLS-ALPN-01 ist die richtige Wahl, wenn Port 80 nicht verfügbar ist (z. B. weil HTTP komplett deaktiviert wurde) und gleichzeitig kein DNS-API-Zugriff besteht. In der Praxis trifft das auf Edge-Devices, IoT-Gateways und manche hochgehärtete Reverse-Proxy-Setups zu.

Vorteile

  • Funktioniert vollständig über Port 443 – keine zusätzlichen Ports notwendig.
  • Sehr nah an der eigentlichen TLS-Implementierung – kaum zusätzliche Angriffsfläche.
  • Ideal für Reverse Proxies wie Caddy oder Traefik, die ALPN nativ unterstützen.

Nachteile

  • Wird von weniger ACME-Clients unterstützt als HTTP-01 oder DNS-01.
  • Nicht für Wildcard-Zertifikate geeignet.
  • Erfordert, dass der Client die ALPN-Antwort kontrolliert – nicht überall möglich.
  • In klassischen Apache-/Nginx-Setups oft nicht ohne Zusatzaufwand nutzbar.
SSL-Zertifikate automatisch verlängern

Vergleichstabelle aller ACME-Challenges

Kriterium

Validierung über

Wildcard-Zertifikate

Interne Hosts möglich

Setup-Komplexität

Voraussetzung

Best Fit

Empfohlene Skalierung

HTTP-01

Port 80 (HTTP)
nein
nein
niedrig
Webroot-Zugriff
Single-Webserver
klein bis mittel

DNS-01

DNS-TXT-Eintrag

ja

ja

mittel

DNS-Update-Pfad

Enterprise/Wildcard

mittel bis groß

Manuell

Port 443 (TLS-ALPN)

nein

nein

mittel bis hch

TLS-Stack-Kontrolle
Edge/Reverse Proxy
spezielle Setups

Welche ACME-Challenge ist die richtige für mein Setup?

Die Wahl der Challenge ist weniger Geschmackssache als oft angenommen – sie ergibt sich aus drei Fragen:

Frage 1: Brauche ich Wildcard-Zertifikate?
Ja → DNS-01 ist die einzige Option.
Nein → weiter zu Frage 2.

Frage 2: Sind die zu validierenden Hosts aus dem öffentlichen Internet erreichbar?
Nein → DNS-01 ist die einzige Option.
Ja → weiter zu Frage 3.

Frage 3: Ist Port 80 in der Umgebung offen und nutzbar?
Ja → HTTP-01 ist die schnellste und einfachste Wahl.
Nein → TLS-ALPN-01 oder DNS-01, je nach Reverse-Proxy- und DNS-Setup.

In Enterprise-Umgebungen gewinnt diese Logik in über 80 Prozent der Fälle DNS-01 – aus Sicherheitsgründen, Wildcard-Anforderungen oder schlicht, weil interne Anwendungen ebenfalls Zertifikate brauchen.

Sicherheitsaspekte: Was bei ACME-Challenges schiefgehen kann

Jede Challenge-Methode hat eigene Bedrohungsvektoren, die Sie kennen sollten:
HTTP-01: Wenn ein Angreifer Schreibzugriff auf das Webroot bekommt, kann er Zertifikate für Ihre Domain ausstellen lassen. CAA-Records im DNS schränken ein, welche CAs überhaupt Zertifikate ausstellen dürfen – ein Pflichtbaustein. DNS-01: Die API-Tokens des DNS-Providers oder TSIG-Keys für RFC 2136 sind das kritische Element. Sie sollten ausschließlich Schreibrechte für den 
_acme-challenge
-Sub-Namespace haben – nicht für die gesamte Zone. Genau das leistet das oben beschriebene DCV-Zonen-Konzept architektonisch. TLS-ALPN-01: Da die Validierung im TLS-Stack passiert, sind Fehler in der ALPN-Implementierung kritisch. Veraltete oder unmaintained Implementierungen sollten vermieden werden.

Übergreifend gilt: CAA-Records (Certification Authority Authorization) gehören in jede ernsthafte ACME-Umgebung. Sie schränken ein, welche Certificate Authorities überhaupt für Ihre Domain Zertifikate ausstellen dürfen – ein massiver Sicherheitsgewinn mit nur einer DNS-Zeile pro Domain.

ACME-Challenges in Enterprise-Umgebungen – warum DNS-01 dominiert

In den von uns betreuten Enterprise-Umgebungen läuft fast jede Validierung über DNS-01. Die Gründe sind betrieblicher Natur. Erstens: Wildcard-Zertifikate sind in heterogenen Microservice-Umgebungen ökonomisch deutlich attraktiver als Hunderte einzelner SAN-Zertifikate. Zweitens: Viele kritische Anwendungen sind aus dem öffentlichen Internet nicht erreichbar – HTTP-01 scheidet damit komplett aus. Drittens: Die saubere Rollen-Trennung zwischen DNS-Admin und Webserver-Admin entspricht der Realität in regulierten Branchen.

Die operative Herausforderung verlagert sich damit allerdings auf das DNS: DNS-Update-Pfade müssen abgesichert, Token rotiert, Propagation berücksichtigt und CAA-Records konsistent gepflegt werden. Genau hier setzt LEMARIT Certificate Automation an: Die Plattform bietet vier Integrations-Modelle (ACME direkt, REST-API, LEMARIT als DNS-Provider mit externer CA, oder reine DCV-Übernahme) und implementiert das DCV-Zonen-Konzept architektonisch – die Kundendomäne bleibt für Validierungs-Updates strukturell unzugänglich. Eine ausführliche Beschreibung der Plattform finden Sie auf unserer Produktseite.

LEMARIT Certificate Automation

Häufige Fragen (FAQ) zu ACME-Challenges

Was ist eine ACME-Challenge?

Eine ACME-Challenge ist ein im RFC 8555 standardisiertes Verfahren, mit dem ein Client gegenüber der Certificate Authority die Kontrolle über eine Domain nachweist. Erst nach erfolgreicher Challenge stellt die CA ein SSL-/TLS-Zertifikat aus. Der ACME-Standard kennt drei produktive Challenge-Typen: HTTP-01, DNS-01 und TLS-ALPN-01.
HTTP-01 validiert über eine Token-Datei auf dem Webserver (Port 80), DNS-01 validiert über einen TXT-Eintrag im DNS. HTTP-01 ist einfacher einzurichten, funktioniert aber nicht für Wildcard-Zertifikate und nicht für interne Server. DNS-01 ist flexibler und Enterprise-tauglich, setzt aber einen Zugriffspfad auf DNS-Updates voraus.
Wildcard-Zertifikate wie 
*.example.com
können ausschließlich über DNS-01 validiert werden. Weder HTTP-01 noch TLS-ALPN-01 unterstützen Wildcards – das ist eine bewusste Festlegung im ACME-Standard.
Praktisch alle namhaften DNS-Anbieter bieten inzwischen ACME-kompatible APIs an. Zu den am häufigsten genutzten gehören AWS Route 53, Cloudflare DNS, Azure DNS, Google Cloud DNS, Hetzner DNS, DigitalOcean, OVH und Gandi. Für on-premise BIND-Setups ist die Validierung über RFC 2136 mit TSIG-Authentifizierung etabliert. Entscheidend ist in allen Fällen die Granularität der Schreibrechte – idealerweise nur auf den 
_acme-challenge
-Namespace.

Das DCV-Zonen-Konzept (auch CNAME-Delegation) ist eine Sicherheits-Architektur für DNS-01 und verwandte Validierungs-Verfahren: Statt dem Vaidierungs-Client Schreibrechte auf Ihre produktive DNS-Zone zu geben, werden die Validierungs-Subnamespaces per CNAME-Eintrag auf einen dedizierten Validierungs-NAmespace umgeleitet. Pro Partner-CA wird ein eigener CNAME benötigt, weil die Prefixes CA-spezifisch sind –

_acme-challenge

bei ACME, – _dnsauth bei DigiCert, dynamisch bei Sectigo. Alle Validierungs-Updates passieren auf dem Delegations-Namespace, Ihre Hauptzone bleibt strukturell unerreichbar. LEMARIT Certificate Automation setzt dieses Konzept architektonisch um – liegt Ihre DNS-Zone bei LEMARIT, automatisiert die LEMARIT.app das CNAME-Setup vollständig und entfernt nicht mehr benötigte Einträge auch wieder. Bei externer DNS-Hostung erhalten Sie die nötigen Einträge im Onboarding.

Beide Methoden sind bei korrekter Implementierung sicher. DNS-01 hat in Enterprise-Umgebungen Sicherheitsvorteile, weil Port 80 nicht offen sein muss und interne Hosts nicht aus dem öffentlichen Internet erreichbar sein müssen. Der Schutz der DNS-Schreibrechte ist dabei kritisch und sollte über Vault-Lösungen oder ein DCV-Zonen-Konzept architektonisch eingeschränkt werden.
TLS-ALPN-01 validiert über einen speziellen ALPN-Handshake auf Port 443. Es eignet sich, wenn weder Port 80 noch eine DNS-Update-Schnittstelle zur Verfügung stehen – typischerweise in Edge-Devices, IoT-Gateways oder bei gehärteten Reverse-Proxy-Setups mit Caddy oder Traefik. In Standard-Enterprise-Umgebungen ist es selten die erste Wahl.
CAA-Records (Certification Authority Authorization) sind DNS-Einträge, die festlegen, welche Certificate Authorities überhaupt Zertifikate für Ihre Domain ausstellen dürfen. Sie sind ein wichtiges Sicherheits-Element gegen unautorisierte Zertifikatsausstellung und sollten in jeder ernsthaften ACME-Umgebung gesetzt sein. Der Aufwand ist minimal, der Sicherheitsgewinn erheblich.
Ja. Viele Enterprise-Setups nutzen DNS-01 als Standard und HTTP-01 als Fallback – oder umgekehrt. Die meisten produktiven ACME-Clients unterstützen Multi-Challenge-Strategien. In der Praxis empfehlen wir, eine primäre Methode festzulegen und Fallbacks nur dort einzurichten, wo sie nachweislich gebraucht werden.

Vom Verstehen zur Implementierung

Welche Challenge Sie wählen, ist nur die halbe Miete. Die andere Hälfte ist der reibungslose Betrieb über Hunderte oder Tausende Zertifikate hinweg – inklusive Token-Rotation, DNS-Konsistenz, CAA-Pflege und Audit-Trail.
LEMARIT Certificate Automation übernimmt diese Komplexität als Zertifikatsautomatisierungs-Plattform – mit vier Integrations-Modellen (ACME, REST-API, LEMARIT als DNS-Provider mit externer CA, oder reine DCV-Übernahme) und dem DCV-Zonen-Konzept als architektonisches Sicherheits-Fundament.
LEMARIT Certificate Automation ansehen
LEMARIT Büro in Harrislee – Arbeitsumgebung

Weiterführende Inhalte

SSL-Zertifikate automatisch verlängern

ACME-Anbieter im Vergleich: Let’s Encrypt, SSL.com, Cloudflare & Co.

Die wichtigsten ACME-Clients im Überblick

ACME einrichten: Schritt-für-Schritt-Anleitung

Close
Suchen