Souveräne Zertifikate: Ein Schritt zur sicheren digitalen Unabhängigkeit

Der Bundesbrief

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!

Wenn 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!

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.

Web-, Mail-, Datenbank- und sonstige Server sollten heute eigentlich immer über verschlüsselte Verbindungen angesprochen werden. Dazu präsentieren sie beim Verbindungsaufbau ein Zertifikat, um ihre Identität zu bezeugen. Dieses Zertifikat wird wiederum von einer Zertifizierungsstellen (CA) ausgestellt. Diese CAs sind öffentlich (vergleichbar Notariat in der realen Welt) oder privat, typischerweise innerhalb der Firma oder innerhalb einer Gruppe von Computern. Gewisse öffentliche CAs folgen den Regeln des CA/Browser Forum und landen damit automatisch in den Browsern. Damit weiss der Browser (und damit der Nutzer), dass die Identität des Servers von einer vertrauenswürdigen CA geprüft wurde. Private Zertifikate müssen von der Firma oder von den Nutzern von Hand installiert werden, falls ihnen auch vertraut werden soll. Neben den Browsern gibt es aber auch noch Betriebssysteme und andere Software (Mailprogramme, Datenbankabfrage-Tools, …). Welchen Zertifizierungsstellen diese vertrauen (und ob diese Liste erweiterbar ist), ist ihnen überlassen; oft basiert die Liste aber auf den Browser-CAs.

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.)

Screenshot eines Webbrowsers beim Besuch von DNIP.ch. Durch Klick auf das Schloss in der Adresszeile und Klick auf "Verbindung ist sicher" erscheint die Information "Sie sind derzeit über eine gesicherte Verbindung mit dieser Webseite verbunden. Verifiziert von Let's Encrypt
Der Browser – hier Firefox – zeigt auf Nachfrage (Klick auf Schloss-Icon links der URL), von welcher CA das Zertifikat ausgestellt wurde; auf Wunsch auch weitere technische Informationen.

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:

AnbieterSitzMuttergesellschaftACME
Let’s Encrypt [1]San Francisco, CA 🇺🇸ISRG 🇺🇸✅ kostenlos
ZeroSSL [2]Wien 🇦🇹(HID Global 🇺🇸),
Assa Abloy 🇸🇪
✅ kostenlos für beliebig viele Einzelzertifikate, kostenpflichtige Optionen
Actalis [3]Ponte San Pietro 🇮🇹Aruba 🇮🇹✅ kostenlos für beliebig viele Einzelzertifikate, kostenpflichtige Optionen
Google Trust Services [4]Mountain View, CA 🇺🇸Alphabet 🇺🇸🮱 Funktion von Google-Cloud-Konten
GlobalSignLeuven 🇧🇪Tokyo 🇯🇵🮱 ACME-Zugang nur nach Antrag
HaricaAthen 🇬🇷GUnet 🇬🇷🮱 kostenpflichtig, ACME scheint eine Enterprise-Funktion zu sein
GoDaddy [5]Tempe, AZ 🇺🇸GoDaddy Inc 🇺🇸🮱 kostenpflichtig, manuelle Einrichtung jedes Zertifikats
DigiCertHarica, UT 🇺🇸🮱 nur für OV/EV-Zertifikate
Sectigo (+InCommon) [6]Manchester 🇬🇧Xcitium 🇺🇸❓ angeblich ja, aber keine Dokumentation
SSL.com [7]Nevada 🇺🇸❓ ACME-Endpunkte existieren, aber keine Dokumentation
Amazon AWS [8]Seattle, WA 🇺🇸Amazon 🇺🇸❌ scheinbar nicht
Microsoft Azure [9]Redmond, WA 🇺🇸Microsoft 🇺🇸❌ scheinbar nicht
CertumSzczecin (Stettin) 🇵🇱Asseco 🇵🇱❌ scheinbar nicht
SwissSignGlattbrugg 🇨🇭Post 🇨🇭❌ scheinbar nicht
Bemerkungen:
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).

Sechs Abhängigkeiten, nach links zu den Mutterfirmen ("Besitzverhältnisse", nach obiger Tabelle), nach rechts zu Zertifizierungsorganisationen ("Zertfikatsanerkennung"). Ganz rechts ist das CA/Browser-Forum. Nur Let's Encrypt und ZeroSSL sind Sub-CAs von anderen Firmen; Let's Encrypt der Mutter ISRG und ZeroSSL von Sectigo. Let's Encrypt, ZeroSSL und Actalis sind grün markiert als CAs, bei denen ich erfolgreich kostenlose ACME-Zertifikate ausgestellt habe. Google Trust Services, Harica und GlobalSign sind in blau gehalten; dort schien es keine Möglichkeit für kostenlose ACME-Zertifikate zu geben.
Die Abhängigkeit einiger ausgewählter CAs aus der obigen Liste. Nach links zu Mutterfirmen, nach rechts zu anderen Zertifizierungsorganisationen (andere CAs bzw. dem koordinierenden CA/Browser-Forum). Die Hintergrundfarben zeigen die geografische Region an: Magenta für die USA, cyan für Europa, blau für Asien. Let’s Encrypt hat als Parent-CA die CA der Parentorganisation ISRG; ZeroSSL hat in beide Richtungen US-Organisationen als Mittelsmänner zur schwedischen Grossmutter und zum internationalen CA/Browser-Forum (ein Zusammenschluss ohne bestimmte Rechtsform und damit auch ohne Sitz).

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.

Verteilung der TLS-Zertifikate nach Zertifizierungsstelle in der Schweiz. Über 93 % der Zertifikate stammen von Let’s Encrypt. Quelle: Screenshot von BuiltWith (Stand: 2026-09-12)

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 certbot der 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.

Weiterführende Literatur

dnip.ch mit Deiner Spende unterstützen

Wir wollen, dass unsere Inhalte frei verfügbar sind, weil wir es wichtig finden, dass möglichst viele Menschen in unserem Land die politischen Dimensionen der Digitalisierung erkennen und verstehen können.

Damit das möglich ist, sind wir auf deine Unterstützung angewiesen. Jeder Beitrag und sei er noch so klein, hilft uns, unsere Aufgabe wahrzunehmen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Weitere Beiträge