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 [2024/01/24 16:39] – [Verfügbare Typen von User-Zertifikaten] Juergen Brauckmannde:dfnpki:tcs:usercert [2024/08/02 15:20] (aktuell) – [Über die AAI] Reimer Karlsen-Masur
Zeile 1: Zeile 1:
-=====User-Zertifikate=====+=====Client-Zertifikate=====
  
-====Verfügbare Typen von User-Zertifikaten=====+====Verfügbare Typen von Client-Zertifikaten=====
  
 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 User-Zertifikaten im Zusammenhang mit Client-Authentifizierung (z.B. für VPNs) nicht empfohlen. Wählen Sie hierfür bitte eine andere PKI, z.B. die [[de:dfnpki:dfnvereincommunitypki|DFN-Verein Community-PKI]]+**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]]
  
  
Zeile 52: Zeile 52:
  
 ^ Profilname     ^ Vertrauen ^ Eigenschaften  ^ Profilname     ^ Vertrauen ^ Eigenschaften 
-| ''GÉANT Personal authentication - RSA'' | Private, nur IGTF / Grid | Für Einzelpersonen. Vor-/Nachname und E-Mail-Adresse im Zertifikat, 1 Jahr Laufzeit und versch. RSA-Schüssellängen  |  +| ''GÉANT Personal Authentication - RSA'' | Private, nur IGTF / Grid | Für Einzelpersonen. Vor-/Nachname und E-Mail-Adresse im Zertifikat, 1 Jahr Laufzeit und versch. RSA-Schüssellängen  |  
-| ''GÉANT Personal authentication - ECC'' | Private, nur IGTF / Grid | Für Einzelpersonen. Vor-/Nachname und E-Mail-Adresse im Zertifikat, 1 Jahr Laufzeit und versch. ECC-Schüssellängen  | +| ''GÉANT Personal Authentication - ECC'' | Private, nur IGTF / Grid | Für Einzelpersonen. Vor-/Nachname und E-Mail-Adresse im Zertifikat, 1 Jahr Laufzeit und versch. ECC-Schüssellängen  | 
 | ''GÉANT Personal Automated Authentication - RSA'' | Private, nur IGTF / Grid | Für automatische Agenten unter der Kontrolle von Einzelpersonen. Vor-/Nachname und E-Mail-Adresse im Zertifikat, 1 Jahr Laufzeit und versch. RSA-Schüssellängen  |  | ''GÉANT Personal Automated Authentication - RSA'' | Private, nur IGTF / Grid | Für automatische Agenten unter der Kontrolle von Einzelpersonen. Vor-/Nachname und E-Mail-Adresse im Zertifikat, 1 Jahr Laufzeit und versch. RSA-Schüssellängen  | 
 | ''GÉANT Personal Automated Authentication - ECC'' | Private, nur IGTF / Grid | Für automatische Agenten unter der Kontrolle von Einzelpersonen. Vor-/Nachname und E-Mail-Adresse im Zertifikat, 1 Jahr Laufzeit und versch. ECC-Schüssellängen  | | ''GÉANT Personal Automated Authentication - ECC'' | Private, nur IGTF / Grid | Für automatische Agenten unter der Kontrolle von Einzelpersonen. Vor-/Nachname und E-Mail-Adresse im Zertifikat, 1 Jahr Laufzeit und versch. ECC-Schüssellängen  |
Zeile 65: 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 73: 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 90: Zeile 90:
  
  
-=====Wege zur Ausstellung von User-Zertifikaten=====+=====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 User-Zertifikaten 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 148: 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 167: Zeile 167:
 ====Über die AAI==== ====Über die AAI====
  
-Unter der URL https://cert-manager.com/customer/DFN/idp/clientgeant können User-Zertifikate 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 177: Zeile 177:
   * Ein Konfigurationsbeispiel für Ihren Identity-Provider finden Sie unter: [[de:shibidp:config-attributes-tcs?s[]=cert&s[]=manager]]   * Ein Konfigurationsbeispiel für Ihren Identity-Provider finden Sie unter: [[de:shibidp:config-attributes-tcs?s[]=cert&s[]=manager]]
   * Insbesondere muss ein eduPersonEntitlement ''urn:mace:terena.org:tcs:personal-user'' gesetzt werden. Bitte beachten Sie die Identifizierungsvoraussetzungen, bevor Sie das Entitlement setzen: [[de:dfnpki:tcs:usercert#identifizierung_und_dokumentation|Identifizierung und Dokumentation]].   * Insbesondere muss ein eduPersonEntitlement ''urn:mace:terena.org:tcs:personal-user'' gesetzt werden. Bitte beachten Sie die Identifizierungsvoraussetzungen, bevor Sie das Entitlement setzen: [[de:dfnpki:tcs:usercert#identifizierung_und_dokumentation|Identifizierung und Dokumentation]].
-     * Die Fehlermeldung ''You are not allowed to self enroll.'' ist ein Symptom für ein nicht übertragenes eduPersonEntitlement ''urn:mace:terena.org:tcs:personal-user''. Der [[de:dfnpki:tcsfaq#tests|SSOcheck]] gibt Auskunft, welche Attribute tatsächlich an TCS übertragen werden. +     * Die Fehlermeldung ''You are not allowed to self enroll.'' ist ein Symptom für ein nicht übertragenes eduPersonEntitlement ''urn:mace:terena.org:tcs:personal-user''. Der [[de:dfnpki:tcs:zugriffperaai#tests|SSOCheck]] gibt Auskunft, welche Attribute tatsächlich an TCS übertragen werden.
- +
  
 Für die Schlüsselerzeugung im AAI-Workflow gibt es in dem angebotenen Formular eine Wahlmöglichkeit: Für die Schlüsselerzeugung im AAI-Workflow gibt es in dem angebotenen Formular eine Wahlmöglichkeit:
Zeile 191: Zeile 189:
 Der korrekte Weg zu Client Certificates mit der AAI ist über  https://cert-manager.com/customer/DFN/idp/clientgeant Der korrekte Weg zu Client Certificates mit der AAI ist über  https://cert-manager.com/customer/DFN/idp/clientgeant
  
-Hinweise zur [[de:dfnpki:tcsfaq#auswahl_des_verschluesselungsalgorithmus_fuer_p12-dateien_pkcs_12|Auswahl und Problematik des Verschlüsselungsalgorithmus]] durch die beantragende Person für ggf. über das Zertifikatantragsformular erzeugte .p12-Dateien (PKCS#12).+Hinweise zur [[de:dfnpki:tcs:usercert#auswahl_des_key_protection_algorithms_in_formularen_fuer_p12-dateien|Auswahl und Problematik des Verschlüsselungsalgorithmus]] durch die beantragende Person für ggf. über das Zertifikatantragsformular erzeugte .p12-Dateien (PKCS#12).
  
 ==Erneuerung== ==Erneuerung==
Zeile 206: Zeile 204:
  
  
-====REST-API für User-Zertifikate====+====REST-API für Client-Zertifikate====
  
-Über das REST API können mit selbst erstellter Software oder Skripten User-Zertifikate 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 227: Zeile 225:
   * 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|User-Zertifikatbeantragung 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 242: Zeile 240:
  
  
-=====Automatische Sperrung von User-Zertifikaten=====+=====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 259: Zeile 257:
 ===Beschränkung der Anzahl der Zertifikate pro Nutzendem=== ===Beschränkung der Anzahl der Zertifikate pro Nutzendem===
  
-Zusätzlich kennt das System eine Beschränkung der Anzahl der gleichzeitig gültigen User-Zertifikate 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 User-Zertifikate 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 267: Zeile 265:
 =====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 User-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.+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 279: Zeile 277:
   * 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 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|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 14 Monaten