Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung		 Vorhergehende Überarbeitung
de:dfnpki:tcs:usercert [2023/11/03 15:04] – [Auswahl des "Key protection Algorithms" in Formularen für .p12-Dateien] Reimer Karlsen-Masurde:dfnpki:tcs:usercert [2024/04/24 15:55] (aktuell) – [Gruppenzertifikate] Internen Link korrigiert Reimer Karlsen-Masur
Zeile 1: Zeile 1:
-=====Nutzerzertifikate=====+=====Client-Zertifikate=====
  
-**Achtung: Seit 28.08.23 ist aufgrund der Umstellung auf neue Richtlinien ("S/MIME-BRs") +====Verfügbare Typen von Client-Zertifikaten=====
-die Erstellung von Nutzerzertifikaten gestört. Einrichtungen werden schrittweise wieder in den Dienst eingebunden.** +
- +
-====Verfügbare Typen von Nutzerzertifikaten=====+
  
 Es stehen verschiedene Typen von Zertifikaten mit unterschiedlichen Eigenschaften zur Verfügung. Es stehen verschiedene Typen von Zertifikaten mit unterschiedlichen Eigenschaften zur Verfügung.
 +
 +**Achtung:** Bei allen Zertifikattypen kann sich der Subject-DN von neu ausgestellten Zertifikaten unvermittelt ändern, wenn Sectigo Organisationen neu validiert. Daher ist die Nutzung von TCS Client-Zertifikaten im Zusammenhang mit Client-Authentifizierung (z.B. für Portale oder VPNs) nicht empfohlen. Wählen Sie hierfür bitte eine andere PKI, z.B. die [[de:dfnpki:dfnvereincommunitypki|DFN-Verein Community-PKI]]
 +
 +
  
 ====Zertifikate für sichere E-Mail - S/MIME==== ====Zertifikate für sichere E-Mail - S/MIME====
Zeile 64: Zeile 65:
 =====Identifizierung und Dokumentation===== =====Identifizierung und Dokumentation=====
  
-Die Anforderungen an die Identifizierung und die Dokumentation für persönliche Zertifikate (client certificates, Nutzerzertifikate) sind im TCS Certification Practice Statement - Personal, eScience Personal and Document Signing Certificates festgehalten: [[https://wiki.geant.org/display/TCSNT/TCS+Repository]]+Die Anforderungen an die Identifizierung und die Dokumentation für persönliche Zertifikate (Client-Zertifikate, Nutzerzertifikate) sind im TCS Certification Practice Statement - Personal, eScience Personal and Document Signing Certificates festgehalten: [[https://wiki.geant.org/display/TCSNT/TCS+Repository]]
  
 Die dort für "TCS eScience Personal" referenzierten Anforderungen der [[https://www.igtf.net|IGTF]] finden sich im Dokument "IGTF Levels of Authentication Assurance": https://www.eugridpma.org/guidelines/authn-assurance/igtf-authn-assurance-1.1.pdf Die dort für "TCS eScience Personal" referenzierten Anforderungen der [[https://www.igtf.net|IGTF]] finden sich im Dokument "IGTF Levels of Authentication Assurance": https://www.eugridpma.org/guidelines/authn-assurance/igtf-authn-assurance-1.1.pdf
Zeile 72: Zeile 73:
   * Vor der Ausstellung eines Zertifikats soll eine persönliche  Identifizierung mit einem Lichtbildausweis oder andere gültigen offiziellen Dokumenten durchgeführt werden.   * Vor der Ausstellung eines Zertifikats soll eine persönliche  Identifizierung mit einem Lichtbildausweis oder andere gültigen offiziellen Dokumenten durchgeführt werden.
   * Alternativ ist auch eine Video-Identifizierung oder eine Identifizierung über einen Notar möglich.   * Alternativ ist auch eine Video-Identifizierung oder eine Identifizierung über einen Notar möglich.
-  * Alternativ genügt auch eine bestehende andauernde Beziehung zum Zertifikatnehmer, z.B im Rahmen eines Beschäftigungsverhältnisses, wenn hierdurch der Account im IdM (und damit der AAI) gesichert ist und zu Beginn eine Prüfung der Identität mit einem vergleichbaren Niveau, wie oben beschrieben, stattgefunden hat.+  * Alternativ genügt auch eine bestehende andauernde Beziehung zum Zertifikatnehmer, z.B. im Rahmen eines Beschäftigungsverhältnisses, wenn hierdurch der Account im IdM (und damit der AAI) gesichert ist und zu Beginn eine Prüfung der Identität mit einem vergleichbaren Niveau, wie oben beschrieben, stattgefunden hat.
  
 Im Unterschied zur DFN-PKI "Global" muss eine Identifizierung **nicht** von speziell benannten Teilnehmerservice-Mitarbeitern durchgeführt und auch **nicht** regelmäßig wiederholt werden. Eine Feststellung der Identität z.B. im Rahmen von Einstellungsprozessen reicht aus. Im Unterschied zur DFN-PKI "Global" muss eine Identifizierung **nicht** von speziell benannten Teilnehmerservice-Mitarbeitern durchgeführt und auch **nicht** regelmäßig wiederholt werden. Eine Feststellung der Identität z.B. im Rahmen von Einstellungsprozessen reicht aus.
Zeile 89: Zeile 90:
  
  
-=====Wege zur Ausstellung von Nutzerzertifikaten=====+=====Wege zur Ausstellung von Client-Zertifikaten=====
  
-Es stehen verschiedene Wege zur Verfügung, um User-Zertifikate auszustellen.+Es stehen verschiedene Wege zur Verfügung, um Client-Zertifikate auszustellen.
  
 ====E-Mail-Einladung==== ====E-Mail-Einladung====
  
-Die Erstellung von Nutzerzertifikaten mit E-Mail-Einladungen ist nach drei Vorbereitungsschritten möglich. +Die Erstellung von Client-Zertifikaten mit E-Mail-Einladungen ist nach drei Vorbereitungsschritten möglich. 
  
 1. Zunächst muss ein ''Account'' in einem ''Enrollment Form'' angelegt werden: 1. Zunächst muss ein ''Account'' in einem ''Enrollment Form'' angelegt werden:
Zeile 147: Zeile 148:
       * Die Person unterhalb von ☰->Persons mit der Checkbox vor dem Namen auswählen.       * Die Person unterhalb von ☰->Persons mit der Checkbox vor dem Namen auswählen.
       * Mit dem Button "Edit" erscheint ein weiterer Dialog, der unter dem Reiter "Enrollment Invitation" hinter Invitations wieder ein "+"-Symbol enthält, mit dem man einen Dialog zum Versenden einer E-Mail-Einladung öffnen kann.       * Mit dem Button "Edit" erscheint ein weiterer Dialog, der unter dem Reiter "Enrollment Invitation" hinter Invitations wieder ein "+"-Symbol enthält, mit dem man einen Dialog zum Versenden einer E-Mail-Einladung öffnen kann.
-      * Dabei genau den "Enrollment Endpoint" aus der Drop-Down-Liste auswählen, in dem Sie oben  den ''Account'' angelegt haben und dann eben diesen angelegten Account auswählen. **Hinweis:** Die Liste der angezeigten Enrollment Endpoints umfasst zur Zeit leider auch fremde Endpoints anderer Einrichtungen. Dieser Bug ist Sectigo bereits bekannt.+      * Dabei genau den "Enrollment Endpoint" aus der Drop-Down-Liste auswählen, in dem Sie oben  den ''Account'' angelegt haben und dann eben diesen angelegten Account auswählen.
       * Abschließend auf den "Send"-Button klicken, um die Einladungs-E-Mail zu versenden.       * Abschließend auf den "Send"-Button klicken, um die Einladungs-E-Mail zu versenden.
       * Mit der Einladungs-E-Mail kann die Person direkt mit einem Klick das Zertifikat beziehen.        * Mit der Einladungs-E-Mail kann die Person direkt mit einem Klick das Zertifikat beziehen. 
Zeile 166: Zeile 167:
 ====Über die AAI==== ====Über die AAI====
  
-Unter der URL https://cert-manager.com/customer/DFN/idp/clientgeant können Nutzerzertifikate direkt per AAI-Login bezogen werden. Die Zertifikate werden automatisiert ohne Einwirkung eines RAO oder DRAO ausgestellt.+Unter der URL https://cert-manager.com/customer/DFN/idp/clientgeant können Client-Zertifikate direkt per AAI-Login bezogen werden. Die Zertifikate werden automatisiert ohne Einwirkung eines RAO oder DRAO ausgestellt.
  
  
Zeile 205: Zeile 206:
  
  
-====REST-API für Nutzerzertifikate====+====REST-API für Client-Zertifikate====
  
-Über das REST API können mit selbst erstellter Software oder Skripten Nutzerzertifikate erstellt werden. Hinweise hierzu unter [[de:dfnpki:tcs:restapi|REST-API]]+Über das REST API können mit selbst erstellter Software oder Skripten Client-Zertifikate erstellt werden. Hinweise hierzu unter [[de:dfnpki:tcs:restapi|REST-API]]
  
 Die Schlüsselerzeugung findet stets auf Seiten des Clients und nicht bei Sectigo statt. Die Schlüsselerzeugung findet stets auf Seiten des Clients und nicht bei Sectigo statt.
Zeile 215: Zeile 216:
 in TCS mit Zertifkaten vom Typ ''GEANT Organisation email signing'' abgebildet werden. Es muss folgendermaßen vorgegangen werden: in TCS mit Zertifkaten vom Typ ''GEANT Organisation email signing'' abgebildet werden. Es muss folgendermaßen vorgegangen werden:
  
-Zunächst die [[de:dfnpki:tcs:usercert#e-mail-einladung|Nutzerzertifikatbeantragung mittels E-Mail-Einladung]] vorbereiten, dabei als Zertifikatprofil ''GEANT Organisation email signing'' setzen. Dann+Zunächst die [[de:dfnpki:tcs:usercert#e-mail-einladung|User-Zertifikatbeantragung mittels E-Mail-Einladung]] vorbereiten, dabei als Zertifikatprofil ''GEANT Organisation email signing'' setzen. Dann
  
   * ☰->Persons, grünen "+"-Button betätigen   * ☰->Persons, grünen "+"-Button betätigen
Zeile 226: Zeile 227:
   * Im neuen Dialog Reiter "Enrollment Invitations" anwählen   * Im neuen Dialog Reiter "Enrollment Invitations" anwählen
   * Dort hinter "Invitations" das "+"-Symbol betätigen   * Dort hinter "Invitations" das "+"-Symbol betätigen
-  * Das gewünschte ''Enrollment Form auswählen'', das im ersten Schritt angelegt wurde ([[de:dfnpki:tcsfaq#e-mail-einladung|Nutzerzertifikatbeantragung mittels E-Mail-Einladung]]).+  * Das gewünschte ''Enrollment Form auswählen'', das im ersten Schritt angelegt wurde ([[de:dfnpki:tcs:usercert#e-mail-einladung|User-Zertifikatbeantragung mittels E-Mail-Einladung]]).
   * Dann den im ersten Schritt vorbereiteten ''Account'' auswählen.   * Dann den im ersten Schritt vorbereiteten ''Account'' auswählen.
   * An die eingetragene E-Mail-Adresse wird nun eine Einladungs-Mail geschickt, und das Zertifikat kann von der für die Gruppe verantwortlichen Person erstellt werden.    * An die eingetragene E-Mail-Adresse wird nun eine Einladungs-Mail geschickt, und das Zertifikat kann von der für die Gruppe verantwortlichen Person erstellt werden. 
Zeile 241: Zeile 242:
  
  
-=====Automatische Sperrung von Nutzerzertifikaten=====+=====Automatische Sperrung von Client-Zertifikaten=====
 ===Sperrung bei Datenänderung=== ===Sperrung bei Datenänderung===
 Sectigo führt eine Liste aller Personen, die ein Zertifikat erhalten haben. Personen werden anhand ihrer primären E-Mail-Adresse identifiziert. Dieselbe natürliche Person kann also verschiedene primäre E-Mail-Adressen verwenden und gilt dann für Sectigo als verschiedene Personen. Sectigo führt eine Liste aller Personen, die ein Zertifikat erhalten haben. Personen werden anhand ihrer primären E-Mail-Adresse identifiziert. Dieselbe natürliche Person kann also verschiedene primäre E-Mail-Adressen verwenden und gilt dann für Sectigo als verschiedene Personen.
Zeile 256: Zeile 257:
  
  
-===Beschränkung der Anzahl der Zertifikate pro Nutzer===+===Beschränkung der Anzahl der Zertifikate pro Nutzendem===
  
-Zusätzlich kennt das System eine Beschränkung der Anzahl der gleichzeitig gültigen Nutzerzertifikate pro Person und Zertifikatprofil:+Zusätzlich kennt das System eine Beschränkung der Anzahl der gleichzeitig gültigen Client-Zertifikate pro Person und Zertifikatprofil:
  
-Pro Person können maximal fünf Nutzerzertifikate je Zertifikatprofil erstellt werden.+Pro Person können maximal fünf Client-Zertifikate je Zertifikatprofil erstellt werden.
  
 Wenn für ein Zertifikatprofil weitere Zertifikate beantragt werden, werden die jeweils ältesten Zertifikate mit diesem Zertifikatprofil automatisch **gesperrt**. Auch hier erfolgt keine Rückfrage und es gibt keinen Hinweis an den Zertifikatinhaber! Wenn für ein Zertifikatprofil weitere Zertifikate beantragt werden, werden die jeweils ältesten Zertifikate mit diesem Zertifikatprofil automatisch **gesperrt**. Auch hier erfolgt keine Rückfrage und es gibt keinen Hinweis an den Zertifikatinhaber!
Zeile 266: Zeile 267:
 =====Auswahl des "Key protection Algorithms" in Formularen für .p12-Dateien===== =====Auswahl des "Key protection Algorithms" in Formularen für .p12-Dateien=====
  
-Sofern bei der Beantragung von Nutzerzertifikaten die Schlüsselerzeugung durch TCS (entweder direkt im Browser der Antrags-Web-Seiten oder auf dem Server des TCS-Dienstleisters) ausgeführt wird, kann aus einer Drop-Down-Liste das kryptografische Verfahren zur Sicherung des privaten Schlüssels (''Choose key protection algorithm'') ausgewählt werden.+Sofern bei der Beantragung von Client-Zertifikaten die Schlüsselerzeugung durch TCS (entweder direkt im Browser der Antrags-Web-Seiten oder auf dem Server des TCS-Dienstleisters) ausgeführt wird, kann aus einer Drop-Down-Liste das kryptografische Verfahren zur Sicherung des privaten Schlüssels (''Choose key protection algorithm'') ausgewählt werden.
  
 Vorausgewählt ist dabei die modernere und sicherere Methode ''Secure AES256-SHA256'', alternativ steht auch die zu älteren Systemen kompatible Methode ''Compatible TripleDES-SHA1'' zur Auswahl. Vorausgewählt ist dabei die modernere und sicherere Methode ''Secure AES256-SHA256'', alternativ steht auch die zu älteren Systemen kompatible Methode ''Compatible TripleDES-SHA1'' zur Auswahl.
  
-Bei ''Secure AES256-SHA256'' kann es dann auf einigen Systemen (z.B. Windows, iOS) beim Import zu Fehlern kommen. Beispiele:+Bei ''Secure AES256-SHA256'' kann es dann auf einigen Systemen (z.B. Windows, iOS, macOS) beim Import zu Fehlern kommen. Beispiele:
   * "//Das eingegebene Kennwort ist falsch.//"   * "//Das eingegebene Kennwort ist falsch.//"
   * "//Fehler im zugrunde liegenden Sicherheitssystem. Ungültigen Anbietertyp angegeben//"   * "//Fehler im zugrunde liegenden Sicherheitssystem. Ungültigen Anbietertyp angegeben//"
Zeile 278: Zeile 279:
   * Die Zertifikate können im Adobe Acrobat zwar ausgewählt werden, der Vorgang der Unterschrift lässt sich aber nicht abschließen.   * Die Zertifikate können im Adobe Acrobat zwar ausgewählt werden, der Vorgang der Unterschrift lässt sich aber nicht abschließen.
  
-In so einem Fehlerfall hilft es, die betroffene .p12-Datei zunächst in den Zertifikat-Manager vom Firefox-Browser zu importieren und dann von dort direkt wieder in eine //neue// .p12-Datei zu exportieren. Sofern das Nutzerzertifikat nicht ebenfalls im Firefox zur SSL-Client-Authentisierung genutzt werden soll, sollte dieses dann aus Firefox wieder gelöscht werden. Eine [[https://www.ca.kit.edu/p/faq/de/fix-tcs-p12|bebilderte Anleitung dafür gibt es vom KIT]].+In so einem Fehlerfall hilft es, die betroffene .p12-Datei zunächst in den Zertifikat-Manager vom Firefox-Browser zu importieren und dann von dort direkt wieder in eine //neue// .p12-Datei zu exportieren. Sofern das User-Zertifikat nicht ebenfalls im Firefox zur SSL-Client-Authentisierung genutzt werden soll, sollte dieses dann aus Firefox wieder gelöscht werden. Eine [[https://www.ca.kit.edu/p/faq/de/fix-tcs-p12|ausführlichst bebilderte detaillierte Anleitung dafür gibt es vom KIT]]. macOS-Besonderheit: Das Zertifikat aus dem .p12-Import in den Firefox-Browser landet unter macOS als defekter störender Eintrag im Schlüsselbund und verhindert später einen neuen Import der mit dem Firefox konvertierten .p12-Datei.
  
 Die neue .p12-Datei ist dann nach unserer Erfahrung problemlos in die betroffenen Systeme zu importieren. Alternativ zu dieser Konvertierung der .p12-Datei kann auch ein neues Zertifikat beantragt werden, wobei dann bereits bei der Beantragung auf den Antrags-Web-Seiten die Methode ''Compatible TripleDES-SHA1'' ausgewählt werden muss. Die neue .p12-Datei ist dann nach unserer Erfahrung problemlos in die betroffenen Systeme zu importieren. Alternativ zu dieser Konvertierung der .p12-Datei kann auch ein neues Zertifikat beantragt werden, wobei dann bereits bei der Beantragung auf den Antrags-Web-Seiten die Methode ''Compatible TripleDES-SHA1'' ausgewählt werden muss.
  
-Die organisations-spezifische Dokumentation und Anleitung zur Nutzerzertifikatbeantragung sollte ggf. einen Hinweis auf diese möglichen Inkompatibilitäten enthalten. +Unter macOS kann auf der Kommandozeile mittels ''security import new-cert.p12'' ein Importversuch unternommen werden. Dabei muss der Dateiname ''new-cert.p12'' der Zertifikatsdatei entsprechend angepasst werden.
  
 +Die organisations-spezifische Dokumentation und Anleitung zur Beantragung von Client-Zertifikaten sollte ggf. einen Hinweis auf diese möglichen Inkompatibilitäten enthalten.
  
  • Zuletzt geändert: vor 7 Monaten