Sprache:

Personenzertifikate

Sie haben Fragen zu unseren Personenzertifikaten? Wir helfen Ihnen gerne. Informieren Sie sich in unserem FAQ-Bereich oder nehmen Sie direkt Kontakt mit unserem Support-Team auf.

Allgemeines

Die Baseline Requirements sind Vorgaben die sicherstellen sollen, dass ein dort festgelegter Sicherheitsstandard für die Ausgabe von vertrauenswürdigen Zertifikaten eingehalten wird.

Als Operator muss man sicherstellen, dass vor Zertifikatsproduktion eine Domain-Validierung erfolgreich durchgeführt worden ist. Weiteres, muss vor dem Bezug von Personenzertifikaten auch die Operatorenschulung (ExtIdent-Schulung) absolviert werden.

Nein, Sie können diese bis zum regulären Enddatum uneingeschränkt nutzen.

Nein, bereits ausgestellte Zertifikate behalten ihre Gültigkeit und müssen nicht vorzeitig gesperrt werden.

Nein, sollten Sie aktuell keine Personenzertifikate beziehen und dies auch in Zukunft planen, besteht für Sie kein Handlungsbedarf.

Wir empfehlen Ihnen das Folgezertifikat entsprechend über Reseller zu beziehen. Hier eine Liste unserer Reseller: ((ausklappbar))

 

 

 

 

Hinweis: Sollten Sie bisher ein Personenzertifikat mit einem Organisationseintrag verwenden, können wir ihnen dieses zukünftig nicht mehr zur Verfügung stellen. 

Identifizierung

Ja, in allen Fällen, auch wenn Dienstleister als technische Ansprechpartner fungieren, müssen die im Zertifikat genannten Personen von einem CSM-Operator der Organisation des zu identifizierenden angehört, identifiziert werden. Für diesen Fall muss ein ExtIdent-Vertrag der Organisation mit D-Trust abgeschlossen werden, und der Identifizierungs- und Nachweisprozess dokumentiert sein.

Die Identität eines Mitarbeiters muss zweifelsfrei sichergestellt werden. Eine Identifizierung durch die Operatoren muss vor Beantragung eines Zertifikats sichergestellt und der Prozess im Unternehmen dokumentiert werden.

Hier gibt es die Möglichkeit, die Identifizierung aus dem HR-Onboarding-Prozess zu nutzen, sofern die Identifizierung nicht länger 824 Tage in der Vergangenheit stattgefunden hat.

Die Prozesse werden in einem jährlichen Audit nachgewiesen. Dieses wird in der Regel in Form eines Self-Audits durchgeführt, bei dem die Organisation einen Fragenkatalog, der von D-Trust zur Verfügung gestellt wird, beantwortet. Die beantworteten Fragen werden der D-Trust zugesandt. Davon unberührt bleibt die Möglichkeit der Durchführung von Vor-Ort oder Dokumenten-Audits durch die D-Trust oder einen externen von der D-Trust benannten Auditor.  

Zu diesem Zweck stellen wir Ihnen die jährliche Operatorenschulung zur Verfügung. In dieser Operatorenschulung finden Sie Antworten auf diese und weitere Fragen.

Wir helfen gerne weiter. Melden Sie sich bei csm@d-trust.net um mehr über die zulässigen Identifizierungsverfahren zu erfahren.

Sämtliche Informationen zu den Identifizierungsprozessen müssen von der Organisation gespeichert und in auditierbarer Form vorgehalten werden.

Die Daten müssen durch Kunden und Kundinnen erfasst und aufbewahrt werden. Eine Übermittlung an D-Trust oder Speicherung im CSM ist nicht notwendig. Die Daten müssen für Auditzwecke während des Aufbewahrungszeitraums jederzeit für D-Trust zugänglich gemacht werden können.

Ja.

Domain Validierung

Ab den 01.09.2023 ist der Nachweis einer Domainkontrolle verpflichtend. Das gilt auch für bereits existierende Domains und nur für Personenzertifikate mit Organisationseintrag.

Nein, die Kontrolle wird für die Domain nachgewiesen und ist produktunabhängig.
Zusatzinfo: Ein Folgezertifikat kann bezogen werden, solange die Domain nachgewiesen wird.

Bei der erweiterten Domänenprüfung weisen Sie als Kunde nach, dass Sie die Kontrolle über die im Zertifikatsantrag verwendete Internet-Domäne haben. Dieser Nachweis erfolgt mit technischer Unterstützung über dafür zugelassene Methoden – z.B. über Validierungsmails auf autorisierte Mailadressen oder Änderungen im DNS-Eintrag der jeweiligen Domäne.Der Nachweis der Domänenkontrolle muss jährlich wiederholt werden und ist automatisierbar.

Nein. Die VS-NfD Enterprise ID unterliegt nicht den Anforderungen der S/MIME Baseline Requirements. Hier ändert sich nichts an der bisherigen Prüfpraxis.

Ja. Die Domain-Prüfung muss für jede Organisation durchgeführt und sichergestellt werden, auch wenn nur eine Domain für alle Organisationen genutzt wird, muss eine erweiterte Prüfung für alle Organisationen durchgeführt werden. Diese Prüfung wird immer durch die D-Trust durchgeführt.

Für die Domain-Prüfung gibt es folgende 6 Verfahren:

  1. Bestätigung durch den Domain Kontakt (3.2.2.4.2)

Wir schicken das Geheimnis an den Domain Kontakt der sich aus den Who is Daten ergibt. Hierbei sind wir oftmals auf die Mithilfe des Kunden angewiesen, da diese Daten wie zum Beispiel bei der Denic in Deutschland, nicht mehr offen einsehbar sind. Das Geheimnis muss dann an die in der E-Mail genannte Adresse zurückgeschickt werden.

  1. Bestätigung durch angenommene Adressen des Domain Contacts (3.2.2.4.4)

Wir schicken eine E-Mail mit Geheimnis an 5 angenommene Mailadressen: hostmaster@domain, postmaster@domain, webmaster@, admin@ und administrator@. Sobald das Geheimnis an die in der E-Mail hinterlegten Adresse zurückkommt, gilt die Domain als validiert. Dabei spielt es keine Rolle von welcher E-Mailadresse das Geheimnis zurück kommt.

  1. Änderung des DNS Eintrags (3.2.2.4.7)

Wir schicken eine E-Mail mit Geheimnis an eine beliebige – vom Ihnen genannte – E-Mailadresse. Dieses Geheimnis muss dann, genau in dem von uns gesendeten Format in den DNS der Domain eingetragen werden. Hinweis: Es kann etwas dauern, bis unser System den neuen DNS Eintrag auslesen kann, da die Aktualisierungszeit vom Server abhängig ist.

  1. Prüfung von „DNS CAA E-Mail Kontakt“ Kontrolle über die Domain ausübt (3.2.2.4.13)

Unser System prüft, ob im Feld „DNS CAA E-Mail-Kontakt“ eine E-Mailadresse hinterlegt ist. Ist dies der Fall, können wir das Geheimnis an diese Adresse versenden. Das Geheimnis muss dann an die in der E-Mail genannte Adresse zurückgeschickt werden.

  1. Prüfung ob „DNS TXT Kontakt“ Kontrolle über die Domain ausübt (3.2.2.4.14)

Unser System prüft, ob im Feld „DNS CAA E-Mail-Kontakt“ eine E-Mailadresse hinterlegt ist. Ist dies der Fall, können wir das Geheimnis an diese Adresse versenden. Das Geheimnis muss dann an die in der E-Mail genannte Adresse zurückgeschickt werden.

  1. Vereinbarte Änderung der Webseite (3.2.2.4.18)

(Methode war vorher unter der 3.2.2.4.6 bekannt, wurde dann aber technisch überarbeitet.) Wir schicken das Geheimnis an eine beliebige – von Ihnen genannte – E-Mailadresse. Die E-Mail beinhaltet einen Pfad, auf dem das Geheimnis anschließend auf der Webseite hinterlegt werden muss. Wichtig: Mit dieser Methode kann nur die eingetragene Domain validiert werden und keine Subdomains.

Schulung

Sie erhalten innerhalb von 30 Tagen zwei weitere Schulungserinnerungen per E-Mail. Sollten Sie diese nicht wahrnehmen, dann wenden Sie sich bitte umgehend an csm-extident.elearning@d-trust.net.
Hinweis: Nach Ablauf der 30-Tage-Frist ohne Schulung, darf die Ident- und Operatorentätigkeit nicht mehr ausgeübt werden.

Bei allen Produkten, die Personennamen im Zertifikat haben, ist eine ExtIdent-Schulung notwendig.

Technische Änderungen

Der SAN RFC822-Name (Mail) bleibt erhalten. Zusätzlich kann die Subject E-Mail optional befüllt werden.

Nein. Ein OU-Feld für Standardprodukte gibt es nicht mehr. 
 

Ja, das ist korrekt. Es können nur prüfbare Unterorganisation eingetragen werden.

Subject E-Mail und RFC822-Name müssen übereinstimmen und werden abgeglichen. Sie dürfen also nicht voneinander abweichen.

Nicht mehr benötigte Felder werden an der Schnittstelle ignoriert und nur die relevanten Felder geprüft. Der Principal Name muss in der Anfrage enthalten sein. 

Es muss immer ein Operator der Organisation, die in den Zertifikaten genannt wird, benannt, geschult und durch D-Trust identifiziert werden.  Für jede Person, die in einem Zertifikat genannt wird, ist eine entsprechende Identifikation durchzuführen.

Als Voraussetzung für die Ausstellung von Zertifikaten mit Organisationseintrag ist ein Org-Identifier verpflichtend. Dieser wird seitens der D-Trust eingetragen. Hierbei handelt es sich um eine eindeutige Kennung einer Organisation, die an internationale Standards angelehnt ist.

Die vorgegebenen Anforderungen müssen immer erfüllt werden, unabhängig vom Bestellweg.

CA Rollover

Für S/MIME-Zertifikate (Personenzertifikate)

Aufgrund regulatorischer Erfordernisse müssen wir Anpassungen an unserer aktuellen „Issuing CA“ (Certificate Authority) vornehmen.

Hintergrund ist zum einen die regulatorisch notwendige Ergänzung um CA/B Forum spezifische OID-Werte innerhalb der CA bis spätestens 14.09.2024 sowie die Notwendigkeit, Advanced RSA-Zertifikate mit Schlüssellängen von 2048 Bit perspektivisch abzukündigen.

Für TLS/SSL-Zertifikate (Serverzertifikate)

Hintergrund ist die regulatorische Notwendigkeit, Advanced RSA-Zertifikate mit Schlüssellängen von 2048 Bit perspektivisch abzukündigen.

Für S/MIME-Zertifikate (Personenzertifikate)

In einem zweistufigen Verfahren wird es daher Änderungen an unserer S/MIME PKI geben.

Schritt 1 (Zwischenschritt / Interims-Lösung): Geänderte Issuing CA bis vsl. Ende 2024

Alle Produkte unter der Issuing CA „D-TRUST Root CA 3 2013“ erhalten am 20.06.2024 (RU) sowie 04.07.2024 (PU) eine neue CA. Diese CA beinhaltet dann zusätzlich durch die D-Trust gesetzten OID Werte. Die Schlüssellängen von 2048 Bit bleiben vorerst erhalten. Aufgrund regulatorischer Anforderungen wird diese CA vsl. Ende 2024 keine neuen Zertifikate mehr ausstellen können und dient daher lediglich als Zwischenlösung.

Die aktuellen Produktnamen und Produktnummern behalten ihre Gültigkeit. Der Name der CA bleibt ebenso erhalten. Lediglich OID-Werte werden durch die D-Trust ergänzt.

Schritt 2 (Finale Lösung): Neue Root-und Issuing CA‘s

Parallel zu Schritt 1 wird ebenso am 20.06.2024 (RU) sowie 04.07.2024 (PU) eine neue 4k PKI verfügbar sein, die dann RSA-Zertifikate mit einer Schlüssellänge von 3072/4096 Bit ausstellt.

Die aus dieser neuen PKI ausgestellten Zertifikate beinhalten dann einen neuen Produktnamen sowie neue Produktnummern, die wir Ihnen zeitnah mitteilen. Gleichzeitig wird es auch eine EC-basierte PKI mit entsprechenden Produkten geben.

Für TLS/SSL-Zertifikate (Serverzertifikate)

Am 27.06.2024 (RU) und 11.07.2024 (PU) wird es für folgende RSA-und EC-basierten Serverzertifikate neue Root- und Issuing-CA’s geben:

  • Advanced DV SSL (EC)
  • Advanced SSL ID (RSA)
  • Advanced EV SSL ID (RSA)
  • Qualified EV SSL ID (RSA)

Parallel dazu bleiben die unterhalb der RSA-basierten Root-CA’s „D-TRUST Root Class 3 CA 2 EV 2009“ und „D-TRUST Root Class 3 CA 2 2009“ erstellten Zertifikate bis voraussichtlich 31.12.2024 weiter in Betrieb. Die bis zu diesem Datum ausgestellten Zertifikate behalten ihre Gültigkeit bis zum regulären Laufzeitende.

Für S/MIME-Zertifikate (Personenzertifikate)

Für die S/MIME Interims-Lösung (Schritt 1) sind Ihrerseits keine Anpassungen von Produktnummern bei der Schnittstellen-basierten (CMP) Beantragung notwendig. Hierbei handelt es sich um eine Stichtags-Umstellung, bei der wir im laufenden Betrieb auf die neue CA umstellen. IN DIESEM FALL ERFOLGT DEMNACH KEIN PARALLELBETRIEB. Es sollte für Sie keine Beeinträchtigungen geben.

Für Schritt 2 (die Erstellung der neuen Root-und Issuing CA’s), wird es einen Parallelbetrieb von alten und neuen Produkten geben, um einen möglichst reibungslosen Ablauf zu gewährleisten. ZU GEGEBENER ZEIT MÜSSEN IHRERSEITS ANPASSUNGEN AN PRODUKTNUMMERN BEI DER SCHNITTSTELLENBASIERTEN (CMP/ACME) BEANTRAGUNG VORGENOMMEN WERDEN

Für TLS/SSL-Zertifikate (Serverzertifikate)

Zu gegebener Zeit müssen Ihrerseits Anpassungen an Produktnummern bei der schnittstellenbasierten-Beantragung (CMP/ACME) vorgenommen werden.

Sie müssen keine Anpassung vornehmen. Die neuen Produkte werden zu gegebener Zeit unsererseits Ihrem Konto zugeordnet. Bitte haben Sie dafür noch etwas Geduld.

Sie können sich die neuen Zertifikate (Root- & CA) in unserem Repository herunterladen. Sie gelangen über folgenden Link an unser Repository.

Sie können als Alternative EC-basierte Zertifikate beantragen. Andere Alternativen (z.B. kürzere Schlüssel) gibt es nur als 3k End-Entity-Zertifikate (End-User-Zertifikate) mit einer 4-k Root.

Nein, hier gibt es bereits entsprechend längere Schlüssellängen, die die regulatorischen Anforderungen erfüllen.

Nein, PSD2-Zertifikate sind nicht von den Änderungen betroffen.

Bitte beachten Sie, dass Apple unsere neuen Root-CA‘s noch nicht abschließend in ihren Browsern hinterlegt bzw. integriert hat. Wir erwarten, dass dies im Laufe des Herbst 2024 erfolgen wird. Bis dahin bedeutet dies, dass die aus der neuen Root ausgestellten Zertifikate bei Apple ggf. als nicht vertrauenswürdig angezeigt werden.

Wir empfehlen daher, so lange wie möglich die alte CA mit neuen OID-Werten zu nutzen.

Es kann im Zusammenhang mit den erhöhten Schlüssellängen (3k / 4k) zu speicherplatzbasierten Problemen bei Personenzertifikaten, die auf physische Karten importiert wurden, kommen. Sollte Sie dies betreffen, testen Sie Ihrerseits bitte schnellstmöglich, ob es für Ihren Anwendungsfall zu den hier vermuteten Problemen kommt.  

Sie haben noch Fragen?

Piktogramm für Support
D-Trust
Support
+49 (0) 30 2598 – 0
Anrufen
E-Mail schreiben
Support D-Trust Frame
Bestellung Ihrer Personen-Zertifikate

Sie möchten eines unserer D-Trust Zertifikatsprodukte bestellen? Dann sind Sie hier richtig!

Zum Bestellen
Support D-Trust Frame
Haben Sie Fragen zu unseren Produkten?

In unserem Service Portal finden Sie Hilfe bei technischen Problemen, Informationen über Voraussetzungen und Anwendungsmöglichkeiten unserer Lösungen sowie unseren Dokumentationen und Preislisten. Wir helfen Ihnen weiter.

Zu unserem Service