Im Zuge der rasanten Weiterentwicklung der Internetsicherheit gibt es immer wieder Anpassungen an bestehenden Standards und Regularien, die besonders Betreiber von Mailservern und anderen Kommunikationsdiensten vor Herausforderungen stellen. Eine jüngst veröffentlichte Ankündigung von LetsEncrypt, dem bislang populärsten Anbieter für kostenfreie TLS-Zertifikate, hat in der Mailserver-Community und darüber hinaus für erheblichen Wirbel gesorgt. Die Entscheidung von LetsEncrypt, ab 2026 keine TLS-Client-Authentifizierungszertifikate mehr auszustellen, folgt einer neuen Richtlinie von Google Chrome, die ein grundlegendes Umdenken für die Authentifizierung von SMTP-Servern bedeutet. Was steckt hinter dem Richtlinienwechsel, welche Folgen hat dies für Betreiber von E-Mail-Infrastrukturen und wie können sie sich auf die Veränderungen vorbereiten? Diese Fragen werden im Folgenden detailliert beleuchtet. LetsEncrypt hat seit seiner Gründung eine Revolution in der Verbreitung von HTTPS und der allgemeinen Verschlüsselung im Internet eingeleitet.
Die Möglichkeit, kostenfreie und automatisierte TLS-Zertifikate zu erhalten, ermöglichte Million von Webseitenbetreibern sowie Dienstanbietern eine starke Absicherung ihrer Kommunikation. Insbesondere für Mailserver war dies ein großer Schritt, da die TLS-Absicherung von SMTP-Verbindungen oft eine hohe Hürde durch Kosten und administrative Komplexität darstellte. Doch mit der Entscheidung, keine Client-Authentifizierungszertifikate mehr auszustellen, verändert sich das Fundament, auf dem viele bestehende SMTP-Authentifizierungsmechanismen basieren. Der Hintergrund für die Umstellung liegt in der Politik von Google Chrome und den Anforderungen an Zertifizierungsstellen (CAs), die ab Juni 2026 nur noch TLS-Zertifikate mit Extended Key Usage (EKU) für die Server-Authentifizierung ausstellen dürfen. Das bedeutet, dass „ClientAuth“ als EKU nicht mehr lang unterstützt wird.
Zertifikate mit dieser Erweiterung werden von Chrome nicht mehr als vertrauenswürdig angesehen. Dies hat deutlichen Einfluss auf die Verwendung von Mutual TLS (mTLS), bei der sich sowohl Client als auch Server gegenseitig per Zertifikat authentifizieren. In der Welt der E-Mail-Kommunikation betrifft dies besonders SMTP-Server, die TLS-Client-Zertifikate für die Authentifizierung bei Verbindungen zwischen Servern oder zu Clients nutzen. Der ursprüngliche Ansatz bei SMTP-TLS-Client-Authentifizierung war eine Art zusätzlicher Schutzmechanismus, der über die einfache Verschlüsselung hinausging und durch gegenseitigen Nachweis der Identität das Vertrauen in den Kommunikationspartner erhöhen sollte. Allerdings war diese Methode nie weitverbreitet oder einheitlich umgesetzt.
Viele Mailserver setzten stattdessen auf Alternativen wie IP-basierte Zugriffsregeln oder Authentifizierungsmechanismen wie SMTP AUTH. Durch die neue CA-Richtlinie und die Abschaffung von ClientAuth-Zertifikaten bei öffentlichen CAs wie LetsEncrypt droht diese Form der Authentifizierung künftig erschwert zu werden oder komplett wegzufallen. Unabhängige Betreiber von Mailservern und föderierten Kommunikationsplattformen, wie zum Beispiel die zahlreichen, oft kleineren und spezialisierten Mastodon-Instanzen, sehen sich dadurch vor neue Hürden gestellt. Nutzer und Administratoren solcher Systeme haben in der Regel weniger Ressourcen als Großanbieter und sind besonders auf flexible und kosteneffiziente Lösungen angewiesen. Für sie war LetsEncrypt eine unverzichtbare Ressource, um den hohen Sicherheitsstandard ohne zusätzliche Kosten aufrechtzuerhalten.
Das Auslaufen der ClientAuth-Unterstützung droht hier zu einem Rückschritt zu führen, der individuelle Betreiber vor schwierige Entscheidungen stellt: eigener Aufbau einer privaten PKI-Infrastruktur, der Einkauf teurer Zertifikate bei kommerziellen Anbietern oder das Umstellen auf andere Authentifizierungsmechanismen. Die Kritik an der Richtlinienänderung ist vielschichtig. Einige Experten und Betreiber werfen Google vor, seine marktbeherrschende Stellung auszunutzen, um indirekt technische Vorgaben durchzusetzen, die nicht zwingend aus Sicherheitsgründen notwendig sind, sondern administrative Vereinfachung bewirken sollen. Die Reduktion von ausgestellten EKUs auf Server-Authentifizierung soll die Komplexität der Vertrauensketten und die Handhabung von Zertifikaten verringern. Gleichzeitig ignoriert diese Maßnahme allerdings legitime Anwendungsfälle, die auf Client-Authentifizierung basieren und für deren sichere Umsetzung der öffentliche PKI-Einsatz bislang ein probates Mittel war.
Es existieren durchaus auch technische Aspekte, die gegen die Nutzung öffentlicher CAs für ClientAuth-Zertifikate sprechen. Weil diese Zertifikate von jedem bezogen werden können, ist der Sicherheitsvorteil gering, wenn die Authentifizierung auf Vertrauen zum Aussteller beruht, anstatt auf einer individuellen Kontrolle der Teilnehmer. Dies führt vielen dazu, für mTLS und andere Client-Authentifizierungen auf private PKI-Systeme umzusteigen. Allerdings sind diese oft technisch anspruchsvoll, kostenintensiv und in der Verwaltung aufwendig, sodass die Umstellung für viele Betreiber eine große Herausforderung darstellt. Zudem bestehen praktische Probleme im Zusammenhang mit Client-Zertifikaten auf Endnutzer-Geräten.
Besonders iOS gilt in der Community als problematisch bei der Handhabung von benutzerdefinierten oder selbstsignierten Client-Zertifikaten. Das bedeutet, dass selbst gut gemeinte Absicherungen durch Client-Zertifikate am Ende durch mangelnde Nutzerfreundlichkeit an Wirkung verlieren. In diesem Kontext stellt der Wegfall von ClientAuth-Zertifikaten durch öffentlich vertrauenswürdige CAs eine zusätzliche Belastung dar, da die Systeme wieder verstärkt auf eigene Lösungen angewiesen sind, die bei nicht-professionellen Anwendern quasi unmöglich zu realisieren sind. Trotz der Bedenken seitens der Community ist die Entscheidung von LetsEncrypt in rechtlicher und technischer Hinsicht nachvollziehbar. Die CA muss den Anforderungen der Browser-Hersteller, besonders Google, entsprechen, um nicht die Vertrauenswürdigkeit ihrer Zertifikate zu gefährden.
Eine Missachtung der Vorgaben droht, dass ausgestellte Zertifikate von Browsern und weiteren Systemen nicht mehr akzeptiert werden. Für eine Organisation, die primär Mittel für den Betrieb und die Absicherung der Web-Ökosysteme bereitstellt, ist dies ein kritisches Risiko. Was bedeutet das konkret für SMTP-Server-Betreiber? Ihre bisherigen Methoden zur Nutzung eines einzigen Zertifikats für Server- und Client-Authentifizierung müssen überdacht werden. Künftig könnte es erforderlich sein, getrennte Zertifikate für ServerAuth und ClientAuth zu verwenden. Da öffentliche CAs wie LetsEncrypt nur noch ServerAuth-Zertifikate ausstellen, bleibt die Option, Client-Zertifikate innerhalb einer eigenen PKI zu verwalten oder bei spezialisierten kommerziellen CAs zu bestellen.
Das erhöht den administrativen Aufwand erheblich und kann Kosten erzeugen, die zuvor entfielen. Für Betreiber kleiner und mittlerer Mailserver kommt erschwerend hinzu, dass viele Nutzer heutzutage zunehmend auf Cloud-basierte Provider zugreifen. Zentralisierte Lösungen bieten einfache Handhabung und hohe Verfügbarkeit, bergen aber Risiken solcher Zentralisierung – zum Beispiel hinsichtlich Datenschutz, Abhängigkeit von US-amerikanischen Firmen und möglicher politischer Einflussnahme. Aufgrund dieser Bedenken wächst weltweit das Interesse daran, eigene Mailserver zu betreiben. Umso ärgerlicher ist es für diese Betreiber, dass die Umstellung bei LetsEncrypt ihre Zertifikatsversorgung erschwert.
Die Diskussion zeigt zudem, dass es Bedarf an alternativen oder ergänzenden Lösungen gibt. Es wird über die Einführung europäischer Zertifizierungsstellen spekuliert, die nicht dem Einfluss US-amerikanischer Politik unterliegen und gegebenenfalls flexiblere Zertifikatsprofile unterstützen könnten. Auch wird verstärkt versucht, standardisierte Profile für unterschiedliche Einsatzzwecke über ACME-Protokolle zu etablieren, um eine einfachere Verwaltung und Zuweisung von Zertifikaten mit verschiedenen EKUs zu ermöglichen. Alternativ setzen manche Betreiber auf bewährte Authentifizierungsmechanismen wie SMTP-AUTH, DKIM, SPF und ARC, die eine zuverlässige Senderüberprüfung gewährleisten. Sie reduzieren so die Abhängigkeit von client-gekoppelten TLS-Zertifikaten.
Zwar bieten diese Verfahren keinen direkten Ersatz für mTLS bei der Server-zu-Server-Kommunikation, doch in der Praxis haben sie sich als robust und durchsetzbar erwiesen. Die Umstellung offenbart auch ein tieferliegendes Problem: Die öffentliche PKI ist nicht ideal für alle Formen der Authentifizierung. Während Zertifikate für Serverauthentifizierung im World Wide Web eine klare Zuordnung und ein verlässliches Vertrauen ermöglichen, sind Client-Zertifikate naturgemäß schwieriger zu verwalten. Ihre Verwendung für Endnutzer-Authentifizierung oder für maschinelle Kommunikation müsste deutlich restriktiver und feiner granuliert geregelt werden. Die Marktmechanismen und Sicherheitsrichtlinien hinken diesem Bedarf hinterher.
Abschließend ist zu sagen, dass die Entscheidung von LetsEncrypt und die Google-Richtlinien den E-Mail-Betrieb vor neue Herausforderungen stellen, aber auch Chancen zur Weiterentwicklung und Professionalisierung eröffnen. Betreiber von SMTP-Servern sollten sich frühzeitig informieren, ihre Infrastruktur prüfen und gegebenenfalls Konzepte für getrennte Zertifikatsvergabe und den Einsatz privater PKIs entwickeln. Gleichzeitig bleibt die Hoffnung, dass zukünftige Standards und Angebote von öffentlichen Zertifizierungsstellen flexibler und anwendungsorientierter werden. Die Community steht vor der Aufgabe, Lösungen für einen sicheren, dezentralen und nutzerfreundlichen E-Mail-Verkehr zu entwickeln – eine Aufgabe, die mit dem Ende der ClientAuth-Zertifikate von LetsEncrypt keineswegs abnimmt, sondern vielmehr an Bedeutung gewinnt.
