Es hat etwas Tragikkomisches an sich, dass im Jahre 2021 die rechtssichere Unterzeichnung von Dokumenten noch immer zum Großteil mittels monströs-grotesker, völlig ineffizienter und unökologischer Provisorien erfolgt wie dem berüchtigten Workflow Dokument ausdrucken – von Hand unterschreiben – wieder einscannen und dann als PDF via Email versenden (inklusive Rechtshinweis, dass der Versand der Email ungesichert erfolgt, der Betroffene sich dieser Tatsache bewusst ist und sein Einverständnis damit erklärt). Getoppt wird das nur noch durch Faxe und den Dokumentversand per Briefpost.

Dabei gibt es seit über zwei Jahrzehnten die Technologie und die rechtlichen Voraussetzungen, all diese Vorgänge sicher auf digitaler Ebene abzuwickeln, so wie es für Websites zur gesicherten Übertragung von Daten in Form von (HTTPS respektive SSL) geschieht.

Doch während sich SSL langsam, aber sicher durchgesetzt hat und heute als weitverbreiteter Standard gelten kann, ist das für signierte und verschlüsselte Emails weit weniger der Fall und für digital signierte PDFs so gut wie gar nicht.

Das hat seinen Grund primär darin, dass sich bei Websites nur die Website-Betreiber mit der neuen Technologie herumschlagen mussten, nicht aber die Website-Besucher, für die alles wie von selbst funktionierte, sobald ein Webbrowser-Update, das die Nutzer ohnehin vornahmen, automatisch die hierfür erforderliche Technologie mitbrachte.

Im Gegensatz zu Websites, wo ein asymmetrisches Verhältnis zwischen Betreiber und Besuchern besteht, sind Email-Verkehr und Austausch unterzeichneter Dokumente aber symmetrische Vorgänge; jeder Nutzer müsste also selbst ähnlich aktiv werden wie bei Websites nur der Betreiber (im Kern müsste er sich ein digitales Zertifikat besorgen).

Das hat die Adaptionsrate entscheidend begrenzt. Infolgedessen blieb die Technologie aufgrund kleiner Stückzahlen teuer (was digitale Zertifikate zum Signieren von PDFs betrifft, für Privatleute definitiv zu teuer) und die Softwarehersteller verwendeten nur wenig Energie darauf, eine kaum genutzte Technologie leichter handhabbar zu machen, was wiederum die Adaptionsrate niedrig hielt – der übliche Teufelskreis.

Wenn wir nicht 2050 immer noch faxen wollen, kann es so aber nicht weitergehen. Ich hatte daher Anfang 2021 zum wiederholten Mal einen Anlauf gemacht zu prüfen, ob digital unterschriebene PDFs mittlerweile für Privatnutzer (und kleine Unternehmen) praktikabel sein könnten, zumal ich diesmal Anhaltspunkte dafür hatte, dass es an der Preisfront – von der IT-Öffentlichkeit weitgehend unbemerkt – einen Durchbruch gegeben haben könnte. (Um es vorwegzunehmen: Hat es; man ist jetzt ab 35€/Jahr (statt bislang mehr als 300€/Jahr) dabei, so viel wie das Briefporto für drei Briefe pro Monat. Und die Installation und Konfiguration sind mittlerweile zumindest einfach genug, um sie mithilfe dieser Anleitung bewältigen zu können. )

Während ich noch bei der Recherche war, fragte @mac auf MacTechNews nach für ihn brauchbaren PDF-Editoren jenseits von Adobe und trat damit einen laaangen Thread los, der sich über ein halbes Jahr erstreckte und bald auf digitale Signaturen konzentrierte: Alternative zu kostenpflichtigen PDF Tools wie Acrobat Pro/DC oder pdf won.... Diesem Thread, in den ich mich einklinkte, verdanke ich viele wichtige Informationen und Impulse, für die ich mich bei allen bedanken will, die dazu beigetragen haben, vornedran marm.

Das Resultat meiner Recherchen und Erfahrungen will ich in diesem Beitrag als hoffentlich verständliche und nachvollziehbare „Kochbuch“-Anleitung zum digitale Unterschreiben von PDFs präsentieren.

Dabei gilt es noch vor Beginn, eines klarzustellen: Es kursieren unter der Überschrift Digitales Signieren zwei völlig unterschiedliche Verfahren. Das eine Verfahren ist das Signieren von PDFs mit digitaler Zertifikate, die auf dem lokalen Rechner gespeichert sind und mit denen man die entsprechenden Dokumente eigenhändig versieht. Das ist das Verfahren, um das es hier ausschließlich gehen soll.

Es gibt noch eine zweite Variante, nämlich Software as a Service: Dazu lädt man sein PDF auf einen Server des entsprechenden Anbieters in les- und bearbeitbarer Form hoch, der unterschreibt es für einen (nachdem man beim Anlegen des Kundenkontos seine Identität nachgewiesen hat), ohne es ansonsten zu verändern, und sendet es dann zurück. Das muss man wollen, gerade bei potentiell wichtigen und vertraulichen Dokumenten, die unterschrieben werden müssen, aber keinesfalls mehr verändert werden dürfen.

Softwareanbieter lieben Software as a Service, weil das kontinuierliche Einnahmen sprudeln lässt. Von Seiten der Kunden ist es meist Bequemlichkeit, weil sie so von einer eventuellen technischen Komplexität des Vorgangs abgeschirmt werden; eine Datei auf einen Webserver hochladen kann dagegen heute jeder und der „Cloud“ wird oft blind vertraut.

Bei digitalen Unterschriften gibt es freilich einen validen Grund, solch einen Dienst in Anspruch zu nehmen: Die entsprechenden Dienste bieten praktisch alle an, bei Dokumenten, die von sehr vielen verschiedenen Personen unterzeichnet werden müssen (Teilnahmelisten zum Beispiel), diese Unterschriften alle einzuholen (die Unterzeichnenden werden dafür aufgefordert, sich alle auf dem Webserver des Dienstleisters anzumelden) und erst am Schluss das von allen unterzeichnete PDF an den Auftraggeber zurückzusenden, der somit die gesamte Arbeit des Sammelns los ist. Wenn die Dokumente selbst, wie eben etwa bei Teilnahmelisten, nicht besonders streng vertraulich sind, mag ein solcher Dienst hilfreich sein.

Ansonsten würde ich solch einen Dienst (es gibt viele verschiedene, typischerweise heißen sie alle xyz Sign, zum Beispiel Adobe Sign) schwerlich nutzen. Wie auch immer, um diese Form des Signierens geht es in dieser Anleitung nicht.


Ich habe die einzelnen Schritte in je einem eigenen Kapitel geschildert, die jeweils einem Posting entsprechen. Ich weiß, dass ich für meine langen Texte berüchtigt bin, aber bitte nicht erschrecken! Diese Anleitung hier ist nicht so lang, weil alles so kompliziert ist, sondern weil sie es einfach machen will, indem sie wirklich jeden Schritt schildert (und damit verbunden wegen der vielen Screenshots). Außerdem befasst sich die Anleitung zum allergrößten Teil mit der Einrichtung; ist erst einmal alles eingerichtet, geht das digitale Unterschreiben flott von der Hand.

Die Kapitel:
1. Rechtliche Situation
2. Kurzanleitung
3. Kauf eines D-TRUST-Personenzertifikats
      3a. Bestellung bei D-TRUST
      3b. Bestellung bei PSW
4. Zertifikat-Installation auf macOS
5. Verwendung des Zertifikats zum Signieren und Verschlüsseln von Email in Mail
6. Wahl des PDF-Programms
7. Zertifikat-Installation in Acrobat Reader
8. Konfiguration eines Zeitstempelservers
9. Das digitale Unterschreiben in Acrobat Reader
10. Die Validierung der digitalen Unterschrift in Acrobat Reader
11. Fehlerquellen
12. Tipps und Tricks


Ich hoffe, dass diese Anleitung viele von Euch ermutigt, sich mit dem Thema auseinanderzusetzen. Ist sozusagen mein kleiner Beitrag zum gegenwärtigen Aufbruch in die Digitalisierung. Die hängt ja nicht nur von unserer Regierung ab, sondern auch von uns.

1. Rechtliche Situation

Niemand bei Trost liest die allgemeinen Geschäftsbedingungen von iTunes, aber mit den rechtlichen Aspekten elektronischer Unterschriften müssen wir uns kurz befassen – schließlich ist der ganze Daseinszweck elektronischer Signaturen ein rein rechtlicher.

Die rechtlichen Grundlagen für elektronische Signaturen bzw. elektronische Unterschriften (die beiden Begriffe werden hier synonym verwendet) sind seit 2014 EU-weit in der eIDAS-Verordnung (electronic IDentification, Authentication and trust Services) niedergelegt. Danach sind 3 Arten von elektronischen Unterschriften zu unterscheiden:

• die einfache elektronische Signatur
• die fortgeschrittene elektronische Signatur
• die qualifizierte elektronische Signatur

Die einfache elektronische Signatur muss keinerlei besondere Anforderungen erfüllen. Wenn man seinen Namen unter ein Dokument tippt oder Name und Adresse in einer Email-Signatur an seine Emails anhängt, ist das bereits eine einfache elektronische Signatur. Dass deren Beweiskraft im Streitfall gering ist, wird niemanden überraschen; schließlich kann auch jeder andere den eigenen Namen tippen. Überraschender ist da vielleicht, dass auch das heute so oft praktizierte Verfahren, einen Ausdruck zu unterschreiben und dann wieder einzuscannen oder alternativ einen existierenden Scan der eigenen Unterschrift in das PDF einzufügen oder dafür mittels Trackpad oder iPad ad hoc zu zeichnen, ebenfalls nur eine einfache Signatur ist und damit rechtlich keinen Deut mehr Wert besitzt. Bei näherem Hinsehen ist das aber verständlich: Schließlich sind das auch nur (Pixel-)Daten, die genauso gut jeder andere, der jemals ein Dokument mit der fraglichen Unterschrift erhalten hat, in das Dokument würde einfügen können. Das, was in der analogen Welt relativ zuverlässig funktioniert, lässt sich hier nicht in die digitale Welt übertragen (dumm nur, wenn aufgrund unserer Erfahrungen in der analogen Welt der Scan einer Unterschrift in der digitalen Welt vertrauenserweckender wirkt als der Name in ASCII-Buchstaben). Dass auch Banken und Behörden solchen Pixelbildern vertrauen (und die PDFs dann über unverschlüsselte Emails senden und empfangen), zeigt nur die gegenwärtige Hilflosigkeit angesichts des digitalen Nachholbedarfs.

Die fortgeschrittene elektronische Signatur verwendet kryptographische Verfahren, durch die der Unterschrift der Unterzeichner eindeutig zugeordnet werden kann und identifizierbar ist, und die sicherstellen, dass mit hoher Sicherheit nur der rechtmäßige Unterzeichner sie leisten kann (durch ein nur ihm bekanntes Passwort). Zudem muss erkennbar sein, wenn der Inhalt des unterschriebenen Dokuments nach der Unterschrift nochmals verändert wurde.

Während elektronische Signatur der juristische Begriff ist, wird eine solche Umsetzung mit kryptographischen Mitteln technisch als digitale Signatur bezeichnet, hier also fortgeschrittene digitale Signatur (obwohl natürlich eine einfache elektronische Signatur, etwa der Name des Unterzeichners in ASCII-Buchstaben, auch schon digital ist … Juristendeutsch halt).

Die qualifizierte digitale Signatur ist die fortgeschrittene digitale Signatur mit Zwei-Faktor-Authentifizierung. Der zweite Faktor wird dabei mit dem eleganten Wortungetüm sichere Signaturerstellungseinheit (SSEE) bezeichnet; de facto handelt es sich um eine Chipkarte mit speziellem Chipkarten-Lesegerät oder um einen USB-Dongle (in diesem Kontext als USB Token bezeichnet).


Die qualifizierte Signatur ist einer eigenhändigen Unterschrift bis auf wenige Ausnahmen gleichgestellt; die fortgeschrittene digitale Signatur hingegen ist nur dort rechtlich anerkannt, wo der Gesetzgeber die Schriftform einer Vereinbarung nicht zwingend vorsieht. Dies ist laut Wikipedia freilich in 95% aller Vereinbarungen der Fall; nur wenige Vorgänge (Arbeits- oder Wohnungskündigungen zum Beispiel) erfordern zwingend die Schriftform.

Dass bei den 95% aller Vereinbarungen, die nicht zwingend die Schriftform erfordern, sowohl einfache als auch fortgeschrittene Signatur grundsätzlich zulässig sind und beide vor Gericht der freien Beweiswürdigung unterliegen (im Gegensatz zur qualifizierten Signatur, die bis auf festgelegte Ausnahmen stets der eigenhändigen Unterschrift gleichgesetzt ist), führt mancherorts zu der These, die fortgeschrittene Signatur sei auch nicht besser als die einfache; das ist aber nicht der Fall. Freie Beweiswürdigung bedeutet ja gerade, dass das Gericht die Umstände individuell betrachtet und bewertet, und da hat eine fortgeschrittene Signatur natürlich ein ganz anderes Gewicht als eine einfache.

Zertifikate für fortgeschrittene Signaturen haben aber auch ihre Vorteile: vom teils deutlich geringeren Preis abgesehen können sie zugleich für das Signieren und Verschlüsseln von Emails eingesetzt werden; das ist bei den qualifizierten Zertifikaten nicht möglich. Manche (allerdings eher hochpreisige) Zertifikatsanbieter legen daher ihren qualifizierten Zertifikaten noch kostenlos fortgeschrittene Zertifikate bei.

Für Mac-Nutzer kommt aber vor allem noch dazu, dass die preiswerten Zertifikate, die in dieser Anleitung Verwendung finden, in ihrer qualifizierten Form für den Mac noch nicht erhältlich sind. Diese Anleitung wird also ein fortgeschrittenes Zertifikat verwenden; ich glaube, das ist zur Zeit eine sehr praxistaugliche Lösung. Wer unbedingt ein qualifiziertes Zertifikat will, muss sich noch ein wenig gedulden.

2. Kurzanleitung

Wer ungeduldig ist, ausführliche Anleitungen nicht mag und sich zutraut, die auftretenden Hürden allesamt allein zu umschiffen, für den gibt es hier eine Kürzestanleitung. Außerdem soll kurz gezeigt werden, wie nach erfolgreicher Installation das digitale Unterschreiben abläuft, um einen Eindruck davon zu bekommen, was das Ziel der ganzen Übung ist.



Kurzanleitung

1. Ein digitales fortgeschrittenes Personenzertifikat Advanced Personal ID von D-TRUST bestellen bei

• D-TRUST direkt – ohne technische Kenntnisse zu beantragen, aber über den Postweg mit einer Bearbeitungsdauer von mehreren Wochen und etwas teurer (94€/2 Jahre)
• dem „Wiederverkäufer“ PSW – erfordert ein paar technische Kenntnisse, dauert aber nur ein oder zwei Arbeitstage und ist etwas billiger (69€/2 Jahre oder 39€/1 Jahr)

2. Das erhaltene Zertifikat mit dem Suffix .p12 per Doppelklick im macOS-Schlüsselbund Anmeldung installieren

3. Sofern nicht schon vorhanden, den Acrobat Reader von Adobe installieren

4. In Acrobat Reader → Einstellungen → Unterschriften → Zeitstempel für Dokumente → Weitere… einen freien Uhrzeitstempelserver aus dieser Github-Liste auswählen, eintragen und als Standardeinstellung festlegen

5. In Acrobat Reader → Einstellungen → Vertrauensdienste → Automatische Updates für Adobe Approved Trust List (AATL) auf Jetzt aktualisieren klicken; dasselbe für die European Union Trusted Lists (EUTL) wiederholen



Digitales Unterschreiben

1. Im Acrobat Reader in der Werkzeugleiste Zertifikate das Werkzeug Digital signieren auswählen




2. Einen Rahmen aufziehen, um den Ort der Unterschrift festzulegen:




3. Das bestellte und installierte D-TRUST-Zertifikat auswählen:




4. Unterschreiben und das Dokument sperren, falls keine weiteren Unterschriften mehr erforderlich sind:




5. Fertig:

3. Kauf eines D-Trust-Personenzertifikats

Digitale Zertifikate

Digitale Unterschriften basieren (wie auch die Signatur und Verschlüsselung von Emails und in leicht angepasster Form HTTPS-Websites) auf einer sogenannten Public-Key-Infrastruktur (PKI). Die beruht zum einen auf dem bekannten Konzept eines asymmetrischen Schlüsselpaares. Der Eigentümer (und nur er) des (geheimgehaltenen, nur ihm bekannten) privaten Schlüssels kann mit seiner Hilfe zu jedem beliebigen Satz digitaler Daten (also auch einem Dokument in einem spezifischen Zustand) einen einzigartigen Wert berechnen, dessen Korrektheit von jedem, der den dazugehörigen öffentlichen Schlüssel besitzt, überprüft werden kann. So kann der Überprüfende sicher sein, dass das Dokument vom Eigentümer des privaten Schlüssels mit dem berechneten Wert versehen = signiert und seitdem auch nicht mehr verändert wurde. (Bei Emails kommt noch hinzu, dass jeder, der den öffentlichen Schlüssel kennt, dessen Eigentümer einen mit dem öffentlichen Schlüssel verschlüsselten Text zukommen lassen kann, den nur der Eigentümer mit seinem zugehörigen privaten Schlüssel wieder entschlüsseln kann.)

Die (mathematische) Pointe dabei ist, dass es keine Möglichkeit gibt, aus dem öffentlichen Schlüssel den privaten zu berechnen. Daher kann der öffentliche Schlüssel problemlos jedem signierten Dokument beigefügt (und mit jeder Email mitgesandt) werden.

Damit ist das Problem einer digitalen Signatur aber nur zur Hälfte gelöst. Der Empfänger von Dokument (oder Email) kann sich zwar sicher sein, dass es (sie) vom Eigentümer des Schlüsselpaares stammt. Aber er kann nicht sicher wissen, wer dieser Eigentümer ist.

Daher muss es zum anderen noch ein Verfahren geben, einem öffentlichen Schlüssel eine eindeutige Identität zuzuordnen (der dazugehörige private Schlüssel hat sie dadurch auch, da er ja nur zu diesem öffentlichen Schlüssel passt). Dies geschieht durch ein sogenanntes digitales Zertifikat, eine Datei, die nicht nur den öffentlichen Schlüssel, sondern eben zusätzlich auch noch die zugehörige Identität (Person oder Email-Adresse) und andere Angaben wie Laufzeit und Verwendungszweck enthält. Man kann also darauf vertrauen, dass der öffentliche Schlüssel die Identität repräsentiert, die er zu repräsentieren vorgibt – wenn man dem Zertifikat vertraut. Das kann man, weil dieses Zertifikat seinerseits durch ein übergeordnetes Zertifikat via asymmetrischem Schlüsselpaar signiert (und dadurch in seiner Vertrauenswürdigkeit bestätigt) ist, und so fort.

So gelangt man zu einer hierarchischen Kette von Zertifikaten, die natürlich irgendwo enden muss. Das tut sie bei der Mutter aller Vertrauenswürdigkeit, dem Root-Zertifikat (Wurzelzertifikat), dessen Authentizität man ohne weitere Überprüfungsmöglichkeit vertrauen muss. Root-Zertifikate werden daher so scharf überwacht wie die Formel für Coca Cola und von anerkannten Zertifizierungsstellen (englisch Certificate Authorities, kurz CAs, deutsch alternativ auch Zertifizierungsinstanz) herausgegeben, die diversen, behördlich kontrollierten Sicherheitsauflagen genügen müssen, um eine Zulassung zu bekommen.

Root-Zertifikate werden aufgrund ihrer zentralen Bedeutung und strengen Überwachung möglichst selten zum Signieren benutzt, weil für den Moment des Signierens irgendjemand mit ihrem geheimen privaten Schlüssel hantieren muss. Endnutzer-Zertifikate für digitale Unterschriften oder die Verschlüsselung von Emails werden daher nicht direkt durch das Root-Zertifikat einer Zertifizierungsstelle beglaubigt, sondern durch „Zwischenzertifikate“, die ihrerseits vom Root-Zertifikat beglaubigt werden – das ist der Grund für Zertifikatsketten. Die privaten Schlüssel der Root-Zertifikate selbst müssen dadurch nur die (wenigen) Zwischenzertifikate beglaubigen, nicht die (vielen) Zertifikate der einzelnen Endnutzer.

Root-Zertifikate müssen einem Computer, insbesondere einem Webbrowser, logischerweise immer schon bekannt sein, bevor eine damit gesicherte Verbindung aufgebaut werden kann; Zwischenzertifikate kann er sich dann bei Bedarf selbst holen. Insofern entscheiden die Betriebssystem-Hersteller dadurch, welche Root-Zertifikate sie auf ihrem Betriebssystem vorinstallieren, in der Praxis darüber, welche Zertifizierungsstellen allgemein anerkannt sind und somit generell genutzt werden können. In der macOS-Schlüsselbundverwaltung sind die von Apple anerkannten Root-Zertifikate im Schlüsselbund System-Roots abgelegt. Apple verwendet für Root- und Zwischenzertifikate die Bezeichnungen Root- und Intermediate-Zertifizierungsinstanz, was etwas seltsam ist, da Zertifizierungsinstanz üblicherweise ja eine Organisation bezeichnet, die Zertifikate ausgibt, und nicht die Zertifikate selbst.

Registrierungsstellen (englisch Registration Authorities, kurz RAs) sind diejenigen, die Zertifikate für einzelne Nutzer ausstellen und dafür deren Identität überprüfen. Nach erfolgreicher Überprüfung erstellen sie in einem technisch vorgegebenen Format einen Certificate Signing Request (kurz CSR, deutsch Zertifikatsignierungsanforderung), der den öffentlichen Schlüssel eines Schlüsselpaares plus den dazugehörigen Angaben zur Identität des Nutzers enthält, und senden ihn an die Zertifizierungsstelle, die daraus das Zertifikat erzeugt und mit dem privaten Schlüssel des übergeordneten (Zwischen-)Zertifikats signiert und somit beglaubigt.

Wenn nur die Authentizität einer Email-Adresse beglaubigt werden soll (was für Verschlüsselung von Emails ausreicht), kann dies weitgehend automatisiert geschehen, indem der Prozess über eben diese Email-Adresse abgewickelt wird; daher sind entsprechende Zertifikate eher preiswert. Für digitale Unterschriften wird hingegen zwingend ein digitales Personenzertifikat benötigt (um die Feststellung der Person des Unterzeichners geht es ja gerade); dafür ist dann z.B. eine Kopie des Personalausweises vonnöten, aus dem die Personendaten entnommen werden, was Aufwand und Kosten erhöht.

Registrierungsstellen können als eigenständige Unternehmen agieren, die mit Zertifizierungsstellen kooperieren, oder eine Zertifizierungsstelle kann ihre eigene Registrierungsstelle unterhalten.



Adobes Extrawurst zum Signieren von PDFs

Die in den Betriebssystemen vorinstallierten Root-Zertifikate sind ja eigentlich per definitionem vertrauenswürdig. Als Adobe als Urheber des PDF-Formats aber daran ging, digitale Signaturen für PDFs zu standardisieren, waren ihnen selbst die nicht sicher genug. Das mag Eigeninteresse gewesen sein, es gab allerdings tatsächlich schon aller Überwachung zum Trotz Sicherheitslecks bei Zertifizierungsstellen.

Daher lässt Adobe für digitale Signaturen nur eine handverlesene kleine Auswahl an Root-Zertifikaten gelten, die es in der Adobe Approved Trust List (AATL) auflistet. Root-Zertifikate, die es bis dahin geschafft haben, nennt Adobe gönnerisch Vertrauensanker und nur mit Zertifikaten, deren Zertifikatskette auf solche Root-Zertifikate zurückgeht, lassen sich PDFs allgemein anerkannt signieren.

Man mag von dieser verstärkten Sicherheitsvorkehrung halten, was man will, es ist aber jedenfalls ein Unding, dass ein US-Unternehmen selbstherrlich über die Rechtsgültigkeit von Unterschriften entscheidet. Das ist irgendwann auch der EU aufgefallen, die daraufhin eine Konkurrenzliste namens EUTL (European Union Trusted List) aufgemacht hat, welche zwischenzeitlich in eine Liste der Listen der einzelnen EU-Mitgliedsstaaten umgewandelt wurde (eine List of Trusted Lists oder LOTL (lol)).

Adobe erkennt auch die EUTL an, aber in der Praxis spielt die AATL nach wie vor die Hauptrolle.



D-TRUST-Zertifikate

AATL-kompatible Personenzertifikate kosteten bislang durch die Bank 300€ oder auch (deutlich) mehr pro Jahr ; das allein ist schon eine Erklärung, warum sie sich jedenfalls bei Privatleuten und kleineren Unternehmen nie durchsetzen konnten.

Hier kommt nun D-TRUST ins Spiel, eine Tochter der Bundesdruckerei, die im Staatsauftrag Ausweise aller Art herstellt; da passt D-TRUST als digitale Variante. Seltsam unbemerkt von der Öffentlichkeit hat sich D-TRUST als Preisbrecher bei AATL-kompatiblen, eIDAS-konformen Zertifikaten hervorgetan; ein fortgeschrittenes Personenzertifikat (zur Terminologie siehe Kapitel 1) mit dem Namen Advanced Personal ID wurde unter 50€/Jahr gedrückt. Das ist der Unterschied ums Ganze, der digitalem Unterschreiben endlich zum Durchbruch verhelfen könnte.

Die Zertifikate kann man bei D-TRUST, der Zertifizierungsstelle selbst, bekommen oder bei PSW, einer Registrierungsstelle für D-TRUST. Beide Verfahren haben Vor- und Nachteile.

Während das Endprodukt selbst ein hochmodernes digitale Zertifikat ist, trägt der Bestellprozess bei D-TRUST noch die Züge der guten alten Zeit und spiegelt die Wendigkeit eines Staatsunternehmens: Man füllt, ohne je mit technischen Begriffen behelligt zu werden, auf der Bestellseite ein ganz normales Formular mit Name, Adresse usw. aus, aus dem ein PDF erstellt wird. Das muss man ausdrucken, unterschreiben (von Hand), per Briefpost mit einer Kopie des Personalausweises an D-TRUST senden und warten. Und warten. Mit etwas Glück erhält man dann nach 4, 5 Wochen das Zertifikat samt privatem Schlüssel per Email und das Passwort für den privaten Schlüssel per Briefpost. Hat man, so wie ich, kein Glück und der Brief mit dem Passwort geht verloren, kann es auch über 4 Monate dauern, bis man sein gültiges Zertifikat in den Händen halt. Der entscheidende Vorteil bei diesem Verfahren: Man kann auch als blutiger (aber geduldiger) Laie problemlos ein Zertifikat bestellen.

PSW, die seit langem als Registrierungsstelle für diverse Zertifizierungsstellen arbeiten, sind hingegen klar auf IT-Profis ausgerichtet (das Hauptgeschäft dürften SSL-Zertifikate für Websites sein). Entsprechend technisch läuft der Bestellprozess ab; man muss das Certificate Signing Request (siehe oben) selbst erstellen und wird auch sonst mit allerlei technischen Vorgängen konfrontiert. Dafür erhält man sein Zertifikat innerhalb zweier Werktage. Preiswerter ist es zudem. Sein Schlüsselpaar muss man hier selbst generieren; dazu gibt es auf der Website ein entsprechendes Werkzeug. Das muss man aber nicht verwenden; wer aus Sicherheitsgründen möchte, dass der private Schlüssel auf dem eigenen Rechner erzeugt wird und diesen nie verlässt, kann auch lokale Werkzeuge auf seinem Rechner zur Schlüsselgenerierung benutzen, sofern er solche besitzt. (Der Zertifikatsassistent der Schlüsselbundverwaltung ist dazu leider nicht geeignet.)

Bei D-TRUST kostet ein fortgeschrittenes Personenzertifikat für 2 Jahre 94€. Bei PSW kostet ein fortgeschrittenes Personenzertifikat für 1 Jahr 39€ und für zwei Jahre 69€. Für beide Bestellvarianten gibt es in den beiden folgenden Unterkapiteln genaue Schritt-für-Schritt-Anleitungen.

Zum Schluss noch ein Wort zu qualifizierten Zertifikaten: Auch hier setzt D-TRUST einen neuen Maßstab für das Preis-Leistungsverhältnis; die D-Trust Card 4.1 kostet bei nun dreijähriger Laufzeit 60€/Jahr plus einmalig (bei der Bestellung für die ersten 3 Jahre) 30€. D-TRUST bietet das Zertifikat aber nur mit einem Chipkartenlesegerät als zweitem Faktor an, für das noch kein macOS-Treiber existiert (er ist laut D-TRUST aber in Entwicklung). PSW wiederum bietet als zweiten Faktor generell nur USB-Dongles („USB-Tokens“) an, die zwar macOS-kompatibel sind, mit denen aber die D-Trust Card 4.1 nicht funktioniert, die deshalb auch gar nicht bei PSW erhältlich ist.

Wer darauf Wert legt, muss sich also noch ein wenig gedulden. Bedenkt aber, die qualifizierten Zertifikate lassen sich nur fürs Unterschreiben von PDFs verwenden, nicht zum Signieren und Verschlüsseln von Emails.

3a. Bestellung bei D-TRUST

Die Bestellung bei D-TRUST startet hier.

Das Ausfüllten der Webformulare ist weitgehend selbsterklärend; zum Abschluss der Bestellung wird aus den eingegebenen Daten wie schon gesagt ein PDF generiert.








Hier muss die Email-Adresse angegeben werden, für die man Emails signieren und verschlüsseln können will. Außerdem muss man sich ein Passwort ausdenken, mit dem sich das Zertifikat ggf. sperren lässt, falls der private Schlüssel in falsche Hände gerät.







Nachdem der zahlungspflichtige Bestellvorgang ausgelöst wurde, druckt man das aus den eigenen Angaben generierte Bestellformular aus, unterschreibt es und sendet es zusammen mit einer Kopie des Personalausweises an D-TRUST.

Nach dem Auslösen des Bestellvorgangs erhält man zudem eine Email mit einer Bestellbestätigung inklusive Antragsnummer. Mit dieser Antragsnummer lässt sich auf einer entsprechenden Webseite der „Produktionsstatus prüfen“. Viel erfährt man freilich nicht; 1 – 2 Wochen nach mutmaßlichem Eingang des Antrags per Briefpost wird dies auch im Produktionsstatus vermerkt. Was die nächsten Wochen passiert, bleibt weiterhin D-TRUSTs süßes Geheimnis, denn am Produktionsstatus ändert sich nichts mehr. Kurz, nachdem man endlich sein Zertifikat per Email erhalten hat, wird dann auch im Produktionsstatus vermerkt, dass dies nun der Fall sei.

In der Email enthalten ist die Datei zertifikat.p12, die bereits im für Macs passenden Format (eben .p12) vorliegt und das Zertifikat inklusive öffentlichem Schlüssel, den privaten Schlüssel und Zwischen- und Root-Zertifikat der Zertifikatskette enthält. Die zugehörige PIN, die man zum Installieren der .p12-Datei in der Schlüsselbundverwaltung von macOS benötigt, wird mit Briefpost etwa innerhalb einer Woche versandt.

3b. Bestellung bei PSW

Bei PSW muss man als erstes ein Benutzerkonto erstellen, weil nur dann das Werkzeug zum Erstellen eines Certificate Signing Requests verfügbar wird, den man hier wie gesagt für den Bestellvorgang braucht.

Wichtig ist beim Ausfüllen des Registrierungsformulars, das Pop-up oben rechts auf Nein, ich bin Neukunde umzustellen, weil man sonst die erforderlichen Eingaben nicht tätigen kann und stattdessen nach einer Kundennummer gefragt wird, die man natürlich noch nicht hat:


Nach abschließendem Klick auf Registrieren bekommt man zur Kontoaktivierung wie üblich einen Link an die angegebene Emailadresse geschickt:


Nach Anklicken des Links sollte diese Meldung erscheinen:


Nun geht man zum CSR-Generator (die gerade erstellen Login-Daten werden dabei abgefragt), um einen Certificate Signing Request zu generieren:


Nach Klick auf Generieren wird das Ergebnis angezeigt:

Diese Daten müssen nun unbedingt sofort in TextEdit als zwei reine Textdateien – jeweils von einschließlich der BEGIN-Zeile bis zu einschließlich der END-Zeile – gesichert werden, da sie aus Sicherheitsgründen sonst nirgendwo abgespeichert sind. Die Namen der Textdateien sind unkritisch, da sie quasi nur eine Notiz für einen selbst darstellen; nur merken muss man sich, was sie bedeuten. Ich verwende für unser Beispiel MaxMustermann.csr für den Certificate Signing Request (den CERTIFICATE REQUEST-Textblock) und MaxMustermann.key für den privaten Schlüssel (den PRIVATE KEY-Textblock).

Nun geht es ans Bestellen. PSW versteckt die die D-TRUST-Advanced Personal ID-Zertifikate verschämt unter identitätsvalidierten Email-Zertifikaten, obwohl es vollwertige, ebenso zum Unterzeichnen von Dokumenten bestimmte Personenzertifikate sind, wie aus dem ja explizit angegebenen Merkmal eIDAS auch hervorgeht.

PSW rechtfertigt das damit, dass diese Zertifikate ja „nur“ fortgeschrittene Zertifikate seien und man daher nicht sicher sein könne, dass Adobe sie nicht aus der AATL entferne. Diese „Gefahr“ besteht aber prinzipiell natürlich bei jedem Zertifikat und außerdem gäbe es dann ja auch noch die EUTL. Der wahre Grund dürfte sein, dass man diese Zertifikate nicht in der Rubrik Document Signing Zertifikate platzieren möchte, in der alle übrigen Produkte mindestens das Zehnfache kosten. (Eine Einschränkung auf Privatpersonen, wie sie diese Webseite nahelegt, existiert ebenfalls nicht.)

Wer ohne diesen Irrgarten direkt zu der Bestellseite gelangen will, kann dies mit diesem Link tun. Zu Beginn der Bestellung ist nun der in MaxMustermann.csr gespeicherte Textblock einzutragen, der den Certificate Signing Request darstellt:

Außerdem kann man noch die Laufzeit wählen und muss bestätigen, die Datenschutzerklärung gelesen zu haben, dann geht es Weiter:


Die zu zertifizierende Email-Adresse ist in dem Certificate Signing Request enthalten und daher hier bereits voreingetragen; das Feld dient daher nur der Kontrolle. Weiter.


Die übrigen Daten zum Zertifikatsinhaber sind natürlich ebenfalls im Certificate Signing Request enthalten, dennoch wurden sie bei meinen Testläufen manchmal nicht automatisch übernommen. Gegebenenfalls also manuell, genau so wie im Certificate Signing Request angegeben, nachtragen.

Auf dieser Seite muss zur Identitätskontrolle nun noch ein Scan des Personalausweises oder Reispasses hochgeladen werden. Dazu klickt man auf Hinzufügen. Es erscheint ein Button Datei auswählen, der das Standard-macOS-Dateiauswahl-Dialogfenster öffnet, mit dem man ein entsprechendes Bild auswählen kann:


Nach Auswahl der Datei erscheint ihr Name in dem Fenster:

Nun kann man erneut auf Weiter klicken.

Es erscheint eine Zusammenfassung der Bestellung, die man, wenn alles passt, in den Warenkorb legen kann:


Vom Warenkorb geht es zur Kasse:


Eine Rechnungsanschrift reicht nicht, nein, es muss auch noch ein Ansprechpartner für die Bestellung angegeben werden:


Dafür wird wenigstens der Rechnungsempfänger aus dem Benutzerkonto automatisch eingesetzt:


Danach kommt es zu einem kleinen Schock; es müssen nochmals Identitätsnachweise hochgeladen werden:


Der Schreck verfliegt, wenn man bemerkt, dass das nur für Zahlung per Rechnung erforderlich ist. Ein Klick auf PayPal und die Welt ist wieder in Ordnung:


Noch eine iTunes-AGB-Zustimmungsorgie® und man kann sein Zertifikat bestellen:


Innerhalb eines Tages nach Absenden der Bestellung erhält man von D-TRUST eine automatisierte Email mit der Bitte, die Email-Adresse durch Klick auf einen Link und Eingabe eines Bestätigungscodes zu bestätigen. Danach erscheint folgendes Fenster:


Zugleich öffnet sich eine Seite, von der man mannigfaltige Root- und Zwischenzertifikate von D-TRUST herunterladen kann:

Beispielhaft ist hier das Zwischenzertifikat hervorgehoben, das für die Advanced Personal ID-Zertifikate benötigt wird.

Von all diesen Zertifikaten braucht man keines herunterzuladen, denn alles, was benötigt wird, erhält man bald darauf in einer Email von PSW: die Dateien MaxMustermann.cer, D-Trust-Intermediate.cer und D-Trust-Root.cer – Personenzertifikat, Zwischenzertifikat und Root-Zertifikat. Allerdings liegen diese Zertifikate noch in einer Form vor, mit der die macOS-Schlüsselbundverwaltung nichts Rechtes anzufangen weiß; daher müssen sie noch zu einer .p12-Datei zusammengebaut werden, wie man sie bei einer Bestellung bei D-TRUST selbst bereits fertig erhält. Dazu gibt es auf der PSW-Website erneut das passende Werkzeug, einen Zertifikat-Konverter:

Hier werden die einzelnen Komponenten mit den gezeigten Einstellungen „zusammengebaut“. MaxMustermann.key ist dabei die TextEdit-Datei im reinen Textformat mit dem privaten Schlüssel, die zuvor beim Erstellen des Certificate Signing Requests abgespeichert worden war. Das anzugebende Passwort entspricht der PIN, die einem bei einer Bestellung bei D-TRUST via Briefpost zugesandt wird, und kann hier frei vergeben werden; es muss natürlich gut und sicher aufbewahrt werden.

Das Root-Zertifikat könnte man eigentlich auch weglassen, da es sich ohnehin schon im System-Roots-Schlüsselbund von macOS befindet; in unserem Beispiel wird es nur aufgenommen, damit die resultierende .p12-Datei identisch mit der von D-TRUST gelieferten ist und damit das Zertifikat gegebenenfalls auch auf anderen Systemen als macOS problemlos installiert werden kann. Keinesfalls weglassen darf man aber das Zwischenzertifikat 1 (D-Trust-Intermediate.cer), weil man sonst mit seinem privaten Schlüssel nichts gültig signieren kann, da er ohne Zwischenzertifikat keine komplette Zertifikatskette zu einem Root-Zertifikat aufweist.

Schließich noch der Hinweis, dass MaxMustermann.key der private, noch nicht durch ein Passwort geschützte Schlüssel ist. Nachdem man in den folgenden Schritten überprüft hat, dass Schlüsselbundverwaltung, Email-Signatur und -Verschlüsselung und digitales Unterschreiben von PDFs funktionieren, sollte man diese Datei daher unbedingt rückstandslos vernichten!

Wenn alles korrekt eingetragen ist, klickt man auf Konvertieren und erhält folgendes Resultat:

Nun kann man sich die Datei certificate.pfx herunterladen und das Suffix von .pfx in .p12 ändern (beide Suffixe bezeichnen denselben Dateityp; .pfx ist unter Windows gebräuchlich, .p12 unter macOS.

4. Zertifikat-Installation auf macOS

Nun muss die .p12-Datei, die man von D-TRUST oder PSW erhalten hat, auf dem Mac installiert werden; das geht wie üblich vorbildlich einfach.

Doch zunächst sollte man der Datei einen aussagekräftigen Namen verpassen, soweit man sie für Neuinstallationen und als Backup aufzubewahren gedenkt, denn im Laufe der Jahre sammeln sich viele solche Dateien an.

Eine vorgeschriebene Form gibt es hierfür nicht; mein Vorschlag wäre – auch für Personenzertifikate, für Email-Zertifikate natürlich sowieso – die Email-Adresse (die ist im Gegensatz zur Person stets einzigartig, während ein und dieselbe Person natürlich mehrere Personenzertifikate für verschiedene Email-Adressen von ihr besitzen kann), ergänzt um den Typ des Zertifikats (ID für Personenzertifikate, Email für Email-Zertifikate) und das Jahr der Ausstellung. So sollte die Einmaligkeit jedes Namens gewährleistet sein; in unserem Beispiel wäre das ID_max.mustermann@domain.tld_2021.p12.

Nun zur Installation in macOS, die einfacher nicht sein könnte: Ein Doppelklick auf die Datei reicht. In der Schlüsselbundverwaltung sollte dabei der Schlüsselbund Anmeldung ausgewählt sein. Daraufhin wird man von der Schlüsselbundverwaltung nach dem Passwort gefragt, das man bei der Bestellung via D-TRUST als PIN per Briefpost erhalten und bei Bestellung über PSW selbst vergeben hat:

Dieses Passwort wird nur für den Import der Schlüssel aus der .p12-Datei in die Schlüsselbundverwaltung benötigt. Sind die Schlüssel dort einmal installiert, werden sie durch das Passwort des jeweiligen Schlüsselbundes geschützt.

Das Personenzertifikat sollte sich nun im Schlüsselbund Anmeldung befinden:

Über das Aufklappdreieck des Zertifikat-Eintrags kann man sich den zum Zertifikat mit dem öffentlichen Schlüssel gehörenden privaten Schlüssel anzeigen lassen, hier A3A42BBB. (Der kryptische Name soll verhindern, dass jemand, der an den privaten Schlüssel gerät, sofort weiß, zu welchem öffentlichen Schlüssel er gehört, was der Fall wäre, wenn er ebenfalls den Personennamen oder ähnliches tragen würde.)

Im oberen Teil der Anzeige sieht man, dass das Personenzertifikat von D-TRUST Application Certificates CA 3-1 2013 beglaubigt wurde; das ist das zugehörige Zwischenzertifikat und eben nicht direkt das Root-Zertifikat.

Durch Eingabe von D-Trust in die Suchmaske lassen sich die in der Schlüsselbundverwaltung vorhandenen Zertifikate von D-TRUST anzeigen:

An oberster Stelle findet sich das frisch installierte Zwischenzertifikat D-TRUST Application Certificates CA 3-1 2013, darunter das zugehörige Root-Zertifikat D-TRUST Root CA 3 2013, beide im Schlüsselbund Anmeldung, in den die .p12-Datei importiert wurde. Das Root-Zertifikat kann sofort gelöscht werden, denn es befindet darunter sowie schon von Haus aus im dafür vorgesehenen Schlüsselbund System-Roots.

Bei den beiden untersten Einträgen handelt es sich um Root-Zertifikate von D-TRUST für andere Zertifikattypen; sie brauchen uns hier nicht zu interessieren.

Durch einen Doppelklick auf das Zwischenzertifikat D-TRUST Application Certificates CA 3-1 2013 lassen sich Details hierzu anzeigen:

Unter Allgemeiner Name des Ausstellers ist hier das Root-Zertifikat D-TRUST Root CA 3 2013 angegeben, das Zwischenzertifikat D-TRUST Application Certificates CA 3-1 2013 seinerseits beglaubigt hat. Damit ist die Zertifikatskette komplett.

5. Verwendung des Zertifikats zum Signieren und Verschlüsseln von Email in Mail

Nicht nur das Installieren des Zertifikats in der Schlüsselbundverwaltung geht vorbildlich einfach; die Nutzung in Mail tut es ebenso oder sogar noch mehr, denn hier ist gar nichts zu tun: Nach der Installation in der Schlüsselbundverwaltung stellt Mail die Funktionalität automatisch zur Verfügung. Einzig eine Bedenkzeit von bis zu einer Minute sollte man Mail einräumen, wenn man das erste Mal eine Email mit einer Email-Adresse, für die ein Zertifikat existiert, schreiben will, damit Mail sich intern darauf einstellen kann.

Wenn man von einer solchen Email-Adresse aus eine Email verfassen will, finden sich im Erstellen-Fenster von Mail zwei neue Bedienelemente:

Während das Schloss noch ausgegraut ist, kann man mit dem Siegel-Button seine Email nun signieren. Damit wird dem Empfänger einerseits angezeigt, dass die Email tatsächlich von in diesem Fall der Person Max Mustermann gesendet wurde, andererseits könnte der Empfänger, in diesem Fall Olaf Scholz, wenn er selbst ebenfalls entsprechend ausgestattet ist, eine verschlüsselte Email an Max Mustermann senden, die er mit dem in der digitalen Signatur enthaltenen öffentlichen Schlüssel von Max Mustermann verschlüsselt, sodass Max Mustermann sie mit seinem privaten Schlüssel entschlüsseln kann.

Beim Absenden der signierten Email fragt Mail nun nach dem Passwort für den Schlüsselbund Anmeldung (das per Konvention dasselbe wie für das Benutzerkonto selbst ist):

Die Antwort sollte man sich gut überlegen. Klickt man auf Erlauben, so muss man das Passwort bei jeder signierten Email erneut eingeben. Klickt man auf Immer erlauben, so kann man ab da ohne weitere Passwortabfragen signierte Emails versenden – aber ein Dritter, der in einem unbeobachteten Moment an einen Mac mit angemeldetem Benutzer gerät, kann das auch.

Da aber einerseits die Signatur einer Email gemeinhin geringeres Gewicht hat als die Unterschrift unter einen Vertrag und man andererseits Emails, wo immer möglich, signieren und verschlüsseln sollte (so wie Websites heutzutage fast grundsätzlich über HTTPS ausgeliefert werden, auch wenn der Inhalt völlig öffentlich ist), sodass die stetig neue Passwortabfrage äußerst lästig wäre, ist es im Allgemeinen wohl vertretbar, Immer erlauben zu verwenden. Im Einzelfall kann die Situation natürlich anders aussehen.

Hat man Immer erlauben angeklickt und will das nun wieder rückgängig machen, so kann man das über die Zugriffseinstellungen des privaten Schlüssels (wie der zugänglich ist, wurde im vorigen Kapitel beschrieben). Ein Doppelklick auf den privaten Schlüssel in der Schlüsselbundverwaltung, hier A3A42BBB, öffnet das Fenster, in dem der Zugriff geregelt ist:

Mit dem Minus-Button kann man so gegebenenfalls Mail wieder aus der Liste jener Programme entfernen, denen der Zugriff immer erlaubt ist.

Zurück zu Max Mustermann und Olaf Scholz. Wenn Olaf Scholz die signierte Email von Max Mustermann liest, sieht er nun, dass die Mail signiert ist und tatsächlich von Max Mustermann stammt:


Antwortet er Max Mustermann mit einer ebenfalls signierten Email, so ist Max Mustermann ab da in der Lage, Emails an Olaf Scholz zu verschlüsseln, da in der Signatur von Olaf Scholz ja dessen öffentliches Zertifikat enthalten ist.

Max Mustermann muss das natürlich nicht tun, aber das nun nicht mehr ausgegraute Schloss zeigt, dass er es könnte:


Sendet Max Mustermann seine Email mit dieser Einstellung, so sieht das für Olaf Scholz nicht anders aus als bisher: die Email ist signiert, aber nicht verschlüsselt.

Schließt Max Mustermann aber das Schloss:

so erhält Olaf Scholz eine signierte und verschlüsselte Email:

6. Wahl des PDF-Programms

Diese Anleitung verdankt sich wie eingangs erwähnt unter anderem einem Thread, in dem es primär um Alternativen zu dem sündhaft teuren (und auf APFS Case-Sensitive im übrigen gar nicht lauffähigen) PDF-Editor Acrobat Pro von Adobe in Bezug auf einige Aufgabenstellungen ging; davon waren digitale Unterschriften die eine, das PDF/A-Format eine andere.

Einen Test aller für den Mac erhältlichen PDF-Editoren außer Acrobat Pro, die überhaupt die geforderten Möglichkeiten bieten, habe ich, weil PDF/A hier kein Thema ist, in einem eigenen Thread veröffentlicht.

Ich will die Ergebnisse hier nicht im Einzelnen wiederholen. Ein erstaunliches Ergebnis, was digitale Unterschriften betrifft, war aber folgendes:

Ich hatte – ursprünglich lediglich als Vergleichsnormal – auch den Acrobat Reader von Adobe in den Vergleichstest mit aufgenommen, der ja gar kein PDF-Editor ist, aber digitales Unterschreiben ermöglicht.

Wie sich während des Tests jedoch herausstellte, ist der Acrobat Reader, was digitale Unterschriften betrifft, allen anderen Programmen derart überlegen, dass eigentlich kein anderes Programm infrage kommt. Einzig der Foxit PDF Editor kann ansatzweise mithalten, spart aber mit diagnostischen Angaben über Zertifikate (die im Falle von deren Ungültigkeit wichtig sind) und beherrscht keine Versionierung.

Diese Fähigkeit der Versionierung – nicht nur feststellen zu können, dass ein Dokument nach einer Unterschrift noch abgeändert wurde, sondern auch anzeigen zu können, wie, indem die Version zum Zeitpunkt der Unterschrift wiederhergestellt werden kann – ist ein Alleinstellungsmerkmal des Acrobat Reader; dazu kommen noch ausgeprägte diagnostische Fähigkeiten. Alle getesteten PDF-Editoren hingegen bis auf den Foxit PDF Editor haben zumindest ein k.o.-Kriterium, das ihre Verwendung zum digitalen Signieren eigentlich unmöglich macht. (Genaueres im Vergleichstest.)

Es geht aber bei dieser speziellen Aufgabenstellung nicht nur um technische Aspekte, sondern auch um juristische. Wie der Vergleichstest zeigt, weicht die Beurteilung der Gültigkeit oder Ungültigkeit einer digitalen Signatur bei allen Programmen in irgendwelchen Konstellationen mehr oder minder geringfügig voneinander ab. Aufgrund der Tatsache, dass Adobe Urheber des PDF-Formats und der digitalen Signaturen von PDFs ist und zudem im Bereich PDF eine marktbeherrschende Stellung besitzt, wird ein Gericht im Zweifelsfalle jene Gültigkeitsbewertung zugrunde legen, die der Acrobat Reader liefert. Das ist hier ein entscheidendes Kriterium, denn schließlich ist der ganze Daseinszweck von Unterschriften ein juristischer.

Wenn man zusätzlich berücksichtigt, dass das Programm kostenfrei ist, im Gegensatz zu den meisten anderen Adobe-Programmen mit allen macOS-Konfigurationen inklusive case-sensitiver Dateisysteme klarkommt und eine erträgliche GUI besitzt, die besser ist als die der meisten übrigen getesteten PDF-Editoren, so bleibt nur die Empfehlung, den Acrobat Reader für digitale Unterschriften zu verwenden.

Wer mich kennt, weiß, dass ich das Unternehmen Adobe überhaupt gar nicht mag. Wenn ich in diesem Falle gleichwohl eine uneingeschränkte Empfehlung für den Acrobat Reader ausspreche, will das also etwas bedeuten. Ich werde mich jedenfalls für diesen Bericht beim digitalen Unterschreiben von PDFs auf den Acrobat Reader beschränken.

7. Zertifikat-Installation in Acrobat Reader

Bevor wir uns mit dem digitalen Signieren in Acrobat Reader beschäftigen, muss das Programm natürlich zunächst einmal installiert werden, sofern das noch nicht geschehen ist. Das Programm lässt sich hier herunterladen und dann wie in macOS üblich installieren. Man darf es aber nicht von seinem vorgegebenen Installationsort /Programme/ an andere Stelle verschieben; dann funktioniert es nicht mehr.

Die Konfiguration für digitale Unterschriften einschließlich der dafür verwendeten Zertifikate findet sich Acrobat Reader → Einstellungen → Unterschriften; dort klickt man im Abschnitt Identitäten und vertrauenswürdige Zertifikate auf Weitere… (eine Fehlübersetzung für Details … oder mehr …):


Es öffnet sich das Fenster Einstellungen für digitale IDs und vertrauenswürdige Zertifikate:

Unter Digitale IDs versteht Adobe Personenzertifikate, unter Vertrauenswürdige Zertifikate die Root-Zertifikate aus AATL und EUTL.

Digitale IDs sind nochmals untergliedert nach der Quelle, aus der die Zertifikate stammen; die Untergliederung lässt sich durch Klick auf das Aufklappdreieck anzeigen. Digitale Keychain-IDs bezeichnet Personenzertifikate aus der macOS-Schlüsselbundverwaltung.

Nebenbei: Es wäre schön, wenn die grauenhafte deutsche Lokalisierung von Acrobat Reader wenigstens ab und an die korrekten Begriffe verwenden würde. Digitale Keychain-IDs ergibt überhaupt gar keinen Sinn, denn es handelt sich ja nicht um eine (digitale) Identität von Keychains (also known as Schlüsselbünde), sondern um digitale IDs (also known as Personenzertifikate), die in Keychains (also known as Schlüsselbünde) abgespeichert werden. Und bei Apple gibt es zwar den Mac App Store, den Mac Keychain Store hat Apple aber bislang als zusätzliche Einnahmequelle glatt übersehen – wie wär’s stattdessen mit Schlüsselbundverwaltung als Speichermethode? Dieses vage Umtänzeln der korrekten Begriffe zeigt, dass der Übersetzer nichts von dem verstanden hat, was er übersetzt, und macht das Einarbeiten in das Feld der digitalen Signaturen nicht gerade leichter.

Weiter mit unserem Adobe-Wörterbuch: Digitale ID-Dateien (gibt es auch analoge? ) bezeichnet irgendwo auf dem Rechner unter Umgehung der macOS-Schlüsselbundverwaltung abgespeicherte .p12-Dateien, die direkt in Acrobat Reader geladen wurden (sollte man nie ohne ganz besonderen Grund machen), Roaming-ID-Konten sind Zertifikate, die in Firmennetzwerken aus eben diesen geladen werden, und PKCS#11-Module und -Token sind qualifizierte Zertifikate, die auf USB-Dongles oder Chipkarten gespeichert sind.

Für unser in der Schlüsselbundverwaltung gespeichertes fortgeschrittenes Personenzertifikat spielt ersichtlich nur der Bereich Digitale Keychain-IDs eine Rolle und in der Tat wurde das Zertifikat dort (neben anderen macOS-internen Zertifikaten) bereits automatisch erkannt; es muss als überhaupt nichts installiert werden. Und (im Gegensatz zu dem, was PSW behauptet) erkennt auch Adobe hier zweifelsfrei an, dass eine Verwendung (sogar die erste genannte!) die Digitale Signatur ist.

Die Freude darüber verfliegt jedoch schnell, wenn man auf Zertifikatdetails klickt und sich das Fenster Zertifikatanzeige öffnet:

Links oben sieht man die Zertifikatskette, von dem installierten Personenzertifikat über das D-TRUST-Zwischenzertifikat zum D-TRUST-Root-Zertifikat, und links untern heißt es zudem ausdrücklich, dass dieser Zertifikatspfad gültig ist. Trotzdem steht ganz oben geschrieben, dass keine der Ketten von einem Vertrauensanker ausgegeben wurde und im Bereich Vertrauenswürdigkeit heißt es daher, dieses Zertifikat sei nicht vertrauenswürdig, und man sieht nur rote Kreuze – für keine Aufgabe kann das Zertifikat verwendet werden.

Nun muss man unbedingt der Versuchung widerstehen, auf den Button Zu vertrauenswürdigen Zertifikaten hinzufügen… zu klicken. Das scheint das Problem in Nullkommanichts zu lösen, doch dieser Schein trügt, denn das ist eine rein lokale Einstellung auf dem eigenen Rechner. Auf allen anderen Computern ändert sich an der Gültigkeit des Zertifikates nichts, aber darauf käme es ja bei Unterschriften an. (Sollte man aus Versehen doch auf den Button Zu vertrauenswürdigen Zertifikaten hinzufügen… geklickt haben, so wird das Zertifikat im Bereich Vertrauenswürdige Zertifikate aufgelistet und man kann durch Löschen dieses Eintrags seinen Fehler wieder rückgängig machen.)

Die weltweite Gültigkeit eines Zertifikats soll ja eben durch die Zertifikatskette bescheinigt werden. Warum geschieht dies hier nicht? Sehen wir uns daher das Zwischenzertifikat an:

Exakt dasselbe Bild. Kein Wunder, dass das Personenzertifikat nicht vertrauenswürdig ist, wenn es bereits das Zwischenzertifikat nicht ist. Also weiter in der Kette zum Root-Zertifikat:

Wieder dasselbe. Das Root-Zertifikat war doch aber sogar schon im Schlüsselbund System-Roots von macOS vorinstalliert; wenn das eigene Personenzertifikat automatisch aus der Schlüsselbundverwaltung in den Acrobat Reader importiert wurde, so sollte das für vorinstallierte Root-Zertifikate doch erst recht gelten?

Des Rätsels Lösung besteht darin, dass Adobe eben nicht jedes Root-Zertifikat als vertrauenswürdig ansieht, sondern nur die als Vertrauensanker bezeichneten, die in der AATL oder EUTL auftauchen.

Die kann man sich wie gesagt im Bereich Vertrauenswürdige Zertifikate ansehen, und da herrscht gähnende Leere:

Ganze zwei Root-Zertifikate, von Adobe selbst, sind hier zu finden; so kann das nichts werden.

Daher muss man im Einstellungen-Fenster in den Bereich Vertrauensdienste wechseln:

Hier ist zwar die vorgegebene Standardeinstellung, dass AATL und EUTL automatisch aktuell gehalten werden, aus irgendeinem Grund geschieht das nach der Installation von Acrobat Reader aber zunächst einmal nicht. Daher muss man für AATL und EUTL jeweils einmal auf den Button Jetzt aktualisieren klicken. Es erscheint danach jeweils folgende Meldung:


Wenn man nun wieder über das Einstellungen-Fenster

in das vorangegangene Fenster Einstellungen für digitale IDs und vertrauenswürdige Zertifikate und dort in den Bereich Vertrauenswürdige Zertifikate zurück wechselt, so sieht es dort nun ganz anders aus:

Statt zweier Adobe-Zertifikate wird dort nun eine Vielzahl von Root-Zertifikaten angezeigt, unter anderem auch das für das eigene Personenzertifikat benötigte Root-Zertifikat von D-TRUST.

Den Lohn seiner Mühen sieht man, wenn man zurück in den Bereich Digitale IDs wechselt

wieder sein Personenzertifikat auswählt und erneut auf Zertifikatdetails klickt:

Betrachtet man zunächst das Root-Zertifikat der Zertifikatskette, so steht hier zum Thema Vertrauenswürdigkeit als erstes der Satz Dieses Zertifikat ist in der Liste der vertrauenswürdigen Zertifikate direkt vertrauenswürdig – eine unbeholfene Umschreibung der Tatsache, dass die Glaubwürdigkeit von Root-Zertifikaten definitionsgemäß eben nicht durch weitere Glieder der Zertifikatskette beglaubigt werden kann, sondern schlicht angenommen werden muss.

Den Grund, warum das Zertifikat nun als vertrauenswürdig gilt, nennt das sprachlich kaum noch zu überbietende Juwel von einem Satz Vertrauensquelle wurde vom Adobe Approved Trust List (AATL). (Im englischen Original: Source of Trust obtained from Adobe Approved Trust List (AATL).) Wie auch immer, AATL ist das entscheidende Stichwort.

Dadurch ist dieses Root-Zertifikat in Adobes Terminologie als Vertrauensanker festgelegt und dankt es mit zwei grünen Häkchen, die allen von ihm beglaubigen Zertifikaten die Fähigkeit bescheinigen, Dokumente zu unterschreiben und zu zertifizieren.

Sperrungen können bei Root-Zertifikaten definitionsgemäß nicht vorgenommen werden und auch der Button Zu vertrauenswürdigen Zertifikaten hinzufügen… ist ausgegraut, das das Zertifikat ja nun als Root-Zertifikat anerkannt und somit direkt vertrauenswürdig ist.

Zwischenzertifikat und Personenzertifikat erben nun, wie Zertifikatsketten es vorsehen, dies Merkmale von Vertrauenswürdigkeit:


Diese Zertifikate haben nach wie vor einen Button Zu vertrauenswürdigen Zertifikaten hinzufügen…, denn sie sind ja nicht für sich vertrauenswürdig, sondern jeweils nur durch das vorangehende Zertifikat in der Zertifikatskette. Erneut sollte man von diesem Button unbedingt die Finger lassen, denn es ist ja erwünscht, dass sie nicht für sich, sondern nur über eine weltweit gültige Zertifikatskette vertrauenswürdig sind.

Man kann nun also mit Genugtuung auf OK klicken, denn das Personenzertifikat mit seinen grünen Häkchen ist bereit zum Unterschreiben.

8. Konfiguration eines Zeitstempelservers

Der Zeitpunkt einer Unterschrift kann juristisch eine große Rolle spielen.

Bei digitalen Unterschriften kommt aber noch ein wichtiger Aspekt hinzu: Digitale Zertifikate haben ein Ablaufdatum, danach sind sie aus Sicherheitsgründen nicht mehr zu benutzen – es sei denn, jemand dreht die Uhrzeit auf dem Computer zurück, auf dem sie verwendet werden sollen.

Solange das Zertifikat aktuell noch gültig ist, spielt dieser Aspekt offenkundig keine Rolle. Unterschriften sollen aber natürlich, sofern sie während der Laufzeit des Zertifikats geleistet wurden, auch dann noch gültig sein, wenn das Zertifikat abgelaufen ist – nach spätestens drei Jahren ungültig werdende Unterschriften sind ersichtlich nicht zu gebrauchen. Damit Unterschriften auch nach dem Verfallsdatum des Zertifikats noch gültig sind, müssen sie LTV-fähig sein – LTV steht für Long Term Validation. Bei einem abgelaufenen Zertifikat ist es aber nicht mehr selbstverständlich, dass die auf ihm beruhende Unterschrift geleistet wurde, als es noch gültig war – hier könnte ein Zurückdrehen der Uhrzeit des Rechners dazu geführt haben, dass fälschlich mit einem ungültigen Zertifikat erfolgreich unterschrieben wird.

Daher sollten Uhrzeit und Datum der Unterschrift nicht von der Uhr des verwendeten Rechners stammen, sondern von einem Zeitstempelserver.

Ein Zeitstempelserver ist nicht mit einem normalen Zeitserver im Internet zu verwechseln. Er signiert das Dokument mit der Uhrzeit zum Zeitpunkt der Unterschrift und beglaubigt diese zusätzliche Signatur erneut mit einer Zertifikatskette zu einem AATL- (oder EUTL-)kompatiblen Root-Zertifikat.

Ursprünglich galten ausschließlich Unterschriften, deren Zeitpunkt von einem Zeitstempelserver beglaubigt wurde, als LTV-fähig. Währenddessen gibt Adobe an, dass dank eines alternativen Mechanismus auch Unterschriften ohne Zeitstempelserver LTV-fähig sein können. Das funktionierte bei meinen Tests aber manchmal nicht, während Unterschriften mit Zeitstempelserver verlässlich LTV-fähig waren.

Da manche renommierte Zertifizierungsstellen neben kostenpflichtigen aus Werbegründen auch frei zu nutzende Zeitstempelserver betreiben und die entsprechende Konfiguration in Acrobat Reader unkompliziert vorzunehmen ist, sollte man unbedingt einen Zeitstempelserver verwenden.

Dazu klickt man in Acrobat Reader → Einstellungen → Unterschriften im Abschnitt Zeitstempel für Dokumente auf den (wiederum falsch lokalisierten) Button Weitere…:


Es öffnet sich ein Fenster Servereinstellungen, das als einzigen Server den gewünschten (Uhr-)Zeitstempelserver anbietet:


Mit einem Klick auf Neu lässt sich ein neuer Zeitstempelserver anlegen:

Eine Liste freier Zeitstempelserver, aus der man wählen kann, findet sich auf GitHub; in unserem Beispiel verwenden wir den Server von DigiCert, http://timestamp.digicert.com.

Nach Klick auf OK muss man den neu eingetragenen Zeitstempelserver noch aktivieren, indem man ihn anwählt und dann auf Standardeinstellung festlegen klickt:


Es öffnet sich ein Dialogfenster, das man mit OK bestätigt:

Nur dann wird der Zeitstempelserver auch tatsächlich verwendet.


So sieht das Endergebnis aus. Mit Löschen kann man die Aktivierung des Zeitstempelservers rückgängig machen, mit Entfernen den Servereintrag löschen. (Wer hätte gedacht, dass Entfernen und Löschen zwei gänzlich unterschiedliche Dinge sind? )

Nur zur Vorwarnung: Wenn man später das erste Mal mit Zeitstempelserver unterschreibt, wird dieser Warndialog angezeigt werden:

Wenn man die Checkbox aktiviert und auf Zulassen klickt, gilt das ab da dauerhaft und man muss in Zukunft nichts mehr bestätigen.

9. Das digitale Unterschreiben in Acrobat Reader

Nach der Konfiguration kann man testweise die erste Unterschrift vornehmen, wobei beim ersten Mal einmalig noch einige weitere Einstellungen vorzunehmen sind, die danach entfallen.


Nach dem Öffnen eines Test-PDFs muss zunächst das Werkzeug zum digitalen Signieren in der Werkzeug-Seitenleiste hinzugefügt werden (das ist nicht das Werkzeug Ausfüllen und unterschreiben). Dazu klickt man auf Mehr Werkzeuge:

Mit einem Doppelklick auf Zertifikate fügt man dieses Werkzeug der Seitenleiste hinzu:

Leider ist diese Einstellung nicht von Dauer; man muss sie jedesmal erneut vornehmen. Das ist natürlich finstere Absicht: Für fast geschenkte 30 € im Monat ließe sich durch ein Upgrade auf Acrobat Pro DC dieses Ärgernis beseitigen, denn der behält die Einstellung bei …

Nachdem man das Werkzeug der Seitenleiste hinzugefügt und ausgewählt hat, kann man in der oberen waagrechten Werkzeugleiste auf Digital signieren klicken; dann wird man mit dem folgenden Dialogfenster konfrontiert:

Nach einem Klick auf OK zieht man den gewünschten Rahmen für die Unterschrift auf:


Es erscheint ein Dialogfenster, in dem man sein digitales Zertifikat auswählen kann, hier also das Personenzertifikat von D-TRUST (es werden unter Umständen noch etliche weitere gültige Zertifikate angeboten, die sich in der macOS-Schlüsselbundverwaltung befinden, bei bei Apple registrierten Entwicklern zum Beispiel ein Entwickler-Zertifikat, das man aber natürlich nicht verwenden kann):

Diese Auswahl muss man nur einmal tätigen. Zwar wird das Dialogfenster bei jedem Signiervorgang angezeigt, aber das zuletzt verwendete Zertifikat ist voreingestellt, sodass man in Zukunft einfach sofort Weiter klicken kann.

Daraufhin muss man noch das Erscheinungsbild der Unterschrift festlegen. Bescheiden, geschmackvoll und feinfühlig, wie Adobe nun einmal ist, schlägt es als Standardeinstellung vor, nur schnöde Lettern zu verwenden, die Unterschrift aber mit einem Adobe-Logo zu hinterlegen, das nach Adobes Auffassung offenbar jeder Person zur Zierde gereicht:

Wer grobschlächtiger gestrickt ist und eine feinsinnige Untermalung seiner Unterschrift durch das Adobe-Logo nicht goutiert, kann durch einen Klick auf Erstellen ein anderes Erscheinungsbild als Standardtext konfigurieren:

Zunächst einmal sollte man Kahlschlag im Dickicht der Standardeinstellung betreiben und die ganzen Textfelder samt Logo löschen:

Dann bleibt nur eine Variable für den Namen übrig, die sich durch ein Bild der eigenen Unterschrift ersetzen lässt, wenn man auf Bild klickt:

Ein Klick auf Durchsuchen öffnet das Standard-macOS-Dateiauswahl-Dialogfenster und erlaubt die Auswahl eines Unterschriften-Scans, der im PDF-Format vorliegen muss und einen transparenten Hintergrund haben sollte:

Der Erscheinungsbild-Vorlage muss man nun noch einen Namen verpassen – Bild im Beispiel – und kann sie dann speichern.

Eine andere Variante wäre etwa, dem Unterschriftsbild noch die eine oder andere Textvariable hinzuzufügen, im Beispiel das Datum, und das Ganze wieder unter einem geeigneten Namen (hier: Bild + Datum) zu speichern:

Leider geraten dabei die Proportionen zwischen Bild und Text leicht aus den Fugen.

Diese Erscheinungsbild-Vorlagen muss man natürlich nur einmal anlegen; danach lässt sich die gewünschte Vorlage aus dem Pop-up Erscheinungsbild auswählen:

Auch hier bleibt die letzte Auswahl voreingestellt, sodass man, will man dabei bleiben, einfach auf Unterschreiben klicken kann.

Was sich von Dokument zu Dokument ändern kann, ist die Frage, ob das Dokument nach dem Signieren gesperrt werden soll. Sind weitere Unterschriften in dem Dokument erforderlich, darf dies natürlich keinesfalls geschehen. Aber möglicherweise will man auch ansonsten etwa noch die Möglichkeit von Anmerkungen erlauben. Hier erweist es sich als hilfreich, dass auch bei nicht gesperrtem Dokument der Acrobat Reader stets die Fassung des Dokumentes anzeigen kann, die zum Zeitpunkt der Unterschrift bestand.

Ansonsten ließen sich noch weitere Vorlagen erstellen, vorhandene bearbeiten und das zu der Unterschrift gehörende Zertifikat anzeigen (in dem in Kapitel 7 besprochenen Fenster Zertifikatanzeige).

Passt alles, klickt man auf Unterschreiben.

Es öffnet sich nun das Sichern-Dialogfenster, denn das PDF sollte unter einem neuen Namen abgespeichert werden, damit ein nicht unterschriebenes, gegebenenfalls noch bearbeitbares Original erhalten bleibt. Im Beispiel wird einfach SIG an den Dokumentnamen angehängt:


Anschließend bittet Acrobat Reader wie zuvor Mail um Erlaubnis, das Zertifikat zum Unterschreiben nutzen zu dürfen:

Hier lohnt eine Überlegung, ob man nicht zurückhaltender als im Falle von Mail sein und nur Erlauben anklicken sollte. Man muss bedenken, dass, wenn man Immer erlauben anklickt, jeder, der bei angemeldetem Nutzer einen Moment unbeobachteten Zugang zu dem Mac hat, im Namen des Nutzers rechtsgültige Unterschriften leisten kann. Und da man in der Regel wohl weit seltener Dokumente unterschreibt als Emails verschickt, scheint hier im Zweifelsfall das zurückhaltendere Erlauben angebracht.

Hat man Immer erlauben geklickt und möchte das rückgängig machen, so muss man wie schon bei Mail in der Schlüsselbundverwaltung durch Doppelklick auf den privaten Schlüssel die Zugriffseinstellungen öffnen und den Acrobat Reader nach Auswahl durch Klick auf den Minus-Button aus der Liste der Programme entfernen, die stets auf den privatenSchlüssel zugreifen dürfen:

(Wie man den privaten Schlüssel in der Schlüsselbundverwaltung findet, ist in Kapitel 4 beschrieben.)

Ebenfalls wird man bei der ersten Unterschrift, wie schon beschrieben, nach der Erlaubnis gefragt, den Zeitstempelserver zu kontaktieren, falls man einen solchen konfiguriert hatte:

Hier kann man bedenkenlos erlauben, den Zeitstempelserver für alle PDF-Dokumente zuzulassen.

Lohn aller Mühen ist ein gültig unterschriebenes PDF:


Ich will nochmals betonen, dass nach der Ersteinrichtung eine Unterschrift im Alltag nur weniger Mausklicks bedarf.

10. Die Validierung der digitalen Unterschrift in Acrobat Reader

Man sollte testweise das Ergebnis der ersten eigenen Unterschrift einer Validierung unterziehen, um zu überprüfen, dass alles in Ordnung ist und ein Gefühl dafür zu bekommen, worauf man gegebenenfalls achten muss, wenn man später einmal die Unterschrift einer anderen Person überprüfen will.

Dazu gibt es grundsätzlich 2 Wege:

Zum einen einen Klick auf Unterschriftsfenster in dem hellblauen waagrechten Statusbalken, der stets erscheint, wenn man auf Alle Signaturen prüfen in der Zertifikate-Werkzeugleiste geklickt hat, zum anderen einen Doppelklick auf die Unterschrift selbst.

Zunächst der Klick auf Unterschriftsfenster, der kein Fenster öffnet (oh, Adobe …), sondern eine Seitenleiste auf der linken Seite des Dokumentfensters:

Nach Klick auf die beiden Aufklappdreiecke lassen sich hier die beiden wesentlichen Informationen zur Gültigkeit einsehen: Zunächst wieder die uns nun schon bekannte, stilistisch ausgefeilte Formulierung Vertrauensquelle wurde vom Adobe Approved Trust List (AATL). zur Begründung der Gültigkeit der Unterschrift sowie die Tatsache, dass der Zeitpunkt der Unterschrift einem Zeitstempelserver entnommen wurde und die Unterschrift somit LTV-fähig ist (zur Bedeutung von LTV siehe Kapitel .

Zertifikatdetails führt zu dem uns schon aus Kapitel 7 bekannten Fenster Zertifikatanzeige mit der Zertifikatskette für diese Unterschrift.

Und, ganz wichtig: Das Dokument im Beispiel wurde zwar laut Angabe nach dem Unterschreiben nicht mehr geändert, aber in anderen Fällen, wo es das wurde, lässt sich durch Klick auf Klicken Sie, um diese Version anzuzeigen das Dokument in dem Zustand anzeigen, in dem es sich zum Zeitpunkt dieser Unterschrift befand. (Bei mehreren Unterschriften können das entsprechend auch mehrere verschiedene Versionen sein.)

Ein Doppelklick auf die Unterschrift im Dokument selbst führt hingegen zunächst zu dieser Kurzübersicht:

Ein Klick auf Unterschriftseigenschaften… öffnet ein Fenster mit ausführlicheren Informationen:


Die Angaben entsprechen großenteils denen in der Seitenleiste des Dokumentfensters (literarische Sternstunden eingeschlossen), sind aber etwas ausführlicher – dafür bieten sie andererseits keine Möglichkeit, sich das Dokument im Zustand zum Zeitpunkt der Unterschrift anzeigen zu lassen.

Die Formulierung Das Dokument wurde vom aktuellen Benutzer unterschrieben. findet sich nur, wenn der Acrobat Reader in einem Nutzerkonto gestartet wurde, in dessen Schlüsselbundverwaltung sich der private Schlüssel desjenigen Personenzertifikats befindet, mit dem das Dokument unterschrieben wurde. Ansonsten steht an dieser Stelle Die Identität des Unterzeichners ist gültig. Dies hat keinerlei Einfluss auf die übrigen Angaben.

Mit Unterschrift prüfen kann man eine (erneute) Überprüfung der Zertifikatskette der Unterschrift veranlassen; Zertifikat des Ausstellers anzeigen… öffnet wiederum das bekannte Fenster Zertifikatanzeige.

Klick man in diesem Fenster hingegen auf Erweiterte Eigenschaften…

so öffnet sich ein Fenster mit Details zum Zeitstempelserver:

Man kann ersehen, welcher Zeitstempelserver verwendet wurde, und mit einem Klick auf Zertifikat anzeigen… auch dessen Zertifikatskette begutachten:

Alles anhand des eigenen Personenzertifikats Erläuterte gilt ebenso für das Zertifikat DigiCert Timestamp 2021, das die Gültigkeit des Zeitstempels beglaubigt.

11. Fehlerquellen

Bislang hat (bis auf Adobes Formulierungskünste) immer alles funktioniert. Was, wenn es das einmal nicht tut?

Dann erblickt man im Dokumentfenster folgende unschöne Meldung:


Ein Doppelklick auf die Unterschrift fördert die Ursache zutage:


Wie stets, lassen sich durch Klick auf Unterschriftseigenschaften… mehr Details anzeigen:

Fast immer wird es sich um ein Problem mit der Zertifikatskette handeln; meist wird das Root-Zertifikat nicht in der AATL oder EUTL gelistet sein.

Ein Klick auf Zertifikat des Ausstellers anzeigen… kann in diesen Falle näheres Informationen liefern; wie es aussieht, wenn sich das Root-Zertifikat weder in der AATL noch der EUTL befindet, wurde bereits eingangs in Kapitel 7 gezeigt.

NB: In diesem Screenshot ist, anders als sonst, beispielhaft ein Dokument zu sehen, das nach der digitalen Unterschrift nicht gesperrt wurde; der 2. Absatz der Gültigkeitszusammenfassung lautet entsprechend anders als sonst.



Ein ganz anderes Problem, das vor allem deshalb tückisch ist, weil es zunächst nicht zu einer Warnmeldung führt, ist, dass die Unterschrift nicht LTV-fähig ist (siehe hierzu Kapitel . Später, nach Ablauf des Zertifikats, wird diese Unterschrift dann als ungültig gemeldet werden.

Das sollte laut Adobe wie gesagt auch ohne Zeitstempelserver nicht passieren, tut es aber manchmal, wie diese beiden Beispiele zeigen:

Beide PDFs wurden ohne Zeitstempelserver und auch ansonsten mit exakt gleichen Einstellungen unterschrieben; dennoch ist die linke Unterschrift LTV-fähig, die rechte nicht.

Bei Verwendung eines Zeitstempelservers taucht dieses Problem nicht auf.

Wenn man daher aus irgendeinem Grund keinen Zeitstempelserver nutzt, sollte man auf die LTV-Fähigkeit einer gerade geleisteten Unterschrift stets ein Auge haben.

12. Tipps und Tricks

Unterschriftsbild

Will man zur grafischen Repräsentation seiner Unterschrift einen Scan der eigenen Unterschrift von Hand verwenden, muss der wie gesagt als PDF vorliegen und sollte transparent sein. Besonders gut und leicht gelingt das, wenn man Affinity Photo zur Hand hat. Dann kann man den Scan mit Affinity Photo → Filter → Weiße Bildanteile entfernen bearbeiten und anschließen einfach als PDF sichern. Alternativen finden sich im Forenthread Unterschrift als Grafik erstellen.

Im Gegensatz zu normalen in einem PDF enthaltenen Pixelbildern lässt sich ein als grafische Repräsentation einer digitalen Unterschrift genutztes Pixelbild nicht einfach aus dem PDF extrahieren, aber natürlich lässt sich ein Screenshot nicht verhindern. Um den zumindest nicht ohne weitere Bearbeitung nutzbar zu machen, kann man sich angewöhnen, die transparente Unterschrift andere Dokumentinhalte, z.B. eine Schriftlinie für die vorgesehene Unterschrift, überlappen zu lassen.


PDF in Acrobat Reader öffnen-Dienst

Ein effektiver Arbeitsablauf wäre, ein Dokument im Programm seiner Wahl zu verfassen, den Druckdialog zu öffnen, über einen entsprechenden Dienst das Dokument als PDF an den Acrobat Reader zu übergeben und dort zu unterschreiben und zu sichern.

Anders als so gut wie alle anderen PDF-Programme auf macOS bietet ausgerechnet Acrobat Reader aber (typische Adobe-Ignoranz von Betriebssystem-Funktionalitäten) keinen entsprechen Dienst an, der im Druckdialog auftauchen und das ermöglichen würde.

Glücklicherweise lässt sich eine solche Funktion mit dem Skript-Editor von macOS aber problemlos nachrüsten:


Als Skript in /Library/PDF Services/PDF in Acrobat Reader öffnen.scpt (für alle Benutzer des Macs) oder /Benutzer/max/Library/PDF Services/PDF in Acrobat Reader öffnen.scpt (nur für Max Mustermann) sichern und im Finder im Info-Fenster Suffix ausblenden aktivieren, dann erscheint in Zukunft im Druckdialog in dem PDF-Pop-up links unten der Eintrag PDF in Acrobat Reader öffnen.

Top-Beitrag, Danke!

Mir fällt nur ein Wort ein:
Unglaublich👍
Jan
Ich hätte nie gedacht, dass das so aufwendig ist!

Weia, du bist ein Held

Sehr ausführlich beschrieben, zeigt aber auch gleichzeitig auf, warum sich die ganze Sache, vor allem bei Otto-Normalverbraucher, nicht durchsetzt.
Wer nur alle Jubeljahre mal was digital zu unterschreiben hat wird sicher schon bei den Kosten zurückzucken und dann auch noch einen mehrseitigen Text lesen um das Ganze durchführen zu können, völlig unpraktikabel.

Alter Schwede! Großartig!

Ganz großartiger Beitrag, vielen, vielen Dank dafür!

So komplett, präzise und nachvollziehbar habe ich noch nirgends etwas zum digitalen Signieren gelesen. Leider zeigt allein die Länge dieser "Anleitung" bzw. die notwendige Anzahl der Schritte ganz deutlich, daß dieses Verfahren vollkommen unpraktikabel ist.

Sehr schön! Aber warum nicht gleich auf einer eigens dafür kreierten Seite via Wordpress o.ä. statt in einem Forum und den Kommentaren.
Vielleicht kommt damit sogar etwas Kleingeld via Seo zusammen 😊

Ich habe einen Token von GlobalSign - teuer, aber ich habe schon viel gespart an Papier und Zeit.

Allerdings ist es ein Krampf, jedesmal wenn Apple das System upgraded, dann kann es sein, dass der Token nicht mehr funktioniert. Im Augenblick geht es nur bei Adobe Reader, aber nicht mehr bei Acrobat DC.

Ich werde mal D-TRUST mir ansehen.

Jeder Upgrade oder ein neuer Computer und man fängt wieder von vorne an. Deswegen war ich eigentlich über die Token Lösung happy. Aber GlobalSign scheint nicht den Mac echt zu unterstützen. Hing so manche Stunde in der Warteschleife bei denen, bzw Email-Schleife.

Danke für den Artikel, gibt mir Mut, mal D-Trust zu verwenden. Eine Bitte, kann man den als pdf erhalten?
Danke!

PS Im Pharma Bereich werden die Unterschriften akzeptiert, auch von Behörden

Hierfür gibt es doch hier auf mactechnews die Journals?

Respekt für den investierten Aufwand und das Teilen mit der Allgemeinheit!

Hervorragend!
Ich denke, Weia ist der erste Anwender, der verstanden und beschrieben hat, wie eine digitale Signierung am Mac möglich ist

Weia, ich hatte in den letzten Wochen hier ungewohnt selten etwas von Dir gelesen, so dass ich mir schon etwas Sorgen gemacht habe, wo Du abgeblieben bist... Jetzt weiß ich, was Du die ganze Zeit gemacht hast
Also herzlichen Dank für die tolle Anleitung und die zugrunde liegende Recherche und Arbeit!

Danke auch Dir marm, für Deine Beiträge in der zugrunde liegenden Diskussion!

Auf jeden Fall Respekt für diese ausführliche Ausarbeitung. Zwei Anmerkungen habe ich aber doch, was die rechtlichen Aspekte angeht.
Grundsätzlich absolut richtig, aber wenn man eine solche Signatur über einen Dienstleister (siehe weiter unten) erstellt, dann bringt dieser in der Regel zusätzlich noch eine sogenannte Siegelsignatur an. Dadurch ist sichergestellt, dass zumindest das Dokument nach der Signatur nicht verändert wurde. Allerdings stellt die Siegelsignatur sonst auch nur fest, von welchem Dienstleister die Signatur stammt. Eine eindeutige und rechtssichere Bestimmung einer Person ist auch damit nicht möglich. Dadurch hat die Siegelsignatur den selben rechtlichen Wert, die einfache elektronische Signatur.
Die qualifizierte Signatur kann mittlerweile auch ohne externes Gerät durchgeführt werden. Dazu gibt es diverse Anbieter, die z.B. über VideoIdent deine Identität verifizieren und dann entsprechend eine solche Signatur erstellen. Das Zertifikat stammt dann von einem qualifizierten Vertrauensdiensteanbieter, der in der EU zertifiziert ist.
Weitere Lektüre zu den drei verschiedenen Varianten gibt es hier (Achtung, ganz an Ende des Artikels wirbt der Anbieter für seine eigene Siganturlösung )

Dein oben beschriebenes Vorgehen ist natürlich durchaus möglich, allerdings mit einem recht hohen Aufwand verbunden. Insbesondere eine qualifizierte elektronische Signatur ist so ohne zusätzliche Hardware überhaupt nicht möglich. Und eben wegen diesem Aufwand ist die fortgeschrittene/qualifizierte elektronische Signatur auch nicht sonderlich weit verbreitet. Daher gibt es mittlerweile diverse Anbieter, die den Signaturprozess massiv erleichtern. Der direkteste Anbieter in Deutschland wäre der Dienst sign-me der Bundesdruckerei (zu der ja auch D-TRUST gehört). sign-me bietet ein Webportal an, über das man, nach erfolgreicher Identifizierung, fortgeschrittene und qualifizierte Signaturen erstellen kann. Natürlich kostet der Spaß auch ein wenig.
Daneben gibt es aber auch noch diverse andere Anbieter, mit denen man relativ simpel einfache, fortgeschrittene und qualifizierte elektronische Signaturen erstellen kann. Die Anbieter unterscheiden sich entsprechend in Umfang, Aufwand und Kosten.
Wer bei heise das Plus-Abo hat, kann sich dort einen ausführlichen Vergleich verschiedener Dienste anschauen (der Artikel ist letztes Jahr auch in der c't erschienen, soweit ich weiß)

Respekt! Herzlichen Dank, auch für das elaborierte teilen Deiner Erfahrung. Gerne mehr.

Ich hatte befürchtet, dass durch die schiere Länge der Anleitung der Eindruck entsteht, das Ganze sei unpraktikabel, und das ist nun auch teilweise eingetroffen.

Dabei ist das im Alltag definitiv nicht der Fall.

Die Länge der Anleitung resultiert wesentlich daraus, dass ich wirklich jeden einzelnen Schritt dokumentiert habe, auch die selbstverständlichen, um den Installationsprozesses komplett nachvollziehbar zu machen und eine eventuelle Verunsicherung während Vorgangs zu nehmen (Ist das jetzt auch richtig so?, Bin ich noch an der richtigen Stelle?), weil dadurch, dass dieser ganze Bereich für viele Neuland ist und es im Internet kaum vollständige Dokumentationen dafür gibt, die Unsicherheit groß sein kann. Eine Anleitung zur Nutzung von TextEdit fiele viiiiieeel länger aus und das kann jeder von uns nutzen.

Dazu kommt dann noch, dass ich auch versucht habe, die technischen und rechtlichen Hintergründe zu schildern, damit man auch versteht, was da passiert. Notwendig zur bloßen Nutzung ist das nicht, aber es hilft in Zweifelsfällen und es ist immer gut, auch zu verstehen, was man tut. Man muss das zu Beginn aber nicht gleich alles mitbedenken, da ist die Anleitung eher zugleich auch Nachschlagewerk.

Wer sich von der Länge überrollt fühlt, für den gibt es extra die Kurzanleitung in Kapitel 2. Da ist das Ganze auf 5 simple Schritte eingedampft (4, wenn man den Acrobat Reader schon installiert hat), die kann wirklich jeder nachvollziehen. Bestellt das Zertifikat bei D-TRUST direkt, dann ist auch der Bestellprozess völlig unkompliziert. Das sollte out-of-the-box funktionieren. Und wenn dann an irgendeiner Stelle etwas unklar sein sollte oder man wissen will, warum, kann man das entsprechende Kapitel der ausführlichen Anleitung konstatieren.

Die Hauptschwierigkeit resultiert einfach daraus, dass man ganz ohne Anleitung nicht darauf kommt, Schritt 5 der Kurzanleitung auszuführen, die Aktualisierung der AATL (die einmalig 1 Mausklick ist). Dann wird einem beim ersten Versuch gleich eine ungültige Unterschrift angezeigt, man versteht nicht warum und fängt an zu verschlimmbessern … Das ist wieder so ein Adobe-Kopfschüttel-Ding, aber vielleicht beheben sie das ja noch irgendwann. Das ist aber die einzige wirkliche Hürde, wenn man das nicht weiß.


Was die Kosten betrifft: Klar, wenn man nur 3 Dokumente im Jahr unterschreiben müsste, lohnt es sich dafür allein nicht. Aber man kann zudem all seine Emails signieren und ggf. verschlüsseln, das allein kostete bislang oft mehr. Und Emails schreibt in der Regel mehr als 3 im Jahr.

Ja, aber das ist genau jenes alternative Verfahren, das ich gleich zu Beginn ausgeschlossen habe:Um es nochmals deutlich zu machen, warum ich persönlich dieses Verfahren für indiskutabel halte: Du musst das PDF, um das es geht und das offensichtlich wichtig genug ist, qualifiziert unterschrieben zu werden (das kann eine Kündigung sein, eine Einverständniserklärung mit einer Gefängnisstrafe, …) lesbar und nicht schreibgeschützt zu dem entsprechenden Anbieter hochladen (denn sonst könnte der es nicht mit einer digitalen Signatur versehen) und musst dem Anbieter dabei vertrauen, dass er das Dokument zwar in Deinem Namen unterschreibt, es ansonsten aber nicht verändert (was er genauso könnte).

Wie man irgendeinem kommerziellen Anbieter bei einem Dokument, das so kritisch ist, dass eine fortgeschrittene Unterschrift nicht ausreicht, derart vertrauen kann, ist mir vollkommen rätselhaft. Aber nachdem diese Anbieter wie Pilze aus dem Boden sprießen, scheint es eine Cloud-gewohnte Klientel zu geben, der das keine Bauchschmerzen bereitet. Für mich käme das niemals infrage.
Klar, genau das ist deren Geschäftsmodell:Ich persönlich halte das für eine Fehlentwicklung, dir irgendwann noch höchst gefährlich werden könnte.

Einerseits mit einer qualifizierten Signatur die höchste Sicherheitsstufe zu wollen, das aber in die Hände eines Dritten zu legen, passt für mich nicht zusammen.

Und nochmals: Seine digitale Signatur in die eigenen Hände zu nehmen ist nicht so schwierig, wie es zu Beginn aussieht. Im Alltag ist es völlig unkompliziert. (Unkomplizierter, als mit so einem Anbieter zu kooperieren!)

Es gibt nur die Hürde, dass zu Beginn alles so kompliziert aussieht. Wenn ich Pech habe, habe ich mit der Ausführlichkeit des Artikels diesen Eindruck noch verstärkt, statt ihm den Stachel zu nehmen, und der Sache somit einen Bärendienst erwiesen.

Zum Beispiel Kündigung; was sollte ich einem Cloud Anbieter nicht vertrauen das er meine Kündigung des Abo bei der T-Mobile nicht manipuliert? Was hätte der Anbieter davon? Datenschutz okay, aber die Veränderlichkeit? Jeder Anbieter der sowas machen würde (v.a. wo es rechtliche Folgen hat), wäre sofort vom Markt.

Der Staat will die höchste Sicherheitsstufe, nicht der User. Mir doch egal was die Sicherheitsstufe ist bei der Kündigung oder Abschliessen eines Services. Ich will es einfach möglichst einfach haben...

Die hatte ich völlig aus den Augen verloren (und ich fürchte, vielen anderen wäre das ebenso gegangen).

Ich hatte sogar bei Synium angefragt, ob für diesen ausführliche Bericht ein Sonderformat möglich sei, aber das war dann nicht der Fall und auch Synium kamen die Journals als Alternative nicht in den Sinn.

Davon abgesehen sind die Journals ja kaum anders aufgebaut als Foren-Threads. Mir hätte ein Format mit parallelen, verlinkten Kapiteln vorgeschwebt wie bei der Rewind, aber das war eben nicht möglich.
Naja, das wäre ein prima Beitrag für eine neue Version meiner eigenen Website gewesen, aber mit der komme ich seit 20 Jahren (kein Scherz) nicht zu Potte.

Und dort ein Forum mit Diskussionsmöglichkeiten zu installieren, bringt gleich einen Rattenschwanz technischer und rechtlicher Probleme mit sich.

Zudem würde dort ja erstmal kein Schwein darauf aufmerksam werden.
Wordpress und Werbung nur über meine Leiche.
Das geht leider nicht wegen der Screenshots. Der Artikel würde völlig explodieren, wenn man die Screenshots gleich in Originalgröße abbilden würde, aber klickbare Miniaturen so wie hier gehen in PDFs nicht. Und das PDF müsste mindestens A3 sein, dass die großen Screenshots draufpassen.
Stimmt, und ein guter Hinweis auf ihre Praxistauglichkeit.
Der ist gut. Neulich hatte ich einer Behörde ein signiertes PDF geschickt. Die waren völlig baff, dass sowas geht, und haben mich gefragt, ob sie das wohl auch machen könnten – „das wäre ja vielleicht nützlich“. 🙄

Oh, da weist Du mich unbeabsichtigt auf die erste wichtige Unklarheit in meinem Bericht hin. Mit Kündigungen sind nicht allgemein Vertragskündigungen, sondern ausschließlich Arbeits- oder Wohnungskündigungen gemeint. Das habe ich nirgendwo erwähnt und kann es jetzt nicht mehr ändern, doof. Mir war das leider so selbstverständlich, dass ich an normale Vertragskündigungen überhaupt nicht gedacht habe. (Ich frage mal Synium, ob sich da noch was ändern lässt.)

Natürlich geht es nicht um triviale Fälle, da bedarf es aber auch keiner qualifizierten Unterschrift. Bei folgenreichen Dokumenten kann man sich aber sehr wohl vorstellen, dass es bestechliche Mitarbeiter gibt. Und außerdem Geheimdienste & Co. Wenn sich dieses Verfahren durchsetzt, wird einfach ein weiterer Angriffsvektor etabliert. Bei selbst gehandhabten Zertifikaten wäre die einzige Möglichkeit, den privaten Schlüssel zu kopieren, solange der noch bei der Registrierungsstelle liegt, und das kann der Zertifikatsinhaber in kritischen Fällen dadurch verhindern, dass er (beim von PSW angewandten Prozedere) das Schlüsselpaar nicht auf der Website von PSW erzeugt, sondern mit lokalen Werkzeugen, sodass PSW den privaten Schlüssel nicht mal für Sekunden zu Gesicht bekommt.
Nicht bei Trivialvorgängen wie einer T-Mobile-Kündigung. Mein Fehler.
Selbst digital zu signieren ist im Alltag einfacher, als jedesmal wieder einen Diensteanbieter zu kontaktieren.

Das war, wie eingangs erwähnt, meine wichtigste Motivation.

Alle klagen über den Stand der Digitalisierung in Deutschland; ich wollte aber nicht immer nur auf andere zeigen, sondern meinen Teil dazu beitragen, dass viele von uns selbst voranschreiten können.

Genau, wegen gerade diesen Disskussionsmöglichkeiten im Forum meinte ich eine eigene Seite à la Ratgeber, damit das eben nicht ausartet mit mehr oder weniger sinnvollen Beiträgen. Du hast dir die Mühe gemacht alles detailliert und übersichtlich aufzuschreiben und dann kommt er erste, der ein Kommentar abgibt über ein anderes Thema wovon die explizit in deinem Beitrag ausgeschlossen hast
Und solche Beiträge verschwinden dann irgendwann in den Tiefen des Forums, bis dann wieder jemand Faules einen neuen Beitrag schreibt, statt sich der Suche zu bemühen…
Und Geld verdienen meinte ich mit Affilitae-Links zu den Produkten die du angibst. WordPress nur, weil es angeblich einfach sein soll, aber das habe ich nie nachvollziehen können. Gute SEO platziert die Seite oben in Suchergebnissen und vielleicht springt dann nebenbei etwas Geld dabei raus…
War nur eine Idee, um deine Arbeit zu versüßen. Wie dem auch sei: Danke und top gemacht! Auch wenn mich das Thema nicht wirklich angeht/interessiert.

Adobe Acrobat habe ich nun neu eingerichtet mit dem D-Trust-Zertifikat von PSW, neuem Unterschrift-Bild usw. Gegenüber meiner ursprünglichen Konfiguration gab es einige Verbesserungen.

Signieren funktioniert jetzt einwandfrei und mit einem konfigurierten Unterschriftbild ist der Prozess sehr komfortabel und obendrein schneller als mit dem üblichen Ausdrucken/Unterschreiben/Scannen bzw. Bild einfügen/Exportieren. Man muss sich nur die Zeit nehmen und einmalig Schritt für Schritt durch die Anleitung arbeiten. Ich finde, die Mühe lohnt sich.

Ah, ok, verstehe. Vielleicht wird’s ja noch.
Danke.

Ok, den Absatz habe ich scheinbar übersehen (kommt davon, wenn man bei langen Texten ab der Hälfte nur noch überfliegt .

Aber offensichtlich kennst du dich in dem Bereich Datenschutz überhaupt nicht aus, daher mal etwas Aufklärungsarbeit von mir. Für solche Fälle gibt es z.B. die DSGVO, die genau diese Sicherheit sicherstellen soll. Daher ist es natürlich notwendig, einen entsprechenden Anbieter aus der EU zu verwenden. Z.B. gibt es auch ein paar deutsche Anbieter für digitale Signaturen. Die DSGVO-Konformität lässt sich als Anbieter übrigens auch bescheinigen lassen, auf sowas kann man auch noch achten. Das solche Dienste auch reihenweise von Behörden und Kommunen verwendet werden (die absolut paranoid sind, was Datenschutz angeht), zeigt auch deutlich, dass man sowas gut verwenden kann.
Du gehst scheinbar davon aus, dass ein solcher Anbieter einfach frei auf deine Dokumente zugreifen kann. Allerdings wäre das ein DSGVO-Super-GAU, wenn das einfach so möglich wäre. Da gibt es ganz strikte gesetzliche Regelungen zu. Es gibt da genug EU- und auch deutsche Anbieter, die absolut seriös sind. "Cloud" und "kommerziell" bedeuten schließlich auf keinen Fall "böse". Und falls man doch keinem kommerziellen Anbieter über den Weg traut, kann man mit sign-me immer noch ganz unkompliziert den Dienst der Bundesdruckerei verwenden (nein, ich arbeite nicht für die )

Auf jeden Fall finde ich es interessant, wie man das ganze komplett händisch umsetzt. Allerdings wäre das für mich als Gelegenheitsnutzer absolut zu umständlich

Die fragliche Passage stand aber in der Einleitung.
Ich kenne mich da einigermaßen gut aus, gewichte das offenbar aber sehr anders als Du.
soll. Ich vertraue da aber überhaupt keiner juristischen Absicht, sondern nur technischer Unmöglichkeit. Darauf beruhen wohl unsere unterschiedlichen Einschätzungen.
Das muss er technisch können, sonst könnte er sie doch nicht signieren, was technisch einfach eine Form der Bearbeitung darstellt.
Die DSGVO ist doch nur ein juristisches Instrument, das verlangt, dass bestimmte Dinge nicht geschehen dürfen. Sie geschehen aber immer wieder, weil ein juristisches Verbot eben nichts mit einer technischen Unmöglichkeit zu tun hat.
Jeder einzelne Mitarbeiter? Alle unbestechlich? Immun gegen Geheimdienste? Sicher vor jeglichen technischen Pannen?
Nicht immer böse, aber manchmal. Und immer unsicher.
Na, ich selbst hebe die in Form von D-TRUST (die auch sign-me betreiben) doch massiv als Empfehlung hervor, ich müsste der Erste sein, den man verdächtigt, für die zu arbeiten und Werbung zu machen. Aber auch sign-me von D-TRUST würde ich niemals verwenden. Es liegt am Prinzip, nicht am einzelnen Unternehmen. (Auch die Bundesdruckerei ist übrigens ein kommerzielles Unternehmen, freilich nach zwischenzeitlicher Privatisierung neuerdings wieder im Staatsbesitz.)
Es ist einfacher als ein Dienst wie sign-me, sobald man das Zertifikat einmal eingerichtet hat, und auch das ist simpel, sobald man einmal begriffen hat, wie es geht.

Doppelklick aufs bei D-TRUST bestellte und von D-TRUST gelieferte Zertifikat und Eingabe der PIN, im Acrobat Reader einmal (und auch nur das erste Mal) bei der AATL auf Jetzt aktualisieren… klicken. Das war’s im Prinzip. Die Anleitung hier behandelt halt alle denkbaren Eventualitäten, technischen Hintergründe usw.

Durch eine Internet-Recherche gelang es mir nicht zu ermitteln, was eine Unterzeichnung per sign-me kostet. Ja, 10 Coins sind frei. Neue Coins soll ich hier kaufen können: (ReinerSCT). Die Website gibt keine Auskunft über die Preise, dafür benötige ich erst ein Nutzerkonto. Ansonsten wirkt die Website auf mich als hätte dort bislang noch kein Mensch versucht Coins zu erwerben.

Wenn ich ein Zertifikat ohnehin kaufe, um E-Mails per S/MIME zu versenden, dann kann ich auch mit ein paar Einstellungen in Adobe Dokumente signieren und mich gegenüber meinen Geschäftspartnern wie ein technischer Pionier fühlen. Aber 1 Euro für eine Unterschrift gebe ich bestimmt nicht aus, wenn ich davon ausgehe, dass der Empfänger des Dokuments solch eine Signatur nicht erwartet.

Der Markt wächst ständig weiter und es kann sein, dass aus Deutschland noch kein entsprechender Anbieter stammt, aber in Europa gibt es doch bestimmt schon mehrere, die man auch als Deutscher verwenden kann.

Luxtrust aus Luxemburg bieten beispielsweise diverse Lösungen an, darunter auch sogenannte SmartCards und eine eigene Middleware Software, die es ermöglicht in Adobe Acrobat mit qualifizierten Zertifikaten zu unterschreiben. Diese können von jedem EU Bürger bestellt und verwendt werden.
Hier auch der Link mit der Anleitung für die Installation und Konfiguration mit Adobe.
(Die rein digitale Lösungen sind nur für in Luxemburg Ansässige interessant, da damit dort alle administrativen, staatlichen Vorgänge sowie lokale Banken arbeiten, diese aber nicht in Acrobat verwendet werden können.)

Und preislich scheinen mir 100€ für 3 Jahre dann vergleichweise wenig. (zzgl. Versand sicherlich + einmalig einen Reader)

Das ist klar. Es scheint ja endlich, endlich etwas in Gang zu kommen.
Bin ich mir nicht so sicher; ich habe aber nicht überall geschaut. Die allgemein bekannten Anbieter jedenfalls sind alle sehr teuer.
Das klingt zweifelsohne interessant und war mir nicht bekannt.
Das ist sogar enorm preiswert. Man sollte dabei aber mitbedenken, dass der Anbieter in der EUTL, nicht aber der AATL gelistet ist. Wenn man weltweit Dokumente austauscht, muss man berücksichtigen, dass Benutzer außerhalb der EU möglicherweise nur die AATL, nicht aber die EUTL laden.

Wer hier und heute auf dem Mac insbesondere in Europa qualifiziert unterschreiben will, für den scheint das aber eine Möglichkeit zu sein.

Was meine Aufmerksamkeit erregt hat, ist, dass hier außer Chipkarte und USB-Dongle auch noch eine iPhone-App aufgeführt ist. Ich hatte mich während meiner Recherche die ganze Zeit gewundert, dass nirgendwo eine iPhone-App als zweiter Faktor für die Zwei-Faktor-Identifizierung bei einer qualifizierten Unterschrift angeboten wird; die Banken machen das bei ihrem Online-Zugang ja mittlerweile praktisch alle so. Das fände ich enorm praktisch und auch eine Preisbrecher-Lösung (40€ für 3 Jahre ist ja wirklich zu vernachlässigen).

Leider habe ich keine Angabe finden können, ob die App als zweiter Faktor für Unterschriften im Acrobat Reader zu verwenden ist. Ich fürchte, eher nicht, weil das wohl einen noch gar nicht vorhandenen neuen Typ Digitale ID in den Einstellungen voraussetzen würde. Weiß Du da was? Sonst rufe ich vielleicht mal dort an.

Nun, zufällig bin ich LuxTrust-Kunde.
In der App wird mir ein qualifziertes Zertifikat angezeigt. Ich kann aber nicht erkennen, dass ich das herunterladen könnte. Wäre ja interessant, wenn ich mehr daraus machen könnte.

Zur Zeit gibt es für Privatkunden 5 kostenlose elektronische Signaturen.
Wenn ich mich dann mit einem Token oder meiner App als zweiter Faktor auf dem Webportal anmelde, kann ich online unterzeichnen.
Die Weboberfläche sieht dann so aus:

Herzlichen Dank für diese ausführliche Fleißarbeit!

Hallo Weia,

Danke für diesen ausführlichen Artikel.

Für alle Österreicher gibt es noch die Möglichkeit eine Handysignatur zu lösen. Das ist gratis und man kann damit diverse amtliche Services sowie Sozialversicherungs-Dinge erledigen/ansehen. Mit Hilfe der "Digitales Amt"-App kann man dann auch beliebige PDFs mit seinem eigenen Zertifikat unterschreiben. Ist eine Sache von < 1Min Aufwand, kostet nix und kann auch die Oma machen



LG
Michael

Interessant finde ich bei beiden vorgestellten Verfahren für die Zertifikatserstellung, dass dort beides mal Scans/Kopien des Personalausweises gearbeitet wird.
Wäre das nicht mal ein Anwendungfall für den e-Perso?

Ich habe jetzt mit LuxTrust telefoniert und laut deren Auskunft ist es ausdrücklich möglich, mit der App im Acrobat Reader zu unterschreiben (statt Chipkartenleser oder USB Token).

Herunterladen kannst Du das Zertifikat ziemlich sicher nicht, aber das ist bei Chipkarte oder USB Token meines Wissens (bislang keine eignen Erfahrung) ebensowenig der Fall; bei diesen Lösungen installierst Du kein Zertifikat auf Deinem Rechner (weswegen man sie auch nicht für Email-Signaturen verwenden kann), sondern steckst stattdessen Chipkartenleser oder USB Token an den Rechner. Und so müsste das dann auch mit dem iPhone gehen (vermutlich ebenfalls nur, wenn es mit USB am Rechner hängt).

Ich konnte mir das Verfahren jetzt im Einzelnen nicht am Telefon erklären lassen, da ich die App ja nicht habe, aber es geht jedenfalls angeblich. Da hast Du Deine nächste Hausaufgabe.

Da sind uns die Österreicher ja und Einiges voraus.
Kannst Du das noch etwas näher erläutern? Ist die Digitales Amt-App eine iPhone-App oder eine Mac-App? Dein Screenshot stammt ja jedenfalls vom Mac. Wie ist da das Zusammenspiel zwischen iPhone und Mac?

Und handelt es sich de facto um ein Online-Signatur-Verfahren (PDF wird zum Signieren hochgeladen) oder ein lokales (PDF bleibt auf dem Rechner)?

Wäre es. Ist es aber nicht. Ich habe mir das auch gedacht.

Man könnte sich ja sogar fragen, ob nicht der e-Perso selbst einfach der zweite Faktor für eine qualifizierte Unterschrift sein könnte und sollte. Aber da gibt es auch das gute Gegenargument, dass zu viel Kontrollmacht an einer Stelle zusammenläuft und man dann dem Staat vorbehaltlos vertrauen muss, dass er keine Hintertüren einbaut – da ist eine Dezentralisierung in staatliche und privatwirtschaftliche (aber staatlich beaufsichtige) Institutionen wie die Zertifizierungsstellen vielleicht die bessere Lösung.