Open TSA: Kostenloser RFC-3161-Zeitstempel-Dienst aus Deutschland

Am 24. April 2026 ging Open TSA öffentlich live — ein kostenloser, quelloffener RFC-3161-Zeitstempeldienst aus Deutschland. Heute, drei Wochen später, ist Zeit für eine erste Bilanz: 1.253 ausgestellte Zeitstempel, Nutzer in vier Ländern, keine Ausfallzeit — und ein paar Beobachtungen, mit denen wir nicht gerechnet hatten.

Was in drei Wochen passiert ist

Die nüchternen Zahlen aus dem Live-Zähler:

Inbetriebnahme	24. April 2026
Ausgestellte Zeitstempel	1.253
Unterschiedliche IP-Adressen	15
Länder mit wiederkehrender Nutzung	Deutschland, Italien, Frankreich, Jordanien
Anfragen pro Tag (Mitte Mai)	60–100, gleichmäßig
Ungeplante Ausfallzeit	0 min
Aktive Werbe-/Marketing-Maßnahmen	keine

Wer die Zahlen live nachprüfen möchte, kann den öffentlichen Statistik-Endpunkt jederzeit abrufen:

curl -s https://open-tsa.eu/stats
# {"total_timestamps":1253,"service":"open-tsa.eu"}

Der Zähler erhöht sich nur dann, wenn der Dienst tatsächlich einen kryptografisch gültigen Zeitstempel ausgestellt hat — Fehlversuche, Health-Checks oder Stats-Abrufe zählen nicht mit.

Kurz zur Einordnung: Was ist Open TSA?

Ein RFC-3161-Zeitstempel ist ein kryptografischer Beweis, dass ein bestimmtes Dokument zu einem bestimmten Zeitpunkt in genau dieser Form existiert hat. Ausgestellt wird er von einer Time Stamping Authority (TSA). Solche Zeitstempel sind nach § 371a ZPO ein anerkanntes Mittel zur Sicherung des Beweiswerts elektronischer Dokumente. Sie werden außerdem in GoBD-konformer Buchhaltung, bei Software-Lieferketten (Reproducible Builds, signierte Releases), in Audit-Trails (ISO 27001, NIS2) und für die Langzeitarchivierung benötigt.

Den Standard gibt es seit 2001. Eine Infrastruktur, die ihn kostenlos, quelloffen und unabhängig in Europa zugänglich macht, gab es bisher nur lückenhaft:

Dienst	Kosten	Open Source	Betreiber
freetsa.org	kostenlos	nein	einzelne Privatperson
D-Trust, DigiCert, GlobalSign	200–1.000 €/Jahr+	nein	kommerzielle Anbieter
sigstore/timestamp-authority	kostenlos	ja	Linux Foundation / Google (USA)
Open TSA	kostenlos	ja (MIT)	Open TSA Project (Deutschland)

Open TSA wurde gebaut, um die offensichtliche Lücke zu schließen: kostenlos wie freetsa, quelltransparent wie sigstore, betrieben als europäische Public-Interest-Infrastruktur statt als Nebenprojekt einer Privatperson oder als kommerzielles Angebot.

Wer den Dienst nutzt — drei Profile

Die 1.253 Zeitstempel verteilen sich auf zwei Gruppen. Etwa 55 % stammen aus drei Anwendungen, die der Betreiber selbst in produktiven Umgebungen einsetzt — ein „Dogfooding”-Anteil, der in einer ehrlichen Bilanz dazugehört. Die restlichen 45 % kommen von externen Nutzern, die den Dienst von sich aus gefunden und in Betrieb genommen haben.

Dogfooding — produktive Anwendungen des Betreibers

Dokumentensignatur mit § 371a ZPO-Beweiswert (mehrere mittelständische Anwender). Jedes signierte PDF erhält automatisch einen RFC-3161-Zeitstempel — das ist die technische Grundlage dafür, dass die signierten Dokumente erhöhten Beweiswert tragen. Mit 667 Zeitstempeln in drei Wochen der größte Einzelnutzer-Block.
Webinhalts-Beweissicherung. Ein Dienst, der Website-Snapshots zeitlich verankert für spätere juristische Verwendung — etwa bei Falschbehauptungen, Urheberrechtsstreitigkeiten oder Compliance-Nachweisen.
Langzeitarchivierung. Ein Archivdienst, der rechtssichere Dokumente über die gesetzlichen Aufbewahrungsfristen hinaus integritätsgesichert vorhält.

Diese Anwendungen werden vom Betreiber in getrennten Kontexten betrieben und sind nicht Gegenstand der Open-TSA-Förderlogik. Sie sind hier gelistet, um zu belegen, dass der Dienst real produktive Last trägt und in Ausfallszenarien echte Anwendungen ihre Integritätsgrundlage verlieren würden. Diese praktische Abhängigkeit ist gleichzeitig die stärkste Motivation für hohe Betriebsqualität.

Externe Nutzer — gefunden über Google, ohne aktive Werbung

Der überraschendste Befund: Die Hälfte des Verkehrs kommt von Nutzern, die wir nicht angesprochen haben.

Eine italienische Java-Anwendung (Hostname unter mynet.it), die sich als größter externer Einzelnutzer etabliert hat — 420 Zeitstempel in drei Wochen. Wir wissen nicht, wer das ist. Der User-Agent Java-http-client/21.0.8 deutet auf eine produktiv eingesetzte Software hin.
Eine Forschungsgruppe an der German-Jordanian University in Amman, erkennbar an einer VPN-IP der Hochschule. 36 Zeitstempel, durchgängig über drei Wochen.
Eine französische Python-basierte Integration (Hostname bei Proxad/Free.fr) mit 52 Zeitstempeln.
Einzelne Entwickler aus Ungarn, der Schweiz, weiteren deutschen Hosting-Anbietern mit Testabfragen.

Diese Adoption hat sich von selbst ergeben. Es gab keine Pressemitteilung, keine Reddit-Posts, keine Tweets. Der Dienst taucht inzwischen in Google-Suchergebnissen und sogar in KI-generierten Suchzusammenfassungen auf — offenbar war das Bedürfnis nach einer echten freien Alternative deutlich größer, als wir vermutet hätten.

Beobachtung am Rand: KI-Agenten haben einen Zeitstempel-Bedarf

Eine Sache haben wir beim Bau des Dienstes vorgesehen, ohne zu wissen, ob sie sich bewähren würde. Zusätzlich zum kryptografischen POST /tsr-Endpunkt stellt Open TSA einen schlanken GET /now-Endpunkt bereit, der die aktuelle UTC-Zeit in Standardformaten zurückliefert:

curl -s https://open-tsa.eu/now
{
  "iso":     "2026-05-15T16:42:08.923Z",
  "unix":    1779036128,
  "unix_ms": 1779036128923,
  "rfc2822": "Fri, 15 May 2026 16:42:08 GMT",
  "timezone": "UTC"
}

Der Gedanke dahinter: LLM-basierte Agenten — Claude, ChatGPT, Anthropic MCP, OpenAI Function Calling, LangChain-Tools — haben in der Regel keine zuverlässige Vorstellung der aktuellen Zeit. Wenn sie zeitabhängige Operationen ausführen, brauchen sie eine autoritative Quelle, die sie per HTTP abfragen können.

Am Tag der Inbetriebnahme, 24. April 2026, kam tatsächlich die erste Anfrage genau dieser Art: Anthropics Claude rief open-tsa.eu/now auf und identifizierte sich dabei korrekt per User-Agent (Claude-User/1.0; +claude-user@anthropic.com). Seitdem wurde der Endpunkt auch von curl-getriebenen Skripten und HTTP-Bibliotheken aus mindestens vier LLM-Ökosystemen aufgerufen.

/now ist bewusst eine Ergänzung, kein Konkurrent zu /tsr. RFC-3161-Zeitstempel beweisen, dass etwas zu einem bestimmten Zeitpunkt existierte. /now beantwortet, welcher Zeitpunkt gerade ist — in Echtzeit, für Clients, die das selbst nicht ermitteln können. Beide Endpunkte nutzen dieselbe europäische Infrastruktur.

Was technisch unter der Haube läuft

Die Architektur ist bewusst minimal gehalten. Drei Wochen ohne Ausfall gehen darauf zurück, dass es schlicht wenig gibt, was kaputtgehen könnte:

Internet
   │
   ▼  HTTPS (Port 443)
nginx — TLS-Termination, Let's Encrypt
   │
   ▼  HTTP (Port 3700, nur localhost)
service.js — Node.js / Express, RFC-3161-Endpunkt
   │
   ▼
openssl ts -reply — Token-Erzeugung
   │
   ▼
CA-Hierarchie (4 Stufen):
   1. Root CA          (25 Jahre, offline)
   2. TSA Root CA      (15 Jahre, offline)
   3. Intermediate CA  (10 Jahre)
   4. TSA Signing Cert (2 Jahre, online)

Die kryptografischen Operationen sind an OpenSSL 3.x delegiert — das produktiv erprobte De-facto-Standardwerkzeug für RFC 3161. Die Node.js-Schicht handhabt HTTP, Eingabevalidierung, Rate-Limiting, Audit-Logging und Prometheus-Metriken. Root- und Intermediate-Schlüssel werden offline gehalten; nur der operative Signierungsschlüssel ist online.

Der gesamte Quellcode — etwa 600 Zeilen JavaScript plus ein 600-Zeilen-Shell-Skript für das CA-Setup — ist auf git.open-tsa.eu/open-tsa/server öffentlich. MIT-lizenziert. Jeder Betreiber kann eine eigene unabhängige Instanz aufsetzen.

Der Zeitstempel-Workflow für eilige Leser

Wer Open TSA selbst ausprobieren möchte, braucht keinen Account, keinen API-Schlüssel, keine Registrierung. Drei Befehle reichen:

# 1. Dokument hashen und in eine TimeStampQuery (TSQ) verpacken
echo "Hallo Welt" > dokument.txt
openssl ts -query -data dokument.txt -cert -sha256 -no_nonce -out request.tsq

# 2. TSQ an den Dienst senden, TimeStampResponse (TSR) empfangen
curl -s -H "Content-Type: application/timestamp-query" \
     --data-binary @request.tsq \
     https://tsr.open-tsa.eu -o response.tsr

# 3. Verifizieren
curl -s https://open-tsa.eu/certs/ca.crt        -o ca.crt
curl -s https://open-tsa.eu/certs/fullchain.pem -o fullchain.pem
openssl ts -verify -in response.tsr -queryfile request.tsq \
           -CAfile ca.crt -untrusted fullchain.pem
# Verification: OK

Verification: OK ist das Signal, dass alles stimmt. Anyone kann diese Verifikation später offline auf jedem beliebigen Rechner wiederholen, solange die CA-Zertifikate verfügbar sind.

Was als nächstes ansteht

Drei Wochen reibungsloser Betrieb auf einem einzelnen Knoten sind ein gutes Zeichen — aber bestätigen vor allem, dass die größte aktuelle Einschränkung dieselbe ist wie am ersten Tag: Ein Ausfall des einzigen Servers würde alle Nutzer treffen. Das ist der Grund, warum als nächste Schritte vorgesehen sind:

Multi-Region-Deployment. Ein zweiter Knoten in Helsinki, geografisch getrennt von Nürnberg, mit DNS-basiertem Failover und unabhängigem Betrieb. Damit wird der derzeitige Single-Point-of-Failure aufgelöst.
Gehärtete Implementierung. Umfassende RFC-3161-Konformitätstests, OpenSSL-3.x-Kompatibilitätskorrekturen upstream beigetragen, Sicherheitsreview der TSR-Verarbeitung.
Browser-basiertes Verifikationswerkzeug. WebAssembly-Client, der Zeitstempel lokal im Browser prüfen lässt — ohne dass das Dokument hochgeladen werden muss.
Mehrsprachige Dokumentation. Englisch, Deutsch, Französisch, Spanisch, Italienisch.

Diese Schritte sind Gegenstand eines NLnet-NGI-Zero-Commons-Fund-Antrags, der derzeit in Vorbereitung ist. Wer ein Projekt betreibt, das von zuverlässiger europäischer RFC-3161-Infrastruktur profitieren würde, kann heute am sinnvollsten den Dienst nutzen, Issues auf git.open-tsa.eu melden oder Code beitragen.

Eine letzte Beobachtung zur europäischen Vertrauensinfrastruktur

Beim Bau dieses Dienstes wurde mehrfach die Frage gestellt, warum es überhaupt eine spezifisch europäische TSA-Infrastruktur geben muss — funktioniert nicht jeder RFC-3161-Dienst weltweit gleich? Technisch: ja. Strukturell: nein.

Die EU-Digital-Identity-Wallet startet im späten 2026. Jede Relying Party, die Wallet-Präsentationen verarbeitet, braucht manipulationssichere Audit-Trails — und die brauchen wiederum zugängliche, verantwortungsvolle RFC-3161-Endpunkte. NIS2 und der Cyber Resilience Act treiben Accountability-Anforderungen, die einfacher zu erfüllen sind, wenn der Betreiber unter europäischem Recht erreichbar ist. eIDAS 2.0 hat Souveränitätserwägungen explizit in die Bewertungskriterien für Vertrauensdienste aufgenommen.

In diesem Kontext ist es nicht egal, dass Open TSA aus Deutschland betrieben wird, auf europäischer Cloud-Infrastruktur deployt ist und auf unabhängiger europäischer Code-Hosting-Plattform (git.open-tsa.eu) entwickelt wird — nicht auf US-basiertem GitHub oder GitLab.com. Das ist nicht Programmatik um ihrer selbst willen. Das ist der pragmatische Unterschied zwischen einer Trust-Infrastruktur, die im Krisenfall verfügbar bleibt, und einer, die das nicht garantieren kann.

Häufig gestellte Fragen

Ist Open TSA ein qualifizierter TSP nach eIDAS?

Nein. Open TSA ist RFC-3161-konform, aber nicht eIDAS-qualifiziert. Eine eIDAS-Qualifikation erfordert Akkreditierung durch eine nationale Aufsichtsstelle und Konformitätsbewertung durch eine benannte Stelle — Auflagen, die mit einem kostenlosen öffentlichen Service-Modell nicht vereinbar sind. Für Workloads, die rechtlich eIDAS-qualifizierte Zeitstempel verlangen (bestimmte regulierte Branchen, spezifische öffentliche Beschaffung), ist ein kommerzieller qualifizierter TSP einzusetzen. Für alles andere — Software-Lieferkette, § 371a ZPO-Beweis, Archivierung, Audit-Logging, OSS-Entwicklung — ist Open TSA vollständig ausreichend.

Wie unterscheidet sich Open TSA von freetsa.org?

Die wichtigsten Unterschiede: Der Quellcode von Open TSA ist vollständig unter MIT-Lizenz veröffentlicht; der Dienst wird als europäische Public-Interest-Infrastruktur mit dokumentierter Projekt-Heimat betrieben, nicht als Nebenprojekt einer Privatperson; Multi-Region-Redundanz steht auf der Roadmap; der Betreiber ist unter europäischem Recht für Accountability und Streitfälle erreichbar.

Was protokolliert Open TSA?

Der Dienst speichert die Anzahl der Anfragen, die Client-IP-Adresse zu Rate-Limit-Zwecken, den Hostnamen (über Reverse-DNS aufgelöst) und den User-Agent-String. Der Zeitstempel-Inhalt selbst — der Hash des Dokuments — wird signiert in die Antwort eingebettet, aber nicht geloggt. Es werden keine personenbezogenen Daten jenseits der IP erfasst. Keine Cookies, kein Tracking.

Gibt es ein Rate-Limit?

Ja, 60 Anfragen pro Minute je Quell-IP. Für Anwendungen mit höherem Durchsatzbedarf bitte an info@open-tsa.eu wenden; das Limit kann pro Deployment für legitime Hochvolumen-Nutzer erhöht werden.

Kann ich eine eigene Instanz betreiben?

Ja. Das Setup-Skript unterstützt unabhängiges Deployment durch jeden Betreiber mit einem Linux-Server, einer Domain und OpenSSL 3.x. Alle Bezeichner — CA-Namen, Pfade, Policy-OIDs — sind über Umgebungsvariablen konfigurierbar. Die vollständige Anleitung steht im README.

Freier RFC-3161-Zeitstempeldienst Open TSA: Drei Wochen Betrieb, 1.253 Zeitstempel, keine Ausfallzeit