Wunder Autosign — IT-Leitfaden

Für die IT-Abteilung der Kanzlei. Wunder Autosign ist keine Anwendung, die jemand täglich bedient — sie läuft als unbeaufsichtigter Ordner-Wächter. Dieser Leitfaden beschreibt alles, was die IT dafür einmalig einrichten muss: Netzfreigaben, Ordnerrechte, Installationsparameter und das eine Windows-Konto, unter dem die App läuft.

Inhaltsverzeichnis (Deutsch)

1. Was macht Autosign
2. Voraussetzungen
3. Installation
4. policy.json
5. Netz
6. Ordner & Rechte
7. PIN & Neustart
8. Updates
9. Fehlersuche
10. Bekannte Grenzen

1 · Was macht Autosign

Wunder Autosign beobachtet einen Eingangsordner („Ordner A"). Jedes PDF, das dort ankommt, wird automatisch mit der qualifizierten elektronischen Signatur (QES) der eingelegten Smartcard (D-Trust oder LuxTrust) signiert — unsichtbar, mit Zeitstempel und Gültigkeitsnachweis (PAdES B-LT, "LTV"), ohne dass ein Mensch eingreift. Das Ergebnis landet in einem Ausgangsordner („Ordner B"). PDFs, die nicht signiert werden konnten, landen mit einer Begründung im Fehlerordner. Einmal nach der PIN gefragt, bleibt die App über Wochen und über Neustarts hinweg betriebsbereit, solange dieselbe Karte im Leser steckt.

Ordner A (Eingang)  →  Autosign (Karte + pyHanko-Sidecar)  →  Ordner B (signiert)
                                      │
                                      └─ Fehler/  (nicht signierbar, mit Begründung)

Die App läuft als Tray-Programm; das Hauptfenster (Karte, PIN, Warteschlange mit Play/Pause) und das Einstellungsfenster lassen sich über das Tray-Symbol öffnen.

2 · Voraussetzungen

Kartentreiber vorher installieren

Die Middleware muss vor Wunder Autosign installiert sein, weil die App beim Start nach dem PKCS#11-Treiber sucht:

• D-Trust: D-Trust Card Assistant 5 (cryptovision). Erwarteter Treiberpfad: C:\Program Files\cryptovision\cvP11.dll (oder eine der anderen in DRIVER_PATHS hinterlegten Vendor-/ProgramData-Pfade).
• LuxTrust: LuxTrust Middleware. Erwarteter Treiberpfad: C:\Program Files\LuxTrust\Middleware\ltpkcs11.dll (ältere Installationen: gclib.dll von Gemalto/IDPrime).

Beide Treiber dürfen nicht gleichzeitig aktiv geladen sein — Autosign schließt bei D-Trust bekannte Konfliktkandidaten (gclib.dll, eTPKCS11.dll, ltpkcs11.dll) aus, wenn D-Trust als Treiber gewählt ist.

3 · Installation

Wunder Autosign wird als NSIS-Setup (.exe) und als MSI ausgeliefert. Beide bauen pro Maschine (perMachine), nicht pro Nutzer.

Stille Installation per MSI (für baramundi, Intune, SCCM)

msiexec /i "Wunder Autosign-0.1.0.msi" /qn ^
  STOREPIN=0 ^
  AUTOUPDATE=0 ^
  LANGUAGE=en ^
  ORDNER_A="D:\Kanzlei\Eingang" ^
  ORDNER_B="D:\Kanzlei\Signiert" ^
  ORDNER_FEHLER="D:\Kanzlei\Fehler" ^
  /L*v "C:\Logs\autosign-install.log"

Alle sechs Parameter sind optional und unabhängig voneinander. Fehlt ein Parameter komplett, bleibt der bisherige Wert (Erstinstallation: der Standard) unverändert — ein MSI ganz ohne Parameter installiert wie bisher.

Stille Installation per NSIS-Setup (.exe)

"Wunder Autosign Setup 0.1.0.exe" /S /STOREPIN=0 /AUTOUPDATE=0 /LANGUAGE=en ^
  "/ORDNER_A=D:\Kanzlei\Eingang" "/ORDNER_B=D:\Kanzlei\Signiert" "/ORDNER_FEHLER=D:\Kanzlei\Fehler"

Dieselben sechs Parameternamen, mit führendem / statt als NAME=WERT-Property. Auch hier gilt: nur übergebene Parameter werden geschrieben, der Rest bleibt wie er ist.

Beide Installationswege schreiben die Parameter in eine policy.json neben der .exe — das ist der einzige Ort, an dem sie landen (keine Registry).

4 · policy.json

policy.json liegt neben der .exe (also im Installationsverzeichnis, z. B. C:\Program Files\Wunder Autosign\policy.json) und überschreibt die Werte, die der Benutzer im Einstellungsfenster setzt — sie ist für die IT da, nicht für den Benutzer.

{
  "STOREPIN": "0",
  "AUTOUPDATE": "0",
  "ORDNER_A": "D:\\Kanzlei\\Eingang",
  "ORDNER_B": "D:\\Kanzlei\\Signiert",
  "ORDNER_FEHLER": "D:\\Kanzlei\\Fehler",
  "LANGUAGE": "en",
  "ATLAS_URL": "https://gen4.atlas.wunderip.cloud"
}

• Alle Felder sind optional; fehlende Felder lassen den Benutzerwert (bzw. den Standard) unangetastet.
• STOREPIN/AUTOUPDATE: Jeder Wert außer "0" oder "false" (Groß-/Kleinschreibung egal) gilt als an — auch ein leerer String oder eine fehlende Zeile.
• ORDNER_*: ein nicht-leerer String setzt den Ordner; er lässt sich dann im Einstellungsfenster weiterhin anzeigen, aber die Policy gewinnt bei jedem Start neu.
• LANGUAGE: genau de oder en (Groß-/Kleinschreibung egal) legt die Sprache von Fenstern, Tray und Windows-Benachrichtigungen fest und schlägt die Auswahl „Sprache / Language“ im Einstellungsfenster. Jeder andere Wert (auch auto) wirkt nicht — dann gilt die Auswahl des Benutzers, Standard „Automatisch“ = Systemsprache.
• ATLAS_URL: überschreibt die Adresse der Atlas-API (Standard https://gen4.atlas.wunderip.cloud) — dorthin meldet Autosign das Gerät, holt das Kontingent und meldet den Verbrauch (s. §5). Nur für Sonderfälle (eigener Server, Reverse-Proxy der Kanzlei); schlägt jede andere Quelle. Wer die Adresse ändert, muss die neue Adresse statt gen4.atlas.wunderip.cloud freigeben — die Netzadressen im Einstellungsfenster folgen dem Wert automatisch. Kein MSI-Parameter, nur in policy.json.
• Die Datei darf mit oder ohne UTF-8-BOM gespeichert sein — Autosign entfernt es beim Lesen automatisch (wichtig, weil Set-Content/Out-File unter Windows PowerShell 5.1 standardmäßig mit BOM schreiben).
• Ist policy.json nicht lesbar (kaputtes JSON), ignoriert Autosign sie und verwendet die Benutzerwerte — das steht dann als Warnung im Log, die App startet trotzdem.
• Vorrang: policy.json (Datei) schlägt eine Umgebungsvariable (STOREPIN=0, AUTOUPDATE=0, LANGUAGE=en, maschinenweit), die wiederum den gespeicherten Benutzerwert schlägt. Die Umgebungsvariable gilt nur für STOREPIN/AUTOUPDATE/ LANGUAGE, nicht für die Ordner. Bei LANGUAGE zählt nur genau de/en — die unter Linux übliche Form LANGUAGE=en_US:en wird bewusst ignoriert.

policy.json überlebt ein Auto-Update über den NSIS-Installer: Die Deinstallation beim Update verschiebt sonst das gesamte Installationsverzeichnis und löscht es, inklusive policy.json. Autosign sichert die Datei deshalb vor dem Update und legt sie danach zurück, bevor neue Parameter (falls das Update mit welchen kommt) sie ersetzen.

5 · Netz

Wunder Autosign braucht Netz nach außen: immer für die Anmeldung und die Abrechnung (auth.wunder-ip.com, gen4.atlas.wunderip.cloud), dazu für LTV (Standard) und Auto-Update (Standard). LTV und Auto-Update lassen sich abschalten, die Anmeldung nicht — ohne Netz zu diesen beiden Adressen signiert Autosign höchstens, solange das lokale Kontingent reicht (bis zu 7 Tage, s. unten und §10).

Die Firewall/Proxy-Freigabe braucht zwei Arten von Adressen:

1. Feste Adressen — immer dieselben, unabhängig von der Karte.
2. Adressen aus dem Zertifikat — stehen auf der jeweiligen Smartcard (AIA/CDP) und unterscheiden sich je Aussteller und ggf. je Karte. Autosign zeigt sie zur Laufzeit im Einstellungsfenster unter „Wartung & Diagnose → Netzadressen" an (rot/grün je Adresse, Autosign prüft sie beim Start und danach alle 15 Minuten). Die IT liest die konkreten Adressen dort ab und trägt sie in die Firewall-/Proxy-Freigabe ein.

Feste Hosts

• wunder-ip.com
• objects.githubusercontent.com
• release-assets.githubusercontent.com
• auth.wunder-ip.com
• gen4.atlas.wunderip.cloud

Konfigurations- und zertifikatsabhängige Quellen

• tsa
• ocsp
• crl
• aia

Erläuterung zu den festen Hosts — diese fünf sind immer dieselben, unabhängig von Konfiguration und Karte:

Warum wunder-ip.com und die beiden GitHub-Adressen: Der Update-Feed unter wunder-ip.com liefert selbst keine Installer-Binärdaten, sondern leitet mit einer 302-Weiterleitung auf die eigentliche Download-Adresse bei GitHub um. Eine Freigabe nur für wunder-ip.com reicht darum nicht — Auto-Update bleibt dann beim Download stecken, auch wenn der erste Zugriff (die Versionsabfrage) funktioniert.

Die vier übrigen Kategorien stehen NICHT fest im Code — sie hängen von der Konfiguration bzw. von der eingelegten Karte ab, und die konkrete Adresse zeigt Autosign zur Laufzeit im Einstellungsfenster unter „Wartung & Diagnose → Netzadressen":

Zur Kategorie tsa: Autosign fragt nur die TSA-Adresse an, die in den Einstellungen hinterlegt ist. Es gibt keine fest eingebaute Standard-TSA — darum ist sie hier als Kategorie und nicht als fester Host geführt. Eine konkrete TSA-Adresse muss konfiguriert und freigegeben werden, sobald ein Zeitstempel gebraucht wird (also praktisch immer, sonst bleibt die Signatur bei B-B hängen). Die tatsächliche Adresse bekommt die IT von der Kanzlei bzw. vom Zeitstempeldienst des Trust-Anbieters — anders als STOREPIN/AUTOUPDATE/ORDNER_* lässt sich tsaUrl nicht per MSI-Parameter oder policy.json vorbelegen, nur über das Einstellungsfenster.

Nur http://- und https://-Adressen werden angefragt; eine ldap://-Adresse in einer CRL-Erweiterung wird ignoriert (pyHanko ruft kein LDAP ab). Die drei zertifikatsabhängigen Kategorien (ocsp/crl/aia) fallen komplett weg, sobald LTV in den Einstellungen ausgeschaltet ist; tsa fällt weg, sobald keine TSA-URL eingetragen ist.

Anmeldung, Abrechnung und Kontingent

Autosign signiert nur, wenn sich jemand aus der Kanzlei mit dem Wunder-Konto angemeldet hat und die Kanzlei Signatur-Budget hat. auth.wunder-ip.com ist die Anmeldung, gen4.atlas.wunderip.cloud die Abrechnung.

• Was das Gerät sendet (je signierter Datei): Zeitpunkt, Stufe (B-B, B-T oder B-LT), einen zufälligen Schlüssel je Signatur (verhindert Doppelbuchungen) und den SHA-256-Hashwert der signierten Datei.
• Was das Gerät nicht sendet: keine Dateinamen, keine Dateiinhalte, keine PIN, keine Kartendaten, keine Ordnerpfade.
• Kontingent: Autosign reserviert vorab bis zu 20 Signaturen, die 7 Tage gültig sind. Fällt das Netz zu gen4.atlas.wunderip.cloud aus, signiert Autosign mit dem vorhandenen Kontingent weiter — bis zu 7 Tage offline. Ist das Kontingent aufgebraucht oder abgelaufen, hält die Warteschlange an (die PDFs bleiben in Ordner A), bis das Netz wieder da ist und ein neues Kontingent geholt wurde.

Proxy

Ein HTTP(S)-Proxy lässt sich im Einstellungsfenster eintragen (http://proxy:3128, optional mit Zugangsdaten in der URL). http://-Ziele gehen dann als absolute URI an den Proxy, https://-Ziele per CONNECT. Ohne Proxy-Eintrag geht Autosign direkt ins Netz.

Ohne Netz (isoliertes Netzwerk)

Ist LTV ausgeschaltet, ruft Autosign weder TSA noch OCSP/CRL ab (B-B statt B-LT) — die Signatur ist dann gültig, aber ohne Zeitstempel-/Sperrstatus-Nachweis zum Zeitpunkt der Prüfung Jahre später. Die Anmeldung und die Abrechnung brauchen trotzdem Netz zu auth.wunder-ip.com und gen4.atlas.wunderip.cloud; ein Netz ohne diese beiden Adressen trägt Autosign höchstens bis zum Ende des Kontingents (7 Tage).

6 · Ordner & Rechte

Drei Ordner, die Autosign braucht — alle drei müssen vor der Installation bzw. vor dem ersten Start existieren und für das Konto aus §7 lesbar und beschreibbar sein:

Validierungsregeln (werden beim Speichern der Einstellungen geprüft, mit Begründung abgelehnt): Ordner B darf nicht gleich Ordner A sein und nicht ineinander verschachtelt liegen; der Fehlerordner darf nicht gleich Ordner A oder Ordner B sein; alle drei müssen existieren und beschreibbar sein.

Innerhalb von Ordner A legt Autosign selbst einen Unterordner .in-arbeit/ an (bei englischer Oberfläche .in-progress/; nach einem Sprachwechsel holt Autosign beim Start die Reste aus dem anderen herüber) — Dateien, die gerade in Bearbeitung sind, liegen dort, nicht mehr direkt in A. Das ist kein Ort für die Kanzlei-IT, etwas hineinzulegen; nach einem Absturz oder Neustart räumt Autosign ihn selbst wieder auf.

Dateinamen: Eine zu signierende Datei muss auf .pdf enden und mit %PDF- beginnen; alles andere landet sofort im Fehlerordner. Während der Signatur heißt das Zwischenergebnis in Ordner B .~name.pdf (Punkt-Tilde-Präfix) — das Kanzlei-Programm soll solche Dateien ignorieren, falls es Ordner B ebenfalls beobachtet; sie werden immer in eine fertige name.pdf umbenannt, nie direkt sichtbar angelegt.

Namenskollision in Ordner B: Liegt dort bereits eine Datei name.pdf (z. B. weil das Kanzlei-Programm sie noch nicht abgeholt hat), wird nichts überschrieben. Das Ergebnis heißt dann name (2).pdf, beim nächsten Konflikt name (3).pdf usw. — wie im Windows-Explorer.

Ordner A, B und Fehler müssen auf demselben Laufwerk liegen wie .in-arbeit/ (innerhalb von A), damit das Umbenennen beim Signieren atomar bleibt. Liegt Ordner B auf einem anderen Laufwerk oder einer Netzfreigabe, kopiert Autosign dorthin (mit fsync) statt umzubenennen — das funktioniert, ist aber minimal langsamer.

7 · PIN & Neustart

E6 — Gespeicherte PIN (Standard: an)

Nach der ersten PIN-Eingabe speichert Autosign die PIN (bei D-Trust 5.x beide PINs) verschlüsselt über Windows DPAPI (Electron safeStorage) in %APPDATA%\Wunder Autosign\pin.bin. Diese Verschlüsselung ist gebunden an genau dieses Windows-Konto auf genau diesem Rechner und zusätzlich an die Seriennummer der Karte. Steckt eine andere Karte, unternimmt Autosign erst gar keinen Versuch und fragt neu. Wurde die PIN am Token geändert, löscht Autosign pin.bin nach dem einen fehlgeschlagenen Versuch sofort — es gibt nie einen zweiten automatischen Versuch (eine QES-Karte sperrt sich nach drei Fehlversuchen).

Abschalten:

• Dauerhaft bei der Installation: MSI-Parameter STOREPIN=0 bzw. NSIS-Parameter /STOREPIN=0 (s. §3), oder "STOREPIN": "0" in policy.json. Mit Policy aus wird eine zuvor gespeicherte pin.bin beim nächsten Start entfernt.
• Im laufenden Betrieb: Schalter im Einstellungsfenster, oder der Knopf „Gespeicherte PIN löschen" im Einstellungsfenster unter „Wartung & Diagnose" (löscht nur die gespeicherte PIN, nicht die Konfiguration).

E6a — Eigenes Windows-Konto mit automatischer Anmeldung

Wunder Autosign ist eine normale Electron-Anwendung, kein Windows-Dienst — sie läuft in einer Benutzersitzung und braucht dafür eine Anmeldung. Nach einem Neustart (z. B. durch ein Windows-Update) startet sie nur, wenn sich jemand anmeldet.

Für den unbeaufsichtigten Betrieb richtet die IT deshalb ein eigenes Windows-Konto ein, das sich automatisch anmeldet (z. B. über netplwiz oder die Registry-Werte AutoAdminLogon/DefaultUserName/DefaultPassword unter HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon). Autosign selbst trägt sich über den Windows-Autostart ein (im Einstellungsfenster „Mit Windows starten"), sodass es nach der automatischen Anmeldung ohne weiteres Zutun läuft.

Wichtig: Es muss immer dasselbe Konto sein, weil die DPAPI-Verschlüsselung aus §6 an das Konto gebunden ist. Ein Kontowechsel (neues Konto, neu erstelltes Profil) macht pin.bin unbrauchbar — Autosign fragt dann wieder nach der PIN.

8 · Updates

Auto-Update folgt demselben Ablauf wie Wunder Desktop/Wunder Sign (electron-updater, Provider generic, Feed https://wunder-ip.com/api/update/autosign). Ein Update wird nie mitten im Signieren installiert: Autosign wartet, bis die Warteschlange leer ist, installiert dann im Hintergrund und startet automatisch neu. Nach dem Neustart entsperrt sich die App wieder über die gespeicherte PIN (E6), falls aktiviert — ein Mensch muss nicht eingreifen.

Abschalten: MSI-/NSIS-Parameter AUTOUPDATE=0 bzw. "AUTOUPDATE": "0" in policy.json. Updates kommen dann nicht mehr automatisch; die IT verteilt neue Versionen selbst als neues MSI.

9 · Fehlersuche

Hauptfenster (über das Tray-Symbol öffnen) zeigt in Echtzeit: Zustand der Karte (Farbe), alles, was ohne PIN über die gesteckte Karte erkennbar ist (Anbieter, Kartenname, Kartennummer, Leser, PIN-Länge, Inhaber, Aussteller, Gültigkeit, QES ja/nein, Algorithmus, Hinweis „Testkarte"), die Warteschlange („Als Nächstes" mit der Datei in Arbeit und geplanten Wiederholungen, „Erledigt" mit Ergebnis, Stufe B-LT/B-T/B-B und Dauer). Das Einstellungsfenster zeigt unter „Wartung & Diagnose" rot/grün je Netzadresse mit Grund (z. B. „Zeitüberschreitung", „Name nicht auflösbar (DNS)", „Verbindung abgelehnt"). Eine Windows-Benachrichtigung erscheint, wenn ein Mensch eingreifen muss (PIN nötig, Karte gesperrt, keine QES-Karte erkannt, Zertifikat läuft in Kürze ab, eine Netzadresse ist rot).

Protokoll je Datei: Scheitert eine Datei, landet sie im Fehlerordner zusammen mit einer Datei name.pdf.fehler.txt (zweisprachig DE/EN), die den Grund in Klartext nennt — z. B. „Kein PDF" (%PDF--Kopf fehlt), „PDF verschlüsselt", „PDF ist bereits signiert" (Autosign signiert nie ein zweites Mal), oder ein Netzgrund bei TSA/OCSP nicht erreichbar (nach drei Wiederholversuchen im Abstand 1/5/30 Minuten).

Pause: Der runde Play/Pause-Knopf im Hauptfenster (oder der Tray-Menüpunkt „Warteschlange pausieren") hält die Warteschlange an: Eine Datei, die gerade signiert wird, wird noch fertig; danach nimmt Autosign keine neue Datei mehr — neue PDFs bleiben in Ordner A liegen und stehen unter „Als Nächstes". „Pausiert" steht im Hauptfenster und im Tray-Tooltip. Die Pause übersteht einen Neustart (gespeichert in config.json als "pausiert": true), damit nach einem Update oder Windows-Neustart nicht unbemerkt wieder signiert wird; erst „Fortsetzen" hebt sie auf. Wer Autosign per Softwareverteilung ausrollt und eine Pause zurücksetzen will, entfernt das Feld oder setzt es auf false.

Bei Netzproblemen: Der erste Fehler eines Dienstes (TSA oder OCSP) meldet sich sofort im Tray und im Hauptfenster; die Warteschlange hält deswegen nicht an — jede wartende Datei behält ihren eigenen Wiederholplan. Sobald der Dienst wieder erreichbar ist, werden alle wartenden Dateien sofort erneut versucht, ohne auf ihren nächsten Termin zu warten.

Protokolldatei/Diagnose-Export: Autosign führt ein durchsuchbares Protokoll (eine Zeile je signierte Datei mit Hash, Zertifikat, Dauer und Ergebnis, tägliche Rotation, 365 Tage Aufbewahrung) und zusätzlich ein allgemeines Betriebslog (ebenfalls tägliche Rotation, 7 Tage Aufbewahrung) — beide unter dem userData-Verzeichnis des Windows-Kontos, unter dem Autosign läuft. Der Knopf „Diagnose exportieren" im Einstellungsfenster (unter „Wartung & Diagnose") öffnet einen Speichern-Dialog und packt beides als ZIP-Datei (protokoll/*.jsonl + log/*.log) — ohne PDFs und ohne PIN (§4.8: die PIN erreicht diese Dateien nie). Liegt zum Zeitpunkt des Exports weder ein Protokoll noch ein Log vor (z. B. ganz frischer Start), enthält die ZIP statt dessen eine HINWEIS.txt. Dieses ZIP ist die erste Anlaufstelle für den Support, zusätzlich zum Hauptfenster selbst.

10 · Bekannte Grenzen

• Doppel-Lieferung bei Absturz im ungünstigsten Moment (Restrisiko): Der letzte Schritt beim Ablegen in Ordner B ist link(.~name.pdf → name.pdf) gefolgt von unlink(.~name.pdf). Holt das Kanzlei-Programm name.pdf genau in diesem schmalen Fenster zwischen diesen beiden Systemaufrufen ab, und stürzt Autosign im selben Moment ab, kann die Datei nach dem Neustart ein zweites Mal geliefert werden. Das Fenster umfasst zwei Systemaufrufe und ist in der Praxis extrem kurz; völlig ausschließen lässt es sich mit dem heutigen Ablauf nicht.
• Strenge Kettenregel bei LTV: Liegt der Root-Zertifikat nicht auf der Karte und hat die Zwischen-CA keine AIA-Adresse (caIssuers), aus der Autosign das fehlende Zertifikat nachladen könnte, signiert Autosign bei eingeschaltetem LTV nicht — die Datei bleibt mit der Begründung „Kette unvollständig" in der Warteschlange bzw. landet im Fehlerordner. Abhilfe: LTV ausschalten (dann B-B statt B-LT) oder eine Karte/einen Aussteller verwenden, deren Kette vollständig ist.
• MSI-Updates sind nicht policy-sicher — s. Empfehlung in §8: AUTOUPDATE=0 bei MSI-Installationen setzen.
• Diagnose-Export ohne Protokoll/Log liefert eine ZIP mit nur einer HINWEIS.txt statt echten Daten — s. §9.
• Isoliertes Netz + LTV widersprechen sich grundsätzlich: Ohne Netz gibt es keinen Zeitstempel und keinen Sperrstatus-Nachweis, also kein LTV („LTV aus" = B-B). Die Anmeldung und Abrechnung brauchen zusätzlich auth.wunder-ip.com und gen4.atlas.wunderip.cloud: ohne diese beiden Adressen signiert Autosign nur, solange das Kontingent reicht (bis zu 7 Tage), danach hält die Warteschlange an.

English

For the law firm's IT department. Wunder Autosign is not an application anyone operates day to day — it runs as an unattended folder watcher. This guide covers everything IT needs to set up once: network allowlisting, folder permissions, installation parameters, and the one Windows account the app runs under.

Table of contents (English)

1. What Autosign does
2. Requirements
3. Installation
4. policy.json
5. Network
6. Folders & permissions
7. PIN & restart
8. Updates
9. Troubleshooting
10. Known limitations

1 · What Autosign does

Wunder Autosign watches an input folder ("Folder A"). Every PDF that arrives there is automatically signed with the qualified electronic signature (QES) of the inserted smartcard (D-Trust or LuxTrust) — invisibly, with a timestamp and long-term validation proof (PAdES B-LT, "LTV"), with no human involved. The result lands in an output folder ("Folder B"). PDFs that cannot be signed are moved to an error folder together with a reason. Once the PIN has been entered, the app stays operational across weeks and restarts as long as the same card remains in the reader.

Folder A (inbox)  →  Autosign (card + pyHanko sidecar)  →  Folder B (signed)
                                  │
                                  └─ Error/  (could not sign, with reason)

The app runs as a tray program; the main window (card, PIN, queue with play/pause) and the settings window can be opened from the tray icon.

2 · Requirements

Install the card driver first

The middleware must be installed before Wunder Autosign, because the app looks for the PKCS#11 driver on startup:

• D-Trust: D-Trust Card Assistant 5 (cryptovision). Expected driver path: C:\Program Files\cryptovision\cvP11.dll (or one of the other vendor/ProgramData paths listed in DRIVER_PATHS).
• LuxTrust: LuxTrust Middleware. Expected driver path: C:\Program Files\LuxTrust\Middleware\ltpkcs11.dll (older installs: Gemalto/IDPrime gclib.dll).

Both drivers must not be loaded at the same time — when D-Trust is selected, Autosign excludes known conflicting drivers (gclib.dll, eTPKCS11.dll, ltpkcs11.dll).

3 · Installation

Wunder Autosign ships as an NSIS setup (.exe) and as an MSI. Both install per machine (perMachine), not per user.

Silent install via MSI (baramundi, Intune, SCCM)

msiexec /i "Wunder Autosign-0.1.0.msi" /qn ^
  STOREPIN=0 ^
  AUTOUPDATE=0 ^
  LANGUAGE=en ^
  ORDNER_A="D:\Firm\Inbox" ^
  ORDNER_B="D:\Firm\Signed" ^
  ORDNER_FEHLER="D:\Firm\Errors" ^
  /L*v "C:\Logs\autosign-install.log"

All six parameters are optional and independent. Omitting a parameter entirely leaves the existing value (the default, on first install) unchanged — an MSI with no parameters at all installs exactly as before.

Silent install via NSIS setup (.exe)

"Wunder Autosign Setup 0.1.0.exe" /S /STOREPIN=0 /AUTOUPDATE=0 /LANGUAGE=en ^
  "/ORDNER_A=D:\Firm\Inbox" "/ORDNER_B=D:\Firm\Signed" "/ORDNER_FEHLER=D:\Firm\Errors"

Same six parameter names, as /NAME=VALUE instead of an MSI property. Same rule: only the parameters passed in are written, everything else is left as is.

Both install paths write the parameters into a policy.json next to the .exe — that is the only place they end up (no registry).

4 · policy.json

policy.json lives next to the .exe (i.e. in the install directory, e.g. C:\Program Files\Wunder Autosign\policy.json) and overrides the values the user sets in the settings window — it is for IT, not for the end user.

{
  "STOREPIN": "0",
  "AUTOUPDATE": "0",
  "ORDNER_A": "D:\\Firm\\Inbox",
  "ORDNER_B": "D:\\Firm\\Signed",
  "ORDNER_FEHLER": "D:\\Firm\\Errors",
  "LANGUAGE": "en",
  "ATLAS_URL": "https://gen4.atlas.wunderip.cloud"
}

• All fields are optional; a missing field leaves the user value (or the default) untouched.
• STOREPIN/AUTOUPDATE: any value other than "0" or "false" (case-insensitive) counts as on — including an empty string or a missing line.
• ORDNER_*: a non-empty string sets the folder; it still shows in the settings window, but the policy wins again on every start.
• LANGUAGE: exactly de or en (case-insensitive) sets the language of the windows, the tray and the Windows notifications, and beats the "Sprache / Language" choice in the settings window. Any other value (including auto) has no effect — the user's choice then applies, default "Automatic" = system language.
• ATLAS_URL: overrides the address of the Atlas API (default https://gen4.atlas.wunderip.cloud) — this is where Autosign registers the device, fetches the quota and reports usage (see §5). For special cases only (your own server, a firm reverse proxy); it beats every other source. If you change it, allow the new address instead of gen4.atlas.wunderip.cloud — the network addresses in the settings window follow the value automatically. Not an MSI parameter, only in policy.json.
• The file may be saved with or without a UTF-8 BOM — Autosign strips it automatically on read (relevant because Windows PowerShell 5.1's Set-Content/Out-File write a BOM by default).
• If policy.json is unreadable (broken JSON), Autosign ignores it and falls back to the user values — a warning is logged, the app still starts.
• Precedence: policy.json (file) beats a machine-wide environment variable (STOREPIN=0, AUTOUPDATE=0, LANGUAGE=en), which in turn beats the saved user value. The environment variable only applies to STOREPIN/AUTOUPDATE/LANGUAGE, not to the folders. For LANGUAGE only exactly de/en counts — the Linux-style form LANGUAGE=en_US:en is deliberately ignored.

policy.json survives an auto-update through the NSIS installer: an update's uninstall step would otherwise move the entire install directory away and delete it, policy.json included. Autosign backs the file up before the update and restores it afterwards, before any new parameters (should the update carry any) replace it.

5 · Network

Wunder Autosign needs outbound network access: always for sign-in and billing (auth.wunder-ip.com, gen4.atlas.wunderip.cloud), plus for LTV (default) and auto-update (default). LTV and auto-update can be switched off, sign-in cannot — without network access to those two addresses Autosign keeps signing only while the local quota lasts (up to 7 days, see below and §10).

The firewall/proxy allowlist needs two kinds of addresses:

1. Fixed addresses — always the same, independent of the card.
2. Addresses from the certificate — they live on the particular smartcard (AIA/CDP) and differ by issuer and sometimes by card. Autosign shows them at runtime in the settings window under "Maintenance & diagnostics → Network addresses" (red/green per address; checked on startup and every 15 minutes after). IT reads the concrete addresses there and adds them to the firewall/proxy allowlist.

Fixed hosts

• wunder-ip.com
• objects.githubusercontent.com
• release-assets.githubusercontent.com
• auth.wunder-ip.com
• gen4.atlas.wunderip.cloud

Configuration- and certificate-dependent sources

• tsa
• ocsp
• crl
• aia

Notes on the fixed hosts — these five are always the same, independent of configuration and card:

Why both wunder-ip.com and the two GitHub addresses: the update feed at wunder-ip.com does not serve the installer binary itself — it 302-redirects to the actual download location on GitHub. An allowlist entry for wunder-ip.com alone is not enough — auto-update then gets stuck on the download, even though the first request (the version check) succeeds.

The remaining four categories are NOT fixed in the code — they depend on configuration or on the inserted card, and Autosign shows the concrete address at runtime in the settings window under "Maintenance & diagnostics → Network addresses":

On the tsa category: Autosign only ever contacts the TSA address configured in settings. There is no built-in default TSA — that is why it is listed as a category here rather than as a fixed host. A concrete TSA address must be configured and allowlisted as soon as a timestamp is needed (which in practice is always — otherwise the signature stays at B-B). IT gets the actual address from the firm or from the trust provider's timestamp service — unlike STOREPIN/AUTOUPDATE/ORDNER_*, tsaUrl cannot be pre-filled via an MSI parameter or policy.json, only through the settings window.

Only http:// and https:// addresses are contacted; an ldap:// address found in a CRL extension is ignored (pyHanko does not fetch over LDAP). The three certificate-dependent categories (ocsp/crl/aia) disappear entirely once LTV is switched off in settings; tsa disappears once no TSA URL is configured.

Sign-in, billing and quota

Autosign only signs once someone from the firm has signed in with their Wunder account and the firm has signature budget. auth.wunder-ip.com is the sign-in, gen4.atlas.wunderip.cloud is billing.

• What the device sends (per signed file): the time, the level (B-B, B-T or B-LT), a random key per signature (prevents double booking) and the SHA-256 hash of the signed file.
• What the device does not send: no file names, no file contents, no PIN, no card data, no folder paths.
• Quota: Autosign reserves up to 20 signatures in advance, valid for 7 days. If the network to gen4.atlas.wunderip.cloud goes down, Autosign keeps signing with the quota it holds — up to 7 days offline. Once the quota is used up or expired, the queue stops (the PDFs stay in Folder A) until the network is back and a new quota has been fetched.

Proxy

An HTTP(S) proxy can be entered in the settings window (http://proxy:3128, optionally with credentials in the URL). http:// targets are sent as an absolute URI to the proxy, https:// targets via CONNECT. Without a proxy entry, Autosign connects directly.

No network (isolated network)

With LTV switched off, Autosign fetches neither TSA nor OCSP/CRL (B-B instead of B-LT) — the signature is still valid, but without a timestamp/revocation proof at the time of a check years later. Sign-in and billing still need network access to auth.wunder-ip.com and gen4.atlas.wunderip.cloud; a network without those two addresses carries Autosign only until the quota runs out (7 days).

6 · Folders & permissions

Three folders Autosign needs — all three must exist before installation / before the first start and be readable and writable for the account from §7:

Validation rules (checked when settings are saved, rejected with a reason): Folder B must not equal Folder A and the two must not be nested inside each other; the error folder must not equal Folder A or Folder B; all three must exist and be writable.

Inside Folder A, Autosign creates its own subfolder .in-progress/ (.in-arbeit/ when the interface is German; after a language change Autosign moves leftovers over on the next start) — files currently being processed live there, no longer directly in A. This is not a place for IT to drop anything into; Autosign cleans it up itself after a crash or restart.

File names: a file to be signed must end in .pdf and start with %PDF-; anything else goes straight to the error folder. While signing, the intermediate result in Folder B is named .~name.pdf (dot-tilde prefix) — the firm's application should ignore such files if it also watches Folder B; they are always renamed to the final name.pdf, never created directly under their final name.

Name collision in Folder B: if a file name.pdf already exists there (e.g. because the firm's application has not picked it up yet), nothing is overwritten. The result is instead named name (2).pdf, then name (3).pdf and so on — the same convention as Windows Explorer.

Folders A, B and Error should sit on the same drive as .in-progress/ (inside A), so the rename-on-sign step stays atomic. If Folder B is on a different drive or a network share, Autosign copies there (with fsync) instead of renaming — this works, but is marginally slower.

7 · PIN & restart

E6 — Stored PIN (default: on)

After the first PIN entry, Autosign stores the PIN (both PINs, for D-Trust 5.x) encrypted via Windows DPAPI (Electron safeStorage) in %APPDATA%\Wunder Autosign\pin.bin. This encryption is bound to this exact Windows account on this exact machine, and additionally to the card's serial number. If a different card is inserted, Autosign does not even attempt to use it and asks again. If the PIN was changed on the token, Autosign deletes pin.bin immediately after the one failed attempt — there is never a second automatic attempt (a QES card locks after three failed attempts).

Disabling it:

• Permanently at install time: MSI parameter STOREPIN=0 or NSIS parameter /STOREPIN=0 (see §3), or "STOREPIN": "0" in policy.json. With the policy off, a previously stored pin.bin is removed on the next start.
• At runtime: the toggle in the settings window, or the "Delete saved PIN" button in the settings window under "Maintenance & diagnostics" (deletes only the stored PIN, not the rest of the configuration).

E6a — Dedicated Windows account with automatic logon

Wunder Autosign is a regular Electron application, not a Windows service — it runs in a user session and needs a logon for that. After a restart (e.g. triggered by a Windows update), it only starts once someone logs in.

For unattended operation, IT therefore sets up a dedicated Windows account that logs on automatically (e.g. via netplwiz or the registry values AutoAdminLogon/DefaultUserName/DefaultPassword under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon). Autosign registers itself with Windows autostart (via "Start with Windows" in the settings window), so it runs without further action once the automatic logon has happened.

Important: it must always be the same account, because the DPAPI encryption from §6 above is bound to that account. Switching accounts (a new account, a freshly created profile) makes pin.bin unusable — Autosign will ask for the PIN again.

8 · Updates

Auto-update follows the same flow as Wunder Desktop/Wunder Sign (electron-updater, provider generic, feed https://wunder-ip.com/api/update/autosign). An update is never installed in the middle of signing: Autosign waits until the queue is empty, then installs in the background and restarts automatically. After the restart, the app unlocks itself again using the stored PIN (E6), if enabled — no human needs to intervene.

Disabling it: MSI/NSIS parameter AUTOUPDATE=0, or "AUTOUPDATE": "0" in policy.json. Updates then no longer arrive automatically; IT distributes new versions itself as a new MSI.

9 · Troubleshooting

Main window (open from the tray icon) shows in real time: card state (colour), everything that can be read from the inserted card without a PIN (provider, card name, card number, reader, PIN length, holder, issuer, validity, QES yes/no, algorithm, a "Test card" hint), and the queue ("Up next" with the file in progress and scheduled retries, "Done" with result, level B-LT/B-T/B-B and duration). The settings window shows red/green per network address with a reason under "Maintenance & diagnostics" (e.g. "timeout", "name not resolvable (DNS)", "connection refused"). A Windows notification appears whenever a human needs to act (PIN required, card locked, no QES card detected, certificate expiring soon, a network address is red).

Per-file record: if a file fails, it is moved to the error folder together with a name.pdf.fehler.txt file (bilingual DE/EN) stating the reason in plain language — e.g. "not a PDF" (missing %PDF- header), "PDF is encrypted", "PDF is already signed" (Autosign never signs a file a second time), or a network reason when TSA/OCSP is unreachable (after three retries spaced 1/5/30 minutes apart).

Pause: the round play/pause button in the main window (or the tray menu item "Pause queue") stops the queue: a file that is being signed right now is still finished; after that Autosign takes no new file — new PDFs stay in folder A and are listed under "Up next". "Paused" is shown in the main window and in the tray tooltip. The pause survives a restart (stored in config.json as "pausiert": true), so that signing does not silently resume after an update or a Windows restart; only "Resume" lifts it. To reset a pause via software distribution, remove the field or set it to false.

On network trouble: the first failure of a given service (TSA or OCSP) is reported immediately in the tray and the main window; the queue does not stop because of it — every waiting file keeps its own retry schedule. As soon as the service is reachable again, all waiting files are retried immediately, without waiting for their next scheduled attempt.

Log file / diagnostics export: Autosign keeps a searchable audit log (one line per signed file with hash, certificate, duration and result; daily rotation, 365-day retention) plus a general operational log (also daily rotation, 7-day retention) — both under the userData directory of the Windows account Autosign runs as. The "Export diagnostics" button in the settings window (under "Maintenance & diagnostics") opens a save dialog and packs both into a ZIP file (protokoll/*.jsonl + log/*.log) — without PDFs and without the PIN (§4.8: the PIN never reaches these files). If neither a log nor an audit record exists at export time (e.g. a very fresh start), the ZIP contains a HINWEIS.txt instead. This ZIP is the first point of contact for support, in addition to the main window itself.

10 · Known limitations

• Double delivery on a crash at the worst possible moment (residual risk): the last step when placing a file in Folder B is link(.~name.pdf → name.pdf) followed by unlink(.~name.pdf). If the firm's application picks up name.pdf exactly in the narrow window between these two system calls, and Autosign crashes at the same moment, the file can be delivered a second time after the restart. The window spans two system calls and is extremely short in practice; it cannot be fully ruled out with the current flow.
• Strict chain rule under LTV: if the root certificate is not on the card and the intermediate CA has no AIA address (caIssuers) from which Autosign could fetch the missing certificate, Autosign will not sign while LTV is on — the file stays queued or ends up in the error folder with the reason "chain incomplete" ("Kette unvollständig"). Workaround: turn LTV off (B-B instead of B-LT), or use a card/issuer whose chain is complete.
• MSI updates are not policy-safe — see the recommendation in §8: set AUTOUPDATE=0 for MSI installs.
• Diagnostics export without a log/audit record yields a ZIP containing only a HINWEIS.txt instead of real data — see §9.
• Isolated network + LTV are fundamentally at odds: without network access there is no timestamp and no revocation proof, hence no LTV ("LTV off" = B-B). Sign-in and billing additionally need auth.wunder-ip.com and gen4.atlas.wunderip.cloud: without those two addresses Autosign signs only while the quota lasts (up to 7 days), after that the queue stops.