Outlook 2016

Diese Anleitung ist optimiert für die Installation und Nutzung von Zertifikaten mit Microsoft Outlook 2016 zum Signieren und Verschlüsseln von E-Mails. Sie finden diese Anleitung unter https://www.globaltrust.eu/static/outlook-anleitung.pdf

Damit Signatoren gültige Signaturen im Mailversand herstellen können, müssen die notwendigen privaten Schlüssel und Zertifikate in der Microsoft Zertifikatsverwaltung installiert werden. Der Installationsvorgang ist für den Signator einmalig erforderlich.
Sofern der Mail-Empfänger ein aktuelles Microsoft Betriebssystem hat (inklusive der von Microsoft empfohlenen Updates), sind keine Aktivitäten von seiner Seite erforderlich. Signierte Mails werden automatisch erkannt. Troubleshooting bei der Zertifikatsverwendung bei Outlook.
Weiters enthält die Dokumentation eine Anleitung zur Verwendung des GLOBALTRUST-LDAP-Servers und Hilfen zur erstmaligen Einrichtung eines Outlook-Accounts.
Die Dokumentation enthält auch frühere Anleitungen zu Outlook 2013 und Outlook 2007/2010.

Quick-Installation für versierte User

Installieren Zertifikat

• PKCS#12-Datei von GLOBALTRUST herunterladen und mit Doppelklick in der Windows-Zertifikatsverwaltung installieren
• In den Outlook-Optionen die Einstellungen für das Trust Center auswählen
• Unter E-Mail-Sicherheit bei Verschlüsselte E-Mail-Nachrichten die „Einstellungen…“ auswählen
• Signatur- und Verschlüsselungszertifikat auswählen, Hash-Algorithmus auf „SHA256“ umstellen

Signieren/Verschlüsseln

• Neue Nachricht verfassen
• Optionen-Ribbon anzeigen lassen
• Button Signieren bzw. Verschlüsseln drücken → Senden
• Um eine Nachricht zu verschlüsseln, wird ein Zertifikat des Empfängers benötigt (siehe Dokumentation)
• GLOBALTRUST erstellt privaten Schlüssel und Zertifikat

Sofern GLOBALTRUST den privaten Schlüssel erstellt und das Zertifikat ausstellt, erhält der Signator eine einzige Datei im PKCS#12-Format (.P12-Endung), die sowohl den privaten Schlüssel, das eigene Zertifikat und alle Angaben zum Zertifizierungspfad enthält.
Nach erfolgreicher Installation (siehe unten) erhalten Sie einen Zertifizierungspfad, der folgendes Aussehen hat:

• „GLOBALTRUST“ → „GLOBALTRUST CLIENT 1“ → „Ihr Endbenutzerzertifikat“ oder
• „GLOBALTRUST 2015 “ → „GLOBALTRUST 2015 CLIENT 1“ → „Ihr Endbenutzerzertifikat“ oder
• „GLOBALTRUST 2020 “ → „GLOBALTRUST 2020 CLIENT 1“ → „Ihr Endbenutzerzertifikat“

Hinweis: aufgrund spezifischer Anforderungen sind auch andere Zertifikatsketten möglich, sie beginnen jedoch alle mit GLOBALTRUST.

Zertifikatsverwendung bei Outlook mit mehreren E-Mail-Adressen

Outlook akzeptiert zum Signieren von Mails nur Zertifikate, die exakt dieselbe Mailadresse wie das aktive Benutzerkonto enthalten. Will jemand bei verschiedenen Mailadressen signieren, dann benötigt er mehrere Zertifikate. Wie man die Zertifikate anzeigen lassen kann erfahren Sie hier.

Das könnte Sie noch interessieren

Benutzeranleitung zum Signieren von PDFs mithilfe PKCS12-basierter Zertifikaten Stand: 13. April 2023

1. Beschaffung geeigneter Signaturzertifikate

PDFCreator erlaubt das automatisierte Unterschreiben aller gedruckten Dokumente mithilfe PKCS-12 basierter Signatur und Siegelzertifikate. Folgende GLOBALTRUST Produkttypen werden standardmäßig als PKCS12-Datei ausgeliefert und sind daher zur PDF-Signatur gemäß dieser Anleitung geeignet:

✓  SIGNATURE
✓ COMPANY

✓ Eine Übersicht über alle Produkte finden Sie hier

2. Druckereinstellungen öffnen

Startoberfläche PDF Creator

Legende:

1. „Drucker“ auswählen
2. „Einstellungen…“ öffnen

3. Einstellungen für PDF öffnen

PDF-Einstellungen

Legende:

1. auf der linken Seite unter „Formate“ das Format „PDF“ auswählen

4. Einstellungen für Unterschriften öffnen

Unterschrifteinstellungen

Legende:

1. auf der rechten Seite den Reiter „Unterschreiben“ auswählen

5. Parameter für Signatur setzen

Zertifikatsdatei hinterlegen und Signaturparameter setzen.

Legende:

1.  „Unterschreibe Datei“ ankreuzen
2. Zertifikatsdatei auswählen (die benötigte PFX Datei finden Sie auf der GLOBALTRUST Download Seite unter ITEM I)
3. Optional Grund, Kontakt, Ort angeben
4. Optional weiter unten „Unterschrift in PDF Datei anzeigen“ ankreuzen
   
    

   Anschließend werden gedruckte PDFs automatisch mit dem angegebenen Zertifikat signiert.

Signaturerstellungseinheiten

Signaturerstellungseinheiten enthalten den privaten Schlüssel, der zur Erzeugung einer fortgeschrittenen Signatur erforderlich ist. Üblicherweise erfolgt die Aufbewahrung in einer verschlüsselten Datei die mittels PIN (Passwort) genutzt werden kann (Details siehe https://www.globaltrust.eu/static/help.html#HLP_B11).

Spezielle Hardware kann die Aufbewahrung und Sicherung der Signaturerstellungsdaten erleichtern. Die anerkannten Signaturerstellungseinheiten werden in einer Liste bei den einzelnen Evaluationsstellen veröffentlicht.

Da die digitale Signatur EU-weit durch eine gemeinsame Verordnung (eIDAS) geregelt ist, müssen in den einzelnen Ländern evaluierte gleichwertige Verfahren in den anderen Ländern gegenseitig anerkannt werden.

Geeignete qualifizierte Signaturerstellungseinheiten (QSCD) zur qualifizierten Signatur

Untenstehende Signaturerstellungseinheiten werden von GLOBALTRUST zur qualifizierten Signatur unterstützt.

Produkt: TRUST2GO®

• Typ: remote-QSCD-Gesamtsystem
  Bestätigungsstelle: A-SIT (AT)
  Bestätigung: AIT VIG A-SIT-VIG-20-105 (https://www.a-sit.at/downloads/1909)
  Ausgestellt: 12.07.2022
  Zertifizierung: § 7 ABS. 1 SVG IVM ART. 30 ABS. 3 LIT. B EIDAS-VO
  Signatursuite:
• RSASSA-PKCS1-v1_5 nach PKCS#1 v2.2 (RFC 8017) mit Schlüssellängen von 2048, 3072 oder 4096 Bit,
• RSASSA-PSS nach PKCS#1 v2.2 (RFC 8017) mit Schlüssellängen von 2048, 3072 oder 4096 Bit und
•  ECDSA nach FIPS PUB 186-4 und den NIST29-Kurven P-256, P-384 oder P-521 mit Länge der Parameter p, q von 256, 384 oder 512 Bit,
  Hashfunktionen:
• SHA31-256, SHA-384 und SHA-512 nach ISO32/IEC33 10118-3 bzw. FIPS 180-4

Produkt: Atos CardOS v5.3

Typ: Smartcard
Bestätigungsstelle: A-SIT (AT)
Bestätigung: A-SIT-1.108 Sichere Signaturerstellungseinheit
CardOS V5.3 QES, V1.0 (http://www.a-sit.at/pdfs/bescheinigungen_sig/1108_bescheinigung_cardos-v53-qes-v1…)
Ausgestellt: 08.08.2014
Zertifizierung: Common Criteria Part 3 conformantEAL 4 augmented by AVA_VAN.5
Signatursuite:
– ECDSA12 nach ANSI X 9.62 bzw. ISO/IEC 15946-2 mit Längen der Parameter p, q von 256 oder 384 Bit. Es werden die Kurven P-256 bzw. P-384 nach FIPS PUB 186-4 sowie brainpoolP256r1 bzw. brainpoolP384r1 nach RFC 5639 unterstützt.
Hashfunktion: SHA-2
Anmerkungen: –
weitere Dokumente: –

Geeignete Kartenlesegeräte (Cardreader)

Eine Bestätigung ist für den Betrieb eines Kartenlesegeräts nach den österreichischen Signaturbestimmungen nicht zwingend erforderlich, kann aber bei der Auswahl zuverlässiger Geräte hilfreich sein. Auf Anfrage testet GLOBALTRUST gewünschte Kartenlesegeräte und stellt eine Bestätigung aus, unter welchen Bedingungen sie für GLOBALTRUST-Smartcards geeignet sind.

Grundsätzlich sind alle Cardreader, die ISO 7816 unterstützen für die Verwendung von GLOBALTRUST-Smartcards geeignet.

Aktuelle Listen offiziell bestätigter Kartenlesegeräte nach dem Signaturgesetz finden sich unter http://www.a-sit.at/, http://www.bundesnetzagentur.de/cln_1421/DE/Service-Funktionen/Qualifizierteelekt…

Produkt: Cherry SmartTerminal ST-2xxx

Typ: Kontaktbehaftet, Single-Slot-Kartenleser, extern,
Schnittstelle: USB, PIN-Eingabe
Kartenformat: Standard (Smartcard Standard im Scheckkartenformat, ID-1: Fullsize, Größe 85,60*53,98, Dicke 0,76, ISO/IEC 7810:2003)
Zertifizierungsstelle: BSI
Zertifikat: BSI-DSZ-CC-0660-2010 (https://www.bsi.bund.de/SharedDocs/Zertifikate/CC/Digitale_Signatur_Kartenleseger…)
Gültigkeit: 31.12.2016
Anmerkungen: –
weitere Dokumente: –

Produkt: Gemalto IDBridge CT40 Smart Card Reader

Typ: kontaktbehaftet, Single-Slot-Kartenleser, extern,
Schnittstelle: USB, keine PIN-Eingabe
Kartenformat: Standard (Smartcard Standard im Scheckkartenformat, ID-1: Fullsize, Größe 85,60*53,98, Dicke 0,76, ISO/IEC 7810:2003)
Zertifizierungsstelle: keine Zertifizierung
Zertifikat: –
Gültigkeit: –
Anmerkungen: –
Datenblatt: https://drivers.softpedia.com/get/CARD-READERS/Gemalto/Gemalto-IDBridge-CT40-USB-…
Treiber Windows: –

Produkt: Gemalto IDBridge K30 Smart Card Reader

Typ: kontaktbehaftet, Single-Slot-Kartenleser, extern, Größe etwa ein USB-Datenstick
Schnittstelle: USB, keine PIN-Eingabe
Kartenformat: Mini (Smartcard Telefon-Micro-SIM-Card-Format, Mini-UICC: Micro-SIM, Größe 15,00*12,00, Dicke 0,76, ETSI TS 102 221 V9.0.0)
Zertifizierungsstelle: keine Zertifizierung
Zertifikat: –
Gültigkeit: –
Anmerkungen: –
Datenblatt: https://drivers.softpedia.com/dyn-search.php?search_term=gemalto+k30&p_category=27
Treiber Windows: –

Produkt:  ACS ACR39TA1-Short Smart Card Reader

Typ: kontaktbehaftet, Single-Slot-Kartenleser, extern, sehr kurz (nur 47 mm lang, inkl. Stecker)
Schnittstelle: USB, keine PIN-Eingabe
Kartenformat: Mini (Smartcard Telefon-Micro-SIM-Card-Format, Mini-UICC: Micro-SIM, Größe 15,00*12,00, Dicke 0,76, ETSI TS 102 221 V9.0.0)
Zertifizierungsstelle: keine Zertifizierung
Zertifikat: –
Gültigkeit: –
Anmerkungen: –
Datenblatt: http://www.acs.com.hk/en/products/331/acr39t-a1-smart-card-reader/
Treiber Windows: –

Produkt: Feitian bR301 Bluetooth+USB Smart Card Reader

Typ: kontaktbehaftet, Single-Slot-Kartenleser, extern,
Schnittstelle: Bluetooth und USB, keine PIN-Eingabe
Kartenformat: Standard (Smartcard Standard im Scheckkartenformat, ID-1: Fullsize, Größe 85,60*53,98, Dicke 0,76, ISO/IEC 7810:2003)
Zertifizierungsstelle: keine Zertifizierung
Zertifikat: –
Gültigkeit: –
Anmerkungen: von GLOBALTRUST unter Windows 8.1 getestet, Geräte ohne integrierte Bluetoothschnittstelle benötigen zusätzlich einen Adapter!
Datenblatt: http://www.ftsafe.com/products/reader/Bluetooth
Driver Windows: https://github.com/FeitianSmartcardReader/bR301_SDK_Latest/tree/master/bR301 Bluetooth Driver
Driver Windows: http://crypt.as/br301_driver
Entwicklung: https://github.com/FeitianSmartcardReader/bR301_SDK_Latest

Produkt: Gemalto IDBridge CT710 Smart Card Reader

Typ: kontaktbehaftet, Single-Slot-Kartenleser, extern,
Schnittstelle: USB, PIN-Eingabe, LED Anzeige
Kartenformat: Standard (Smartcard Standard im Scheckkartenformat, ID-1: Fullsize, Größe 85,60*53,98, Dicke 0,76, ISO/IEC 7810:2003)
Zertifizierungsstelle: keine Zertifizierung
Zertifikat: –
Gültigkeit: –
Anmerkungen: mit Standardtreiber nur ohne PinPad verwendbar; für PinPad Unterstützung eigenen Treiber installieren
Datenblatt:
Treiber Windows: http://support.gemalto.com/?id=idbridge_ct710#.VjiAsSviOAA

Produkt: LENOVO Gemplus ExpressCard Card Reader

Typ: kontaktbehaftet, Single-Slot-Kartenleser, intern,
Schnittstelle: ExpressCard/54, keine PIN-Eingabe
Kartenformat: Standard (Smartcard Standard im Scheckkartenformat, ID-1: Fullsize, Größe 85,60*53,98, Dicke 0,76, ISO/IEC 7810:2003)
Zertifizierungsstelle: keine Zertifizierung
Zertifikat: –
Gültigkeit: –
Anmerkungen: von GLOBALTRUST unter Windows 7 64 Bit getestet
Datenblatt: –
Treiber Windows: –

Geeignete Signaturerstellungssoftware für qualifizierte Signaturen

Grundlagen

Die Spezifikation eines Formats für zu signierende Daten muss allgemein verfügbar sein und sicherstellen, dass die signierten Daten sowohl bei der Signaturerstellung als auch bei der Signaturprüfung zweifelsfrei und mit gleichem Ergebnis darstellbar sind. Können in einem Format dynamische Änderungen kodiert werden, so dürfen jene Elemente, die dynamische Änderungen hervorrufen können, nicht verwendet werden.

Produkt: GlobalTrustApp

Dokumentenformate: pdf, xml
Signaturformate: Adobe (pdf), XMLDSIG (xml)
Anmerkung: Kostenlose Software direkt von GLOBALTRUST
Download Windows: https://www.globaltrust.eu/static/globaltrustapp.exe
Dokumentation: https://www.globaltrust.eu/static/doku-globaltrustapp.pdf

Geeignete Signaturerstellungseinheiten zur fortgeschrittenen Signatur

Produkt: Safenet (vormals Aladdin) eToken Pro 72k

Typ:Token
Zertifizierungsstelle: NIST
Zertifikat: #1135, #1136 (http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm)
Gültigkeit: zeitlich unbeschränkt
Zertifizierung: EAL4+ (Prozessor), FIPS 140-2 L2, FIPS 140-2 L3
Signatursuite: 001 (RSA)
Padding: PKCS1-v1.5 (3.01)
Hashfunktion: SHA-1 (2.01)
Anmerkungen: –
weitere Dokumente: http://www.safenet-inc.com/products/data-protection/two-factor-authentication/eto…/

Der „eToken Pro“ der Firma Safenet (vormals Aladdin) enthält einen Prozessor-Chip (Smartchip) mit einem Betriebssystem für die Erstellung von Signaturen.

Der Token hat eine USB-Schnittstelle und kann daher bei jedem Computer mit USB-Anschluss verwendet werden. Der eToken ist eine Smartcard mit USB-Anschluss.

Die Entscheidung von GLOBALTRUST für diese Hardware erfolgte, da zur Benutzung kein Zusatzgerät (Kartenleser) erforderlich ist, die erforderlichen Treiber leicht zu installieren sind und Standardprodukte, wie Adobe Acrobat (ab Version 7) den Token unterstützen.

Zur Verwendung des Safenet eToken ist eine Treibersoftware des Herstellers notwendig. Diese erhalten Kunden, die ein Zertifikat auf einem eToken bestellen, von uns auf Anfrage.

XML – DSig – XaDES

XML-Basisinformation

XML ist eine sogenannte Markup Language und wird verwendet, um Daten zu strukturieren. Mithilfe von XML-Schemata können bestimmte XML-basierte Datenformate (z. B. Webinterface für XML-Rechnungen) festgelegt werden.
Eine Besonderheit von XML ist, dass ein und dasselbe XML Dokument mehrere physische (=byte-)Repräsentationen besitzen kann. Ein Beispiel:

test1.xml:
<?xml version=“1.0″ encoding=“UTF-8″ ?>
<hello>Hello World!</hello>

test2.xml:
<?xml version=“1.0″ encoding=“ISO-8859-15″ ?>
<hello>Hello World!</hello>

Obwohl test1.xml und test2.xml verschiedene Dateigrößen aufweisen, sind sie aus XML-Sicht ein und dieselbe Datei. Wenn man nun einfach test1.xml als Datei signieren würde, würde die Signatur für test2.xml nicht mehr gelten. Das erscheint zwar als kein großes Problem, wenn man diese 2 Dateien betrachtet, wenn man aber bedenkt, dass XML darauf ausgelegt ist, von Maschine zu Maschine weitergereicht und dazwischen ausgewertet zu werden, wird das Problem sichtbar. Wenn jetzt eine Maschine das ISO-8859-15 kodierte File einliest, auswertet, und wieder UTF-8 kodiert ausgibt, um es der nächsten bearbeitenden Applikation zu übergeben, wird die Signatur ungültig, obwohl nur XML Transformationen stattgefunden haben, die den Inhalt des Dokuments nicht verändern.

Zu vergleichen ist die Problematik mit ASN.1, wo aus diesem Grund DER eingeführt wurde – semantisch gleiche Daten werden auf Byte-Ebene gleich abgebildet.

Bei XML gibt es auch eine Technologie, die aus semantisch gleichen XML-Dokumenten eine gleiche physische Repräsentation erzeugt: Canonical XML (C14n).

„DSig“ ist XML-Signaturstandard von W3C

Nach der sogenannten Canonicalization ist ein XML Dokument bereit, signiert zu werden. Auch dies könnte theoretisch auf verschiedene Arten passieren, am naheliegendsten ist aber die Verwendung des flexiblen „XML-Signature Syntax and Processing“ Standards (DSig) der W3C.

Dieser Standard ist so flexibel, dass es nicht nur möglich ist, XML Dokumente damit zu signieren, sondern beliebige Dokumente. Der Kernpunkt des Standards ist eigentlich, dass die Signatur im XML Format abgelegt wird – egal, welche Art von Daten damit signiert werden.

Es gibt 3 verschiedene Arten, mit DSig zu signieren: Enveloping, Enveloped und Detached. Enveloping und Enveloped Signaturen werden primär auf XML Dokumente angewandt, die Signatur befindet sich dabei zusammen mit den XML Daten in dem selben XML File. Mit einer Detached Signatur können alle Dokumenttypen signiert werden, die Signatur wird in einem eigenen XML File gespeichert. Grundsätzlich können mit XML DSig immer beliebig viele Dokumente auf einmal unterschrieben werden – sie müssen nur mit dem ds:Reference-Tag eingebunden werden.

Unterschreiben des folgenden XML Files (/home/gast/test2.xml):

<rechnung>
<empfaenger>
<vorname>Daniel</vorname>
<nachname>Weller</nachname>
</empfaenger>
</rechnung>

Enveloped Signature:
<rechnung>
<empfaenger>
<vorname>Daniel</vorname>
<nachname>Weller</nachname>
</empfaenger>
<ds:Signature xmlns:ds=“http://www.w3.org/2000/09/xmldsig#“>
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm=“http://www.w3.org/TR/2001/REC-xml-c14n-20010315″></ds:CanonicalizationMethod>
<ds:SignatureMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#rsa-sha1″></ds:SignatureMethod>
<ds:Reference URI=““>
<ds:Transforms>
<ds:Transform Algorithm=“http://www.w3.org/2000/09/xmldsig#enveloped-signature“></ds:Transform>
<ds:Transform Algorithm=“http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments“></ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1″></ds:DigestMethod>
<ds:DigestValue>YHkJTgkmev7VDyv1/Iiqm6RMRYk=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
C377H6bQoX39eNFxcdB0GQ/CMMxstEsErhK91CHCnsYnLr+9DZd6Wv+KwdlyINtiYWInBGJJzjPg
W2dp7acCbZYO1lt60qYlnZYTvoCpC1JW9KQhkLg0h5AiRegBJqPj7h+gz6lYrZ1g3kWxg0ZzUEmB
dT0yUjwhp9SqKRoiUXQ=
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIIFCzCCA/OgAwIBAgICAPAwDQYJKoZIhvcNAQEFBQAwgcwxCzAJBgNVBAYTAkFUMRAwDgYDVQQI
EwdBdXN0cmlhMQ8wDQYDVQQHEwZWaWVubmExOjA4BgNVBAoTMUFSR0UgREFURU4gLSBBdXN0cmlh
biBTb2NpZXR5IGZvciBEYXRhIFByb3RlY3Rpb24xJTAjBgNVBAsTHEEtQ0VSVCBDZXJ0aWZpY2F0
aW9uIFNlcnZpY2UxGDAWBgNVBAMTD0EtQ0VSVCBBRFZBTkNFRDEdMBsGCSqGSIb3DQEJARYOaW5m
b0BhLWNlcnQuYXQwHhcNMDUwOTA2MDAwMDAwWhcNMDcwOTA2MTM0NjMzWjCBgTELMAkGA1UEBhMC
QVQxCjAIBgNVBAgTAS0xDTALBgNVBAcTBFdpZW4xCjAIBgNVBAoTAS0xLDAqBgNVBAMTI0Rhbmll
bCBXZWxsZXIsIE5FVUFVU1NURUxMVU5HKFRlc3QpMR0wGwYJKoZIhvcNAQkBFg5kLndAZnJlZW5l
dC5hdDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsi4csbc69/NYQqm9X1VdLcgPf2nkfDgi
8C4JDKji3UWoNISFA8UzuNvk65Hfm9ZNaBXK5E/sE7BgCuvNiTKDlyg9u0iJwKqboWoSTvSvQrLc
ADBtqD0wl0K1y8mF1Dra0CInPIMC/x0tJSpDs6vwSKSR5d6yIgH6YNjBXx1LqvcCAwEAAaOCAcIw
ggG+MAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFC51MRVwN//xQPfZQO0ZhW1sgA5LMB8GA1UdIwQY
MBaAFDd/Pj6ZcWDKJNSRE3nQdCm0qCTYMBkGA1UdEQQSMBCBDmQud0BmcmVlbmV0LmF0MC8GA1Ud
EgQoMCaBDmluZm9AYS1jZXJ0LmF0hhRodHRwOi8vd3d3LmEtY2VydC5hdDA5BgNVHR8EMjAwMC6g
LKAqhihodHRwOi8vd3d3LmEtY2VydC5hdC9zdGF0aWMvYWR2YW5jZWQuY3JsMA4GA1UdDwEB/wQE
AwIE8DARBglghkgBhvhCAQEEBAMCBPAwUQYDVR0gBEowSDBGBggqKAAYAQEBAzA6MDgGCCsGAQUF
wIBFixodHRwOi8vd3d3LmEtY2VydC5hdC9jZXJ0aWZpY2F0ZS1wb2xpY3kuaHRtbDA7BglghkgB
hvhCAQgELhYsaHR0cDovL3d3dy5hLWNlcnQuYXQvY2VydGlmaWNhdGUtcG9saWN5Lmh0bWwwNAYJ
YIZIAYb4QgENBCcWJUEtQ0VSVCBBRFZBTkNFRCBDZXJ0aWZpY2F0aW9uIFNlcnZpY2UwDQYJKoZI
hvcNAQEFBQADggEBAI7lW+WJbVm6E3qwY0w9F21LjKI3nf19NxWg9jmHN8vwfLsWnwatW3cBpxQO
4jAfxl8xqpX36e3QGXOiDPnYOJ3blmcOxZ3sNL15s+Iq6P9DPyLv/7L0La2FRh4gfWGEbh15BEfh
S65VdxR+LTr9prIt1FSTpl2qIO/nIs+6ouN6TQ6B2JUAeXXaMuQGxM7LNL4XcWVveOaC3oem+Ym7
c2omf3Sge5nRj6Eg7KYh5VCvy6Dhvk8AT25f2qimhXAyl1hMV3ESpZOJVxPqMSoQO8+hSlXbLPsC
MWk88fnm2YdRTU4RKVbmCrfjvrFO6Rvx1/3AaJQ7gFJdbmLUCOm3LUc=
</ds:X509Certificate>
</ds:X509Data>
<ds:KeyValue>
<ds:RSAKeyValue>
<ds:Modulus>
si4csbc69/NYQqm9X1VdLcgPf2nkfDgi8C4JDKji3UWoNISFA8UzuNvk65Hfm9ZNaBXK5E/sE7Bg
CuvNiTKDlyg9u0iJwKqboWoSTvSvQrLcADBtqD0wl0K1y8mF1Dra0CInPIMC/x0tJSpDs6vwSKSR
5d6yIgH6YNjBXx1Lqvc=
</ds:Modulus>
<ds:Exponent>AQAB</ds:Exponent>
</ds:RSAKeyValue>
</ds:KeyValue>
</ds:KeyInfo>
</ds:Signature></rechnung>

Sie haben noch keine digitale Signatur? Bestellen Sie jetzt!

Enveloping Signature:

<ds:Signature xmlns:ds=“http://www.w3.org/2000/09/xmldsig#“>
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm=“http://www.w3.org/TR/2001/REC-xml-c14n-20010315″></ds:CanonicalizationMethod>
<ds:SignatureMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#rsa-sha1″></ds:SignatureMethod>
<ds:Reference URI=“#5pg5d8xpho“>
<ds:Transforms>
<ds:Transform Algorithm=“http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments“></ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1″></ds:DigestMethod>
<ds:DigestValue>FJw+7uwssGSno6pC01roT5pCrOE=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
Me4KrnkhFFP6+1wcw0r54UMS4sn0pyCgLWKJbEMEIvQw9NJ0Jrw/QfRegg0AcHvuYidCS5dDnLm2
vXM5TQFhzsW2PtpBWKG4cdX9D/HYjve4rhdgkH/z9ATqIJEtF1bARL3J46xm93NcnNOHb1vY8m9D
YHUrkPjrmnwirfLm2Wg=
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIIFCzCCA/OgAwIBAgICAPAwDQYJKoZIhvcNAQEFBQAwgcwxCzAJBgNVBAYTAkFUMRAwDgYDVQQI
EwdBdXN0cmlhMQ8wDQYDVQQHEwZWaWVubmExOjA4BgNVBAoTMUFSR0UgREFURU4gLSBBdXN0cmlh
biBTb2NpZXR5IGZvciBEYXRhIFByb3RlY3Rpb24xJTAjBgNVBAsTHEEtQ0VSVCBDZXJ0aWZpY2F0
aW9uIFNlcnZpY2UxGDAWBgNVBAMTD0EtQ0VSVCBBRFZBTkNFRDEdMBsGCSqGSIb3DQEJARYOaW5m
b0BhLWNlcnQuYXQwHhcNMDUwOTA2MDAwMDAwWhcNMDcwOTA2MTM0NjMzWjCBgTELMAkGA1UEBhMC
QVQxCjAIBgNVBAgTAS0xDTALBgNVBAcTBFdpZW4xCjAIBgNVBAoTAS0xLDAqBgNVBAMTI0Rhbmll
bCBXZWxsZXIsIE5FVUFVU1NURUxMVU5HKFRlc3QpMR0wGwYJKoZIhvcNAQkBFg5kLndAZnJlZW5l
dC5hdDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsi4csbc69/NYQqm9X1VdLcgPf2nkfDgi
8C4JDKji3UWoNISFA8UzuNvk65Hfm9ZNaBXK5E/sE7BgCuvNiTKDlyg9u0iJwKqboWoSTvSvQrLc
ADBtqD0wl0K1y8mF1Dra0CInPIMC/x0tJSpDs6vwSKSR5d6yIgH6YNjBXx1LqvcCAwEAAaOCAcIw
ggG+MAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFC51MRVwN//xQPfZQO0ZhW1sgA5LMB8GA1UdIwQY
MBaAFDd/Pj6ZcWDKJNSRE3nQdCm0qCTYMBkGA1UdEQQSMBCBDmQud0BmcmVlbmV0LmF0MC8GA1Ud
EgQoMCaBDmluZm9AYS1jZXJ0LmF0hhRodHRwOi8vd3d3LmEtY2VydC5hdDA5BgNVHR8EMjAwMC6g
LKAqhihodHRwOi8vd3d3LmEtY2VydC5hdC9zdGF0aWMvYWR2YW5jZWQuY3JsMA4GA1UdDwEB/wQE
AwIE8DARBglghkgBhvhCAQEEBAMCBPAwUQYDVR0gBEowSDBGBggqKAAYAQEBAzA6MDgGCCsGAQUF
BwIBFixodHRwOi8vd3d3LmEtY2VydC5hdC9jZXJ0aWZpY2F0ZS1wb2xpY3kuaHRtbDA7BglghkgB
hvhCAQgELhYsaHR0cDovL3d3dy5hLWNlcnQuYXQvY2VydGlmaWNhdGUtcG9saWN5Lmh0bWwwNAYJ
YIZIAYb4QgENBCcWJUEtQ0VSVCBBRFZBTkNFRCBDZXJ0aWZpY2F0aW9uIFNlcnZpY2UwDQYJKoZI
hvcNAQEFBQADggEBAI7lW+WJbVm6E3qwY0w9F21LjKI3nf19NxWg9jmHN8vwfLsWnwatW3cBpxQO
4jAfxl8xqpX36e3QGXOiDPnYOJ3blmcOxZ3sNL15s+Iq6P9DPyLv/7L0La2FRh4gfWGEbh15BEfh
S65VdxR+LTr9prIt1FSTpl2qIO/nIs+6ouN6TQ6B2JUAeXXaMuQGxM7LNL4XcWVveOaC3oem+Ym7
c2omf3Sge5nRj6Eg7KYh5VCvy6Dhvk8AT25f2qimhXAyl1hMV3ESpZOJVxPqMSoQO8+hSlXbLPsC
MWk88fnm2YdRTU4RKVbmCrfjvrFO6Rvx1/3AaJQ7gFJdbmLUCOm3LUc=
</ds:X509Certificate>
</ds:X509Data>
<ds:KeyValue>
<ds:RSAKeyValue>
<ds:Modulus>
si4csbc69/NYQqm9X1VdLcgPf2nkfDgi8C4JDKji3UWoNISFA8UzuNvk65Hfm9ZNaBXK5E/sE7Bg
CuvNiTKDlyg9u0iJwKqboWoSTvSvQrLcADBtqD0wl0K1y8mF1Dra0CInPIMC/x0tJSpDs6vwSKSR
5d6yIgH6YNjBXx1Lqvc=
</ds:Modulus>
<ds:Exponent>AQAB</ds:Exponent>
</ds:RSAKeyValue>
</ds:KeyValue>
</ds:KeyInfo>
<ds:Object Id=“5pg5d8xpho“><rechnung>
<empfaenger>
<vorname>Daniel</vorname>
<nachname>Weller</nachname>
</empfaenger>
</rechnung></ds:Object>
</ds:Signature>

Der große Unterschied zwischen diesen beiden Formaten ist, dass bei der Enveloped Signatur die Reference URI=““ ist – also sich auf das gesamte Dokument (ausgenommen dem Inhalt des Signature-Tags) bezieht, während bei der Enveloping Signatur die Reference URI=“#5pg5d8xpho“ ist. Diese Referenz bezieht sich also auf das gleiche Dokument, und zwar spezifisch auf das Element mit der id „5pg5d8xpho“. Dieses Element ist das Object Element, in dem die zu signierenden Daten verpackt sind.
Diese Reference-Tags ermöglichen es also, genau zu bestimmen, auf was sich die Signatur bezieht: ganze XML Dokumente, Teile von XML Dokumenten, nicht-XML Daten.
Es ist auch möglich, einen über eine XPath Expression definierten Bereich eines XML Files zu unterschreiben – die Möglichkeiten sind quasi endlos.

Detached Signature

<ds:Signature xmlns:ds=“http://www.w3.org/2000/09/xmldsig#“>
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm=“http://www.w3.org/TR/2001/REC-xml-c14n-20010315″></ds:CanonicalizationMethod>
<ds:SignatureMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#rsa-sha1″></ds:SignatureMethod>
<ds:Reference URI=“file:///home/gast/test2.xml“>
<ds:Transforms>
<ds:Transform Algorithm=“http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments“></ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1″></ds:DigestMethod>
<ds:DigestValue>YHkJTgkmev7VDyv1/Iiqm6RMRYk=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
bdGQ7KXzwCESRRMW49Wd+Fg3LPpzs7KKjGwQfnr0EYMVqku75HaLoxjtssGzwAylvemQEkIiEhIO
szZeH/LeM97e4knNwNSXN4Wor2djqQFQOsMJQt4x9vW+9i+uPVlXF1jOMPDS2TSsgoQWTZog9+h4
/veQvi10H6LVxp+XHIM=
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIIFCzCCA/OgAwIBAgICAPAwDQYJKoZIhvcNAQEFBQAwgcwxCzAJBgNVBAYTAkFUMRAwDgYDVQQI
EwdBdXN0cmlhMQ8wDQYDVQQHEwZWaWVubmExOjA4BgNVBAoTMUFSR0UgREFURU4gLSBBdXN0cmlh
biBTb2NpZXR5IGZvciBEYXRhIFByb3RlY3Rpb24xJTAjBgNVBAsTHEEtQ0VSVCBDZXJ0aWZpY2F0
aW9uIFNlcnZpY2UxGDAWBgNVBAMTD0EtQ0VSVCBBRFZBTkNFRDEdMBsGCSqGSIb3DQEJARYOaW5m
b0BhLWNlcnQuYXQwHhcNMDUwOTA2MDAwMDAwWhcNMDcwOTA2MTM0NjMzWjCBgTELMAkGA1UEBhMC
QVQxCjAIBgNVBAgTAS0xDTALBgNVBAcTBFdpZW4xCjAIBgNVBAoTAS0xLDAqBgNVBAMTI0Rhbmll
bCBXZWxsZXIsIE5FVUFVU1NURUxMVU5HKFRlc3QpMR0wGwYJKoZIhvcNAQkBFg5kLndAZnJlZW5l
dC5hdDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsi4csbc69/NYQqm9X1VdLcgPf2nkfDgi
8C4JDKji3UWoNISFA8UzuNvk65Hfm9ZNaBXK5E/sE7BgCuvNiTKDlyg9u0iJwKqboWoSTvSvQrLc
ADBtqD0wl0K1y8mF1Dra0CInPIMC/x0tJSpDs6vwSKSR5d6yIgH6YNjBXx1LqvcCAwEAAaOCAcIw
ggG+MAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFC51MRVwN//xQPfZQO0ZhW1sgA5LMB8GA1UdIwQY
MBaAFDd/Pj6ZcWDKJNSRE3nQdCm0qCTYMBkGA1UdEQQSMBCBDmQud0BmcmVlbmV0LmF0MC8GA1Ud
EgQoMCaBDmluZm9AYS1jZXJ0LmF0hhRodHRwOi8vd3d3LmEtY2VydC5hdDA5BgNVHR8EMjAwMC6g
LKAqhihodHRwOi8vd3d3LmEtY2VydC5hdC9zdGF0aWMvYWR2YW5jZWQuY3JsMA4GA1UdDwEB/wQE
AwIE8DARBglghkgBhvhCAQEEBAMCBPAwUQYDVR0gBEowSDBGBggqKAAYAQEBAzA6MDgGCCsGAQUF
BwIBFixodHRwOi8vd3d3LmEtY2VydC5hdC9jZXJ0aWZpY2F0ZS1wb2xpY3kuaHRtbDA7BglghkgB
hvhCAQgELhYsaHR0cDovL3d3dy5hLWNlcnQuYXQvY2VydGlmaWNhdGUtcG9saWN5Lmh0bWwwNAYJ
YIZIAYb4QgENBCcWJUEtQ0VSVCBBRFZBTkNFRCBDZXJ0aWZpY2F0aW9uIFNlcnZpY2UwDQYJKoZI
hvcNAQEFBQADggEBAI7lW+WJbVm6E3qwY0w9F21LjKI3nf19NxWg9jmHN8vwfLsWnwatW3cBpxQO
4jAfxl8xqpX36e3QGXOiDPnYOJ3blmcOxZ3sNL15s+Iq6P9DPyLv/7L0La2FRh4gfWGEbh15BEfh
S65VdxR+LTr9prIt1FSTpl2qIO/nIs+6ouN6TQ6B2JUAeXXaMuQGxM7LNL4XcWVveOaC3oem+Ym7
c2omf3Sge5nRj6Eg7KYh5VCvy6Dhvk8AT25f2qimhXAyl1hMV3ESpZOJVxPqMSoQO8+hSlXbLPsC
MWk88fnm2YdRTU4RKVbmCrfjvrFO6Rvx1/3AaJQ7gFJdbmLUCOm3LUc=
</ds:X509Certificate>
</ds:X509Data>
<ds:KeyValue>
<ds:RSAKeyValue>
<ds:Modulus>
si4csbc69/NYQqm9X1VdLcgPf2nkfDgi8C4JDKji3UWoNISFA8UzuNvk65Hfm9ZNaBXK5E/sE7Bg
CuvNiTKDlyg9u0iJwKqboWoSTvSvQrLcADBtqD0wl0K1y8mF1Dra0CInPIMC/x0tJSpDs6vwSKSR
5d6yIgH6YNjBXx1Lqvc=
</ds:Modulus>
<ds:Exponent>AQAB</ds:Exponent>
</ds:RSAKeyValue>
</ds:KeyValue>
</ds:KeyInfo>
</ds:Signature>

Die angeführte Detached Signatur unterschreibt das gleiche Dokument wie die vorhergehenden Beispiele, nur sind diesmal die zu unterschreibenden XML Daten über die Reference URI file:///home/gast/test2.xml eingebunden – sie befinden sich also in einer anderen Datei. Es ist also offensichtlich, dass bei der Verwendung von detached Signatures die zu unterschreibenden Daten so gespeichert werden, dass sie immer über dieselbe URI erreichbar sind – sonst verliert die Signatur ihre Gültigkeit.

XML-Erweiterung für qualifizierte Signaturen (XAdES)

Qualifizierte XML-Signaturen verwenden zur Darstellung der Qualifizierungseigenschaften die Erweiterung (XAdES) in verschiedenen Varianten.

Das könnte Sie noch interessieren

Beschränkungen und sonstige zwingend erforderliche Vorgaben bei der Ausgabe oder Verwendung von Zertifikaten, soweit sie nicht ausdrücklich in der Certificate Policy oder dem Certificate Practice Statement (https://www.globaltrust.eu/certificate-policy.html) genannt werden

Sicherheitstechnische Beschränkungen (2017/06/09)
– Signaturen die mit RSA Schlüsseln von Smartcards erstellt wurden, deren Zertifikate vor dem 9. Juni 2017 ausgestellt können nicht sicher sein.
– betroffen sind Smartcards mit folgenden Seriennummern: 02-03-4B-73-00-01-32-**, 02-03-4B-73-00-01-33-**, 02-03-4B-73-00-01-34
– die Seriennummer ist Teil des Subjects und kann direkt im Zertifikat festgestellt werden
– Empfänger von Dokumenten mit Signaturen deren Zertifikat diese Seriennummern enthalten, wird empfohlen die Gültigkeit des Dokuments über einen zweiten Informationsweg zu validieren
– die Gültigkeit der eigenhändigen Unterschrift bleibt bestehen, sofern es keinen Zweifel gibt, dass die Signatur von der im Zertifikat genannten Person stammen.

Was ist eine Certificate Revocation List (CRL)?

Die Certificate Revocation List ist eine Datei, die widerrufene Zertifikate, die von einem bestimmten Stamm- oder Zwischenzertifikat ausgegeben wurden, enthält. In einer CRL zum Stammzertifikat wird der Widerruf der darunter liegenden Zwischen- oder Ausstellerzertifikate bekannt gegeben. (sog. Certificate Authority Certificate Revocation List – CARL) in einer CRL zu einem Ausstellerzertifikat wird der Widerruf der Endbenutzerzertifikate dokumentiert.

Widerrufene Zertifikate, die bereits abgelaufen sind, können aus der CRL entfernt werden – standardkonforme Software lässt mit i ihnen ja keine gültige Signatur(Prüfung) mehr zu. Werden abgelaufenen trotzdem Zertifikate in der CRL behalten, wird dieser Umstand durch die CRL-Erweitung expiredCertsOnCrl (OID: 2.5.29.60) kenntlich gemacht.

Woher die CRL zu beziehen ist, ist in den einzelnen Zertifikaten eingetragen. Es handelt sich dabei um die X509v3-ErweiterungCRL Distribution Point, üblicherweise mit einer http-URI zu einer .crl-Datei.

Die CRL-Dateien werden von GLOBALTRUST immer dann neu veröffentlicht, wenn eine Änderung vorgenommen wurde (also ein weiteres Zertifikat widerrufen wurde) oder wenn der Gültigkeitszeitraum der CRL abgelaufen ist. Damit ist garantiert, dass die CRL immer auf dem aktuellen Stand ist.

Wie sind CRLs zu interpretieren?

Ein in der CRL eingetragenes Zertifikat verliert mit dem Eintragungszeitpunkt seine Gültigkeit. Der Signator darf das Zertifikat nicht mehr verwenden. Bis zu diesem Zeitpunkt unterfertigte Rechnungen oder Dokumente behalten jedoch ihre Gültigkeit. Einzelne Programme bringen hier fallweise irreführende Meldungen, indem Sie behaupten „Die Unterschrift ist ungültig, da das Zertifikat widerrufen wurde.“ Diese Meldungen sind jedoch nicht RFC5280 konform. Für sensitive Anwendungen sollte daher auf korrekt arbeitende Produkte ausgewichen werden.

Welcher Zeitpunkt wird herangezogen?

Verbindlich ist die Uhrzeit der Zertifizierungsstelle. Zur Synchronisierung der Zeit bietet GLOBALTRUST auch den Zeitstempelservice GLOBALTRUST QUALIFIED TIMESTAMP an, welcher garantiert, dass eine elektronische Unterschrift zu einem bestimmten Zeitpunkt erfolgte.

Bestellen Sie jetzt Ihr Globaltrust Qualified Timestamp

CRL-Erweiterung für Widerrufsgründe

RFC5280 bietet die Möglichkeit, zu Informationszwecken den Grund für den Zertifikatswiderruf in die Erweiterung reasonCode einzutragen. Dies soll Softwareherstellern ermöglichen, je nach Schweregrad unterschiedlich auf widerrufene Zertifikate zu reagieren – zum Beispiel kann sich ein Endbenutzer beim Widerrufsgrund cessationOfOperation (Betriebseinstellung) über eine bloße Warnung hinwegsetzen; im Fall der keyCompromise (Schlüsselkompromittierung) folgt unweigerlich ein „hard fail“. Der Mechanismus wurde erst relativ spät aufgegriffen und ist etwa im Bereich der Webbrowserhersteller derzeit noch in Entwicklung.

Kann man einen Widerruf rückgängig machen?

Es besteht Möglichkeit, ein Zertifikat von vornherein mit dem reasonCode „certificateHold“ in eine CRL einzutragen. Dies hat den Effekt, dass der Eintrag nachträglich wieder aus der CRL entfernt werden kann. Üblicherweise spricht man dann nicht von Widerruf (Revocation), sondern von Aussetzung (Suspension). Wird binnen 10 Tagen ab Eintrag der Aussetzung keine Entscheidung getroffen, geht die Aussetzung automatisch in einen endgültigen Widerruf über.

Geeignet ist die Aussetzung insbesondere als Vorsichtsmaßnahme, wenn etwa Schlüsselkompromittierung vermutet wird – eine verloren geglaubte Signaturerstellungseinheit könnte wieder gefunden werden etc.

Worauf muss der Benutzer der CRL achten?

Grundsätzlich wird die CRL durch die Zertifikatsspeicherverwaltung selbständig angefordert und beim Benutzer lokal verwaltet. Üblicherweise werden die aktualisierten CRL-Dateien erst nach Ablauf des in der CRL angegebenen Gültigkeitsdatums automatisch neu angefordert und aktualisiert. Dies kann bedeuten, dass ein Benutzer ein unterschriebenes Dokument irrtümlich als korrekt unterschrieben interpretiert, obwohl es mit einem abgelaufenen, aber noch nicht seiner lokalen CRL enthaltenen Zertifikat unterschrieben ist.

Um diese Situation zu verhindern, bieten manche Zertifikatsverwaltungen die CRL-Aktualisierung bei jeder Signaturprüfung an, bei anderen muss die CRL manuell aktualisiert werden. Andere Zertifikatsverwaltungen erwarten, dass man die lokal gespeicherte CRL löscht und diese Zertifikatsverwaltungen rufen dann automatisch die neue CRL ab. Welche Variante, die Zertifikatsverwaltung, ihre Applikation (ihr Programm) verwendet, müssen aus der Dokumentation entnommen werden und kann nicht von GLOBALTRUST supportet werden (im Zweifelsfall ist direkt mit dem Hersteller Kontakt aufzunehmen). In allen Fällen ist jedoch eine Verbindung zum Internet erforderlich.

Aufgrund der großen Verbreitung hat GLOBALTRUST für Microsoft Windows die CRL-Informationen des Microsoft-Supports zusammen gestellt (siehe unten). Für die Richtigkeit und Gültigkeit bei Ihrer Computer-Installation kann keine Gewähr geleistet werden.

Certificate Revocation List (CRL) unter Microsoft Windows

Grundsätzlich wird eine neue CRL von Microsoft Betriebssystemen nur dann neu heruntergeladen, wenn die in der vorhandenen CRL eingetragene Gültigkeitsdauer überschritten ist oder überhaupt keine CRL vorhanden ist.

Unter Microsoft werden CRLs in 3 verschiedenen Orten gespeichert:

• im Hauptspeicher des Computers,
• im Microsoft-Zertifikatsspeicher und
• in den „temporären Internetdateien“

Um CRLs aus den „temporären Internetdateien“ zu entfernen, müssen diese mittels Microsoft Internet Explorer komplett gelöscht werden.

Um vorhandene CRLs zu entfernen und ein Update der CRL zu erzwingen, bietet Microsoft in einem Artikel umfangreiche Informationen zur CRL-Verwaltung an (http://www.microsoft.com/technet/prodtechnol/winxppro/support/tshtcrl.mspx#EDAA). Dieser Artikel enthält auch ein VisualBasic Script zum Entfernen veralteter CRL’s. Weiterführende Fragen zur Administration von CRLs sind direkt beim Support von Microsoft abzufragen.

Um CRLs aus dem Hauptspeicher zu entfernen, ist ein Neustart der Applikation, die die CRL verwendet, bzw. ein Neustart des Betriebssystems erforderlich.
Aus dem Microsoft-Zertifikatsspeicher können CRLs mit der Microsoft Management Console mmc.exe mittels des Zertifikate-Snap-Ins entfernt werden.
Start → Ausführen → mmc → Konsole → Snap-In hinzufügen/Entfernen → Hinzufügen → Zertifikate → Hinzufügen → Eigenes Benutzerkonto → Fertigstellen → Schließen → OK
CRLs, die in der Zertifikatsliste eingetragen sind, können dann gelöscht werden. Wir empfehlen, die Konsolen-Einstellungen abzuspeichern.

Erstellen PKCS#12 Datei aus privaten Schlüssel und neuem Zertifikat

Möchte man eine neue PKCS#12 Datei (Endung .p12 oder .pfx) aus einem bestehenden Schlüssel und einem neuen Zertifikat zusammenbauen, so kann dafür das Open-Source-Tool XCA verwendet werden.

Ablauf:
1) Download des Programms XCA
2) Die Datei setup_xca-0.7.0.exe ausführen und das Tool installieren.
3) Im Menü „Datei“ „Neue Datenbank“ auswählen und einen beliebigen Dateinamen eingeben.
4) Reiter „Private Schlüssel“ wählen und auf „Import“ klicken. Datei mit dem privaten Schlüssel angeben.
5) Reiter „Zertifikate“ wählen und auf „Import“ klicken. Datei mit dem neuen Zertifikat angeben.
6) Das importierte Zertifikat auswählen und auf „Export“ klicken.
7) Als Exportformat „PKCS#12 with certificate chain“ auswählen, einen Zielpfad angeben.
8) Eingabe eines Exportpassworts
9) Die in Punkt 3) erstellte Datenbankdatei wird wieder gelöscht.

Erstellen Zertifikat ohne privaten Schlüssel im PKCS#12 Format

Generierung mittels openssl:
(Das geprompte Passwort muss leer bleiben, da der private Schlüssel nicht verwendet wird)
openssl pkcs12 -nokeys -in [zertifikatsdatei-alt].pem -export -out [zertifikatsdatei-neu].p12

Kontrolle des Inhaltes:
openssl pkcs12 -info -in [zertifikatsdatei-neu].p12

Einsatzvoraussetzungen GlobalTrustApp

Zum Einsatz der GlobalTrustApp ist die Benutzeranleitung zu beachten. Die Einsatzmöglichkeiten werden laufend getestet und erweitert. Die ausführliche Benutzeranleitung ist unter https://www.globaltrust.eu/static/doku-globaltrustapp.pdf abrufbar.

Getestete Systeme:
– Windows 7 Professional 32- oder 64-bit mit Kartenleser mit PIN-Pad (Cherry ST-2000)
– Windows 8 Professional oder Windows 8.1 Professional 32- oder 64-bit mit Kartenleser mit PIN-Pad (Cherry ST-2000)
– Windows 10 Professional 64-bit mit Kartenleser mit PIN-Pad (Cherry ST-2000)

Die GlobalTrustApp erfordert .NET ab Version 4.5.1:
– Direktlink .NET-Installation: http://www.microsoft.com/de-DE/download/confirmation.aspx?id=42642
– Test installierte .NET-Version: https://msdn.microsoft.com/de-de/library/hh925568(v=vs.110).aspx#net_d

Zu sonstigen Windowssystemen liegen keine Testergebnisse vor. Weitere geeignete Cardreader finden sich unter https://www.globaltrust.eu/produkte.html.

Verwendung GlobalTrustApp

Die GlobalTrustApp kann gemeinsam mit GLOBALTRUST-Zertifikates auf Smartcard verwendet werden und erlaubt die Signatur von pdf- und xml-Dateien ohne zusätzliche Kosten.

Abhängig vom gekauften Produkt können pdf-Dokumente zusätzlich mit einem qualifizierten Zeitstempel versehen werden. Wurde ein qualifiziertes Zertifkat gekauft (GLOBALTRUST QUALIFIED), dann entsprechen die Signaturen den Anforderungen europäischer und österreichischer Signaturbestimmungen (eIDAS-VO, SVG) für qualifizierte Signaturen und sind der persönlichen Unterschrift gleichgestellt.

Im Falle des Einsatzes für qualifizierte Signaturen wird empfohlen vorab die Übersicht https://www.globaltrust.eu/static/general.pdf zu lesen.

Das könnte Sie noch interessieren