Der Weg zur digitalen Souveränität besteht aus vielen Schritten. Einige davon sind beschwerlich, aber einige sind auch erstaunlich einfach. So der Wechsel zu den für sichere Kommunikation notwendigen TLS-Zertifikaten, wie sie z.B. für HTTPS eingesetzt werden. Schritte zur Unabhängigkeit von den USA und ihren kurzfristigen Zoll- und Sanktionsaktivitäten sind gerade auch nach der weiteren Verschärfung der ICC-Sanktionen vor einigen Tagen hoffentlich in jeder Teppichetage gerade ein Thema. Und bei Zertifikaten sind die Schritte in die digitale Unabhängigkeit fast identisch mit Schritten, die sowieso anstehen sollten. Phuh!
Inhalte
ToggleWenn man die Wichtigkeit der Zertifikate in einem Satz zusammenfassen wollte, wahrscheinlich mit folgendem:
Ohne Zertifikate keine Verschlüsselung; und ohne Verschlüsselung im Internet keine IT-Sicherheit und kein Datenschutz.
Auch wenn es Wege gibt, Zertifikate zu vermeiden: Ihre zentrale Schlüsselfunktion für ein sicheres Internet ist unbestritten. Und doch werden fast alle Zertifikate für CH-Domains aus den USA ausgestellt. Die USA, deren Präsident Trump schon mal einem Land androht, «alle Deals» mit ihm einzustellen, wenn sie ihm nicht sofort gehorchten oder sich in die Souveränität der Schweiz einmischt, indem er verlangt, dass die Schweiz keine Steuern auf Digitaldienste erhebe oder sich den laxen Datenschutz-Standards der USA annähern solle. Oder aber gezielt einzelne Personen und unliebsame Organisationen auf Sanktionslisten gesetzt oder wegen Sicherheitsbedenken von bestimmten Diensten ausgeschlossen. Manchmal scheinbar einfach, weil der Präsident mit dem falschen Bein aufgestanden ist.
Schlussfolgerung: Ohne souveräne Zertifikate keine souveränen Internetdienste.
Es ist also nicht auszuschliessen, dass Drohungen, Sanktionen oder sonstige Restriktionen rund um Zertifikatsdienste irgendwann plötzlich Realität werden könnten. Darauf sollte man vorbereitet sein. Zum Glück gibt es Alternativen mit einfachen Umstiegsmöglichkeiten.
Viel, viel einfacher, als die ganze Verwandtschaft von WhatsApp auf Threema (oder auch nur Signal) umzustellen. Also packen wir’s an!
Das Wichtigste in Kürze
- Ohne Zertifikate kein Internet
- Aktuell besteht bei Zertifikaten eine sehr hohe Abhängigkeit von den USA
- Automatische Zertifikatserstellung und -update mittels ACME ist wichtig, sowohl wegen den kürzer werdenden Zertifikatslaufzeiten als auch um Lock-In- und Souveränitäts-Risiken zu reduzieren
- Ein Wechsel ist wichtig und zukunftssicher, meist einfach
- Jetzt loslegen mit den untenstehenden Tipps
- Der Wechsel bietet neben der Souveränität auch weitere Vorteile wie Aufwandsersparnis, Automatisierung und höhere Zuverlässigkeit
Wieso sind Zertifikate so wichtig?
Wer eine Webseite abruft, eine Online-Bestellung aufgibt, Software herunterlädt oder sich von einem Chatbot beraten lässt, macht das heute meist über eine verschlüsselte Verbindung, über das HTTPS-Protokoll. Damit kann weder der Betreiberin des WLAN-Access-Points noch der Mobil- oder Internet-Provider sehen, welche Informationen mit der Gegenstelle ausgetauscht werden; Passwörter und persönliche Daten sind vor diesen Mittelsmännern sicher.
Die Verbindung ist nicht nur verschlüsselt, sondern auch noch authentisiert und integritätsgeschützt. Das bedeutet, wenn ihr eine Seite von DNIP.ch abruft, wisst ihr, dass ihr wirklich mit DNIP.ch sprecht und die Daten zwischendurch nicht verändert wurden. Bei einer Webseite klingt das scheinbar zuerst einmal harmlos. Offensichtlich wird das Problem aber bei einem Software-Download: Da wollt ihr die gewünschte Software installieren und nicht eine bösärtige Variante davon auf euren Rechner loslassen.
Woher aber weiss euer Rechner oder Handy, dass es mit der richtigen Gegenstelle verbunden ist, in unserem Beispiel dem Server für DNIP.ch? Dazu präsentiert der DNIP-Webserver beim Verbindungsaufbau ein Zertifikat, in dem drin steht, dass er auch wirklich DNIP.ch sei. Diese Zertifikate wiederum werden von Zertifizierungsstellen (Certificate Authority, CA; analog einem Notariat) ausgestellt. Daran erkennen Browser, dass die Gegegenstelle identifiziert wurde.
Auf vielen Webseiten taucht noch der Begriff «SSL-Zertifikat» auf. SSL (Secure Sockets Layer) war der Vorgänger von TLS (Transport Layer Security). Alle SSL-Versionen gelten seit spätestens 2015 als unsicher und sollten nicht mehr verwendet werden. Wer heute Webseiten, Mails und vieles andere mehr sicher übers Internet abruft, nutzt TLS, nicht SSL. Damit ist der SSL-Begriff seit über 10 Jahren falsch und sollte nicht mehr verwendet werden. (Offiziell sind TLS-Zertifikate übrigens ein Spezialfall von X.509-Zertifikaten.)

Kasten: Wie identifizieren CAs die Server?
Klassischerweise identifizierte man sich als Person oder Firma gegenüber der CA mittels Passkopien, Handelsregisterauszügen oder ähnlicher Mechanismen. Dabei zeigt man auch, dass man für die entsprechenden Internet-Domains zuständig ist, z. B. DNIP.ch. Dieser Prozess ist bekannt als Organisational Validation (OV) oder Individual Validation (IV). Danach kann man für beliebige Namen unterhalb dieser Internet-Domains (www.DNIP.ch, mail.DNIP.ch, …) Zertifikate ausstellen. Diese Zertifikate wurden von Hand heruntergeladen und installiert und mussten rechtzeitig vor ihrem Ablauf (typischerweise alle 1-3 Jahre, aktuell alle 200 Tage, ab 2027/2029 alle 100 bzw. 47 Tage) neu generiert, heruntergeladen und installiert werden. Ein aufwändiger Prozess, sowohl für die Administratorin des Servers als auch für die CA; entsprechend war das Ausstellen eines Zertifikats teuer und Verschlüsselung war alles andere als flächendeckend verfügbar.
Moderne Server-Installationen setzen auf möglichst vollständige Automatisierung aller Prozesse, auch in der Zertifikatsvergabe. Über das ACME-Protokoll beispielsweise kann ein Webserver sich bei einer CA melden und ein Zertifikat beantragen oder verlängern. Die CA führt dann – ebenfalls auitomatisiert – verschiedene Tests durch, beispielsweise, ob der anfragende Webserver aus verschiedenen Ecken der Welt dieselben Resultate liefert. Damit kann beispielsweise verhindert werden, dass sich der WLAN-, Mobilfunk- oder Internetprovider von Nutzer:innen sich als «Man/Machine/Monster in the Middle» (MITM) in den Verkehr einmischt und Inhalte mithört oder Daten verändert.
Diese sogenannte Domain Validation (DV) ist zwar etwas schwächer als OV/IV oben. Doch durch die Automatisierung werden menschliche Fehler reduziert und als Folge der flächendeckenden Nutzung steigt der Nutzen für die Gesamtgesellschaft stark.
Die Nutzung von IV/OV-Zertifikaten (oder gar den besonders teuren EV-Zertifikaten) bringt heutzutage eigentlich keine Vorteile mehr, da Webbrowser (und damit die Nutzerschaft) den Unterschied zwischen den verwendeten Zertifikaten nicht prominent anzeigen. (Wer für seine eigene Applikation sicherstellen will, dass sie mit dem eigenen Server spricht, sollte Public Key Pinning einsetzen.)
Zertifikatsstellen für automatische Zertifikatserstellung
ACME (Automatic Certificate Management Environment) ist das Standardprotokoll für automatische Zertifikatsverwaltung. Wenn Souveränität das Ziel sein soll, dann sollte man auch auf einen offenen Standard setzen, damit man sich nicht in einen erneuten Lock-In begibt. Denn nur so hat man die Chance, den Anbieter einfach zu wechseln, sollten die Vertragsbedingungen nicht mehr passen.
Aktuell sind in Browsern rund 60 verschiedene CAs als vertrauenswürdig konfiguriert. Doch welche davon unterstützen ACME und sind für eine souveräne Lösung interessant? Dazu hier ein Überblick über einige relevante Anbieter von TLS-Zertifikaten und ihre Eigenschaften:
1. Let’s Encrypt: Wer als Firma mehr als die grosszügigen Standard-Gratis-Limiten nutzen will, wird um finanzielle Unterstützung gebeten (für eine Non-Profit-Organisation konnte ich deren Limiten kostenfrei mit einfacher Begründung erhöhen).
2. ZeroSSL: ZeroSSL.com ist laut Webseite und Nachfragen bei der Pressestelle eine 100%ige Tochter von „HID Global Corporation“, obwohl laut Creditreform Assa Abloy direkt 100%ige Anteilseignerin von ZeroSSL sei.
3. Actalis: Benötigt kostenloses Konto
4. GTS: Funktioniert scheinbar auch mit Servern und Diensten, die nicht in der Google Cloud stehen; benötigt ein Google-Cloud-Konto
5. GoDaddy: Viel Handarbeit für jedes Zertifikat notwendig
6. Sectigo etc.: ACME-Integration scheinbar nur mit persönlicher Beratung. Bei meinen Versuchen war kein Login mittels Firefox möglich, da sich „mein Browser ungewöhnlich verhalte“.
7. SSL.com: Arbeitsplätze selbst mutmasslich in Houston aufgrund von Stelleninseraten („Opportunities at Houston’s premier Digital Certificate Authority“).
8. AWS: Automatisierung ja, auch für Fremddomains, aber nicht mit ACME
9. Azure: Integrationen in den Azure Key Vault
ACME-Zertifizierungsstellen
Hier eine Auswahl von sechs CAs, welche ACME ähnlich einfach anzubieten scheinen, wie wir es von Let’s Encrypt gewohnt sind. Die drei CAs in grün konnte ich auf Basis der Dokumentation im Self-Service-Verfahren selbst nutzen und habe je über 100 Zertifikate ausstellen lassen (alles Zertifikate für Dienste, die vorher schon über Jahre mittels Let’s Encrypt genutzt wurden).
Die meisten der CAs sind direkt ihren obersten (Konzern-)Müttern unterstellt und sind direkt vom CA/Browser Forum anerkannt, also direkt in den Browsern (und Betriebssystemen etc.) verankert. Doch es gibt einige Ausnahmen:
- Google Trust Services: Es ist unklar, wie Google Trust Services LLC innerhalb des Alphabet-Konzerns aufgehängt sind. Durch die enge Verknüpfung und den einheitlichen Hauptsitz ist das hier aber auch nicht relevant.
- Let’s Encrypt: Die CAs von Let’s Encrypt sind Sub-CAs von ISRG. Da ISRG aber auch die Mutterorganisation ist und den Sitz teilt, dürfte sich in den wenigsten Fällen einen praktischen Unterschied ergeben.
- ZeroSSL: Die relevante Ausnahme sowohl von der Besitz- als auch der Anerkennungsregelung ist ZeroSSL. Als österreichische Firma gehört sie zu einem schwedischen Konzern gehört, die direkte Muttergesellschaft ist aber eine US-Firma. ZeroSSL ist auch nicht direkt in den Browsern verankert, sondern eine Sub-CA von Sectigo, also auch von ihr abhängig. Beide Abhängigkeiten lassen sich lösen, benötigen aber Zeit. Zeit, die man im schlimmsten Falle nicht hat.
Schritte zur Souveränität
Die Ziele von Souveränität, Resilienz und digitaler Selbstbestimmung ist es, Unabhängigkeit sowie Kontroll- und Handlungsfreiheit zu erhalten. Am einfachsten kann das erreicht werden, wenn Monopole und Machtkonzentrationen vermieden werden und auf mehrere Lieferanten in unterschiedlichen Ländern und Jurisdiktionen zugegriffen werden kann. Dazu ist aber auch ein Ökosystem notwendig, welches Optionen zulässt. Laut einer BuiltWith-Statistik sind über 93 % der Schweizer Web-Zertifikate von Let’s Encrypt ausgestellt, essenziell eine Monopolsituation eines US-Anbieters.

Eine Monopolsituation ist aus Kundensicht immer gefährlich, auch ohne Sanktionsdrohungen. Doch zum Glück gibt es ein paar einfach Schritte und die komplizierteren davon sollte man sowieso angehen, wenn man die nicht schon aus anderen Gründen umgesetzt hat.
1. Wechsel zu ACME
Die Zeiten von manuell installierten Zertifikaten sind definitiv vorbei. In den Anfängen mit wenigen Zertifikaten und mehrjährigen Laufzeiten war das noch eine Option, auch wenn schon damals die meisten Organisationen Erfahrungen mit zu spätet aktualisierten Zertifikaten gesammelt haben dürften.
Da ab Anfang 2029 von Browsern anerkannte Zertifikate nur noch maximal 47 Tage lang gültig sein dürfen, ist in den nächsten zwei Jahren eine Umstellung der Prozesse auf automatische Erneuerung sowieso notwendig. In den meisten Fällen ist die Umstellung auf ACME dank der ausgereiften Werkzeuge und Anleitungen auch sehr einfach, wie die Quote von über 93 % Let’s-Encrypt-Zertifikaten beweist. Diese sind nämlich grundsätzlich nur mit ACME ausstellbar.
(In einigen Sonderfällen sind die Standardprozesse nicht 1:1 anwendbar; aber es ist davon auszugehen, dass fast jeder der Sonderfälle inzwischen von irgendjemandem auf ACME-Basis umgesetzt worden ist. Und sehr wahrscheinlich hat den Fall auch jemand öffentlich dokumentiert.)
Der ACME-Wechsel steht sowieso an und über 90 % der Schweizer Webseiten haben den Wechsel schon geschafft. Worauf also warten?
2. Wechsel zu Einzelzertifikaten
Ebenfalls aus den Zertifikatsanfängen stammt der Trend, ein Zertifikat für möglichst viele Server- bzw. Webseitennamen gleichzeitig auszustellen. Das war damals auch sinnvoll, denn es gab nicht nur technische (fehlende SNI-Unterstützung) und prozessuale Gründe (nur ein Zertifikat zu installieren), auch die Preisstruktur der CAs legte das nahe.
Bei ACME gibt es zwar weiterhin die Möglichkeit, mehr als einen Namen in ein Zertifikat zu verpacken. Doch Zertifikate mit mehreren Namen können nur automatisch erneuert werden, wenn alle Namen durch die CA verifiziert werden können. Wenn sich also etwas an der Konfiguration verändert hat, beispielsweise, dass ein Server ausgetragen bzw. umbenannt wurde oder dass eine Domain gekündigt wurde, dann schlägt bei einem Mehrfachzertifikat die gesamte Erneuerung fehl.
Veteranen mögen sich an Zertifikate mit über 100 Namen erinnern, in einem einzigen Zertifikat. Ein von mir betreuter Server hatte 80 Namen in einem einzigen Zertifikat, ein anderer Server im Team besass ein Zertifikat mit 256 Namen. Falls bei nur einem einzelnen der 256 Verifikationsschritte etwas schiefläuft, schlägt die Erneuerung des gesamten Zertifikats fehl. Sprich, für keinen einzigen der Servernamen im Zertifikat gibt es dann noch ein gültiges Zertifikat; nicht nur für den einen Eintrag, dessen Änderung unvollkommen kommuniziert wurde.
Das Verhalten bei Fehlern ist bei Einzelzertifikaten also deutlich harmloser. Und man erreicht gleichzeitig, die Auswahl zwischen drei kostenfreien ACME-CAs zu haben. Zuverlässiger und gleichzeitig mehr Souveränität, was will man denn mehr?
3. Wechsel jetzt
Das wichtigste aber ist, dass möglichst viele Zertifikate jetzt umgestellt werden. Über 93 % der Zertifikate aus der Schweiz werden durch Let’s Encrypt ausgestellt, Actalis und ZeroSSL dagegen verstecken sich irgendwo in den 0.33 % „Other“, wie die BuiltWith-Grafik oben zeigt; nicht einmal die detaillierte Auflistung weiter unten auf der BuiltWith-Seite listet die beiden überhaupt auf.
Let’s Encrypt stellt täglich über 10 Millionen Zertifikate aus, also über 100 pro Sekunde. Wenn nun aus irgendeinem Grund (technisches Problem, Sanktionen, wasauchimmer) Let’s Encrypt nicht verfügbar ist, werden etliche Serverbetreiber panikartig auf andere ACME-CAs wechseln wollen. Let’s Encrypt hatte für das Wachstum auf 100 Zertifikate pro Sekunde 10 Jahre Zeit. Für die meisten CAs dürfte eine derartige Skalierung von heute auf morgen schwierig sein.
Wenn wir alle jetzt mit dem Wechsel beginnen, haben die CAs Zeit, zu wachsen. Bevor der US-Präsident eines Tages eine kurzfristige Entscheidung veröffentlicht, bei der panikartig alle wechseln und die – nicht gewachsenen – CAs hoffnungslos überlasten.
Deshalb ist es notwendig, dass die CAs bereits jetzt ihre Infrastruktur auf den Ansturm vorbereiten können. Nur so können mehrere gleichberechtigte ACME-CAs existieren, welche auch mal die Last einer nicht verfügbaren anderen CA übernehmen können. Damit auch eine reale Wahlfreiheit entsteht, müssen die Alternativen Zeit haben, zu wachsen.
Optional: Unterstützung der Firmen hinter den CAs
Der Betrieb einer kostenlosen CA ist weder selbstverständlich noch gratis. Deshalb ist es wichtig, dass wir Nutzenden den Betreibern und ihren Muttergesellschaften mitteilen, dass wir diesen Dienst schätzen.
Eine gute Möglichkeit, dies zu zeigen, ist, in dem wir Produkte und Dienstleistungen aus den jeweiligen Firmenstrukturen nutzen und ihnen sagen, dass wir die Firma wegen ihrer ACME-CA gewählt hätten. Was bieten denn die Firmen an?
- ZeroSSL gehört zur Assa Abloy-Gruppe, zu der auch der Schweizer Schliesssysteme-Hersteller Keso zählt. Die direkte ZeroSSL-Mutter ist HID Global, welche Identitäts- und Zugriffskontrollsysteme herstellen.
- Actalis ist eine Tochter von Aruba, die in Italien beispielsweise Cloud- und Hostingdienste anbieten, auch in Bergamo, unweit der Schweizer Grenze.
(Weder DNIP noch ich haben geschäftliche, finanzielle oder persönliche Beziehungen zu den beiden Unternehmen, ausser dass einige von uns deren öffentliches, kostenloses Angebot von ACME-Zertifikaten zufrieden nutzen.)
Wer einen kostenlosen Dienst nutzt, bei dem man nicht selbst das Produkt ist und mit ihm zufrieden ist, sollte die Firma möglichst unterstützen und sich auch bei ihr bedanken. Das hilft, dass der Dienst weiterhin kostenlos bleibt.
Praktische Erfahrungen
Ich habe seit Juni mein „erweitertes Homelab“ auf ZeroSSL und Actalis umgestellt und dafür über 100 Zertifikate ausstellen lassen. Hier die Erfahrungen:
- Die Umstellung der Webserver lief problemlos. Ich verwende Caddy als Reverse Proxy für die TLS-Terminierung, dort muss man nur die URL des ACME-Endpunkts eintragen (und bei Actalis Key-ID sowie Key, ohne finale „=“-Zeichen). Aber auch bei anderen beliebten ACME-Clients, wie dem weit verbreiteten
certbotder EFF, ist es nur eine winzige Änderung. - Bei meiner Mailserver-Software, mailcow: dockerized, musste ich etwas Hand anlegen, da es standardmässig ein Kombizertifikat mit allen Einträge zusammen anlegt. Aber auch das kann einfach geändert werden, wie hier für Caddy und mailcow: dockerized und Einzelzertifikate beschrieben ist.
- Eine Domain unterhalb der
.town-TLD liess sich mit ZeroSSL nicht ausstellen, nur mit Actalis (und natürlich Let’s Encrypt). Auf meine Anfrage bekam ich keine Antwort.
Empfehlungen, zusammengefasst
Was sind die Hauptschritte, um zu souveränen Zertifikaten zu kommen? Also, Zertifikate, bei denen man kurzfristig den Anbieter
- ACME: Wechsel zur Zertifikatsausstellung mit ACME, wo immer möglich. Für öffentlich sichtbare
.ch-Dienste ist das bereits bei über 90 % der Fall; die Umstellung dürfte also auch anderswo keine Hexerei sein. Dies sollte sowieso geschehen, unabhängig von Souveränitätsüberlegungen, da niemand bereit sein dürfte, bald jeden Monat alle Zertifikate von Hand zu wechseln. - Einzelzertifikate: Dieser Schritt dürfte etwas schwieriger sein. Aber auch er sollte unabhängig von Souveränitätsüberlegungen getan werden, denn er bietet höhere Fehlertoleranz. Bei Webservern dürfte der Schritt sehr einfach sein (und moderne Webserver wie Caddy kümmern sich da automatisch um alle Details); bei Mailservern ist da je nachdem etwas mehr Handarbeit nötig.
- Wechsel: Wer die beiden obigen Schritte gegangen ist, kann dann meist durch eine Zeile Konfigurationsänderung zwischen den öffentlichen ACME-Diensten wechseln (und auch jederzeit wieder zurück). Das sollte man gleich mal machen.
- Optional: Firmen der Betreiber berücksichtigen (Supportverträge, andere Produkte nutzen); sonst sterben die Alternativen aus
Weiterführende Literatur
- Marcel Waldvogel: Souveräne Internet-Dienste: Ein mehrstufiges Unterfangen, DNIP, 2026-09-09.
Grundlegendes zur Souveränität von Internetdiensten und Internet-Domains. - Marcel Waldvogel: Domains for Digital Sovereignty, 2026-09-05.
Vollständige Liste der IANA-Domain-Informationen in einem Tabellendokument; Snapshot mit Stand vom 2026-08-09. - Marcel Waldvogel: Sovereign ACME certificates for Mailcow with Caddy and SNI, 2026-11-10.
Wie man Einzelzertifikate für einen Mailserver aktiviert, der eigentlich nicht dafür vorgesehen ist. - List of ACME Servers, lebendiges Dokument auf GitHub.
Übersicht über die ACME-Endpunkte verschiedener Firmen. - Michael Driscoll: The Illustrated TLS 1.3 Connection.
Detaillierter Ablauf eines Verbindungsaufbaus bei der modernsten TLS-Version. - Michael Driscoll: The Illustrated TLS 1.2 Connection.
Detaillierter Ablauf eines TLS-Verbindungsaufbaus in immer noch sehr weit verbreiteten Vorgängerversion TLS 1.2.

