Open TSA – Kostenloser RFC-3161-Zeitstempel-Dienst für Europa: Drei Wochen live

Open TSA ist ein kostenloser, quelloffener RFC-3161-Zeitstempel-Dienst, betrieben aus einem deutschen Hochverfügbarkeits-Rechenzentrum. Nach drei Wochen öffentlicher Verfügbarkeit hat der Dienst 1.253 Zeitstempel an 15 verschiedene Nutzer in vier Ländern ausgestellt — ohne Ausfall und ohne aktive Vermarktung. Dieser Beitrag erklärt, was der Dienst leistet, warum es ihn gibt und wie sich in zwei Minuten ein erster Zeitstempel von der Kommandozeile aus anfordern lässt.

Was ist ein qualifizierter Zeitstempel, und warum braucht man ihn?

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): Man bildet einen Hash über das eigene Dokument, sendet diesen Hash an die TSA und erhält eine signierte Antwort (ein TimeStampToken) zurück, die jeder Dritte anhand der Zertifikatskette der TSA prüfen kann.

Zeitstempel sind in vielen realen Arbeitsabläufen vorgeschrieben oder dringend empfohlen:

Beweissicherheit nach deutschem Recht: Nach § 371a ZPO haben elektronische Dokumente einen erhöhten Beweiswert, wenn ihre Integrität nachweisbar ist. RFC-3161-Zeitstempel erfüllen diese Anforderung.
GoBD-Konformität: Die Unveränderbarkeit aufbewahrungspflichtiger Belege lässt sich mit Zeitstempeln über deren Hashwert technisch belegen — wichtig für Betriebsprüfungen.
Software-Lieferketten: Reproducible Builds, SBOM-Attestierungen, signierte Releases — alle profitieren von einem nachweisbaren „dieses Artefakt existierte zum Zeitpunkt T”.
Audit-Trails: Compliance-Rahmenwerke (ISO 27001, SOC 2, NIS2) verlangen routinemäßig manipulationssichere Protokollierung.
Forschungsintegrität: Datensätze, Laborbücher, Erfindungsmeldungen — alle gewinnen Glaubwürdigkeit, wenn sie gegen einen unabhängigen Dritten zeitlich verankert sind.
Langzeitarchivierung: PDF/A-3, eIDAS-konforme Dokumentenaufbewahrung, das kommende EU-Digital-Identity-Wallet-Ökosystem — alle stützen sich auf dieselbe RFC-3161-Grundprimitive.

Den Standard gibt es seit 2001. Eine Infrastruktur, die ihn in Europa kostenlos, quelloffen und unabhängig zugänglich macht, gab es bisher nicht — bis jetzt.

Die bisherigen Optionen und ihre Grenzen

Dienst	Kosten	Open Source	Betreiber	Redundanz
freetsa.org	kostenlos	nein	einzelne Privatperson	keine
D-Trust, DigiCert, GlobalSign, Notarius	200–1.000 €/Jahr+	nein	kommerzielle Anbieter	ja (kostenpflichtig)
Nationale qualifizierte TSPs (EE, PL, IT, ES, …)	überwiegend kostenpflichtig	nein	nationale Betreiber	länderspezifisch
sigstore/timestamp-authority	kostenlos	ja (Apache 2.0)	Linux Foundation / Google	nicht für allgemeine Dokumentennutzung konzipiert
Open TSA	kostenlos	ja (MIT)	Open TSA Project (öffentliche Infrastruktur)	Multi-Region geplant

Jede bestehende Option hat eine Lücke. freetsa.org wird in unzähligen Tutorials und Entwicklerdokumenten zitiert, hat aber keinen veröffentlichten Quellcode, keine juristische Verantwortlichkeit und hängt an einer einzelnen Person. Kommerzielle qualifizierte TSAs sind verlässlich, aber für Enterprise-Budgets gepreist. sigstore ist technisch hervorragend, aber für Software-Lieferketten gebaut, nicht für allgemeine Dokumenten-Integrität.

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

Anwendung in zwei Minuten

Der Dienst spricht Standard-RFC 3161 über HTTPS. Jeder Client, der die ts-Werkzeuge von OpenSSL nutzt — also Python-, Java-, Go- und Rust-Ökosysteme inklusive — kann den Dienst ohne Anpassung ansprechen.

Zeitstempel anfordern

# 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

# 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

Das ist die gesamte Anforderungsseite. Die TSR ist nun eine Binärdatei, die eine kryptografisch signierte Aussage darüber enthält, dass dokument.txt zum Anforderungszeitpunkt in genau dieser Form existierte.

Zeitstempel verifizieren

# CA-Kette herunterladen (einmalig)
curl -s https://open-tsa.eu/certs/ca.crt        -o ca.crt
curl -s https://open-tsa.eu/certs/fullchain.pem -o fullchain.pem

# Verifizieren
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: Dokumenten-Hash, TSA-Signatur und Zertifikatskette sind konsistent. Jeder — nicht nur der ursprüngliche Anforderer — kann dieselbe TSR später überall vollständig offline überprüfen, indem er die öffentlichen CA-Zertifikate von dieser Website herunterlädt.

TSR-Inhalt einsehen

openssl ts -reply -in response.tsr -text

Das gibt Seriennummer, signierten Zeitpunkt, Policy-OID, Hash-Algorithmus und das eingebettete Signierungszertifikat aus.

Architektur in einem Diagramm

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)
   │
   ├── Stufe 1: Root CA (25 Jahre, offline)
   ├── Stufe 2: TSA Root CA (15 Jahre, offline)
   ├── Stufe 3: Intermediate CA (10 Jahre)
   └── Stufe 4: TSA Signing Cert (2 Jahre, online)

Die Umsetzung ist bewusst minimal. Die kryptografischen Operationen sind an OpenSSL 3.x delegiert. Die Node.js-Schicht erledigt HTTP, Eingabevalidierung, Rate-Limiting, Audit-Logging und Prometheus-Metriken. Der Quellcode umfasst etwa 600 Zeilen JavaScript plus ein 600-Zeilen-Shell-Skript für das CA-Setup, alles öffentlich auf git.open-tsa.eu/open-tsa/server.

Root- und Intermediate-Privatschlüssel werden offline gehalten. Nur der operative Signierungsschlüssel ist online — und auch dieser wird alle zwei Jahre rotiert.

Drei Wochen Live-Traffic

Seit der Inbetriebnahme am 24. April 2026:

1.253 Zeitstempel ausgestellt
15 verschiedene IP-Adressen
Vier Länder mit wiederkehrender Nutzung: Deutschland, Italien, Frankreich, Jordanien
60–100 Anfragen pro Tag, gleichmäßig, Stand Mitte Mai
Keine ungeplante Ausfallzeit

Zu den Nutzern gehören:

Eine deutsche Steuerberatungskanzlei, die Open TSA für § 371a ZPO-Beweissicherung auf signierten PDFs einsetzt
Ein Webinhalts-Beweissicherungsdienst, der zeitlich verankerte Snapshots von Webseiten für spätere juristische Verwendung archiviert
Eine akademische Forschungsgruppe an der German-Jordanian University in Amman
Eine italienische Java-Anwendung, die sich als größter externer Einzelnutzer etabliert hat — mit bisher 420 Zeitstempeln
Einzelne Entwickler aus mindestens sieben weiteren Ländern mit Testanfragen

Der Live-Zähler ist jederzeit öffentlich nachprüfbar:

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

Der Dienst erfordert keine Registrierung, keine API-Schlüssel, keine Rate-Limit-Tokens. Die Nutzung ist anonym; der Dienst speichert ausschließlich die Anzahl der Anfragen, die Client-IP zu Rate-Limit-Zwecken und den User-Agent-String.

Warum europäische Infrastruktur?

Der Abhängigkeitsstack von „Vertrauensinfrastruktur” — Certificate Authorities, Timestamp Authorities, Schlüsselverzeichnisse, Identity Provider — ist stark in den USA konzentriert. Für manche Anwendungen spielt das keine Rolle. Für andere zunehmend schon:

Öffentliche Beschaffung präferiert immer häufiger EU-gehostete Vertrauensdienste
Der Rollout der EU-Digital-Identity-Wallet (Ende 2026) erfordert, dass jede Relying Party manipulationssichere Audit-Protokolle der Wallet-Präsentationen führt — im großen Maßstab braucht das zugängliche, verantwortungsvolle europäische RFC-3161-Endpunkte
Der eIDAS-2.0-Rahmen führt Souveränitätserwägungen explizit als Bewertungskriterium für Vertrauensdienste ein
NIS2 und der Cyber Resilience Act treiben Accountability-Anforderungen, die leichter zu erfüllen sind, wenn der Betreiber unter europäischem Recht erreichbar ist

Open TSA wird aus Deutschland betrieben, auf europäischer Cloud-Infrastruktur deployt (Hetzner Falkenstein, Helsinki geplant) und auf unabhängiger europäischer Code-Hosting-Plattform entwickelt (git.open-tsa.eu), nicht auf US-basiertem GitHub oder GitLab.com. Die MIT-Lizenz erlegt keine Beschränkung auf, wo oder von wem der Code erneut bereitgestellt werden darf.

Eine Notiz zu KI-Agenten

Ein unerwarteter Anwendungsfall ist aufgetaucht. Zusätzlich zum kryptografischen POST /tsr-Endpunkt stellt der Dienst einen schlanken GET /now-Endpunkt bereit, der die aktuelle UTC-Zeit in Standardformaten zurückliefert (ISO 8601, Unix-Epoche, RFC 2822):

curl -s https://open-tsa.eu/now

LLM-basierte Agenten — Claude, ChatGPT, Agenten-Frameworks auf Anthropics MCP oder OpenAI Function Calling — haben üblicherweise keine zuverlässige Vorstellung der aktuellen Zeit. Sie brauchen eine autoritative Quelle. Am 24. April 2026, dem Tag der Inbetriebnahme, hat Anthropics Claude die aktuelle Zeit von /now abgerufen und sich dabei korrekt per User-Agent identifiziert (Claude-User/1.0). Seitdem wurde der Endpunkt von curl-getriebenen Skripten, browserbasierten Clients 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 souveräne Infrastruktur.

Roadmap

Der Dienst ist heute ein einzelner Knoten in Nürnberg mit einer vierstufigen, offline-verankerten CA-Hierarchie, MIT-lizenziertem Quellcode und reproduzierbarem Deployment aus einem öffentlichen Git-Repository.

Die nächsten Schritte sind:

Multi-Region-Deployment. Ein zweiter Knoten in Helsinki, geografisch getrennt, mit DNS-basiertem Failover. Unabhängiger Betrieb jedes Knotens, damit ein regionaler Ausfall die Verfügbarkeit nicht beeinträchtigt.
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 jeden Nutzer eine TSR lokal im Browser prüfen lässt, ohne das Dokument hochzuladen.
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, und seine Unterstützung ausdrücken möchte, kann heute am sinnvollsten den Dienst nutzen, Issues melden oder Code beitragen auf git.open-tsa.eu.

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, Konformitätsbewertung durch eine benannte Stelle und Betrieb unter spezifischen rechtlichen und prozeduralen 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 zu verwenden. 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.

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.

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.

Was passiert, wenn der Dienst nicht verfügbar ist?

Heute, mit einem einzelnen Knoten, betrifft ein Ausfall alle Nutzer. Das ist die wichtigste Einschränkung der aktuellen Architektur und die Hauptmotivation für das geplante Multi-Region-Deployment. Die zwischenzeitliche Notlösung für Hochverfügbarkeits-Bedarf: Den eigenen Client so konfigurieren, dass er bei Open-TSA-Ausfall auf einen kommerziellen TSP zurückfällt. Sobald Multi-Region live ist, sollte dieser Fallback selten nötig sein.

Kann ich beitragen?

Ja. Das Repository liegt auf git.open-tsa.eu/open-tsa/server. Issues, Pull Requests und Diskussionen sind willkommen. Anonymes Clonen funktioniert ohne Account; Push setzt eine Registrierung auf der Forgejo-Instanz voraus.