Hinweis:

Wartungsarbeiten ServerPass - mögliche Ausfälle des Serviceportals am Dienstag, 27.10., von 07:00 bis 18:00 Uhr.

Produkte und Lösungen

ServerPass

      • Ja. Die Aktivierung von JavaScript ist Voraussetzung für die Benutzung des ServerPass Kundenportals.

      • Der ServerPass Standard und der ServerPass SAN/UCC haben eine Gültigkeit von einem Jahr. Die Kulanzzeit beträgt fünf Tage.

      • Ja, mit ServerPass Standard (Wildcard) steht ein SSL/TLS-Zertifikat mit Wildcardzeichen (*) zur Verfügung.

      • Für die Beauftragung eines SAN/UCC melden Sie sich am Kundenportal "MyServerPass" an und wählen den Menüpunkt "Zertifikat beauftragen" und anschließend: "TeleSec ServerPass SAN/UCC".

        Hier erfolgen die Root-Auswahl sowie die Produktauswahl (Laufzeit des gewünschten Zertifikats).
        In das Feld "Mein PKCS#10 Zertifikats-Request" kopieren Sie Ihren Zertifikatsrequest hinein.

        Der Request selbst kann im Webserver oder mit einem Zusatzprogramm wie OpenSSL oder Java-Keytool erzeugt werden. Die Erzeugung des Requests ist in den entsprechenden Anleitungen dokumentiert.

        Es wird kein spezieller Request für die Beauftragung eines SAN/UCC-Zertifikats benötigt. Die zusätzlichen Servernamen lassen sich während des Beauftragungsprozess manuell eintragen. Der eingefügte Request wird automatisch untersucht.

        Anschließend werden die ermittelten Feldeinträge dargestellt und Sie erhalten die Möglichkeit, weitere Servernamen hinzuzufügen. Der hinzugefügte Eintrag wird automatisch überprüft und Sie können weitere Servernamen (aktuell bis zu 5 weitere Namen) hinzufügen. Wird ein Eintrag als ungültig erkannt, so muss er wieder entfernt werden.

        Bitte beachten Sie hierbei die Erläuterungen gemäß CPS ab Punkt 1.1 (TeleSec ServerPass SAN/UCC)

        Kontrollieren Sie die ermittelten Inhalte Ihres Zertifikat-Requests.
        Abschließend die restlichen Eingabefelder entsprechend Ihrer Angaben ausfüllen und Auftrag absenden.

      • Bei der Registrierung legen Sie Ihr Login-Passwort fest. Unmittelbar nach Abschließen der Registrierung durch die Bestätigung der Mailadresse mittels Link ist der Zugang freigeschaltet.

      • Das für ein Zertifikat gültige Service-Passwort wird dem Technischen Ansprechpartner nach der Ausstellung des Zertifikats in Form einer Auftragsbestätigung per E-Mail zugesendet.

      • Ein Google-Projekt für Zertifikatstransparenz: Ausgestellte Zertifikate werden in öffentlich überprüfbare, manipulationsgeschützte Logserver geschrieben, um missbräuchlich oder fehlerhaft ausgestellte TLS/SSL-Zertifikate schneller ermitteln und blockieren zu können. Während dem Zertifikatsausstellungsprozess werden erforderliche CT Logserver kontaktiert. Diese wiederum liefern in ihrer Antwort je einen signierten Zeitstempel (SCT) zurück, die dann im Zertifikat hinterlegt werden und nachweisen, dass das Zertifikat auf einem Logserver registriert wurde.

        Die CT-Erweiterung kann auf Kundenwunsch abgewählt werden. Die fehlende CT-Erweiterung reduziert den Funktionsumfang des Zertifikats in manchen Browsern.

      • CAA ist eine zusätzliche Sicherheitsmaßnahme der Baseline Requirements des CA/Browserforums, um Missbrauch bei der Zertifikatsausstellung zu verhindern.

        Der Domaininhaber kann durch die Hinterlegung von CAA Einträgen (Certification Authority Authorization DNS Resource Record) für jeden FQDN (Fully Qualified Domain Name) festlegen, welche Zertifizierungsstelle er für die Zertifikatsausstellung autorisiert. Im Rahmen der Auftragsvalidierung prüft die Zertifizierungsstelle alle FQDN des Zertifikatsrequests auf vorhandene CAA Einträge im DNS (CAA Records for Fully Qualified Domain Names).

        Die ServerPass Zertifizierungsstelle darf das Zertifikat nur dann ausstellen, wenn für jeden FQDN eines Zertifikatauftrags ein CAA Eintrag gefunden wird, dessen issue- bzw. issuewild-Property „telesec.de“ beinhaltet oder kein CAA Eintrag hinterlegt wurde.

        Um die Auftragsbearbeitung zu beschleunigen, hinterlegen Sie für alle Ihre Domains den issue- bzw. issuewild-Property „telesec.de“.

      • Es werden keine SSL/TLS-Zertifikate für interne Hostnamen (z.B. CN=test) oder für IP-Adressen aus einem reservierten Adressbereich (z.B. 192.168.*.*) ausgestellt.

        Solche Zertifikate wären nicht einzigartig, da sie gleichermaßen in vielen privaten Netzwerken eingesetzt werden könnten. Auch kann keine Eindeutigkeit bescheinigt werden, da die Nutzung keinerlei Registrierung voraussetzt.

         

      • Die Allgemeinen Geschäftsbedingungen (AGB) TeleSec Produkte regeln die Vertragsgrundlagen zwischen den Vertragspartnern.

        Alle AGB, Leistungsbeschreibungen und Preislisten haben wir für Sie im Bereich "Service > Produkt-Support > Allgemeine Geschäftsbedingungen" zusammengestellt.

      • Das Dokument beschreibt in Ergänzung zu den Allgemeinen Geschäftsbedingungen die Tätigkeiten des T-Systems Trust Centers in der Funktion als Zertifizierungs- und Registrierungsstelle. Es ermöglicht die qualitative Beurteilung der angebotenen Dienstleistung und dient als Entscheidungsgrundlage für eine Anerkennung der ausgestellten SSL/TLS-Zertifikate.

      • Anleitungen zur Requesterzeugung finden Sie im Bereich "Service > Downloads > Produkte & Lösungen".

         

      • SAN Einträge müssen im Request mit der SAN Extension OID=2.5.29.17 kodiert sein.

        Microsoft Server verwendet teilweise eine anderes Format. Im Microsoft-Technet gibt es dazu unter:

        http://technet.microso ft.com/de-de/library/ff625722(v=ws.10).aspx eine ausführliche Anleitung, wie das passende Format erzeugt werden kann.

      • Beim CSR (Certificate Signing Request) oder Server-Zertifikat-Request handelt es sich um eine Zertifizierungsanfrage des Servers, auf dem das SSL Zertifikat installiert werden soll. Der CSR wird in der Regel vom Kunden auf der entsprechenden Maschine erstellt und dann manuell in die Beauftragungsseite eingefügt. Die Syntax wird durch den Standard PKCS#10 beschrieben. Die Serverapplikationen stellen für die Erstellung geeignete Tools zur Verfügung. Die produktspezifischen Eigenarten sind bei der Erstellung des Requests zu beachten.

      • Beim Erzeugen des Requests werden u.a. folgende sechs Felder (Common Name . Domain Name bzw. IP-Adresse, Organization - Organisation oder Firma, Organizational Unit - Organisationseinheit oder Abteilung, Locality - Ort, State or Province - Bundesland, Country -Land) abgefragt. Es ist zu beachten, dass diese Daten unwiderrufbar den Zertifikatsinhalt darstellen! Eine Änderung kann später nur durch eine Neubeautragung erfolgen. Die wichtigste Angabe ist der Common Name. Hier ist die vollständige (https-)Adresse des zu zertifizierenden Servers einzutragen, z.B. www.musterfirma.de.


        Hintergrund ist, dass jeder Browser seine angewählte Adresse mit der Angabe des Common Name im Zertifikat vergleicht. Stimmen diese nicht überein, so erscheint ein Sicherheitshinweis.

      • Der verwendete Zertifikatsrequest (CSR) muss für Neubeauftragungen/Erneuerungen eine Schlüssellänge von 2048 oder 4096 Bit bei RSA, bzw. 256 Bit (prime256v1) oder 384 Bit (secp384r1) bei ECC aufweisen. Andere Schlüssellängen werden nicht akzeptiert.

      • Bei den Ortsangaben wird auf die offizielle Schreibweise und auf die Konsistenz Land/Bundesland/Stadt/PLZ geprüft. Fehlerhafte Ortsangaben müssen korrigiert werden.

         

      • Nach der Anmeldung am Kundenportal <myServerPass> werden unter dem Menüpunkt "Meine Zertifikate" alle Ihre Zertifikate aufgelistet. Ein Klick auf die Referenznummer oder den Common Name des Zertifikats blendet die Zertifikatdetails ein.

        Für alle verlängerbaren Zertifikate steht dann der Button "Erneuern" zur Verfügung.

         

      • Das erneuerte Zertifikat wird in der Regel sofort ausgestellt und ist - unabhängig von der Laufzeit des zu erneuernden Zertifikats - per sofort gültig!

      • Um durchgehend authentische und sichere elektronische Kommunikation zu gewährleisten, muss die Erneuerung vor Ablauf der Gültigkeit erfolgen. Die Möglichkeit der Erneuerung wird vier Wochen vor Ablauf des Zertifikates dem technischen Ansprechpartner per E-Mail mitgeteilt. Von diesem Zeitpunkt an bis zum Ablauf der Gültigkeit ist die Erneuerung mittels vereinfachter Beauftragung über das Kundenportal "myServerPass" möglich.

      • Der ServerPass hat eine Gültigkeit von einem oder zwei Jahren (+5 Tage). Da ein einmal ausgegebenes Zertifikat nachträglich nicht mehr verändert werden kann, muss die Verlängerung der Gültigkeit durch eine Erneuerung vollzogen werden. Bei der Erneuerung wird ein neues Zertifikat mit neuer Gültigkeit, jedoch mit den Zertifikatsangaben des zu erneuernden Zertifikates generiert.

      • Um die Erneuerung nutzen zu können, wird in vielen Webservern die Option "Verlängerung bzw. Erneuerung des Zertifikats" angeboten. Hierbei entsteht ein neuer Request, der dann auf der Website in das entsprechende Feld kopiert wird. Bietet Ihr Webserver die oben angesprochene Option nicht, muss i. d. R. ein neuer Schlüssel und damit auch ein neuer Request erzeugt werden. Einige Zusatzprogramme, wie OpenSSL können Requests mit einem bereits vorhandenen Schlüssel erzeugen.

        Bitte beachten Sie die jeweiligen Betriebsdokumentationen, da die Vorgehensweisen zum Teil stark voneinander abweichen!

      • Bei einer Zertifikatserneuerung (Renewal)  wird auf Basis des gleichen Subject-DN ein neues Zertifikat generiert, das einen neuen Gültigkeitszeitraum und eine neue Seriennummer besitzt. Es kann ein neuer öffentlicher Schlüssel eines neu generierten Schlüsselpaares oder der öffentlicher Schlüssel des Vorgängerzertifikats verwendet werden.

        Eine Wiederausstellung eines Zertifikats (Re-Issue) entspricht einer Zertifikatserneuerung mit der einen Ausnahme, dass das Ablaufdatum des Vorgängerzertifikats eingetragen wird. DIESE OPTION IST KOSTENLOS.

      • Handlungsvollmacht für ServerPass EV:
        Durch eine Handlungsvollmacht bevollmächtigt die ausstellende Organisation / Firma eine aufgeführte Person im Namen der Firma bei EV-SSL-Zertifikaten in der Rolle als zeichnungsberechtigter, administrativer oder technischer Ansprechpartner tätig zu sein. Die Vollmacht muss von einem Geschäftsführer oder Prokuristen unterzeichnet sein.

        Wurde einer Person als zeichnungsberechtigter Ansprechpartner bevollmächtigt, so kann diese im Rahmen einer Einzelbeauftragung die Personen für die Rollen administrativer und technischer Ansprechpartner bevollmächtigen.

        Domainvollmacht:
        Durch eine Domainvollmacht bevollmächtigt der Domaininhaber, durch den eingetragenen Admin-C, eine Organisation / Firma die genannte Domain zu nutzen.

      • Im Rahmen eines Auftrags für ein EV Zertifikat können per anwaltlicher Stellungnahme alle für die Beauftragung notwendigen Nachweise erbracht werden. Eine anwaltliche Stellungnahme bestätigt:

        • Die offizielle Eintragung der Gesellschaft
        • Den offiziellen Geschäftssitz
        • Die regelmäßige Geschäftstätigkeit
        • Die Berechtigung des Zeichnungsberechtigten
        • Die Rechte zur Nutzung der Domain
      • Die folgenden Felder müssen im Subject enthalten sind: O (Organization), C (Country), ST (State), L (Locality). Optional sind die Felder STREET und PostalCode.

        Die Schreibweise der Organisation muss mit der offiziellen Schreibweise, wie sie z.B. im Handelsregister aufgeführt ist, identisch sein.

        Bei den Adressinformationen sollte vorzugweise die physikalische Adresse des Geschäftssitzes der Organisation benutzt werden. Alternativ kann auch eine, über offizielle Quellen nachprüfbare Adresse einer Niederlassung o.ä. genutzt werden. Eine Angabe von Postfächern o.ä. ist nicht erlaubt.

      • Bei der Beauftragung eines sind folgende Punkte zu beachten oder wichtig:

        • Inhalt von Feldern im Zertifikatsrequest –siehe FAQ „Inhalt von Feldern im Zertifikatsrequest / Zertifikat“
        • Der Name der Organisation muss von der Schreibweise identisch zur Schreibweise in offiziellen Registern sein.
        • Die Adresse des Geschäftssitzes muss als physikalische Adresse angegeben werden.
        • Die Kontrolle über die Domain muss nachgewiesen werden (Verfahren: siehe CP/CPS).
        • Der angegebene zeichnungsberechtigte Ansprechpartner unterschreibt den Auftrag. Diese Person muss im Register als Geschäftsführer oder mit Prokura eingetragen sein. Sollte er dies nicht sein, so benötigt er eine auf ihn ausgestellte „Handlungsvollmacht für ServerPass EV Zertifikate“ oder alternativ eine anwaltliche Stellungnahme welche die Bevollmächtigung ausweist.
        • Der administrative Ansprechpartner ist für die Genehmigung der Zertifikatsauftrags zuständig. Die Genehmigung wird vom Trustcenter während des Prüfprozesses eingeholt. Die Bevollmächtigung des administrative Ansprechpartners erfolgt entweder im Rahmen der Auftragserteilung (siehe EV-SSL-Auftrag – Pflichten des Auftraggebers – Feld „Der technische und/oder administrative Ansprechpartner wird mit der Unterzeichnung dieses Auftrags, durch den zeichnungsberechtigten Ansprechpartner, bevollmächtigt entsprechend der definierten Rollen zu handeln. Die Mitarbeiter der T-Systems sind berechtigt, die Bevollmächtigung mittels Kontaktaufnahme zu verifizieren.“) oder durch eine separate „Handlungsvollmacht für ServerPass EV Zertifikate“
        • Der technische Ansprechpartner stellt den Auftrag in ServerPass ein, lädt den Zertifikatsrequest hoch und kann das ausgestellte Zertifikat aus ServerPass herunterladen. Die Bevollmächtigung des technischen Ansprechpartners erfolgt entweder im Rahmen der Auftragserteilung (siehe EV-SSL-Auftrag – Pflichten des Auftraggebers – Feld „Der technische und/oder administrative Ansprechpartner wird mit der Unterzeichnung dieses Auftrags, durch den zeichnungsberechtigten Ansprechpartner, bevollmächtigt entsprechend der definierten Rollen zu handeln. Die Mitarbeiter der T-Systems sind berechtigt, die Bevollmächtigung mittels Kontaktaufnahme zu verifizieren.“) oder durch eine separate „Handlungsvollmacht für ServerPass EV Zertifikate“
      • Folgen Sie auf der Anmeldeseite zum Kundenportal dem Link "Haben Sie Ihr Passwort vergessen?"
        Hier können Sie nun unter Angabe der entsprechenden E-Mailadresse sowie des angegebenen Sicherheitscode ein neues Passwort anfordern. Weitere Informationen zur Zurücksetzung Ihres Passwortes werden an die von Ihnen angegebene E-Mailadresse gesendet.

      • Bitte nehmen Sie mit unserem Service-Desk Kontakt auf.

      • Die Registrierung für das Portal ist für Sie kostenfrei.

      • Sobald das Zertifikat genehmigt und ausgestellt wurde, wird es im Kundenportal unter dem Menüpunkt "Meine Zertifikate" aufgelistet. Ein Klick auf die Referenznummer oder den Common Name des Zertifikats blendet die Zertifikatdetails ein. Etwas weiter unten besteht dann die Möglichkeit des Downloads in mehreren Formaten.

        Sobald das Zertifikat ausgestellt wurde, wird zudem der technische Ansprechpartner per E-Mail informiert.

         

      • Im Kundenportal unter dem Menüpunkt "Meine Zertifikate" finden Sie nur Zertifikate, die genehmigt und ausgestellt wurden. Zertifikate, die noch nicht genehmigt und ausgestellt wurden, finden Sie unter "Auftragsstatus".

      • Es stehen zwei Möglichkeiten zur Auswahl:

        • Sie laden nur Ihr SSL/TLS-Zertifikat im PEM bzw. BASE64-Format als Datei herunter.
        • Sie laden das Zertifikat inklusive aller ausstellenden Instanzen (Root- und CA-Zertifikate) in einer Datei herunter. Das Format der einzelnen Zertifikate ist ebenfalls das PEM bzw. BASE64-Format.
      • Nach der Anmeldung am Kundenportal <myServerPass> werden unter dem Menüpunkt "Meine Zertifikate" alle Ihre Zertifikate aufgelistet. Für alle verlängerbaren Zertifikate steht dann der Button "Verlängern" zur Verfügung.

      • Der bestehende technische Ansprechpartner ist im Kundenportal unter einer Organisation angemeldet. Er kann durch eine „Accountübertragung“ seine Berechtigung an dieser Organisation auf einen neuen technischen Ansprechpartner (Nachfolger) übertragen. Einzige Voraussetzung ist, dass sich der neue technische Ansprechpartner (Nachfolger) am Kundenportal registriert hat.

        Sobald der bestehende technische Ansprechpartner die E-Mailadresse im Abschnitt - Technischer Ansprechpartner – ändert, erscheint ein Informationstext mit der Beschreibung der Übergabe-Prozedur. Außerdem wird ein Sitzungspasswort angezeigt. Dieses ist zu notieren und sicher an den neuen technischen Ansprechpartner zu übermitteln.

        Der neue technische Ansprechpartner erhält eine E-Mail mit der Möglichkeit die neue Zuordnung zu akzeptieren oder abzulehnen. Nach der Akzeptanz kann sich der neue technische Ansprechpartner mit seinen eigenen Accountdaten am Kundenportal anmelden, mit dem Sitzungspasswort autorisieren und hat damit unmittelbar Zugang zu den Zertifikaten dieser Organisation übernommenen.

        Hat der bestehende technische Ansprechpartner noch weitere Organisationen die er verwaltet, so kann er dies auch weiterhin durchführen.

        Ansonsten muss die Übergabe-Prozedur für jede verwaltete Organisation angestoßen werden, die übertragen werden soll.

         

      • Wenn die Übergabe an einen neuen technischen Ansprechpartner im Vorfeld nicht erfolgt ist (beispielsweise steht ein ausgeschiedener Mitarbeiter nicht mehr zur Verfügung), hat man folgende zwei Möglichkeiten:

        Der neue technische Ansprechpartner legt einen neuen Account an und beauftragt darüber die benötigten Zertifikate. Die Historie der alten Zertifikate und die Aufträge gehen dabei verloren und stehen nicht mehr zur Verfügung

        Ein Verantwortlicher, der im Zertifikat unter O genannten Firma oder eine durch Vollmacht autorisierte Person dieser Firma erteilt schriftlich den Auftrag an die T-Systems Registrierungsstelle auf „Zusammenführung“ von Accounts. Dabei ist sowohl der alte technische Ansprechpartner, auf dessen Account es keinen Zugriff mehr gibt, als auch der neue technische Ansprechpartner, der zukünftig das Management der Zertifikate betreuen wird, zu nennen. Nach Prüfung der Daten durch Registrierungsstelle, werden dem neuen technische Ansprechpartner die alten Zertifikate übertragen.

         

      • Ja. Die Aktivierung von JavaScript ist Voraussetzung für die Benutzung des ServerPass Kundenportals.

      • Eine Übersicht der Root-/Sub-CA-Zertifikate finden Sie im Bereich "Root Programm".

      • Eine Übersicht der Applikationen und Betriebssysteme, in denen die Telesec ServerPass Root-Zertifikate implementiert sind, finden Sie hier.

      • Der Browser ihrer Kunden untersucht neben ihrem Zertifikat auch alle anderen beteiligten Zertifikate in der Vertrauenskette. Nach erfolgreicher Prüfung stuft er ihr Zertifikat als vertrauenswürdig ein. Dafür benötigt der Browser neben dem eigentlichen Webserver-Zertifikat auch das Sub-CA-Zertifikat der ausstellenden Instanz.

         

      • Sobald das Zertifikat genehmigt und ausgestellt wurde, wird es im Kundenportal unter dem Menüpunkt "Meine Zertifikate" aufgelistet. Ein Klick auf die Referenznummer oder den Common Name des Zertifikats blendet die Zertifikatdetails ein.

        Dort können Sie über den Button "Download (inkl. Zertifikatskette)" das Zertifikat mit dem dazugehörigen Sub-CA-Zertifikat herunterladen.

         

      • Nein, das Sub-CA-Zertifikat muss nur einmal installiert werden und verbleibt danach im Zertifikatsspeicher des Webservers.

         

      • Sie können Ihr Serverzertifikat im Kundenportal jederzeit herunterladen.

      • Der Private Key und das Serverzertifikat bilden eine untrennbare Einheit. Geht der Private Key verloren, wird das Serverzertifikat unbrauchbar und muss sofort gesperrt werden. Vor der Sperrung können Sie das bestehende Zertifikat per ReIssue mit einem neuen Key kostenlos für die Restlaufzeit ausstellen lassen.

      • Der ausgedruckte und unterschriebene Onlineauftrag und je nach Fall:

        Auftraggeber ist eine juristische Person:
        Die beglaubigte Kopie des Handelsregisterauszuges ist nur in Ausnahmefällen erforderlich. T-Systems überprüft die Angaben zur juristischen Person im elektronischen Handelsregister.

        Auftraggeber ist eine Behörde:
        Dienstsiegel und die Unterschrift eines Bevollmächtigten der Behörde auf dem Auftragsformular.

        Auftraggeber ist ein Verein:
        Die beglaubigte Kopie (nicht älter als 30 Tage) des Vereinsregisterauszuges.

        Auftraggeber ist eine natürliche Person:
        Es werden keine Zertifikate für natürliche Personen ausgestellt.

        Auftraggeber ist ein Gewerbetreibender:
        Die beglaubigte Kopie (nicht älter als 30 Tage) eines aktuellen Gewerbescheins und des Personalausweises des Gewerbetreibenden.

      • Ja, auch die Zertifizierung einer IP-Adresse ist möglich.

      • Die im Kundenportal herunter geladenen Zertifikate haben stets das Format BASE64 (PEM).

        Nachfolgend beschrieben wird der Vorgang zur Erzeugung einer Zertifikats-Datei im PKCS7-Format.
        Die erzeugte Datei enthält das Server-Zertifikat sowie alle Zertifikate der ausstellenden Instanzen (Root- und CA-Zertifikate).
        Um die benötigte Datei zu erzeugen stehen mehrere Wege offen.
        Exemplarisch wird hier je eine Methode für eine Windows- bzw. eine Linux/Unix-Umgebung beschrieben.

        Vorbereitung - plattformübergreifend:
        Laden Sie Ihre Zertifikats-Datei im Kundenportal unter der Verwendung der Option "Download incl. Zertifikatskette" herunter.
        Sie erhalten die Datei "servpass-123456-x509chain.pem".
        Alle Zertifikate in dieser Datei müssen nun separiert und in separaten Dateien abgespeichert werden.
        Dieser Vorgang ist beschrieben z. B. in der Anleitung:
        "Java Keytool (auf Java-basierende Webserver, z.B. Jetty, Tomcat)" unter Punkt 2.4.2
        Die Anleitung ist links unter dem Menüpunkt "Support" bzw. "Anleitungen" verfügbar.

        Nach der Aufteilung der Zertifikate sind mehrere Dateien entstanden, z. B. nach diesem Schema:
        BaltimoreCyberTrustRoot.crt
        ServerPass-CA1.crt
        usercert.crt

        Die PKCS7-Datei in einer Linux- oder Unix-Umgebung erzeugen:
        In einer Linux- oder Unix-Umgebung steht in der Regel das Programm OpenSSL zur Verfügung.
        Folgender Befehl erzeugt aus den separierten Zertifikats-Dateien die benötigte Datei:
        openssl crl2pkcs7 -certfile BaltimoreCyberTrustRoot.crt -certfile ServerPass-CA1.crt -certfile usercert.crt -nocrl -outform PEM -out usercert.pem.p7b

        Das Ergebnis ist eine Datei im Format PKCS7, PEM-kodiert. Sie enthält das Serverzertifikat sowie alle Zertifikate der ausstellenden Zertifikats-Instanzen.

        Die PKCS7-Datei in einer Windows-Umgebung erzeugen:
        In einer Windows-Umgebung steht das Programm OpenSSL in der Regel nicht zur Verfügung.
        Nachfolgend wird der Vorgang unter Verwendung des Zertifikat-Managers beschrieben:
        Es wird empfohlen, diesen Vorgang nicht auf der Maschine auszuführen, wo das Serverzertifikat später eingesetzt werden soll.
        Importieren Sie alle Zertifikate über den Zertifikatmanager durch Doppelklick auf die jeweilige Datei.
        Folgen Sie jeweils den Anweisungen des Zertifikatmanagers.
        Nun kann das Server-Zertifikat exportiert werden.
        Erneut Doppelklick auf die Datei "usercert.crt".
        Unter der Lasche "Zertifizierungspfad" werden nun alle zuvor importierten Zertifikate aufgelistet.
        Unter der Lasche "Detail" wählen Sie die Option "In Datei kopieren".
        Es öffnet sich der Zertifikatsexport-Assist.
        Wählen Sie hier die Optionen
        "Syntaxstandard kryptografischer Meldungen - PKCS#7-Zertifikate (.P7B)"
        sowie "Wenn möglich, alle Zertifikate im Zertifizierungspfad einbeziehen".
        Anschliessend wird noch ein Dateiname sowie der Speicherort festgelegt.
        Das Ergebnis ist eine Datei im Format PKCS7, DER-kodiert. Sie enthält das Serverzertifikat sowie alle Zertifikate der ausstellenden Zertifikats-Instanzen.

      • Es werden RSA-Schlüssel mit einer Schlüssellänge von 2048 Bit oder 4096 Bit, sowie ECC-Schlüssel mit 256 Bit (prime256v1) oder 384 Bit (secp384r1) zertifiziert.

      • Das Telekom Trust Center erstellt in regelmäßigen Abständen Sperrlisten (Certificate Revocation List, CRL), in der alle gesperrten Zertifikate eingetragen werden. Die Sperrlisten sind über die Webseite abrufbar.

        Zusätzlich können die ServerPass-Zertifikate auch via OCSP-Protokoll geprüft werden.

        Nähere Angaben hierzu finden Sie in der CPS für ServerPass.

Public Key Service

      • Wir empfehlen zur Signaturprüfung die Verwendung einer Signatursoftware aus dem Bereich Software. Die hier genannten Hersteller sind bei uns als Partner registriert. Sie erhalten frühzeitig Informationen über Neuerungen bzgl. der Nutzung der PKS Signaturkarte. So ist sichergestellt, dass deren Software immer mit den neuesten Signaturkarten funktioniert. Für Sie als Nutzer ist es besonders wichtig Ihre Signatursoftware immer aktuell zu halten. Nur so ist gewährleistet, dass notwendige Anpassungen an der Signaturkarte oder unseren Services nicht zu Fehlern führen. Falls Sie Nutzer einer Plattform mit integrierter Signatursoftware sind, so gilt diese Pflicht ebenso für den Betreiber Ihrer Fachanwendung.

        Die EU bietet einen Service für die schnelle Online Prüfung einer qualifiziert signierten Datei an. Sie erreichen diesen Service unter der URL https://ec.europa.eu/cefdigital/DSS/webapp-demo/validation

        Andere Hersteller unterstützen die PKS Signaturkarte ebenfalls.

        Fragen zur Kompatibilität einer Signatursoftware mit einem bestimmten Anwendungszweck oder einer Fachanwendung richten Sie bitte an den Hersteller der Software oder den Betreiber der Fachanwendung.

        Auf Grund der Verwendung eines Signaturformats, welches durch das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) spezifiziert wurde, kommt es bei Nutzung der PKS Signaturkarte mit Software von nicht europäischen Herstellern teilweise zu Fehlern. Weitere Informationen erhalten Sie unter dem Stichwort "Welches Signaturformat verwendet die PKS Signaturkarte?". Dies betrifft insbesondere die Nutzung der qualifizierten Signaturfunktion mit Adobe Produkten sowie die Nutzung der Verschlüsselungsfunktion mit Thunderbird. Dies gilt ebenso für die Nutzung der PKS Signaturkarte innerhalb von Fachanwendungen innerhalb der EU.

        Wenn Sie eine qualifiziert signierte Datei an einen Empfänger senden und dieser die Prüfung wegen obiger Fehler ablehnt, dann können Sie ihn zusätzlich auf die folgenden unabhängigen Informationsquellen hinweisen:

         

      • Das Dateiformat der zu signierenden Datei hat für die PKS Signaturkarte keine Bedeutung. Sie können also jedes beliebige Dateiformat signieren.

        Genaugenommen „sieht“ die Signaturkarte Ihre Datei nicht einmal. Die Karte verarbeitet einen Hashwert, der von Ihrer Signaturanwendung erstellt und an Ihre Karte übertragen wird. Dies ist genau der Moment in dem Sie die PIN eingeben.

        Es kann von Ihrer Signaturanwendung abhängig sein, welches Dateiformat Sie signieren können. Wir empfehlen zur Signaturerstellung die Verwendung von Signatursoftware deutscher Hersteller. Nach unserem Kenntnisstand sind diese auch in vielen Signaturanwendungen integriert.

        Bei Signatursoftware von anderen Herstellern (z.B. wenn Sie an EU-weiten Plattformen teilnehmen) können die Signaturen von PKS Signaturkarten manchmal nicht verarbeitet werden. Dies liegt an der Verwendung der noch nicht so weit verbreiteten ECDSA Signatur (siehe Welches Signaturformat verwendet die PKS Signaturkarte ?). Insbesondere ist eine qualifizierte Signatur von PDF Dateien mit dem Adobe Reader oder die Prüfung von qualifizierten Signaturen durch den Adobe Reader ohne Zusatzsoftware derzeit nicht möglich.

         

      • Die Anleitung zur Aktivierung/Inbetriebnahme Ihrer Signaturkarte im PDF Format finden Sie im Downloadbereich.

         

      • Die Fehlermeldung UnknownHostException oder ConnectTimeoutException bei der Inbetriebnahme der Signaturkarte im letzten Schritt "Empfang bestätigen und Karte freischalten" bedeutet wahrscheinlich, dass Sie Ihre Signaturkarte in einem Firmennetzwerk nutzen über das Sie keinen direkten Internetzugang haben. Stattdessen nutzen Sie wahrscheinlich einen Proxy zur Verbindung ins Internet.

        UnknownHostException in SignLive Toolbox

        Ihre SignLive Toolbox ist von uns auf direkte Internetverbindung voreingestellt. Bitte klicken Sie im Hauptfenster der SignLive Toolbox auf "Erweitert" und anschließend auf "Einstellungen". Im Bereich "Internetverbindung" können Sie nun den Proxy einstellen. In den meisten Fällen ist die Einstellung "Systemeinstellungen verwenden" die richtige Auswahl.

        Nach Durchführung dieser Einstellung können Sie den Inbetriebnahmeassistenten erneut starten und jetzt im letzten Schritt auch online den Empfang der Karte bestätigen.

         

      • Diese sogenannte TrustList finden Sie für Deutschland auf dem Server der Bundesnetzagentur.

         

      • Bitte wenden Sie sich an den Hersteller der Software.

         

      • Der Support zur Nutzung der Elektronischen Steuererklärung (ELSTER) mit PKS-Signaturkarte wurde von uns eingestellt. Auf Grund der mangelnden Unterstützung für neue Signaturkarten (PKS-ECC) durch ELSTER haben wir uns entschlossen den Support für ELSTER nicht länger aufrecht zu erhalten.

         

      • Sie benötigen einen PC mit einem Chipkartenleser und geeigneter Anwendungssoftware. Wir empfehlen die Verwendung von Signatursoftware unserer Partnerfirmen. Bitte beachten Sie dazu den Punkt Signatursoftware auf unserer Webseite.

        Zur Nutzung der Signaturkarte bieten wir Treiber für unterschiedliche Standardschnittstellen an:

        • PKCS#11: Dies ist ein hersteller- und betriebssystemübergrefender Standard. Die Einbindung in Software erfolgt üblicherweise durch das Laden einer DLL in dieser Software. Diese Schnittstelle wird von vielen Hersteller (mit Ausnahme von Microsoft und Adobe) unterstützt. Wir bieten Treiber für die qualifizierte Signatur sowie für fortgeschrittene Signatur, Verschlüsselung und Authentisierung an.
        • Windows BaseCSP: Hierbei handelt es sich um eine Schnittstelle, die von Microsoft zur Einbindung von Signaturkarten in Windows spezifiziert wurde. Diese Schnittstelle wird beispielsweise von MS Office, Outlook und Adobe zur Signatur verwendet. Wir bieten einen Treiber zur Nutzung der Signaturkarte für fortgeschrittene Signatur, Verschlüsselung und Authentisierung an. Mit diesem Treiber ist keine qualifizierte Signatur möglich.

        Bitte beachten Sie, dass es sich bei den oben beschriebenen Treibern ausschließlich um Möglichkeiten für die Einbindung der Karte in andere Programme handelt. Diese Treiber beinhalten nicht den Funktionsumfang, den eine vollständige Signatursoftware benötigt. Insbesondere beinhalten diese Treiber nicht die Möglichkeit zur Prüfung einer qualifizierten Signatur.

        Auf Grund der Verwendung eines durch das deutsche Bundesamt für Sicherheit in der Informationstechnik spezifizierten Signaturalgorithmus unterliegt die Nutzung der qualifizierten Signatur in verschiedenen Anwendung gewissen Einschränkungen. Bitte beachten Sie dazu unsere FAQ "Welches Signaturformat verwendet die PKS Signaturkarte?".

         

      • Unsere Auftragsprozesse unterstützen die Verwendung des Zeichensatzes ISO/IEC 8859-1. Dieser Standard ist auch als Latin-1 bekannt. ISO/IEC 8859-1 versucht, möglichst viele Zeichen westeuropäischer Sprachen abzudecken. In diesen beiden Tabellen finden Sie welche Zeichen erlaubt sind

        Leider sind beispielsweise einige im Französischen verwendete Zeichen und das Euro-Symbol in diesem Zeichensatz nicht enthalten. Bitte beachten Sie dazu die folgende Vorgehensweise:

        • Schreiben Sie Ihren Namen so wie er auf Ihrem Ausweis in der maschinenlesbaren Zone geschrieben ist, d.h. ohne Diakritische Zeichen.
        • Verfahren Sie bei Sonderzeichen in anderen Feldern genauso.
        • Falls Sie beispielsweise im Attribut Selbstbeschränkung eine Beschränkung auf einen bestimmten Betrag aufnehmen möchten schreiben Sie bitte das Wort Euro aus statt das Euro-Symbol zu verwenden.

        Insbesondere für die Emailadresse gibt es weitere Einschränkungen. Im Feld Emailadresse lassen wir keine Umlaute oder Sonderzeichen anderer Sprachen zu.

         

      • Mit einem Folgeauftrag können Besitzer einer gültigen und funktionsfähigen PKS Signaturkarte eine neue Signaturkarte beauftragen. Sie benötigen dabei keine erneute Identifikation oder Nachweise für ggf. in Ihrem Zertifikat enthaltene Zusatzinformationen (z.B. Handelsregisterauszug bei Geschäftsführer oder Bestätigung durch Ihre Kammer bei Ärzten, Anwälten, usw.).

        Bitte beachten Sie, dass auf Grund der eIDAS Verordnung Folgekartenaufträge nur bearbeitet werden dürfen, wenn diese direkt auf einer persönlichen Identifikation von Ihnen beruhen. Es darf kein Folgekartenauftrag bearbeitet werden, der bereits mit einer Folgekarte signiert wird. In diesem Fall ist eine Neubeauftragung notwendig!

        Den Folgeauftrag führen Sie komplett online aus. Bitte starten Sie den Vorgang hier. Wenn Sie Ihre aktuelle Signaturkarte über einen Kooperationspartner des Trust Centers erworben haben, so bitten wir Sie, dass Sie sich an diesen Kooperationspartner wenden. Insbesondere können wir die zusätzlichen Serviceleistungen Ihres Kooperationspartners nicht erbringen.

        Zur Erzeugung eines Folgeauftrags müssen Sie Ihre Kontaktdaten, die Versandadresse der Signaturkarte sowie die Rechnungsadresse erneut eingeben. Den Folgeauftrag können Sie nicht verwenden wenn sich in der Zwischenzeit Ihr Name oder der Inhalt von Zusatzinformationen im Zertifikat geändert hat. In diesen Fällen benötigen wir von Ihnen einen Neuauftrag.

        Mit der Signatur des Folgeauftrags bestätigen Sie uns, dass sich Ihr Name nicht geändert hat und das Sie eine neue Signaturkarte, zu den zu diesem Zeitpunkt gültigen, AGB beauftragen.

        Zur Verwendung des Folgeauftrags wird ein Browser mit aktiviertem JavaScript benötigt. Außerdem wird eine Java Installation mit Version 1.8 zur Ausführung der Signatursoftware benötigt. Die Signaturkomponente wird als Java Applet nachgeladen. Bitte beachten Sie, dass die meisten aktuellen Browser die Nutzung von Java Applets nicht mehr unterstützen. Wir empfehlen daher die Verwendung des Internet Explorers von Microsoft.

        Bevor Sie den Folgeauftrag starten, sollten Sie alle anderen Programme, die die Signaturkarte nutzen, beenden, da diese den Zugriff auf die Signaturkarte behindern könnten. Achten Sie dabei auch auf Hintergrundprogramme.

         

      • Wir benötigen zur Ausstellung eines qualifizierten Zertifikates auf jeden Fall eine Ausweiskopie von Ihnen.

        Wenn Sie möchten, dann können Sie auf der Kopie die Felder Augenfarbe, Größe und die Zugangssnummer so wie das Bild schwärzen. Alle anderen Angaben auf dem Ausweis benötigen wir jedoch.

        Sollte ein Registrierungsmitarbeiter von Ihnen jedoch die Herausgabe Ihres Ausweises, zum Zweck des Kopierens, verlangen, so können Sie dies ablehnen. Es ist gesetzlich festgelegt, das Sie niemand dazu zwingen darf Ihren Ausweis an ihn abzugeben oder bei ihm zu hinterlegen.

        Sie sollten in diesem Fall den Registrierungsmitarbeiter zum Kopierer begleiten so dass er die Kopie in Ihrem Beisein ausführt.

         

      • Eine genaue Beschreibung und den notwendigen PostIdent-Coupon finden Sie in unserem Download-Bereich.

         

      • Ihren PKS Auftrag nimmt jede Postfiliale / -agentur (zusammen mit PostIdent-Coupon) entgegen, vgl. auch die FAQ (Wie funktioniert die Identifizierung über PostIdent?).

         

      • Die Dateiformate P12 oder PFX sind international spezifiziert als PKCS#12 Format. Dieses Dateiformat enthält neben Ihrem Zertifikat auch den dazugehörigen privaten Schlüssel. Auf Grund des vorgesehenen Einsatzzwecks der PKS Signaturkarte besteht für die PKS Signaturkarte jedoch die Anforderung das die privaten Schlüssel nicht auslesbar sind. Aus diesem Grund ist es nicht möglich von der PKS Signaturkarte Dateien im P12- oder PFX-Format erstellt werden.

        Oftmals bietet Software, die die Einbindung einer P12- bzw. PFX-Datei fordert, auch die möglichkeit zur Einbindung eines Kartenleser Treibers. Weitere Informationen dazu finden Sie in unserer FAQ "Welche Systemvoraussetzungen benötigt mein Computer?".

         

      • Bei CAdES, PAdES und XAdES handelt es sich um technische Spezifikationen von Signaturformaten, die über die allgemein genutzten Signaturformate hinausgehen.

        • Bei CAdES handelt es sich um eine Erweiterung der Cryptographic Message Syntax (CMS). Dieses Format wird unter anderem bei der Signatur von Emails (S/MIME) verwendet. Dateien in diesem Format tragen oft die Dateierweiterung .p7m, .p7s oder .pkcs7.
        • Bei PAdES handelt es sich um eine Erweiterung der PDF Signatur.
        • Bei XAdES handelt es sich um eine Erweiterung der XML Signatur.

        Für Ihre Signaturkarte haben diese speziellen Erweiterungen keine Bedeutung. Die Erweiterungen der Signaturformate werden von Ihrer Signaturanwendung erzeugt. Falls Sie eine Signatur in einem der obigen Formate erzeugen müssen prüfen Sie bitte ob Ihre Signaturanwendung das Format unterstützt.

         

      • Der Signaturalgorithmus RSA (genauer RSA mit PKCS#1 Version 1.5 Padding) wurde von der Bundesnetzagentur im Jahr 2016 als nicht mehr empfohlen für qualifizierte Signaturen ab dem Jahr 2018 eingestuft. Wir nehmen an, dass manche Signaturplattformen ihre Nutzer deswegen informiert haben, dass nur noch RSASSA-PSS Signaturen zugelassen werden. Dabei handelt es sich ebenfalls um Signaturen gemäß RSA Standard, jedoch mit modernerem Padding (genauer PKCS#1 Version 2.1).

        Beim Padding handelt es sich um eine Vorschrift wie der während der Signatur erzeugte Hashwert des Dokuments auf die gleiche Länge wie der RSA Schlüssel (also meistens 2048 Bit) gebraucht wird. Hashwerte sind üblicherweise nur 256 Bit lang. Dies ist für die Rechenoperation mit dem RSA Schlüssel erforderlich.

        Die PKS Signaturkarte erzeugt keine RSA Signatur. Sie kann somit auch keine RSASSA-PSS Signatur erzeugen. Die PKS Signaturkarte verwendet einen Signaturalgorithmus, der eine andere mathematische Basis hat (siehe Welches Signaturformat verwendet die PKS Signaturkarte ?). Bei der ECDSA Signatur ist kein Padding erforderlich.

        Sowohl RSA als auch ECDSA sind gemäß der EU Vorschriften geeignete Signaturalgorithmen für die Erstellung qualifizierter Signaturen. Daher erwarten wir, dass die von den Signaturplattformen herausgegebenen Informationen also nur für Signaturkarten gelten, die RSA Signaturen erzeugen und Sie Ihre PKS Signaturkarte weiterhin nutzen können.

         

      • Die PKS Signaturkarte verwendet den Signaturalgorithmus ECDSA. Diese Art der Kryptografie kommt, bei gleicher Sicherheit, mit deutlich kürzeren Schlüssellängen aus wie die RSA Kryptografie und ist somit auch deutlich performanter.

        Bei diesem Signaturalgorithmus handelt es sich um eine Anwendung der Kryptografie mit elliptischen Kurven. Hier muss neben dem Algorithmus auch noch die verwendete Kurve angegeben werden. Solche Kurven wurden von mehreren Organisationen spezifiziert. Weltweit am stärksten verbreitet sind die elliptischen Kurven, die durch das US amerikanische NIST (National Institute of Standards and Technology) spezifiziert wurden.

        Die PKS Signaturkarte verwendet im Bereich der qualifizierten Signatur eine Kurve, die durch das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) spezifiziert wurde. Die vom BSI spezifizierten elliptischen Kurven werden von internationaler Software oft nicht unterstützt.

         

      • Seit dem 1.1.2016 gibt Sign Live! CC beim Validieren von Signaturen, die mit ECC-Signaturkarten erstellt wurden, eine Warnung aus. Diese besagt, dass die vorliegende Signatur mit einem Algorithmus mit ungenügender Schlüssellänge erstellt sei. Die gleiche Warnung erscheint beim Erstellen der Signatur.

        Diese Warnung ist falsch. Trotz dieser Warnung sind die erstellten Signaturen korrekt.

        Ein Hotfix zur Korrektur dieses Verhaltens wurde umgehend erstellt. 

        Bitte ersetzen Sie die Datei "issecmodelbasic.jar" im Unterverzeichnis "lib" des Installationsverzeichnisses von Sign Live! CC Telekom Edition durch die in der zip-Datei enthaltene Datei.

      • Die Bereitstellung von Sperrlisten zu qualifizierten Zertifikaten wurde am 02.07.2015 eingestellt.

        Das Trust Center wurden schon vor Jahren durch die Aufsichtsbehörde für die qualifizierte Signatur -der Bundesnetzagentur- gebeten, die Veröffentlichung der CRL einzustellen.

        Hintergrund ist einfach der, dass eine korrekte Prüfung lediglich aufgrund einer Sperrliste nicht ausreichend sei, um die Anforderungen des Signaturgesetzes zu erfüllen. Da die Existenz des Zertifikats im Verzeichnisdienst nachgewiesen werden muss, ist eine OCSP-Abfrage bzgl. dieses Zertifikats durch die Signaturanwendungskomponente zwingend erforderlich. Die OCSP Antwort fungiert als Nachweis über den aktuellen Status des Zertifikats.

        Wir haben dann, nachdem auch die Bundesnetzagentur die Veröffentlichung ihrer CRL eingestellt hat und keine negativen Erfahrungen bei den Kunden und Softwareherstellern bekannt wurden, uns auch entschlossen dieser Aufforderung nachzukommen.

        Bitte nutzen Sie zur Prüfung der Gültigkeit qualifizierter Zertifikate die Online-Prüfung mit OCSP in Ihrer Signatursoftware.

         

      • Auch in neu heruntergeladener und installierter OpenLIMIT Software sind nicht alle Updates enthalten. Bitte überprüfen Sie nach der Installation der Software unbedingt ob Updates verfügbar sind und installieren Sie diese. Nur so ist sichergestellt das Ihre Signaturkarte auch funktioniert. Um das Update auszuführen verwenden Sie die Funktion Update-Check, die im Startmenü in der Gruppe OPENLiMiT enthalten ist.

        OPENLiMiT Update Check

         

      • Diese Zertifikate haben unterschiedliche Einsatzzwecke.

        Wenn von Ihrer Anwendung eine "qualifizierte Signatur" gefordert wird und Sie das falsche Zertifikat zur Signaturerstellung verwenden, so wird diese Signatur von der Gegenseite abgelehnt.

        Ein "qualifiziertes Signaturzertifikat" erkennen Sie am einfachsten an seinem Aussteller. Alle qualifizierten Signaturzertifikate, die von der Deutschen Telekom AG ausgestellt wurden, verwenden einen Aussteller dessen Name mit TeleSec PKS eIDAS QES CA oder TeleSec PKS SigG CA beginnt. Danach folgt eine Nummer.

        Achten Sie hier unbedingt auf eIDAS QES oder SigG im Namen des Ausstellers.

         

      • Für die Nutzung des EGVP werden zwei verschiedene Zertifikate benötigt. Zum einen wird ein qualifiziertes Signaturzertifikat für das Signieren von Nachrichten verwendet. Mit diesem Erfordernis wird den Anforderungen aus den Verfahrensverordnungen (insbesondere Schriftformerforderniss) Rechnung getragen. Darüber hinaus ist die Nutzung eines weiteren Zertifikates für die Ende-zu-Ende-Verschlüsselung des Transportweges erforderlich.

        Mit diesem Zertifikat werden das Postfach geöffnet und die Nachrichten (für Sie unbemerkt) ver- und entschlüsselt. Seit der Version 2.6.0 von EGVP werden an dieses Zertifikat besondere Anforderungen gestellt. Es muss sich dabei um ein sog. Kombinationszertifikat (ein Zertifikat mit dem gleichzeitig signiert, ver- und entschlüsselt werden kann) handeln. Ein Zertifikat, dass diese Anforderungen erfüllt ist auf Ihrer PKS-Signaturkarte nicht enthalten. Die Anforderungen an Kombinationszertifikate werden durch Softwarezertifikate erfüllt.

        Das EGVP bietet die komfortable Möglichkeit Softwarezertifikate zu erstellen und in die Anwendung einzubinden. Dabei handelt es sich um die von EGVP empfohlene Art der Nutzung Ihres Postfachs. Einzelheiten sind in der Anwenderdokumentation des EGVP unter Punkt 6.1.1.2.1 beschrieben.

         

      • Falls Ihr Zertifikat im öffentlichen Verzeichnis nicht auffindbar ist, kann dies folgende Ursachen haben:

        • Bitte überprüfen Sie Ihren verwendeten Suchfilter. Geben Sie ggfs. einen allgemeineren Suchbegriff ein.
        • Sie haben Ihr Zertifikat bei der Beantragung nicht zur Veröffentlichung freigegeben.
        • Sie haben nach Erhalt Ihrer Signaturkarte die Empfangsbestätigung noch nicht ausgeführt. Ist dies der Fall, so verfahren Sie bitte wie unter Was bedeutet die Freischaltung des Zertifikats (Verzeichnisdienst) beschrieben und führen Sie die Empfangsbestätigung aus.
      • Wir informieren Sie etwa 6 Wochen vor Ablauf des Zertifikats per eMail. Wir empfehlen Ihnen dann eine neue PKS Karte zu beauftragen. Die einfachste Möglichkeit zur Beauftragung einer neuen Signaturkarte für Bestandskunden ist der Folgeauftrag.

         

      • Diese Überprüfung ist auf Grund von Anforderungen der Browser Hersteller (Microsoft, Mozilla), des CABrowser Forums und der daraus erforderlichen ETSI Zertifizierung erforderlich. Damit wird sichergestellt, daß nur Sie als Eigentümer Ihrer Emailadresse eine Signaturkarte bekommen können, die diese Emailadresse enthält.

        Diese Überprüfung erfolgt dadurch, daß wir Ihnen eine E-Mail an die angegebene Adresse zur Aufnahme ins Zertifikat senden. Diese E-Mail enthält eine achtstellige Prüfnummer, die Sie bei einem Neuauftrag handschriftlich auf Ihren PKS-Auftrag übernehmen müssen. Sollten wir Ihren Auftrag ohne Prüfnummer erhalten, so lehnen wir die Produktion der Signaturkarte ab.

        Sollten Sie keine Email mit der Prüfnummer erhalten, so sehen Sie bitte in Ihrem SPAM-Filter nach oder warten Sie einen Moment. Die Zustellung einer Email kann einige Minuten dauern. Bitte wenden Sie sich ggf. an unseren Support. Die Kollegen dort können Ihnen die Email mit der Prüfnummer erneut zusenden.

         

      • Sie haben die Möglichkeit, ein frei wählbares Pseudonym auf dem Auftrag anzugeben. Das Pseudonym wird im Zertifikat als solches gekennzeichnet (mit einem Zusatz „:PN“). Ihr Name ist im Zertifikat nicht vorhanden. Bei einer Prüfung einer mit diesem Zertifikat erstellten elektronischen Signatur wird das Pseudonym als Signaturersteller angezeigt. Das Zertifikat ist Ihnen persönlich trotzdem zweifelsfrei zugewiesen. In Rechtsfällen sind wir verpflichtet, berechtigten Stellen Auskunft über den Inhaber der Zertifikate zu geben.

      • Bevor Sie mit Ihrer Karte rechtsverbindlich signieren können, ist die Durchführung der Empfangsbestätigung zwingend erforderlich! Erst danach kann der Status Ihres Zertifikats im Verzeichnisdienst überprüft werden. Die Empfangsbestätigung können Sie uns bequem online übermitteln.

        Nutzen Sie dafür den folgenden Link Online-Empfangsbestätigung.

         

      • Der Dienst Public Key Service bietet keine Attributzertifikate an.

         

      • Falls Ihr Zertifikat online nicht nachprüfbar ist, kann dies folgende Ursachen haben: Sie haben die Empfangsbestätigung noch nicht zurück geschickt. Ist dies der Fall, so verfahren Sie bitte wie bei "Was bedeutet die Freischaltung des Zertifikats (Verzeichnisdienst)?" beschrieben und holen Sie die Freischaltung des Zertifikats nach. Es ist auch möglich, dass Ihr Zertifikat gesperrt wurde.

         

      • Die qualifizierten Zertifikate, die vom Public Key Service ausgegeben werden, entsprechen dem Standard X.509 v3 und sind konform zu Common-PKI. Damit legt TeleSec Public Key Service die Basis für eine weitgehende Interoperabilität der Zertifikate und Dienstleistungen mit anderen Zertifizierungsdiensteanbietern und einer Vielzahl von Anwendungen. Das Zertifikatsprofil können Sie in unserem Downloadbereich herunterladen.

         

      • Die Referenz für die Beschaffung von CA Zertifikaten zur Nutzung im Rahmen der qualifizierten Signatur ist die Trusted List der EU. Diese erhalten Sie unter dem Link https://www.nrca-ds.de/st/TSL-XML.xml. Sie können sich unter der URL https://webgate.ec.europa.eu/tl-browser/#/ auch mit Ihrem Browser ansehen.  

        Wir bieten Ihnen die Möglichkeit an, alle unsere CA Zertifikate in einem Paket herunterzuladen. Darin enthalten sind neben den aktuell genutzten Zertifikate für die Ausstellung qualifizierter Signaturzertifikate auch ehemals genutzte Zertifikate für die Ausstellung qualifizierter Signaturzertifikate und Ausstellerzertifikate für andere Zwecke.

         

      • Unsere Chipkarten werden von den gängigen Chipkartenlesern am Markt unterstützt. Jedoch wird oft ein gewisser Firmwarestand vorausgesetzt. Details hierzu sind in der Beschreibung des Kartenlesers zu finden.

         

      • Die Sperrung Ihrer Signaturkarte können Sie jederzeit, online unter dem unten angegebenen Link veranlassen.

        Zusätzlich können Sie die Sperrung entweder telefonisch 24 Stunden am Tag nach Identifikation durch Ihr Telepasswort bzw. TelePIN oder schriftlich beauftragen.

        Die Kontaktdaten für alle Möglichkeiten und die OnlineSperrung finden Sie unter Sperrservice.

      • Zur Nutzung dieser Funktion müssen Sie Ihre Ergänzungszertifikate auf der Signaturkarte installiert haben. Danach gehen Sie wie folgt vor.

        Der Firefox bietet die Möglichkeit einen Treiber für eine Signaturkarte direkt zu laden. Dazu wird das PKCS#11 Modul von unserer Webseite (im bereich Secure Elements & Smartcards) benötigt. Hier ist darauf zu achten die Version (32 Bit oder 64 Bit) zu verwenden für die der Browser erstellt wurde. Die Information findet man in Firefox über Hilfe -> Über Firefox. Meistens wird heutzutage die 64 Bit Version benötigt. Danach in den Einstellungen von Firefox unter dem Punkt "Datenschutz & Sicherheit" den Button "Zertifikate anzeigen" auswählen und im Tab "Zertifizierungsstelle" die CA "TeleSec PKS CA 9" aus importieren. Dieses Zertifikat ist in einem Paket enthalten. Beim Import die beiden Häkchen "Webseite identifizieren" und "E-Mail nutzer identifizieren" anklicken. Danach den Button "Kryptografie Module" auswählen. Dort dann P11TCOS3NetKey64.dll oder P11TCOS3NetKey.dll aus dem Download des PKCS#11 Moduls laden. Spätestens jetzt die Karte einlegen und darauf achten das beim einlegen die grüne LED kurzzeitig blinkt. Jetzt wieder "Zertifikate anzeigen" und da auf das Tab "Ihre Zertifikate" gehen. In dem Moment wird wahrscheinlich jetzt schon die PIN am Kartenleser abgefragt.

      • Dieser Fehler kann im Zusammenhang mit der PIN Eingabe am Kartenleser auftreten. Dies betrifft sowohl den Signaturvorgang als auch die PIN Änderung bzw. PIN Zurücksetzung.

        Für die Eingabe der PIN an der Tastatur des Kartenlesers haben Sie, je nach verwendeter Software, 30 Sekunden bis eine Minute Zeit. In dieser Zeit muss die PIN vollständig eingegeben und mit der Taste OK am Kartenleser bestätigt sein. Im Falle der PIN Änderung müssen die alte PIN, die neue PIN und die Wiederholung der neuen PIN in der geforderten Zeit eingegeben werden. Bitte achten Sie außerdem auf das betätigen der Taste OK nach der Eingabe jedes Teils. Sollte dieser Fehler Zeitüberschreitung bei Ihnen aufgetreten sein, können Sie den Signatur- oder PIN-Änderungsvorgang normalerweise einfach erneut starten.

        Bitte achten Sie darauf das Sie nicht mit der PIN Eingabe beginnen ehe der Kartenlser bereit dazu ist. Ihr Kartenleser zeigt diese Bereitschaft entweder auf seinem Display oder durch eine LED mit Schlosssymbol an. Wenn Sie zu früh mit der Eingabe beginnen, wird Ihre Karte die PIN ablehnen weil sie unvollständig und damit falsch ist.

         

      • Da Ihre PKS Karte unterschiedliche Anwendungen mit unterschiedlichen Sicherheitsanforderungen enthält, werden diese durch separate PINs geschützt.

         

      • Ihre Chipkarte wird mit einem elektronischen Siegel ausgeliefert. Dieses Verfahren wird als NullPIN-Verfahren bezeichnet. Wie jedes herkömmliche Siegel verhindert auch dieses Siegel nicht den Zugriff auf Ihre Karte, ermöglicht aber eine verlässliche Kontrolle der Unversehrtheit der Karte. Eine nicht mehr gesetzte NullPIN ist ein sicheres Indiz, dass die Karte (ggf. von einem Dritten) bereits benutzt wurde. Ein solches Vergehen kann also vom Karteninhaber verlässlich erkannt und auch beanstandet werden.

         

      • Sie können die PIN1 Ihrer Signaturkarte mit der PIN2 zurücksetzen. Für die Nutzung dieser Funktion empfehlen wir Ihnen unser kostenloses Programm SignLive! Toolbox, welches Sie in unserem Downloadbereich herunterladen können. Nach dem Start des Programms wählen Sie die Funktion PIN Management, es öffnet sich folgendes Fenster.

        PIN Management in der SignLive! Toolbox

         

      • Ihre persönliche Identifikationsnummer (PIN) schützt die Karte vor missbräuchlicher Nutzung.

         

      • Das Telepasswort / die TelePIN identifiziert Sie gegenüber dem Trust Center. Sie benötigen es zur Freischaltung Ihres Zertifikats sowie zur Sperrung Ihres Zertifikates auf telefonischem Wege. In bestimmten Fällen wird das Telepasswort / die TelePIN zusätzlich für die Entschlüsselung verschlüsselt übermittelter Zertifikate benötigt.

         

      • Dazu benötigen Sie eine entsprechende Anwendungssoftware, die die NullPIN erkennt und den Karteninhaber zur Eingabe bzw. Wahl einer eigenen PIN auffordert.

        Wenn Sie dazu kein eigenes Programm haben empfehlen wir Ihnen unser kostenloses Programm SignLive! Toolbox, welche Sie im Downloadbereich finden.

      • Wahrscheinlich hat der Leser die Karte über die kontaktlose Schnittstelle angesprochen. Bei Verwendung eines Reiner SCT cyberJack RFID Kartenlesers erkennen Sie dies an der Farbe der Duo-LED. Leuchtet diese blau, so hat der Kartenleser die Karte mittels der RFID Schnittstelle angesprochen. Die Verwendung der SigG-PINs ist jedoch ausschließlich über die kontaktbehaftete Verbindung realisiert. Bei kontaktloser (RFID-)Verbindung stehen lediglich die Globalen PINs zur Verfügung.

        Die Fehlermeldung "Die SigG PIN 1 (für qualifizierte Signatur) kann nicht initialisiert werden. Der Vorgang kann leider nicht fortgesetzt werden" hat die gleiche Ursache. Diese Fehlermeldung erscheint, wenn Sie den Menüpunkt "Karte in Betrieb nehmen" verwendet haben.

        Falls Sie die RFID Funktion des Kartenlesers nicht benötigen (z.B. für den neuen Personalausweis), so empfehlen wir Ihnen diese Abzuschalten.

         

      • Die qualifizierten Signaturzertifikate Ihrer Signaturkarte sind nicht primär für die Nutzung mit Windows vorgesehen. Dies liegt insbesondere an den Anforderungen der EIDAS Verordnung. Diese schreibt beispielsweise bei der Zertifikatsprüfung einen Abgleich mit der Vertrauensliste der EU vor. Dieser Abgleich kann von Windows nicht durchgeführt werden.

        Abhängig von den vorhandenen Einstellungen kann die Aussage von Windows zu Ihrem Zertifikat unterschiedlich ausfallen. Die Aussage wird vermutlich "Dieses Zertifikat kann nicht bis zu einer Zertifizierungsstelle verifiziert werden" oder "Es liegen keine ausreichenden Informationen vor um dieses Zertifikat zu verifizieren". Bitte beachten Sie auch die weiteren Artikel in unserer FAQ im Bereich "PKS Zertifikate unter Windows". Bei der Nutzung der Zertifikate sind unter Umständen weitere Besonderheiten zu beachten.

        Ihre Zertifikate werden von Windows in der Standardeinstellung nicht als gültige Zertifikate anerkannt weil Windows das verwendete Ausstellerzertifikat nicht kennt bzw. den verwendeten Signaturalgorithmus nicht verarbeiten kann.

        Wenn Sie möchten, dann können Sie die Ausstellerzertifikate, das ist derzeit "TeleSec PKS eIDAS QES CA 1" und "TeleSec qualified Root CA 1" in Windows installieren. Die Zertifikate finden Sie in unserem Downloadbereich unter Technische Dokumentation in einer ZIP-Datei "CA-Zertifikate.zip". Wenn Sie eine aktuelle (regelmäßig aktualisierte) Windows Version ab Windows 7 verwenden werden die qualifizierten Zertifikate jetzt als gültig angezeigt. Wenn Windows die Zertifikate als gültig anerkennt, so können Sie diese trotzdem nicht nutzen ohne weitere Software zu installieren. 

        Informationen welche Möglichkeiten wir empfehlen die qualifizierte Signatur mit Ihrer Signaturkarte zu nutzen finden Sie in unserer FAQ "Welche Systemvoraussetzungen benötigt mein Computer?".

         

      • Wir empfehlen Ihnen die Verwendung der Adressbuch Funktion Ihres Email Programms um ein Zertifikat / eine Person im Verzeichnisdienst zu suchen. Entsprechende Funktionen werden zum Beispiel von Microsoft Outlook zur Verfügung gestellt. Nachfolgend erklären wir Ihnen die Nutzung von Outlook zur Suche im PKS Verzeichnisdienst. 

        Öffnen Sie Konfiguration Ihres Email Kontos mittels der Systemsteuerung. Wählen Sie danach die Registerkarte Adressbücher aus. Fügen Sie ein neues Adressbuch mit einen Klick auf den Button "Neu" hinzu. Wählen Sie im nachfolgenden Dialog den Typ "Internetverzeichnisdienst (LDAP)". Geben Sie als Servername den Namen pks-ldap.telesec.de ein. 

        Öffnen Sie danach Outlook und das Adressbuch. Wählen Sie im Adressbuch Ihr neu erstelltes Adressbuch pks-ldap.telesec.de aus. Klicken Sie auf "Erweiterte Suche". Geben Sie hier im Feld Anzeigename Ihr Suchkriterium ein. Nachdem Outlook den gewünschten Eintrag gefunden hat wählen Sie bei diesem Eintrag im Kontextmenü die Funktion "Zu den Kontakten hinzufügen". Es wird Ihnen jetzt die Outlook - Visitenkarte des Eintrags angezeigt. Wählen Sie hier unter Anzeigen den Punkt Zertifikate.

         

      • Diese Fehlermeldung wird nicht von der Chipkarte erzeugt sondern vom Kartenverwaltungssystem von Windows. Dieses regelt den Zugriff auf die Chipkarte von mehreren Anwendungen.

        Die Fehlermeldung SCARD_E_SHARING_VIOLATION bedeutet, dass in diesem Moment mehrere Anwendungen gleichzeitig auf Ihre Signaturkarte zugreifen möchten und sich dabei gegenseitig behindern. Bestimmte Aktionen, wie zum Beispiel die Änderung einer PIN erfordern einen exklusiven Zugriff auf die Chipkarte. Dieser exklusive Zugriff ist aktuell nicht möglich.

        Um den Fehler zu lösen beenden Sie bitte alle Programme, die auf die Chipkarte zugreifen könnten. Achten Sie dabei auch auf Programme, die im Hintergrund laufen und zum Beispiel nur im Informationsbereich der Taskleiste (neben der Uhr) mit einem Icon sichtbar sind. Nachdem der konkurrierende Zugriff auf die Chipkarte gelöst wurde tritt dieser Fehler nicht mehr auf.

         

      • Damit Sie Ihre Signaturkarte mit Outlook nutzen können ist es erforderlich das Sie bei der Beauftragung die Emailadresse des Email-Kontos welches Sie nutzen möchten in Ihre Signaturkarte eingetragen und mittels der Prüfnummer bestätigt haben.

        Eine qualifizierte Signatur von Emails ist mit der hier beschriebenen Vorgehensweise nicht möglich.

        Diese Anleitung richtet sich ausschließlich an erfahrene Anwender und Administratoren mit sehr guten Kenntnissen von Windows und Outlook. Sie beschreibt die Vorgehensweise unter dem Betriebssystem Windows 7 und Outlook 2007. Bitte beachten Sie, dass die aktuell ausgelieferten Signaturkarten nicht mit Windows XP kompatibel sind. Die verschiedenen Konfigurationsschritte können in Abhängigkeit der vielen unterschiedlichen Versionen von Windows und Outlook geringfügig unterschiedlich sein. Die Vorgehensweise dieser Anleitung ist nicht mit Mozilla Thunderbird kompatibel.

        Um Ihre Signaturkarte anschließend mit Outlook nutzen zu können muss die Karte in Windows eingebunden werden. 

        Zur Einbindung der Signaturkarte in Windows benötigen Sie einen Crypto Service Provider (CSP). Dies ist eine von Microsoft definierte Schnittstelle zwischen Windows und Ihrer Signaturkarte. Wenn Sie bereits eine Signatursoftware wie zum Beispiel OpenLimit CC Sign oder Intarsys SignLive! oder den SecSigner von SecCommerce installiert haben so wurde der Crypto Service Provider wahrscheinlich bereits installiert.

        Bitte stecken Sie jetzt Ihre Signaturkarte in den Kartenleser. Sollte von Windows nun die Aufforderung zur Installation eines Treibers angezeigt werden so haben Sie noch keinen CSP installiert. In diesem Fall können Sie einen kompatiblen CSP von unserer Webseite herunterladen. Bitte laden Sie die Datei Read Only Cardmodul zur "Signature Card 2.0" - Mit ECC-Unterstützung 32Bit oder 64Bit (entsprechend Ihrer Betriebssystemarchitektur) aus dem Downloadbereich herunter. Installieren Sie den Treiber in dem Sie die Datei ausführen. Öffnen Sie den Gerätemanager von Windows über die Systemsteuerung → System → Gerätemanager. Dort sollte jetzt in der Baumansicht unter Smartcards ein Eintrag für Ihre Chipkarte angezeigt werden.

        Bitte entfernen Sie jetzt Ihre Signaturkarte aus dem Kartenleser, warten Sie 10 Sekunden und stecken Sie sie danach wieder ein. Durch diesen Vorgang merkt der neu installierte Treiber die neu eingesteckte Chipkarte und liest sie aus. Die Aufforderung zur Installation eines Treibers sollte jetzt nicht mehr erscheinen. Der Kartenleser beginnt zu blinken. Bitte warten Sie ab bis der Kartenleser aufhört zu blinken.

        Starten Sie das Programm certmgr.msc in dem Sie das Startmenü öffnen und dort im Eingabefeld certmgr.msc eingeben und die Eingabetaste drücken. Erweitern Sie in dem Programm die Ansicht unter dem Punkt „Eigene Zertifikate“. Dann erscheint der Unterpunkt „Zertifikate“. Klicken Sie auf den Unterpunkt Zertifikate. Jetzt sollten im rechten Teil des Fensters die Zertifikate Ihrer Signaturkarte angezeigt werden.

        Öffnen Sie eines Ihrer Zertifikate in dem Sie darauf einen Doppelklick ausführen. Im unteren Teil des Fensters sollte die Aussage stehen „Sie besitzen einen privaten Schlüssel zu diesem Zertifikat“. Ist dies nicht der Fall schließen Sie das Zertifikat, klicken es mit der rechten Maustaste an und wählen Sie löschen. Den gleichen Vorgang machen Sie für Ihre weiteren Zertifikate. Danach schließen Sie das Programm, entfernen die Chipkarte aus dem Kartenleser, warten Sie 10 Sekunden und stecken Sie die Chipkarte erneut. Dadurch wird die Signaturkarte neu eingelesen. Bitte führen Sie den Vorgang fort in dem Sie mit dem vorherigen Punkt dieser Anleitung weiter machen.

        Nachdem Sie im vorherigen Punkt sichergestellt haben, dass die Zuordnung des Zertifikats zu Ihrer Signaturkarte funktioniert prüfen Sie nun ob Windows das Zertifikat als ein gültiges Zertifikat erkennt. Dazu öffnen Sie eines Ihrer Zertifikate im Programm certmgr.msc. Möglicherweise wird dort jetzt angezeigt „Es liegen keine ausreichenden Informationen vor, um dieses Zertifikat zu verifizieren“. In diesem Fall müssen die Ausstellerzertifikate installiert werden. Dabei handelt es sich um die Zertifikate "TeleSec PKS CA 9" und "Deutsche Telekom Internal Root CA 2". Laden Sie die Datei CA-Zertifikate.zip von unserer Webseite. Öffnen Sie diese Datei und suchen Sie darin die oben genannten Ausstellerzertifikate und extrahieren Sie diese aus der ZIP-Datei. Es ist nicht nötig die komplette ZIP-Datei zu extrahieren. Erweitern Sie in dem Programm certmgr.msc den Punkt „Zwischenzertifizierungsstellen“. Klicken Sie anschließend mit der rechten Maustaste auf den Unterpunkt „Zertifikate“ von „Zwischenzertifizierungsstellen“. Wählen Sie dort im Menü die Funktion „Alle Aufgaben“ und dann den weiteren Unterpunkt „Importieren“. Es öffnet sich der Zertifikatsimport-Assistent. Laden Sie damit das eben extrahierte Ausstellerzertifikat "TeleSec PKS CA 9". Klicken Sie dafür mehrfach auf „Weiter“ und zum Schluss auf „Fertigstellen“. Erweitern Sie anschließend den Punkt „Vertrauenswürdige Stammzertifizierungsstellen“. Klicken Sie mit der rechten Maustaste auf den Unterpunkt „Zertifikate“ von „Vertrauenswürdige Stammzertifizierungsstellen“. Wählen Sie dort im Menü die Funktion „Alle Aufgaben“ und dann den weiteren Unterpunkt „Importieren“. Laden Sie mit dem Zertifikatsimport-Assistent das eben extrahierte Ausstellerzertifikat "Deutsche Telekom Internal Root CA 2". Klicken Sie dafür mehrfach auf „Weiter“ und zum Schluss auf „Fertigstellen“. Zum Abschluß müssen Sie noch bestätigen dass Sie das neue Zertifikat wirklich im Bereich "Vertrauenswürdige Stammzertifizierungsstellen" importieren möchten.

        Wenn Sie Ihr Zertifikat im Programm certmgr.msc unter „Eigene Zertifikate“ → „Zertifikate“ jetzt erneut öffnen und dort im Reiter „Zertifizierungspfad“ auf den Inhalt des Feldes „Zertifizierungsstatus“ achten, sollte dort jetzt stehen „Dieses Zertifikat ist gültig“.

        Zur Einbindung des Zertifikats in Outlook öffnen Sie bitte das Vertrauensstellungscenter. Dieses finden Sie im Menü Extras. Wählen Sie im linken Teil des Fensters die Kategorie „E-Mail Sicherheit“. Klicken Sie anschließend im rechten Teil des Fensters, unter der Überschrift „Verschlüsselte E-Mail Nachrichten auf den Button „Einstellungen“. Klicken Sie in dem sich jetzt neu geöffneten Fenster „Sicherheitseinstellungen“ auf den Button „Auswählen“ neben der Anzeige „Signaturzertifikat“ und auf den Button „Auswählen“ neben der Anzeige „Verschlüsselungszertifikat“. Wählen Sie dann jeweils ein Zertifikat von Ihrer Signaturkarte aus. Es ist empfehlenswert den Haken bei „Signierten Nachrichten diese Zertifikate hinzufügen“. Schließen Sie dieses Fenster und das Vertrauensstellungscenter.

        Die Nutzung der Signaturkarte mit Outlook zum signieren und verschlüsseln von Email sollte jetzt funktionieren.

        Falls Sie für jemand anderes Verschlüsseln möchten, ist es empfehlenswert, dass Sie denjenigen bitten Ihnen eine signierte Email zukommen zu lassen. Mit den oben beschriebenen Einstellungen können Sie diese Person anschließend in Ihr Adressbuch übernehmen. Dabei wird auch das Zertifikat des Empfängers gespeichert. Anschließend können Sie für ihn verschlüsseln, in dem Sie den Eintrag aus Ihrem Adressbuch verwenden. Falls jemand anderes für Sie verschlüsseln möchte gehen Sie umgekehrt vor. Senden Sie demjenigen eine signierte Email und bitten Sie ihn das er Sie als Empfänger in sein Adressbuch aufnimmt. Anschließend kann er für Sie verschlüsseln.

         

      • MS Windows erwartet in CA-Zertifikaten eine Zertifikatserweiterung namens "BasicConstraints", die ein Zertifikat als CA-Zertifikat ausweist. Diese Zertifikatserweiterung ist in manchen alten TeleSec CA-Zertifikaten nicht enthalten. Diese Zertifikate wurden von der Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen ausgestellt und unterliegen nicht unserem Einfluss.

         

      • In PKS Zertifikaten wird ein Signaturalgorithmus verwendet, der von Windows ohne zusätzliche Software nicht unterstützt wird.

        Bitte beachten Sie außerdem das zur Gültigkeitsprüfung eines qualifizierten Zertifikats eine Onlineprüfung zwingend erforderlich ist. Windows kann eine solche Prüfung nicht vornehmen.

        Für den korrekten Umgang mit qualifizierten Zertifikaten benötigen Sie einen Crypto Service Provider (CSP) oder eine Signatursoftware, die die verwendeten Algorithmen und die erforderlichen Onlineprüfungen unterstützten. Alle für den Einsatz zur Erzeugung qualifizierter elektronischer Signaturen geeigneten Signaturanwendungskomponenten enthalten diese Funktionen.

        Bitte achten Sie darauf immer die aktuellsten Versionen Ihrer Signatursoftware zu verwenden, da diese ständig an Stand der Technik angepasst werden müssen.

         

      • Nach dem deutschen Signaturgesetz verliert ein qualifiziertes Zertifikat seine Gültigkeit nicht, wenn ein darüber liegendes Root- oder CA-Zertifikat abläuft oder gesperrt.

        Diese Art der Prüfung der Gültigkeit von qualifizierten Zertifikaten wird als das sogenannte Kettenmodell bezeichnet. Bei einer Gültigkeitsprüfung nach dem Kettenmodell ist es wesentlich, dass das nächsthöhere Zertifikat zum Erstellungszeitpunkt der Signatur / des Zertifikats gültig ist bzw. war. Daher ist es auch erlaubt, dass der Gültigkeitszeitraum eines qualifizierten Zertifikats über die Gültigkeitsdauer des entsprechenden CA-Zertifikats hinaus geht.

        Microsoft Windows und manche andere Anwendungen prüfen die Zertifikate jedoch nach dem Schalenmodell, welches, anders als das Kettenmodell, die Gültigkeit aller Zertifikate des Zertifizierungspfads zum Prüfzeitpunkt fordert. Im o.g. Fall liefert damit Windows einen falschen Status für ein qualifiziertes Zertifikat welches gemäß dem deutschen Signaturgesetz ausgestellt wurde.

         

      • Wir empfehlen E-Mails nicht qualifiziert zu signieren. E-Mailprogramme haben nicht die notwendigen Funktionen um eine Signatur mittels der von der EU herausgegebenen Vertrauensliste zu prüfen. Aus diesem Grund biten wir keinen Treiber für den Windows CSP an mit dem es möglich wäre eine E-Mail qualifiziert zu signieren.

        Aus sicherheitstechnischer Sicht empfehlen wir, statt einer signierten E-Mail, eine signierte Datei, die Sie als Anhang zu einer E-Mail versenden können.

         

Energy CA

      • Informationen zur Energy Test CA Schnittstelle:

         

        Webservice: Energy Test CA
        Version: 1.3.1
        URL: https://energyca.test.telesec.de/energycatest/131/services/SmartMeterService
        Port: 443

         

      • Informationen zur Schnittstelle der  EnergyCA (Wirkumgebung):

         

        Webservice: T-Systems-EnergyCA.CA
        Version: 1.3.0
        URL: https://api.energyca.telesec.de/energyca/services/SmartMeterService
        Port: 443

         

      • Grundsätzlich werden im Rahmen der Registrierung die Ansprechpartner der Endkunden registriert und sind somit der EnergyCA bekannt. Der Support-Anspruch gilt somit gegenüber nur dem jeweils hinterlegten Ansprechpartner des Endkunden. In Ausnahmefällen wird der Support auch gegenüber Dritten geleistet. Hierzu ist eine entsprechende Information seitens des registrierten Ansprechpartner per S/MIME notwendig.

      • Die Formulare sind im Service / Downloads / Produkte & Lösungen zu finden.

         

      • Die Formulare sind im Service / Downloads / Produkte & Lösungen zu finden.

         

      • Die Formulare sind im Service / Downloads / Produkte & Lösungen zu finden.

         

      • Die EnergyCA stellt in Ihrer Funktion einer Sub-CA folgende Endnutzer-Tripel Zertifikate aus:

        • SMGW Hersteller (GWH)
        • SMGW Administrator (GWA)
        • Endmarktteilnehmer (EMT)

        Der GWH ist neben seinem eigenen Zertifikat noch für die SMGW-Gütesiegelzertifikate verantwortlich.

        Der GWA ist neben seinem eigenen Zertifikat noch für die SMGW-Wirkzertifikate verantwortlich.

         

      • Die Zuordnung der einzelnen Zertifikatstypen sind der nachfolgenden Tabelle zu entnehmen:

         

        Mandanten
        ​SMGW Güte-

        siegel Zertifikate
        SMGW Wirk-

        Zertifikate​​
        ​Administrator

        Zertifikate​
        SMGW Hersteller

        Zertifikate​
        EMT

        Zertifkate​
        ​SMGW Hersteller
        SMGW
        Admin​
         
        EMT​​
         

          

      • Jedes in der SM-PKI verwendete Zertifikat besitzt eine Gültigkeitszeit und eine Verwendungszeit für den zugehörigen privaten Schlüssel, welche im Zertifikat angegeben werden.

        Die folgende Tabelle gibt die Zertifikatslaufzeiten bei alle Zertifikaten  - außer denen der SM-PKI Root - laut TR 3109-4 ( Tabelle 11) verbindlich vor: 

        Zertifikat​

        ​Gültigkeitszeit

        Root-CRL-Signer Zertifikat

        ​4 Jahre

        ​Root-CRL-TLS Zertifikat

        ​4 Jahre

        ​Sub-CA (EnergyCA) Zertifikat

        ​5 Jahre

        TLS Zertifikate der Root CA und der Sub-CA​ (EnergyCA)

        ​2 Jahre

        GWA Zertitifkate (Sign, ENC, TLS)​

        ​3 Jahre

        Andere Endnutzerzertifikate (Sign, ENC, TLS)​

        ​2 Jahre

         

      • Nein, die Zertifikate werden immer gemeinsam ausgestellt und gesperrt. Bei einem notwendigen Folgezertifikat sind auch immer drei neue Zertifikate zu beantragen.

      • Nein, nach der TR 3109-4 sind immer Folgezertifikate mit neuem Schlüsselmaterial zu erstellen. Eine Verlängerung würde eine Änderung der laufzeit bei gelichem Schlüsselmaterial bedeuten.

      • Wenn neben der EnergyCA auch eine andere Sub-CA aus der Smart-Metering PKI beteiligt ist, ist zu beachten, dass im Request immer die komplette Zertifikatskette enthalten sein muss. Nur so kann die EnergyCA - vorausgesetzt die andere Sub-CA ist aus dem TC erreichbar - die Zertifikatskette prüfen. Beispiel: Ein GWA der EnergyCA möchte in einem SMGW das „fremde“ Gütesiegelzertifikat aus einer andere Sub-CA durch ein Wirkzertifikat aus der EnergyCA ersetzen.

      • Unter "Suspendierung" versteht man die temporäre Sperrung eines Zertifikates. Dieses kommt in der EnergyCA nur bei SMGW Zertifikaten vor und muss vom GWA bzw. vom GWH (nur Gütesiegelzertifikate) durchgeführt werden.

         

        Die Suspendierung MUSS über die Web-Service-Schnittelle der Sub-CA beantragt werden. Im Ausnahmefall (z.B. Web-Service-Schnittstelle steht nicht zur Verfügung) kann dies auch über einen entsprechend abgesicherten, etablierten Kommunikationskanal (z.B. signierte E-Mail) durchgeführt werden. Eine Suspendierung eines SMGW MUSS immer als Paket (enthält Zertifikatstripel) erfolgen, siehe [TR-03109-4].

         

        Eine Suspendierung des jeweiligen Zertifikats MUSS über die Sperrliste der CA veröffentlicht werden. Der Zertifikatsinhaber (GWA) MUSS über den abgeschlossenen Sperrprozess informiert werden.

      • Die Sperrung der nicht systemrelevanten Zertifikate können vom Zertifikatsnehmer direkt über das „Kunden-Frontend“ der EnergyCA umgesetzt werden.

        Für die Sperre ist eine erfolgreiche Anmeldung am Frontend mit Kunden (TLS) Zertifikat in der Rolle „Kunde“ Voraussetzung. Dieses Zertifikat stammt nicht aus der SMPKI.

        Es wird im Rahmen der Erstregistrierung für den Kunden explizit durch Telekkom Security erstellt und über einen sicheren Kanal (S/MIME) an den Kunden übermittelt.

        Nach Auswahl des Menüpunktes „Zertifikate sperren“ kann der zuständige Ansprechpartner die Zertifikat laut nachfolgender Tabelle sperren.

         

        Alternativ – bzw. für die systemrelevante Sperrung des GWA Zertifikates - ist der Sperrwunsch via S/MIME von einem der registrierten Ansprechpartner über die Kommunikationsschnittstelle der Registration Authority (RA) der EnergyCA möglich.

        Der Sperrservice der RA kann auch telefonisch kontaktiert werden. Hierzu werden im Rahmen der Erstregistrierung die Kontaktdaten ausgetauscht und ein Sperrkennwort vereinbart. Dieses ist bei einem telefonischen Sperrwunsch seitens des Kunden zu nennen. Der RA Mitarbeiter prüft das Kennwort auf Übereinstimmung.

        Eine Sperrung des GWA Zertifikates hat systemrelevante Bedeutung und muss daher in Abstimmung mit der SM-PKI Root erfolgen. Der Sperrwunsch des Kunden, wenn nicht seitens der EnergyCA iniziiert, wird zunächst seitens der EnergyCA entgegengenommen, geprüft und danach per signierter Email an die SM-PKI Root CA als beteiligte Instanz übermittelt. Nach Zustimmung wird das Zertifikat im Vier-Augenprinzip gesperrt und der Kunde hierüber informiert.

         

Secure Elements & Smartcards

      • NetKey / IDKey eignet sich z.B. für

        • E-Mail-Verschlüsselung
        • E-Mail-Signatur
        • Offline-Verschlüsselung von Daten (Files)
        • Festplattenverschlüsselung
        • Online-Authentifikation an Web-Servern, Zutrittsanlagen, Gleitzeit-Terminals
        • Online-Authentifikation an Web-Servern, z.B. mit Einmalpasswörtern
        • Bezahlsysteme geschlossener Benutzergruppen
        • Anmeldung an Computern (z.B. WinLogon)

        Diese Liste ist beispielhaft und nicht vollständig.

      • Im ersten Schritt wird eine Identität definiert. Am Beispiel einer Person ist schnell zu erkennen, dass diese nach der Geburt im Familienkontext über Mutter und Vater identifiziert wird. Durch die Vergabe eines Namens und die Eintragung in ein Melderegister entsteht eine neue Identität. Bei technischen Komponenten vergibt zum Beispiel der Hersteller eines Produktes eine Seriennummer.

      • Im einfachsten Fall kann der Inhaber eines NetKey / IDKey sich selbst ein Zertifizikat ausstellen. Hierbei handelt es sich dann um ein sogenanntes „selfsigned Certificate“. Streng genommen behauptet der Inhaber also lediglich, eine bestimmte Identität und einen bestimmten Schlüssel zu besitzen.

        Technisch gesehen können solche Zertifikate für alle Zwecke eingesetzt werden, bei denen das Zertifikat als berechtigt akzeptiert wird.

        Die Identitätsprüfung erfolgt in solchen Fällen meist vorab z.B. per Telefon oder durch persönliche Begegnung, wobei man sich auf eine Zusammenarbeit auf dieser Basis einigt.

      • Die Identität einer Person wird bei Bedarf üblicherweise durch die Präsentation eines Ausweisdokumentes nachgewiesen. Dazu werden sichtbare Identitätsmerkmale wie Lichtbild, Augenfarbe oder besondere Merkmale wie Narben abgeglichen.

        Im Falle des Verlustes eines solchen Ausweises muss die Person sich ggf. durch z.B. Vorlage eines Familienstammbuches beim Melderegister ausweisen, um einen neuen Ausweis zu bekommen.

        Vor der Ausstellung des Zertifikates kann der Zertifizierungsdienst ggf. durch Abgleich gegen ein vorgelegtes Ausweisdokument die Identität des Auftraggebers prüfen. Die Qualität dieser Prüfung ist die Basis für die Qualität des Zertifikats.

        Eine E-Mail-Adresse kann z. B. nur dann als Identitätsmerkmal genutzt werden, wenn gewährleistet ist, dass das zugehörige E-Mail-Konto unter der Kontrolle des Auftraggebers ist. Diese Prüfung kann mittels Zusendung und Beantwortung einer Bestätigungs-E-Mail erfolgen.

      • In diesem Fall muss sich der Inhaber des NetKey / IDKey dem Registrierungsprozess eines anerkannten Zertifizierungsdienstes unterziehen. Hierbei muss die eigene Identität nach den jeweiligen Anforderungen des Zertifizierungsdienstes z.B. auf Basis einer persönlichen Vorstellung mit Vorlage eines Ausweisdokumentes nachgewiesen werden.

        Der Zertifizierungsdienst stellt ein Zertifikat erst nach positiver Prüfung der vorgelegten Identitätsnachweise aus.

        Der Zertifizierungsdienst stellt eine sogenannte „dritte Instanz“ dar. Somit ist das ausgestellte Zertifikat nicht mehr bloß eine Behauptung, sondern eine nachprüfbare Identität. Zertifizierungsdienste stellen darüber hinaus üblicherweise Prüfmöglichkeiten in Form von standardisierten Verzeichnis- und Sperrservices bereit.

      • Die Personalisierung des NetKey / IDKey erfolgt durch die Zuordnung eines öffentlichen Schlüssels aus dem NetKey / IDKey zu Identitätsmerkmalen des NetKey-/IDKey-Inhabers innerhalb eines Zertifikats.

        Diese Zuordnung geschieht in der Regel als Versiegelung mittels elektronischer Signatur dieser Verknüpfung. Durch diese Versiegelung entsteht aus einer Ansammlung von Identitätsmerkmalen ein Zertifikat. Der öffentliche Schlüssel wird dabei zu einem weiteren Identitätsmerkmal.

        Die Verbindung zum NetKey / IDKey liegt in der Verknüpfung zwischen öffentlichem und geheimem Schlüssel.

      • Der geeignete Zertifizierungsdienst ergibt sich in der Regel aus dem Anwendungskontext. Weltweit bieten verschiedene Zertifikatsaussteller ihre Dienste über das Internet an.

        In großen Firmen oder Organisationen existieren oft eigene Public Key Infrastrukturen (PKI) zur Ausstellung und zum Management von fortgeschrittenen Zertifikaten. Das heißt, die Registrierung der Teilnehmer erfolgt nach den Regeln des jeweiligen Anbieters.

        Darüber hinaus sind in den letzten Jahren in verschiedenen Ländern Zertifizierungsdiensteanbieter (ZDA) entstanden, die sogenannte qualifizierte Zertifikate anbieten. Für die Ausstellung eines qualifizierten Zertifikats beschreibt das jeweilige Land bestimmte Anforderungen hinsichtlich der Qualität der Registrierung. Ebenso wird die Qualität der Sicheren Signatur-Erstellungseinheit (SSEE) vorgeschrieben.

        Ob der TeleSec NetKey / IDKey als SSEE geeignet ist, muss im Einzelfall mit dem zuständigen ZDA abgestimmt werden.

      • Fertig initialisierte TeleSec NetKey / IDKey sind anonym und mit dem durch die Deutsche Telekom AG patentierten Null-PIN-Verfahren geschützt.

        Vor der Zuordnung eines NetKey / IDKey aus einer Menge neuer Karten zu einer Person oder einem System kann die Unversehrtheit der Karte durch Überprüfung des Null-PIN-Status gewährleistet werden.

        Eine Kartennutzung verbunden mit der Vergabe einer kundenindividuellen PIN durch die Person oder das System zerstört dieses Schutzsiegel und bindet die Karte an den PIN-Inhaber (Wissen).

        Ab diesem Zeitpunkt ermöglicht NetKey die sogenannte Zwei-Faktor-Autorisierung durch Besitz und Wissen.

        Vorteile:

        • TeleSec NetKey / IDKey können bevorratet werden, ohne den exakten Bedarf vorher zu kennen. Die Personalisierung erfolgt nach der Ausgabe eines NetKey / IDKey.
        • Da der für Plastikkarten ansonsten notwendige PIN-Brief entfallen kann, sind Optimierungen monetärer, administrativer und personeller Art realisierbar durch:
          • vereinfachte Lagerhaltung
          • Einsparung der Portokosten
          • Einsparung der teuren Spezialpapier-Formulare für PIN-Briefe
          • Einsparung des administrativen Aufwandes zur richtigen Zuordnung des PIN-Briefs zur Karte
          • Einsparung des Aufwandes für die Kuvertierung der PIN-Briefe
          • Einsparung von Porto für den zeitversetzten Versand des PIN-Briefes

        Der Endanwender sucht sich selbst ein Passwort (PIN) aus, das für ihn nach seinem individuellen Denkmuster leicht zu merken ist. (Ein solches Passwort kann aus dem kompletten ASCII-Satz in einer empfohlenen Passwortlänge von bis zu 64 Zeichen bestehen. Der Einsatz von z.B. PIN-Tastaturen sicherer Kartenleser kann es erforderlich machen, dabei nur die Ziffern 0 bis 9 zu verwenden.)

      • Ein Schlüsselpaar wird üblicherweise innerhalb des Browsers in Software erzeugt, der öffentliche Teil wird in den Zertifikatsrequest eingebaut und dieser wird mit dem geheimen Teil signiert, um die Authentizität des öffentlichen Schlüssels nachzuweisen. Der Secret Key wird anschließend passwortgeschützt im Rechner abgelegt (meist innerhalb eines PKCS#12-Containers).

        Der TeleSec NetKey / IDKey hingegen bringt Schlüsselpaare mit, die innerhalb des Trust Centers der Telekom in einem hochsicheren Schlüsselgenerator entstanden sind. Dieser Schlüsselgenerator kann diese Schlüssel nur in geeignete TCOS-Chips exportieren. Dieser Export erfolgt kryptografisch derart gesichert, dass ein Mitlesen der Schlüssel ausgeschlossen ist. Somit können keine Schlüsselkopien existieren.

        Eine Middleware integriert den NetKey / IDKey so in die Betriebssystemplattform, dass beim Anfordern eines Schlüsselpaares durch eine Anwendung das öffentliche Schlüsselmaterial der TCOS Smartcard benutzt wird.

      • Nach Fertigstellung eines NetKey / IDKey können die geheimen Schlüssel nur noch innerhalb des TCOS-Chips für Kryptooperationen herangezogen werden. Die Nutzung der geheimen Schlüssel ist PIN-gesichert, d. h. nur berechtigte Benutzer können geheime Schlüssel anwenden.

      • Der Schlüsselgenerator im TeleSec Trust Center speichert keine Schlüssel; die Übertragung der Schlüssel an die Smartcard erfolgt über verschlüsselte Leitungen innerhalb des sicherheitszertifizierten Trustcenters der Telekom. Somit ist die Existenz von Doppeln völlig ausgeschlossen, der geheime Schlüssel liegt somit ausschließlich im TCOS-Chip

      • Für Testzwecke wird für den TCOS Cardmanager ein PlugIn zur Verfügung gestellt, mit dem selbstsignierte Test-Zertifikate generiert und auf die auf die Karte geschrieben werden können. Hierzu muss zusätzlich die OpenSource-Bibliothek OpenSSL installiert werden.

        Das Plugin unterstützt nur Netkey 3.0 und IDKey TCOS 3.0 Chipkarten. Diese Zertifikate verwenden nicht die bei der Produktion auf den TCOS 3.0 Smartcards vorpersonalisierten Schlüsselpaare. Für diese Zertifikate existierert keine vertrauenwürdige Root oder nicht die Möglichkeit zur Zertifikatsprüfung (LDAP/OCSP).

        Aus diesem Grund können in einigen Anwendungen diese selbstgenerierten Zertifikate nur eingeschränkt genutzt werden. Wir empfehlen immer hochwertige Zertifikate von einer entsprechenden CA mit einer vertrauenwürdigen Root und Verzeichnisdiensten zur Überprüfung der Vertrauenswürdigkeit und Gültigkeit der Zertifikate zu verwenden.

      • Unter Microsoft Windows existiert ein sogenannter BaseCSP zur Einbindung von Hardware-Token. Die Schnittstelle zur Einbindung eines Card Moduls ist beschrieben. Zum NetKey / IDKey steht ein solches Card Modul bereit, welches ab Windows 7 über Windowsupdate.com zur Verfügung stehen wird. Dies bedeutet, dass sobald ein NetKey / IDKey erkannt wird, im Bedarfsfall das TCOS Card Modul automatisch geladen wird.

        Nach Installation des Card Moduls wird NetKey / IDKey wie ein PKCS#12 Container behandelt. Der Benutzer kann zur Anforderung eines Zertifikates den Public Key aus NetKey / IDKey präsentieren. Die Krypto-Middleware von Windows handelt alles Weitere mit dem TCOS-Chip aus. Das sonst übliche Passwort zur Nutzung des geheimen Schlüssels aus einem PKCS#12-Container wird durch die Abfrage der NetKey-/IDKey-PIN ersetzt.

        Für andere Betriebsysteme wie z. B. Linux steht eine PKCS#11-Bibliothek zur Verfügung, die im Rahmen eines Software-Setup installiert werden kann.

        Für embedded Systeme können NetKey über speziell entwickelte Treiber integriert werden. Das Chipkartenbetriebssystem ist vollständig dokumentiert und stellt ein zu ISO 7816-4 konformes Interface bereit.

      • TCOS Card Module für den MS BaseCSP

        Mit dem Card Module steht die Funktionalität der TCOS Smartcard allen Anwendungen über die MS CryptoAPI zur Verfügung. Das heißt, E-Mail Sicherheit wie Signatur und Ver-/Entschlüsselung in Outlook oder die Signatur ab Microsoft Word 2003 sind damit Basisbestandteile. Wenn durch den Webseitenbetreiber vorgesehen, kann Smartcard-Login und damit mehr Sicherheit für Anwender und Betreiber genutzt werden.

        Windows-Logon lässt sich in verschiedenen Arten realisieren, je nachdem ob ihr System in einer Windows-Domäne eingebunden ist oder nicht.

         

        PKCS#11

        Das PKCS#11 SDK bietet die Möglichkeit, einfach höhere Datensicherheit zu integrieren. So z.B. in Lotus Notes oder Mozilla für E-Mail-Signatur und Ver-/Entschlüsselung für mehr Sicherheit und Vertrauen beim allgemeinen E-Mail Austausch.

        Weitere Anwendungen sind der evidian SSO-Client, cryptovision, (utimaco und pgp sind in Planung).

      • Windows:

        TCOS Card Module zur Netkey-/IDKey-Applikation mit dem MS BaseCSP für Windows 2000 und XP (mit MSDN Software Update 909520 für MS BaseCSP: http://support.microsoft.com/kb/909520/de).

        Unter Windows XP ist der BaseCSP bereits Bestandteil des SP 1 und unterstützt auch die sichere PIN-Eingabe über ein PIN-Pad am Kartenleser.

        PKCS#11 SDK zur Integration der SigG-Applikation (für qualifizierte Signaturen), Netkey-Applikation (für fortgeschrittene Signaturen, Entschlüsselung und Authentifikation) und ein ELSTER Modul*) für die ELSTER-Steuersoftware.

        *) nur wenn der Zertifikatsaussteller ELSTER zugelassen ist

         

        Linux:

        Für einen einfachen Zugriff auf die Kartenfunktionalität wird für LINUX (SO-File) und OpenBSD das PKCS#11 SDK zur Verfügung gestellt.

         

        MacOS:

        Für einen einfachen Zugriff auf die Kartenfunktionalität wird für MacOS ab 10.x das PKCS#11 SDK zur Verfügung gestellt.

      • Gängige moderne Computerbetriebssysteme stellen Schnittstellen und Middleware für die Anschaltung und Ansteuerung von Chipkartenlesern zur Verfügung. Für die Benutzung des NetKey / IDKey benötigen Sie einen geeigneten Chipkartenleser, der über diese Middleware die Verbindung zwischen den Kontakten der NetKey-/IDKey-Smartcard und dem Betriebssystem Ihres Rechners herstellt.

      • Für Testzwecke wird für den TCOS Cardmanager ein PlugIn zur Verfügung gestellt, mit dem selbstsignierte Test-Zertifikate generiert und auf die auf die Karte geschrieben werden können. Hierzu muss zusätzlich die OpenSource-Bibliothek OpenSSL installiert werden.

        Das Plugin unterstützt nur Netkey 3.0 und IDKey TCOS 3.0 Smartcards. Diese Zertifikate verwenden nicht die bei der Produktion auf den TCOS 3.0 Smartcards vorpersonalisierten Schlüsselpaare. Für diese Zertifikate existierert keine vertrauenwürdige Root oder nicht die Möglichkeit zur Zertifikatsprüfung (LDAP/OCSP). Aus diesem Grund können in einigen Anwendungen diese selbstgenerierten Zertifikate nur eingeschränkt genutzt werden. Wir empfehlen immer hochwertige Zertifikate von einer entsprechenden CA mit einer vertrauenwürdigen Root und Verzeichnisdiensten zur Überpfüfung der Vertrauenswürdigkeit und Gültigkeit der Zertifikate zu verwenden.

      • Dies ist die Aufgabe von Identitätsmanagement-Systemen. Hier wird die Sammlung der Attribute verwaltet und bestimmten Identitäten zugeordnet. In der Regel kann die Zuordnung von Identitätsmerkmalen in Abwesenheit der Person oder des Systems erfolgen.

        Systeme und Anwendungen, die eine Nutzung aufgrund der Präsentation von Attributen anbieten, erhalten diese direkt vom Identitätsmanagement-Service. Die Berechtigung zur Nutzung eines Attributs weist der berechtigte Inhaber mit seinem NetKey / IDKey nach.

      • Im Leben und/oder im Beruf sind Personen in der Regel mehreren Rollen mit unterschiedlichen Aufgaben und Berechtigungen zugeordnet. Zur Wahrnehmung der Aufgaben und Berechtigungen ist jeweils ein Nachweis der rechtmäßigen Zuordnung erforderlich. Hierzu erhält die Person z.B. zu jeder Rolle ein separates Zertifikat oder es existiert ein Rollen- und Rechteverwaltungssystem, welches die Berechtigungen auf Basis eines übergeordneten Zertifikats verwaltet. Somit muss die Person entweder nachweisen, dass sie zum jeweiligen Zertifikat den richtigen Secret Key besitzt oder am Rollen- und Rechteverwaltungssystem nachweisen, dass sie die richtige Person zur jeweiligen Rolle ist. Hierbei wird dann wiederum verlangt, den richtigen geheimen Schlüssel zum übergeordneten Zertifikat verwenden zu können.

      • Da der NetKey / IDKey lediglich nachweist, dass der Inhaber eine Rolle mit dem zugehörigen Zertifikat benutzen darf, muss auf allen Rechnersystemen, an denen die Person ihre Rolle wahrnehmen soll, das Zertifikat zur Rolle installiert oder im Zugriff sein. Die Smartcard wird nur jeweils zur Autorisierung von Aktionen im Zusammenspiel mit dem Zertifikat benötigt. Aufgrund der Zwei-Faktor-Sicherheit des NetKey muss dieser für den mobilen Einsatz mitgeführt werden und bleibt somit unter der Kontrolle des Inhabers.

      • Die Anzahl möglicher Rollen wird durch TeleSec NetKey / IDKey nicht beschränkt. Überall dort, wo Identitätsdaten mit dem öffentlichen Schlüssel des NetKey / IDKey in Verbindung gebracht werden, lässt sich diese Verbindung mittels des NetKey rechtmäßig nutzen.

      • Zertifikate sind Bestandteil sogenannter Public Key Infrastrukturen und Services. Ein elementarer Bestandteil einer PKI ist der Directory Service. Eine Hauptaufgabe von Directory Services ist die Verbreitung und Verteilung von Zertifikaten.

        Systeme und Anwendungen können über standardisierte Protokolle Zertifikate am Directory Service abfragen.

        Darüber hinaus können Zertifikate durch die Inhaber selbst verteilt werden.

        Die Validierungsdienste einer PKI ermöglichen jederzeit eine Gültigkeitsprüfung von Zertifikaten mittels standardisierter Protokolle.

      • Die tatsächliche Identität eines NetKey-/IDKey-Inhabers kann durch die Wahl der Attribute während der Registrierung für die Ausstellung eines Zertifikates erreicht werden.

        Nach der Vorlage der Identifizierungsdaten gegenüber dem Zertifizierungsdienst wird ein pseudonymes Attribut als Zertifikatsinhaber eingetragen.

        Im Rahmen eines Streitfalles kann die tatsächliche Identität hinter dem Pseudonym reproduziert werden.

        Die Voraussetzungen für eine Reproduktion ergeben sich aus den Grundsätzen des Zertifizierungsdienstes und ggf. aus gesetzlichen Anforderungen.

        Es entsteht eine pseudonyme Rolle.

      • Bei Public Key Systemen werden die Identitätsmerkmale üblicherweise in Form von Zertifikaten mit dem öffentlichen Schlüssel zusammen versiegelt. Das Gegenstück, der geheime kryptografische Schlüssel, befindet sich in sicherer Verwahrung durch die Karte.

        Das Betriebssystem der Smartcard verhindert einerseits, dass der Schlüssel aus der Karte gelesen und damit kopiert werden kann. Die Hauptaufgabe der Karte besteht andererseits in der Abwicklung des kryptografischen Rechenprozesses unter Anwendung des geheimen Schlüssels. Um diese Leistungen auf eine Person oder ein System zu beschränken, erwartet die Karte vor der Nutzung die Präsentation eines gültigen individuellen Passwortes (PIN) durch die Person oder Komponente. Das Betriebssystem der Smartcard legt mit der Initialisierung und Codierung der Karte fest, welche Aktionen der Karte PIN-geschützt sein sollen. So ist es z.B. möglich, Bereiche so zu kodieren, dass sie nur nach PIN-Prüfung gelesen werden können.

        Damit entstehen „abgestufte Geheimnisse“, die entsprechend den Anforderungen der geschützten Systeme preisgegeben oder angewendet werden können. Einmal ist es das Rechnerpasswort, welches nach PIN-Prüfung durch eine Chipkarte übergeben wird. In einem anderen Fall wird ein digitales Zertifikat erwartet, welches den Inhaber als Bürger eines Staates oder als Mitarbeiter einer Firma oder Institution ausweist. Im ersten Fall liefert die Karte das Passwort nach PIN-Prüfung. Im zweiten Fall erwartet das geschützte System den Nachweis, dass der Karteninhaber das präsentierte Zertifikat benutzen darf. Hierzu wird der Karte ein zufälliger Wert zur Verschlüsselung mit dem internen geheimen kryptografischen Schlüssel übergeben. Kann das Ergebnis nach der Entschlüsselung mit dem öffentlichen Schlüssel aus dem Zertifikat positiv verglichen werden, passt die Karte zum Zertifikat.

        Da vor der Aktion die PIN abgefragt wurde, kann und muss davon ausgegangen werden, dass der Karteninhaber die gewünschte Person oder das vorgegebene System ist.

      • Der TeleSec NetKey / IDKey beinhaltet verschiedene Applikationen für symmetrische Authentifikationen. Insbesondere die Applikation OTP soll hier näher erläutert werden. Es handelt sich um eine Anwendung zur Erzeugung von dynamischen Einmallpasswörtern.

        Im Rahmen der Trust Center Dienstleistungen bietet die Telekom den Service OneTimePass an. Dieser kann vom NetKey / IDKey erzeugte Einmalpasswörter auf Korrektheit prüfen. Die Anbindung von Kundensystemen an OneTimePass erfolgt über die Standardprotokolle RADIUS und SOAP.

        Die vollständigen Informationen finden Sie unter: OneTimePass

        Zwei weitere Applikationen, ZTRT und GLAZ beinhalten ebenso symmetrischen Schlüssel zu denen das Trust Center den Schlüssel ebenfalls kennt. Diese werden nur zur Vollständigkeit hier aufgeführt, sind jedoch meist für Einzelanwender uninteressant.

      • Der Einsatz moderner Informations- und Kommunikationstechnologien ermöglicht eine sehr weit gehende Prozessoptimierung in weiten Teilen des gesellschaftlichen und geschäftlichen Zusammenlebens.

        Viele Bereiche des täglichen Lebens erfordern, dass sich der Mensch zu entfernten Orten bewegt, um mit anderen Menschen oder Institutionen Transaktionen abzuwickeln oder Verträge zu schließen.

        Der Einsatz der vorgenannten Informations- und Kommunikationstechnologien ermöglicht theoretisch die Fernabwicklung solcher Transaktionen. Auf den zweiten Blick scheitert diese Möglichkeit jedoch schnell an der Notwendigkeit, die Beteiligten sicher zu identifizieren.

        Eine Vor-Ort-Prüfung der Identität mittels z. B. eines Abgleichens gegenüber einem Personalausweis ist dabei aufgrund der räumlichen Trennung meist nicht möglich. Diese Feststellung macht den Bedarf an digitalen Identitäten deutlich. Bedingt durch die nicht vorhandene persönliche Präsenz müssen technische Alternativen geschaffen werden, die das Zusammenwirken auf die Ferne gegebenenfalls auch global verbindlich und nachprüfbar machen.

        Geeignete digitale Identitäten

        In den letzten Jahren haben sich weltweit einheitliche Verfahren etabliert, die digitale Identitäten zum Beispiel in Form von Zertifikaten erzeugen und verwalten. Ein Zertifikat ist eine elektronische Sammlung von Identitätsmerkmalen wie Name, Anschrift, Geburtsdaten.

        International existieren verschiedene Institutionen, die die Glaubwürdigkeit solcher Zertifikate besiegeln. Unter dem Oberbegriff Trust Center bestätigen diese Stellen, dass die Identitätsmerkmale auf den Nutzer zutreffen. Hierzu wird entweder durch die Trust Center selbst oder durch von ihnen anerkannte Registrierungsstellen ein Abgleich gegen ein physikalisches Ausweisdokument vorgenommen.

        Grundprinzip

        Das zu Grunde liegende Prinzip ist meist ein so genanntes Public Key Verfahren. Hierbei werden für alle Beteiligten Schlüsselpaare erzeugt von denen ein Teil zum öffentlichen Schlüssel erklärt wird. Der zweite, geheime Teil sollte idealerweise so sicher aufbewahrt werden dass er nicht kopiert und somit die Anwendung des Schlüssels kontrolliert werden kann. Der erste Teil des Schlüssel ermöglicht wiederum die Prüfung, ob der geheime Schlüssel, wie behauptet, auf bestimmte Informationen angewendet wurde. Der öffentliche Schlüssel kann im einfachsten Fall zusammen mit dem Namen oder als Alias des Inhabers als digitale Identität verteilt werden.

        Zusammenfassung

        Mit den TCOS Smartcards erhalten Sie besonders hochwertige digitalen Schlüssel, die es Ihnen ermöglichen, sich gegen viele Ärgernisse des Internet zu schützen und gleichzeitig Ihre Präsenz in der „virtuellen Welt“ aufzuwerten. Und diese Möglichkeiten liegen, im wörtlichen Sinne, alleine in Ihrer Hand! Sie erhalten eine Chipkarte, wie Sie sie aus vielen Anwendungen wie der Krankenversichertenkarte oder der Geldkarte kennen. Bei TCOS Smartcards handelt es sich um speziell für Sicherheitsanwendungen entwickelte Chipkarten. Im Chip dieser Karten werden im Herstellungsprozess nach modernsten Erkenntnissen erzeugte geheime Schlüssel abgelegt. Von diesen Schlüsseln existieren keine Kopien und es ist nach dem Stand der Technik unmöglich, die Schlüssel aus der Karte auszulesen.

        Zur Anwendung kommen diese Schlüssel nur, wenn der Karte gegenüber das gültige Passwort, im üblichen Sprachgebrauch die PIN, präsentiert wird. Die Anwendung geheimer Schlüssel ermöglicht die eindeutige Zuordnung von Aktionen zu einer Person oder einem System, für welche die Chipkarte registriert wurde.

        TCOS Smartcards ermöglichen darüber hinaus einen vertraulichen Informationsaustausch oder verschlüsselte Datenablage. Alle Daten, die unter Zuhilfenahme öffentlicher Schlüssel aus einer TCOS Smartcard verschlüsselt wurden, lassen sich nur mit dem zugehörigen geheimen Schlüssel, also einer TCOS Smartcard wieder entschlüsseln.

      • Die Zuordnung einer Aktion zu einer bestimmten Person oder einem bestimmten System (Identität) erfolgt meist in zwei Schritten. Zunächst behauptet der Verursacher einer Aktion, eine bestimmte Identität zu besitzen und die Aktion ausführen zu dürfen (Identifizierung). Im zweiten Schritt wird überprüft, ob die Aktion tatsächlich dieser Identität zugeordnet werden kann (Authentifizierung).

        Identifizierung

        Die oben genannten Funktionen basieren auf der Nutzung bestimmter digitaler Identitätsmerkmale. An verschiedenen Systemen werden gegebenenfalls unterschiedliche Identitätsmerkmale verlangt. Diese unterschiedlichen Identitätsmerkmale (Attribute) präsentieren die verschieden Rollen, in denen der Inhaber unterwegs ist. So ist ein Mensch in der Regel ein Bürger mit Namen, Vornamen und Geburtsdatum. In einer anderen Rolle Mitarbeiter eines Unternehmens oder Prokurist desselben, in der Freizeit engagiert als Vorsitzender eines Vereins oder ehrenamtlich in einer anderen gesellschaftlichen Rolle. Je nach Rolle kommen Attribute hinzu, die allein oder in Kombination mit dem Namen Verwendung finden können. Im englischen Sprachgebrauch werden solche Attribute auch als Claims bezeichnet.

        Eine geeignete Form für die Zusammenfassung solcher Identitätsmerkmale stellt z.B. ein X.509 Zertifikat dar. Hier werden diese Identitätsmerkmale zusammen mit dem öffentlichen Teil eines kryptografischen Schlüssels derart versiegelt, dass wiederum durch Anwendung des öffentlichen Teils des Siegelschlüssels das Siegel geprüft werden kann. Der öffentliche Teil des Benutzer-Schlüssels wird dadurch zu einem weiteren, einem digitalen Identitätsmerkmal des Zertifikatsinhabers. Technisch gibt es verschiedene Möglichkeiten, digitale Identitätsmerkmale geeignet zusammenzufassen. So kann z.B. ein authentischer Server ebenfalls eine Zusammenfassung von Identitätsmerkmalen präsentieren. Zur Vereinfachung der Betrachtung nutzen wir an der Stelle nur die Variante der X.509 Zertifikate.

        Geht es nun um die Identifizierung einer Person oder einer technischen Komponente, weisen sich diese mittels eines Zertifikats aus. Die Prüfinstanz kann hierbei jedoch bis jetzt nur feststellen, ob es sich um ein gültiges Zertifikat handelt. Damit ist nur nachgewiesen, dass die Person oder Komponente existiert. Das heißt, eine Zertifizierungsinstanz hat das Vorhandensein der Person oder Komponente und damit die Identitätsmerkmale überprüft und das Zertifikat gültig erzeugt.

        Authentifizierung

        Eine TCOS Smartcard mit ihren hochwertigen Schlüsseln gibt dem Inhaber die Möglichkeit sich auszuweisen. Die Karte weist nach, dass präsentierte Identitätsmerkmale, die die jeweilige Rolle widerspiegeln, benutzt werden dürfen. Der Beweis entsteht durch die technische Verknüpfung von Identitätsmerkmalen und dem Nachweis eines Geheimnisses. Hier bieten TCOS Smartcards verschiedene Applikationen, die je nach Einsatzgebiet Verwendung finden können.

        Symmetrische Authentifizierung

        TCOS Smartcards beinhalten je nach Produkt verschiedene Applikationen für symmetrische Authentifikationen. Insbesondere die Applikation OTP soll hier näher erläutert werden.

        Es handelt sich um eine Anwendung zur Erzeugung von dynamischen Einmalpasswörtern. Im Rahmen der Trust Center Dienstleistungen bietet die Telekom Security den Service OneTimePass an. Dieser kann von TCOS Smartcards erzeugte Einmalpasswörter auf Korrektheit prüfen. Die Anbindung von Kundensystemen an OneTimePass erfolgt über die Standardprotokolle RADIUS und SOAP.

        Die vollständigen Informationen finden Sie unter: OneTimePass

        Zwei weitere Applikationen, ZTRT und GLAZ, beinhalten ebenso symmetrischen Schlüssel, zu denen das Trust Center den Schlüssel ebenfalls kennt. Diese werden nur zu Vollständigkeit hier aufgeführt, sind jedoch meist für Einzelanwender uninteressant.

        Asymmetrische Authentifizierung mittels Public Key

        Bei Public Key Systemen werden die Identitätsmerkmale üblicherweise in Form von Zertifikaten mit dem öffentlichen Schlüssel zusammen versiegelt. Das Gegenstück, der geheime kryptografische Schlüssel, befindet sich in sicherer Verwahrung durch die Karte. Das Betriebssystem der Chipkarte verhindert einerseits, dass der Schlüssel aus der Karte gelesen und damit kopiert werden kann. Die Hauptaufgabe der Karte besteht andererseits in der Abwicklung des kryptografischen Rechenprozesses unter Anwendung des geheimen Schlüssels.

        Um diese Leistungen auf eine Person oder ein System zu beschränken, erwartet die Karte vor der Nutzung die Präsentation eines gültigen individuellen Passwortes (PIN) durch die Person oder Komponente.

        Das Betriebssystem der Chipkarte legt mit der Initialisierung und Codierung der Karte fest, welche Aktionen der Karte PIN-geschützt sein sollen. So ist es z.B. möglich, Bereiche so zu kodieren, dass sie nur nach PIN-Prüfung gelesen werden können. Damit entstehen „abgestufte Geheimnisse“, die entsprechend den Anforderungen der geschützten Systeme preisgegeben oder angewendet werden können.

        Einmal ist es das Rechnerpasswort, welches nach PIN-Prüfung durch eine Chipkarte übergeben wird. In einem anderen Fall wird ein digitales Zertifikat erwartet, welches den Inhaber als Bürger eines Staates oder als Mitarbeiter einer Firma oder Institution ausweist.

        Im ersten Fall liefert die Karte das Passwort nach PIN-Prüfung. Im zweiten Fall erwartet das geschützte System den Nachweis, dass der Karteninhaber das präsentierte Zertifikat benutzen darf. Hierzu wird der Karte ein zufälliger Wert zur Verschlüsselung mit dem internen geheimen kryptografischen Schlüssel übergeben. Kann das Ergebnis nach Entschlüsselung mit dem öffentlichen Schlüssel aus dem Zertifikat positiv verglichen werden, passt die Karte zum Zertifikat.

        Da vor der Aktion die PIN abgefragt wurde, kann und muss davon ausgegangen werden, dass der Karteninhaber die gewünschte Person oder das vorgegebene System ist.

         

      • Wie bereits beschrieben, liegen den TCOS Smartcards Kenntnisse modernster Verschlüsselungstechnik (Kryptologie) zugrunde. Verschlüsselung wird immer dann benötigt, wenn es darum geht, Informationen vor unberechtigtem Lesen oder Verarbeiten zu schützen.

        Dazu wird zwischen einem Autor oder Absender einer Nachricht (A) und dem Verarbeiter oder Empfänger (B) ein Schlüssel ausgetauscht. Damit ist es A möglich, die Information so zu verschlüsseln, dass nur B sie wieder lesen oder verarbeiten kann.

        Möchte man nun in einer größeren Gruppe von Teilnehmern Daten so austauschen, dass jeder mit jedem so verschlüsselt kommuniziert, dass kein Dritter mitlesen kann, wird das notwendige Schlüsselmanagement schnell sehr aufwendig. So genannte Public Key Kryptologie vereinfacht das Schlüsselmanagement sehr stark. Jeder Teilnehmer benötigt genau ein Schlüsselpaar bestehend aus einem öffentlichen (public) Schlüssel und einem geheimen (secret) Schlüssel.

        Öffentliche Schlüssel können über öffentliche Verzeichnisse verteilt werden. Somit ist es möglich, jedem Teilnehmer aus dem Verzeichnis Informationen vertraulich zukommen zu lassen. Dazu sind diese Informationen lediglich mithilfe des öffentlichen Schlüssels zu verschlüsseln. Nur der Inhaber des zugehörigen geheimen Schlüssels kann die Klardaten wieder reproduzieren.

        Bei verschlüsselter Datenablage kann z.B. der Autor selbst seine Daten mit seinem eigenen öffentlichen Schlüssel verschlüsselt ablegen. Damit sind diese Daten vor dem Zugriff durch Dritte geschützt.

      • Die TCOS Smartcards der Telekom Security bestehen aus zwei entscheidenden Komponenten, deren Qualität die Alleinstellung der TCOS Smartcards ausmachen: die Qualität des Betriebssystems und die Qualität der internen Schlüssel.

        Die Qualität des Betriebssystems

        TCOS Smartcards basieren auf dem TeleSec Chipcard Operating System (TCOS), welches seit vielen Jahren unter ständiger Begleitung durch neutrale Sicherheitsevaluatoren entwickelt und gepflegt wird.

        So bildet TCOS zum Beispiel die Basis für die qualifizierten Signaturkarten der Deutschen Telekom AG oder auch für den Chip im deutschen Reisepass oder dem neuen deutschen Personalausweis.

        Dies sind nur zwei Beispiele in denen TCOS die jeweils notwendige Qualitäts- und Vertrauensstufe erreicht hat.

        Die Qualität der internen Schlüssel

        Die Generierung der Schlüssel für TCOS Smartcards erfolgt innerhalb des Trust Centers der Telekom Security. Ausgesuchte TCOS Smartcards, wie die TCOS 3.0 Signature Card, enthalten eine gesonderte Applikation (SigG), die als sogenannte Sichere Signatur Erstellungseinheit (SSEE) nach dem deutschen Signaturgesetz evaluiert und bestätigt ist. Das Schlüsselmaterial dieser Applikation stammt von einem ebenfalls evaluierten und bestätigten Schlüsselgenerator. Diese Bestätigung stellt sicher, dass die Schlüssel eines Generators nur in geeignete TCOS Module geschrieben werden können. Diese SSEE kann somit im Zusammenspiel mit einem geeigneten Zertifizierungsdiensteanbieter für qualifizierte elektronische Signatur eingesetzt werden.

        Andere Applikationen beinhalten ggf. mehrere ebenfalls im Trust Center erzeugte asymmetrische Schlüssel, die von einem technologisch gleichen Schlüsselgenerator erzeugt wurden. Diese Schlüssel erfüllen die Bedingungen für sogenannte fortgeschrittene Zertifikate.

      • Gängige moderne Computerbetriebssysteme stellen Schnittstellen und Middleware für die Anschaltung und Ansteuerung von Chipkartenlesern zur Verfügung. Für die Benutzung von TCOS Smartcards benötigen Sie einen geeigneten Chipkartenleser, der über solche Middleware die Verbindung zwischen den Kontakten der Chipkarte oder der Funkantenne und dem Betriebssystem Ihres Rechners herstellt.

      • Für Testzwecke wird für den TCOS CardManager ein Plug-In zur Verfügung gestellt, mit dem selbstsignierte Test-Zertifikate generiert und geeignete Karten geschrieben werden können. Hierzu muss zusätzlich die OpenSource-Bibliothek OpenSSL installiert werden. Das Plug-In unterstützt nur TeleSec Netkey 3.0 und TeleSec IDKey Smartcards. Diese Zertifikate verwenden nicht die bei der Produktion auf den TCOS Smartcards vorinstallierten Schlüsselpaare. Für diese Zertifikate existiert keine vertrauenwürdige Root oder nicht die Möglichkeit zur standardisierten Zertifikatsprüfung (LDAP/OCSP). Aus diesem Grund können in einigen Anwendungen diese selbstgenerierten Zertifikate nur eingeschränkt genutzt werden. Wir empfehlen immer hochwertige Zertifikate von einer entsprechenden CA mit einer vertrauenswürdigen Root und Verzeichnisdiensten zur Überprüfung der Vertrauenswürdigkeit und Gültigkeit der Zertifikate zu verwenden.