Stell dir vor, es ist Freitagabend, 21:00 Uhr. Du hast gerade die Migration deines Load Balancers abgeschlossen. Alles sieht gut aus, die Konfiguration ist geladen, doch plötzlich schlagen die Zertifikatserneuerungen fehl. Deine Logs füllen sich mit der Fehlermeldung Let's Encrypt ACME: Could Not Find Solver For: TLS-ALPN-01 und die Browser deiner Kunden zeigen bald nur noch Sicherheitswarnungen an. Ich habe dieses Szenario bei Dutzenden von Unternehmen miterlebt, von kleinen Startups bis hin zu mittelständischen Hostern. Meistens passiert das, weil jemand dachte, er könne den TLS-ALPN-01-Challenge-Typ einfach "mitnehmen", ohne zu verstehen, wie tief dieser in die Protokollschicht deines Webservers eingreift. Ein solcher Fehler kostet dich nicht nur Nerven, sondern im schlimmsten Fall Stunden an Downtime, während dein Team hektisch in Foren nach Lösungen sucht, die nicht zu eurer Infrastruktur passen.
Der fatale Irrglaube an die Universalität von TLS-ALPN-01
Viele Administratoren wählen TLS-ALPN-01, weil sie keine Lust auf HTTP-Challenges über Port 80 haben oder DNS-Einträge nicht automatisiert ändern können. Sie gehen davon aus, dass jeder moderne ACME-Client dieses Protokoll beherrscht. Das ist ein Irrtum. Wenn du Traefik, Caddy oder Nginx mit speziellen Modulen einsetzt, funktioniert das oft wunderbar. Sobald du aber versuchst, diesen Prozess auf einen Standard-Certbot oder einen Client umzubiegen, der die ALPN-Verhandlung nicht direkt im TLS-Handshake abfangen kann, stehst du vor einer Mauer.
Das Problem ist technischer Natur: Bei TLS-ALPN-01 muss der Server während des Handshakes eine spezielle Kennung (acme-tls/1) erkennen und darauf mit einem temporären, selbstsignierten Zertifikat antworten. Wenn dein ACME-Client nicht tief genug in den Webserver integriert ist oder ein externer Proxy die ALPN-Header filtert, wird die Validierung niemals klappen. Wer hier blindlings auf Tools setzt, die das Feature nur auf dem Papier unterstützen, verbrennt Zeit. In der Praxis bedeutet das oft 4 bis 5 Stunden Fehlersuche, nur um am Ende festzustellen, dass die Architektur diesen Solver schlichtweg nicht zulässt.
Die Fehlkonfiguration hinter dem Proxy
Ein Klassiker in meiner Laufbahn: Ein Unternehmen nutzt einen Cloud-Provider-Load-Balancer vor seinen eigentlichen Knoten. Der Load Balancer terminiert TLS und leitet den Traffic weiter. Der Admin auf dem Knoten installiert einen Client und wundert sich über Let's Encrypt ACME: Could Not Find Solver For: TLS-ALPN-01 in den Ausgaben. Das kann nicht funktionieren. Der Load Balancer müsste die ALPN-Anfrage verstehen und an den Client durchreichen oder selbst den Solver bereitstellen. Da die meisten Standard-Load-Balancer der großen Cloud-Anbieter für TLS-ALPN-01 nicht transparent genug sind, ist das Vorhaben von vornherein zum Scheitern verurteilt.
Let's Encrypt ACME: Could Not Find Solver For: TLS-ALPN-01 und die falsche Client-Wahl
Ein häufiger Fehler ist der Versuch, TLS-ALPN-01 mit einem Client zu erzwingen, der gar nicht als eigenständiger Server agieren kann oder keinen Zugriff auf den TLS-Stack hat. Certbot zum Beispiel unterstützt TLS-ALPN-01 standardmäßig nicht direkt über einen "Standalone"-Modus wie bei HTTP-01. Wer hier stundenlang versucht, Parameter zu verbiegen, verliert den Fokus.
Ich habe Projekte gesehen, bei denen Entwickler zwei Tage lang versucht haben, TLS-ALPN-01 in einer Apache-Umgebung zum Laufen zu bringen. Apache hat nativ keine saubere Möglichkeit, den ACME-Solver für ALPN während des Handshakes dynamisch einzubinden, ohne den gesamten Dienst zu unterbrechen oder komplexe Patches zu verwenden. Hier ist die Lösung simpel, aber schmerzhaft für die eigene Planung: Wechsle den Challenge-Typ. Wenn dein Setup nicht explizit für ALPN gebaut ist (wie es bei Traefik der Fall ist), dann ist HTTP-01 oder DNS-01 fast immer die wirtschaftlichere Wahl. Zeit ist Geld, und die Eitelkeit, unbedingt den "modernsten" Challenge-Typ nutzen zu wollen, zahlt keine Rechnungen.
Warum Port 443 nicht gleich Port 443 ist
Ein weit verbreitetes Missverständnis besagt, dass TLS-ALPN-01 die beste Wahl ist, weil nur Port 443 offen sein muss. Das klingt sicherheitsrelevant und sauber. Doch in der Realität blockieren viele Firewalls oder Intrusion Detection Systeme (IDS) Pakete, die ungewöhnliche ALPN-Identifier enthalten. Wenn deine Sicherheitsabteilung eine Deep Packet Inspection (DPI) fährt, wird der ACME-Versuch oft als Protokoll-Anomalie eingestuft und verworfen.
In einem Fall bei einem Finanzdienstleister führte das dazu, dass die Zertifikate nachts abliefen, weil die neue Firewall-Regel zwar Port 443 erlaubte, aber den speziellen ALPN-Handshake von Let's Encrypt blockierte. Der Fehler trat erst bei der ersten automatischen Erneuerung auf. Hätte man auf HTTP-01 gesetzt, wäre das Problem sofort bei der Einrichtung aufgefallen. Wer auf TLS-ALPN-01 setzt, muss die gesamte Kette vom Internet bis zum Prozess auf dem Server kontrollieren können. Kannst du das nicht, lässt du die Finger davon.
Vorher-Nachher-Vergleich: Ein Realitätsbericht aus der Infrastruktur-Hölle
Schauen wir uns an, wie ein typischer Prozess aussieht, wenn man falsch startet und wie er aussieht, wenn man pragmatisch korrigiert.
Vorher: Ein Team möchte eine Kubernetes-Umgebung absichern. Sie entscheiden sich für einen spezialisierten Ingress-Controller und wollen TLS-ALPN-01 nutzen, weil Port 80 aus "Sicherheitsgründen" in der Firmenpolicy gesperrt ist. Sie verbringen drei Tage damit, Fehlermeldungen zu analysieren. Sie finden heraus, dass ihr Cloud-Load-Balancer die ALPN-Header strippt. Sie versuchen, den Load Balancer auf Layer 4 (TCP-Passthrough) umzustellen, was aber das interne Monitoring und die IP-Logging-Funktionen bricht. Am Ende haben sie eine instabile Netzwerkarchitektur, nur um diesen einen Challenge-Typ zu erzwingen. Die Kosten: Drei Manntage hochbezahlter Engineers und eine unzuverlässige Protokollierung.
Nachher: Nach einer kurzen Beratung wird der Fokus verschoben. Anstatt gegen die Infrastruktur zu kämpfen, wird Port 80 für die ACME-Validierung auf dem Ingress-Controller kurzzeitig freigegeben – nur für die Well-Known-Pfade. Alternativ wird auf DNS-01 umgestellt, da der Provider eine API anbietet. Innerhalb von zwei Stunden sind alle Zertifikate ausgestellt. Die Firewall bleibt für normalen Web-Traffic auf Port 80 zu, nur die spezifische Validierung darf durch. Das Ergebnis ist ein stabiles, standardkonformes System, das keine Sonderlocken benötigt.
Dieser Vergleich zeigt deutlich: Der technische Stolz, eine vermeintlich "elegantere" Lösung wie TLS-ALPN-01 zu nutzen, steht oft im krassen Gegensatz zur betrieblichen Stabilität.
Die versteckten Kosten von Layer-7-Filtern
Wenn du in einer deutschen Unternehmensumgebung arbeitest, hast du es oft mit Proxys wie Sophos, Blue Coat oder ähnlichen Gateways zu tun. Diese Geräte fungieren als Man-in-the-Middle für den ausgehenden und manchmal auch eingehenden Traffic. TLS-ALPN-01 bricht hier fast immer. Da der Solver ein Zertifikat präsentiert, das nicht zur eigentlichen Domain passt (da es nur für die Validierung generiert wurde), schlagen die Sicherheitsmechanismen der Proxys an.
Ich habe erlebt, wie Administratoren versuchten, Ausnahmeregeln für diese Pakete zu definieren. Das Ergebnis war ein Flickenteppich an Firewall-Regeln, der nach dem nächsten Firmware-Update des Gateways wieder in sich zusammenfiel. Wenn du nicht derjenige bist, der die Hoheit über diese Hardware hat, ist jeder Versuch, den Solver für ALPN zum Laufen zu bringen, eine Verschwendung von Ressourcen. Wer hier klug ist, schwenkt sofort auf DNS-Validierung um. Das kostet zwar die Einrichtung eines API-Keys für den DNS-Provider, spart aber Wochen an Support-Tickets bei der Netzwerkabteilung.
Die Architektur-Falle: Shared IP und Virtual Hosting
Ein oft übersehener Grund für das Scheitern dieses Ansatzes ist das klassische Virtual Hosting auf einer einzigen IP-Adresse. Wenn mehrere Dienste auf derselben IP auf Port 443 lauschen und unterschiedliche ACME-Clients nutzen, entsteht Chaos. Nur ein Prozess kann den Port 443 binden oder den TLS-Handshake verarbeiten.
In meiner Praxis führte das oft dazu, dass der erste Dienst erfolgreich validiert wurde, während alle anderen mit Fehlern abbrachen. Die Lösung ist hier meist ein zentraler Reverse Proxy, der die Zertifikatsverwaltung übernimmt. Aber Achtung: Dieser Proxy muss dann zwingend die ALPN-Logik beherrschen. Nginx kann das zum Beispiel über das stream-Modul und ssl_preread, aber das Setup ist komplex und fehleranfällig. Wer das tut, muss genau wissen, wie der server_name im TLS-Handshake (SNI) mit der ALPN-Erweiterung korreliert. Für die meisten Standardanwendungen ist dieser Aufwand schlicht nicht gerechtfertigt.
Fehlende Berechtigungen und System-Restriktionen
In hochsicheren Umgebungen darf der Webserver-Prozess oft nicht an Ports unter 1024 binden oder hat keinen Zugriff auf die notwendigen Bibliotheken, um Zertifikate on-the-fly zu generieren. TLS-ALPN-01 erfordert jedoch genau das: Eine sehr enge Kopplung zwischen dem ACME-Client und dem TLS-Terminator.
Wenn du versuchst, einen externen Client in einem separaten Container oder als unprivilegierten Nutzer laufen zu lassen, wird er den Port 443 niemals rechtzeitig für die Challenge übernehmen können, ohne den echten Webserver zu stoppen. Downtime während der Validierung ist jedoch für 99% aller Unternehmen inakzeptabel. Wer also nicht auf spezialisierte Lösungen wie Caddy setzt, die genau dafür gebaut wurden, läuft in eine Sackgasse. Das ist kein Mangel an Kompetenz, sondern ein strukturelles Problem der gewählten Software-Kombination.
Der Realitätscheck für deine TLS-Strategie
Kommen wir zum Punkt: Wenn du vor der Meldung sitzt, dass kein Solver gefunden wurde, dann ist das ein klares Zeichen deines Systems, dass deine aktuelle Architektur nicht für TLS-ALPN-01 geeignet ist. Es gibt keine magische Konfigurationszeile, die das Problem löst, wenn dein Load Balancer oder dein ACME-Client die ALPN-Verhandlung nicht beherrscht.
In der echten Welt gewinnt die einfachste Lösung, die stabil läuft. Wenn du nicht gerade ein riesiges CDN betreibst oder Traefik als nativen Ingress-Controller nutzt, ist TLS-ALPN-01 oft mehr Last als Nutzen. In 9 von 10 Fällen ist der Wechsel auf HTTP-01 (über Port 80) oder DNS-01 (über API) die einzig richtige Entscheidung. Ersteres ist simpel und bewährt, letzteres funktioniert sogar für interne Systeme ohne Internet-Anbindung von außen.
Hör auf, Zeit in ein sterbendes Pferd zu investieren. Wenn der Solver nicht gefunden wird und du nicht innerhalb von 30 Minuten verstehst, warum dein TLS-Stack die acme-tls/1-Anfrage verschluckt, dann brich das Experiment ab. Deine Aufgabe ist es, sichere Verbindungen bereitzustellen, nicht die Tiefen der TLS-Protokoll-Erweiterungen zu erforschen, während dein Service offline ist. Wer Erfolg haben will, baut Systeme, die vorhersehbar reagieren – und TLS-ALPN-01 ist in heterogenen Umgebungen alles andere als vorhersehbar.
Manchmal ist der "härtere" Weg – das Einrichten von DNS-API-Zugriffen oder das Öffnen von Port 80 für einen Bruchteil einer Sekunde – der eigentlich professionellere Pfad, weil er langfristig wartbar bleibt. Alles andere ist technisches Basteln auf Kosten der Zuverlässigkeit.
