Let's Encrypt, die weltweit größte Zertifizierungsstelle für kostenlose TLS-Zertifikate, hat kürzlich eine wichtige Änderung bekanntgegeben: Man wird die Nutzung der ausgestellten TLS-Zertifikate für die Client-Authentifizierung in TLS-Verbindungen nicht mehr unterstützen. Diese unmittelbare Konsequenz bedeutet, dass TLS-Zertifikate von Let's Encrypt künftig nicht mehr zur Authentifizierung von Clients gegenüber TLS-Servern dienen können – ein Prozess, der bisher durch die sogenannte Mutual TLS-Authentifizierung (mTLS) möglich war. Diese Entscheidung fällt inmitten eines sich verändernden Zertifizierungsumfelds und wird sowohl von technischen Hintergründen als auch von Veränderungen in Browser-Richtlinien beeinflusst. Die Neuerung birgt weitreichende Folgen für bestimmte Einsatzbereiche von TLS-Client-Zertifikaten und wird in erster Linie durch Anpassungen seitens Googles Chrome Root-Programm getrieben.
Gleichzeitig distanziert sich Let's Encrypt damit von einem weniger genutzten Teil ihres Offerings, der außerhalb des klassischen Webs gelegentlich – wenn auch selten – Anwendung fand. Die Mutual TLS-Authentifizierung erlaubt es, dass nicht nur Server ein Zertifikat präsentieren, sondern auch Clients sich gegenüber Servern mittels eines eigenen Zertifikats ausweisen. Letzteres birgt in der Theorie Vorteile in puncto Sicherheit und Vertrauenswürdigkeit. Praktisch wurden für diese Anwendung jedoch oft spezielle Zertifikate oder private PKIs verwendet. Let’s Encrypt stellte bisher keine Zertifikate mit expliziter Eignung für die Client-Authentifizierung aus, doch die alten Zertifikate enthielten diese Option noch. Durch die Entfernung der Client-Authentifizierungsmarkierung in den von Let's Encrypt ausgestellten Zertifikaten entfällt diese Möglichkeit nun gänzlich. Der unmittelbare Auslöser für diese Änderung liegt in einer Anpassung von Googles Chrome Root-Programm.
Das Chrome-Team verfolgt das Ziel, das öffentliche Web-PKI-Ökosystem sicherer und übersichtlicher zu gestalten. Ein Resultat ist die Entscheidung, dass eine Mehrheit der Root-Zertifizierungsstellen, die bislang viele verschiedene Arten von Zertifikaten ausstellen durften, künftig nur noch serverbasierte TLS-Zertifikate validieren dürfen. Dadurch wird die Klasse von Zertifikaten für Client-Authentifizierung zurückgedrängt oder obsolet gemacht. Interessanterweise gibt es trotz dieser Anpassungen keine verpflichtende Vorgabe durch den CA/Browser-Forum, sondern es handelt sich um eine eigenständige Entscheidung von Chrome. Daher ist die Veränderung zunächst vor allem auf das Verhalten des Browsers und dessen Vertrauensgrundlage ausgerichtet. Die klassische Public Web PKI war bisher ohnehin kaum auf Client-Zertifikate angewiesen.
Die meisten Webdienste nutzen alternativen Ansätze zur Authentifizierung der Benutzer, wie Passwörter oder OAuth-Verfahren, sodass das Fehlen von CA-verifizierten Client-Zertifikaten im Web kaum spürbar sein dürfte. Dennoch gibt es bestimmte Nischenbereiche, in denen Client-Authentifizierungszertifikate in der öffentlichen PKI zum Einsatz kamen. Ein Beispiel hierfür sind SMTP-Verbindungen beim E-Mail-Versand. Dort werden TLS-Verbindungen zwischen Mail-Servern genutzt, um Nachrichten sicher zu übertragen. Einige Mail-Server setzen auf die Möglichkeit, sich gegenseitig mittels TLS-Client-Zertifikaten zu authentifizieren, um Vertrauen zu schaffen oder zusätzlichen Schutz gegen Spam und Phishing zu bieten. Einige wenige Anbieter, darunter auch große E-Mail-Dienste wie Gmail oder Outlook, nutzen bereits TLS-Client-Zertifikate für die Authentifizierung beim Mailversand.
Andere Mailserver wiederum senden zwar TLS-Zertifikate, jedoch oftmals ungültige oder nicht als Client-Authentifizierung zugelassene Zertifikate. Der Wegfall der Client-Authentifizierungsfunktionalität in Let's Encrypt-Zertifikaten schränkt diese Nische weiter ein, da eine wichtige Quelle für gratis, leicht zugängliche TLS-Client-Zertifikate entfällt. Die bisher möglichen Einsatzszenarien im SMTP-Bereich werden dadurch weniger attraktiv. Trotz dieser Einschränkungen ändert sich bei der Zertifizierung und Authentifizierung von Servern, die TLS einsetzen, weder etwas an der Verfügbarkeit von Let's Encrypt-Zertifikaten noch an deren weitverbreiteter Nutzung für Webserver. Serverzertifikate bleiben vollständig erhalten und werden auch weiterhin kostenfrei und automatisiert bereitgestellt. Für Betreiber von Mailservern ist es weiterhin möglich, TLS-Serverzertifikate von Let's Encrypt zu nutzen, etwa um Verbindungen für den Posteingang abzusichern.
Für das Versenden von E-Mails mit öffentlicher TLS-Client-Authentifizierung steht diese Option jedoch nicht mehr zur Verfügung. Es entsteht dadurch eine Lücke, die theoretisch neue Mitbewerber für kostenlose TLS-Client-Zertifikate auf den Plan rufen könnte. Eine solche Möglichkeit bestünde etwa über eine spezialisierte, ACME-kompatible Zertifizierungsstelle, die genau diese Nische abdeckt und entsprechende Zertifikate ausstellt. Bislang ist jedoch unklar, ob ein solches Angebot entsteht oder vom Markt gefordert wird. Für Entwickler und Systemarchitekten, die eigene Systeme mit TLS-Client-Authentifizierung planen, bleibt weiterhin die Option, Zertifikate anderer Aussteller oder private PKIs zu nutzen oder alternativ auch öffentliche TLS-Serverzertifikate als Client-Zertifikate einzusetzen.
Letzteres könnte allerdings erfordern, dass die Zertifikatsprüfung auf Serverseite entsprechend angepasst wird, da die Validierung nicht mehr auf die übliche Client-Authentifizierungsmarkierung abgestützt werden kann. Die Sicherheitsanalyse solcher Eigenlösungen ist jedoch komplex und sollte sorgfältig erfolgen, bevor produktive Systeme entsprechend umgestellt werden. Trotz der vermeintlichen Herausforderungen sind viele Experten der Meinung, dass die Umstellung auf die neue Situation und das Entfernen der Client-Authentifizierungsfunktionalität von Let's Encrypt keine dramatischen Auswirkungen auf den Gesamtverkehr im Internet haben wird. Die breite Mehrheit der Nutzer und Webseiten ist von der Änderung nicht betroffen, da TLS-Client-Zertifikate im öffentlichen Web praktisch kaum verwendet werden.
Die Auswirkungen konzentrieren sich eher auf kleine Nischenbereiche und Spezialanwendungen wie das Zuschalten von TLS-Client-Zertifikaten beim SMTP-Mailversand oder anderen nicht-webbasierten Systemen. Als Konsequenz empfiehlt sich für Betreiber, die TLS-Client-Authentifizierung benötigen, aktiv über Alternativen nachzudenken und zum Beispiel auf Private-PKI-Lösungen oder kommerzielle Anbieter auszuweichen, die diese Funktion noch unterstützen. Insgesamt zeigt die Entscheidung von Let's Encrypt auch die Herausforderungen und Dynamiken, die das PKI-Ökosystem im öffentlichen Internet prägen. Kostenlose Zertifikate und Automatisierung haben das Thema Verschlüsselung für Webseiten revolutioniert, gleichzeitig führen stetige Anpassungen der Browserhersteller und deren Sicherheitsrichtlinien zu Veränderungen in der Art und Weise, wie Zertifikate genutzt werden können.
Es bleibt spannend zu beobachten, wie sich diese Trends auf die Langfristigkeit der Nutzung von TLS-Client-Zertifikaten auswirken und ob alternative Technologien beziehungsweise Verfahren entstehen, die die Anforderungen an eine sichere Client-Authentifizierung im Internet neu definieren. Nutzer und Administratoren sollten die Entwicklung aufmerksam verfolgen und gegebenenfalls rechtzeitig ihre Infrastruktur an die neuen Rahmenbedingungen anpassen, um weiterhin sichere und reibungslose Kommunikationswege zu gewährleisten. In jedem Fall ist es bemerkenswert, dass eine so einflussreiche CA wie Let’s Encrypt diesen Schritt geht und damit ein Signal an die gesamte PKI-Landschaft sendet. Die Veränderungen unterstreichen die Bedeutung von kontinuierlicher Weiterentwicklung und Anpassung in der Sicherheitslandschaft des Internets.
Während es auf den ersten Blick eine Einschränkung darstellt, könnte diese Entscheidung letztlich zu sinnvolleren und gezielteren Lösungen in der Client-Authentifizierung führen und damit langfristig die Sicherheit verbessern.
