=====Client-Zertifikate===== ====Verfügbare Typen von Client-Zertifikaten===== 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==== Die folgenden Zertifikattypen stehen für sichere E-Mail / S/MIME zur Verfügung: | ''GÉANT Personal email signing and encryption'' | Public | Für Einzelpersonen. Vor-/Nachname und E-Mail-Adresse im Zertifikat, 1 oder 2 Jahre Laufzeit und versch. ECC- und RSA-Schüssellängen | | ''GÉANT Personal email signing and encryption - 2 Years RSA 4096'' | Public | Für Einzelpersonen. Sichere E-Mail, Signatur und Verschlüsselung, Vor-/Nachname und E-Mail-Adresse im Zertifikat, 2 Jahre Laufzeit und 4096 Bit RSA Schlüssel | | ''GÉANT Organisation email signing'' | Public | Für Gruppen oder nicht identifizierte Einzelpersonen. Sichere E-Mail, Signatur und auch Verschlüsselung, E-Mail-Adresse im Zertifikat, 1 oder 2 Jahre Laufzeit und versch. ECC- und RSA-Schüssellängen | | ''GÉANT Organisation email signing - 2 Years RSA 4096'' | Public | Für Gruppen oder nicht identifizierte Einzelpersonen. E-Mail-Adresse im Zertifikat, 2 Jahre Laufzeit und 4096 Bit RSA Schlüssel | ===GÉANT Personal email signing and encryption=== Dieser Zertifikattyp enthält sowohl die E-Mail-Adresse als auch Vorname/Nachname des Users und die Organisations-Informationen. Voraussetzung für die Ausstellung dieses Zertifikattyps ist, dass ein Person-Objekt in SCM existiert mit Validation Type 'HIGH'. Diese Zertifikate sind geeignet für sichere E-Mail für User, die mit Vorname/Nachname im Zertifikat auftreten sollen, und die in der Organisation bereits identifiziert wurden. **Bitte stellen Sie auf keinen Fall „Testzertifikate“ mit unsinnigen Namen aus. Dies verstößt gegen das TCS CPS, die Policies von Sectigo und die Regeln für S/MIME-Zertifikate , und gefährdet den Dienst. Sie dürfen nur Zertifikate zu identifizierten Personen ausstellen.** Diese Zertifikate können über die folgenden Antragswege ausgestellt werden: [[de:dfnpki:tcs:usercert#ueber_die_aai|Über die AAI (''idp/clientgeant'']], [[de:dfnpki:tcs:usercert#E-Mail-Einladung|E-Mail-Einladung]] oder [[de:dfnpki:tcs:restapi|REST-API]] ausgestellt werden. ==Anforderungen an Identifizierung== Es gibt von Sectigo derzeit keine konkreten zusätzlichen Verfahrensanweisungen, um einen Validation Type 'HIGH' zu setzen. Die Anforderungen, die im TCS CPS an die Identifizierung und die Dokumentation festgehalten sind, gelten weiterhin. Siehe hierzu [[de:dfnpki:tcs:usercert#identifizierung_und_dokumentation|Identifizierung und Dokumentation]]. ===GÉANT Organisation email signing=== Dieser Zertifikattyp enthält nur die E-Mail-Adresse und Organisations-Informationen und keine Namen von Personen. Im cert-manager existiert trotzdem ein Personeneintrag, in dem die Felder ''firstName'' und ''lastName'' befüllt sein müssen. Der Validation Type des Personeneintrags kann auch 'STANDARD' sein. Diese Zertifikate sind geeignet für Gruppen oder für Personen, die in der Einrichtung noch nicht persönlich identifiziert wurden. Entgegen dem Profilnamen ist auch E-Mail Verschlüsselung möglich. Diese Zertifikate können ausschließlich über [[de:dfnpki:tcs:usercert#E-Mail-Einladung|E-Mail-Einladung]] oder [[de:dfnpki:tcs:restapi|REST-API]] ausgestellt werden. In ''idp/clientgeant'' steht dieser Typ nicht zur Verfügung. ====IGTF / Grid-Computing==== Zertifikate für Grid-Computing und (nach Planung und Freischaltung im Dienst) interne Authentifizierungszwecke werden in den folgenden Profilen ausgestellt. Nutzen Sie diese Zertifikattypen nur im Kontext von Grid-Computing. Die Zertifikate sind **nicht für sichere E-Mail** geeignet, da sie in einer privaten, nicht in Browsern und Betriebssystemen vorinstallierten Zertifizierungshierarchie ausgestellt werden. Für sichere E-Mail - S/MIME sind diese Zertifikate **nicht** geeignet. ^ 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 - 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 - 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 Organisation Automated Authentication - RSA'' | Private, nur IGTF / Grid | Für automatische Agenten in einem Organisationskontext. E-Mail-Adresse im Zertifikat, 1 Jahr Laufzeit und versch. RSA-Schüssellängen | | ''GÉANT Organisation Automated Authentication - ECC'' | Private, nur IGTF / Grid | Für automatische Agenten in einem Organisationskontext. E-Mail-Adresse im Zertifikat, 1 Jahr Laufzeit und versch. ECC-Schüssellängen | **Achtung:** Aufgrund der Verwechslungsmöglichkeit für User bei der Beantragung stellen wir diese Profile **nicht** mehr allgemein zur Verfügung. Wenn Sie Zertifikate für Grid-Computing ausstellen wollen, melden Sie sich bitte bei dfnpca@dfn-cert.de. Wir weisen die Profile dann Ihrer Organisation zu. =====Identifizierung und Dokumentation===== 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 wichtigsten Punkte: * 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 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. Die Dokumentation der Identifizierung muss nicht über die Verfahren hinausgehen, die für die üblichen Einrichtungs-internen Prozesse im Rahmen eines Beschäftigungsverhältnisses oder eines Studiums notwendig sind. Die Einrichtung muss mit ihrer Dokumentation in der Lage sein, den Namen im Zertifikat auf eine konkrete Person zurückzuführen. ==== Vergleich mit DFN-AAI ==== Die Regeln zur [[de:aai:assurance|Identity Assurance in der DFN-AAI]] und die Regeln zur Identifizierung von Personen in TCS sind nicht deckungsgleich. In der DFN-AAI gilt das [[https://wiki.refeds.org/display/ASS/REFEDS+Assurance+Framework+ver+1.0|REFEDS Assurance Framework]] mit seinen verschiedenen Einstufungen. Ob die an Ihrer Einrichtung praktizierten Verfahren im Rahmen der DFN-AAI den oben genannten Regeln von GÉANT TCS genügen, kann darum nicht pauschal beantwortet werden, sondern muss von Ihnen bewertet werden. Vor einer gründlichen Prüfung der internen Prozesse sollten darum auf keinen Fall pauschal alle Personen in Ihrem IdP für den Zertifikatbezug freigeschaltet werden (Setzen des Attributs eduPersonEntitlement mit Wert ''urn:mace:terena.org:tcs:personal-user'') =====Wege zur Ausstellung von Client-Zertifikaten===== Es stehen verschiedene Wege zur Verfügung, um Client-Zertifikate auszustellen. ====E-Mail-Einladung==== 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: * Im SCM unter ☰->Enrollment->Enrollment Forms * Mit dem grünen Button "+" oben rechts ein neues Enrollment Form erzeugen * Einen sprechenden Namen vergeben, der auf Ihre Einrichtung hinweist * Als Typ "Client certificate certificate enrollment form" setzen * Im folgenden Dialog unter Tab "Details" eine URI Extension setzen oder generieren lassen. Diese URI Extension definiert die URL, unter der später Zertifikate beantragt werden kann: ''%%https://cert-manager.com/customer/DFN/smime/%%'' * Im selben Dialog unter Tab "Configuration" den Authentication Type "Email Confirmation" anwählen. **Achtung:** Auf keinen Fall "Identity Provider" setzen! * Mit "Save" abspeichern * Oben auf "Accounts" klicken. * Im daraufhin geöffneten Popup-Fenster über mit dem grünen "+"-Button einen neuen Account hinzufügen. * Einen sprechenden Namen für den Account vergeben, der auf Ihre Einrichtung hindeutet. * Als "Organization" Ihre Einrichtung aus der Drop-Down-Liste auswählen (und ggf. auch ein Department setzen). * Bei den Zertifikatprofilen über das kleine "+"-Zeichen aus der Drop-Down-Liste das gewünschte Zertifikatprofil für den E-Mail-Einladungsprozess auswählen. * Für Zertifikate für S/MIME mit Identifizierung der Person und Vorname/Nachname im Zertifikat: * "GEANT Personal email signing and encryption", dieses mit Auswahl von Laufzeit, Algorithmus und Schlüssellänge durch den Antragsstellenden * alternativ "GEANT email signing and encryption - 2 Years RSA 4096" mit Limitierung auf 4096 Bit RSA mit 2 Jahr Laufzeit. * Für Zertifikate für S/MIME ohne Identifizierung und ohne Vorname/Nachname: * "GEANT Organisation email signing", dieses mit Auswahl von Laufzeit, Algorithmus und Schlüssellänge durch den Antragsstellenden * alternativ "GEANT Organisation signing - 2 Years RSA 4096" mit Limitierung auf 4096 Bit RSA mit 2 Jahr Laufzeit. * Als "CSR Generation Method" den Wert "Browser" oder "Server" auswählen. * "Server" erzeugt den Schlüssel auf Sectigo-Seite * "Browser" erzeugt den Schlüssel im Browser des Antragsstellenden * "Allow empty PKCS12 Password" **nicht** aktivieren. * Als "Authorization Method" den Wert "none" auswählen. **Achtung**: Bitte auf keinen Fall Authorization Method ''Access Code'' im Zusammenhang mit client certificates verwenden! Die Nutzenden können bei diesem Antragsweg beliebige Vor- und Nachnamen angeben. Es wird lediglich die E-Mail-Adresse verifiziert, und das Zertifikat anschließend automatisch ausgestellt. Sie haben keine Möglichkeit, Vor- und Nachnamen vor Ausstellung zu verifizieren. * Mit "Save" abspeichern. 2. Anschließend werden unterhalb von ☰->Persons neue Einträge für Personen angelegt: * Mit dem grünen "+"-Button kann eine einzelne Person angelegt werden. * Zunächst die Felder ''First Name'', ''Last Name'' und ''Email Address'' ausfüllen * Im folgenden Dialog den ''Common Name'' setzen * Wenn die Person Zertifikate vom Typ ''GÉANT Personal email signing and encryption'' erhalten soll (inklusive vorname/Nachname im Zertifikat), so muss der Validation Type auf ''HIGH'' gesetzt werden. Voraussetzung ist, dass in Ihrer Einrichtung eine Identifizierung der Person stattgefunden hat, siehe hierzu auch [[de:dfnpki:tcs:usercert#identifizierung_und_dokumentation|Identifizierung und Dokumentation]] * Mit dem Upload-Symbol neben dem "+"-Button kann eine CSV-Datei (//Zeichenkodierung UTF-8//) hochgeladen werden. Mit der CSV-Datei können mehrere Personen auf einmal angelegt werden. Das CSV-Format ist in der SCM-Dokumentation in Abschnitt B.3 beschrieben. Die grundsätzliche minimale Struktur ist: ;;;;;High;;;;;DE;;; Als Beispiel: Erika;;Musterfrau;musterfrau@dfn-cert.de;;High;Example GmbH;;AL07rQCsofFQfrJqqmAn;;DE;;musterfau@example.org;Erika Musterfrau 3. Nachdem Personen angelegt wurden, gibt es zwei verschiedene Möglichkeiten: * Entweder eine Email Invitation aus dem System heraus versenden: * 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. * 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. * Mit der Einladungs-E-Mail kann die Person direkt mit einem Klick das Zertifikat beziehen. * Oder aber die URL des Enrollment Forms an die Personen auf anderem Wege weiterleiten. (URL selbst definiert in Schritt 1, ''%%https://cert-manager.com/customer/DFN/smime/%%'') * Mit der URL kann die Person nach einer E-Mail-Challenge direkt das Zertifikat beziehen. Bitte beachten Sie die Identifizierungsvoraussetzungen, bevor Sie Personen anlegen: [[de:dfnpki:tcs:usercert#identifizierung_und_dokumentation|Identifizierung und Dokumentation]]. 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== Über die selbst definierte URL des Enrollment Forms können Zertifikate jederzeit erneut beantragt werden. ====Über die AAI==== 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. Um https://cert-manager.com/customer/DFN/idp/clientgeant nutzen zu können, sind vorbereitende Konfigurationsarbeiten notwendig. Diese erfordern zwingend die Mithilfe Ihrer AAI-Administration, da in der Regel die Attributfreigaben anzupassen sind und für berechtigte Personen ein Entitlement gesetzt werden muss. Die folgenden Voraussetzungen müssen erfüllt sein: * Grundkonfiguration siehe [[de:dfnpki:tcsfaq#zugriff_per_aai|Zugriff per AAI]] * Ihr Identity-Provider muss alle Attribute wie in folgender Beschreibung von GÉANT freigeben: [[https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ#TCS2020FAQ-TouseSAMLinordertoallowuserstoorderclientcertificates:]] * 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]]. * 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. Für die Schlüsselerzeugung im AAI-Workflow gibt es in dem angebotenen Formular eine Wahlmöglichkeit: * Entweder wird der private Schlüssel von Sectigo erzeugt * oder aber vom Beantragenden vorab zusammen mit einem CSR generiert. Der erstellte CSR kann dann im Formular zur Zertifikaterstellung hochgeladen werden. **Achtung:** Es gibt für Client Certificates alternative Wege mit AAI-Bezug, die aber **nicht verwendet** werden sollen. (Individuelle ''Client certificate enrollment form'' mit Authentifizierung "Identity Provider"). Diese Wege erlauben den Nutzenden beliebige Vor- und Nachnamen anzugeben. Es wird lediglich die E-Mail-Adresse aus dem IdP übernommen, und das Zertifikat anschließend automatisch ausgestellt. Sie haben keine Möglichkeit, Vor- und Nachnamen vor Ausstellung zu verifizieren. 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). ==Erneuerung== Über https://cert-manager.com/customer/DFN/idp/clientgeant können Zertifikate jederzeit erneut beantragt werden. == Alternativer ''displayName'' aus dem IdP == Wenn der IdP keinen verwendbaren ''displayName'' liefert und die Werte nicht korrigiert werden können oder sollen, so kann ein eigenes Attribut unter dem entsprechenden SAML2-Namen ''urn:oid:2.16.840.1.113730.3.1.241'' bereitgestellt werden, hier am Beispiel von Shibboleth: - In ''attribute-resolver.xml'' ein eigenes neues Attribut definieren (mit einer eigenen ''id''), z.B. ''id=″displayName2″'' vom ''xsi:type=″Template″'', siehe [[https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631563/TemplateAttributeDefinition]] - Attribut ''displayName2'' in der Datei ''attribute-filter.xml'' für Sectigo freigeben (statt ''displayName'') - In ''/opt/shibboleth-idp/conf/attributes/'' aus ''inetOrgPerson.xml'' die Bean-Definition für ''displayName'' kopieren und mit dem neuen Attributnamen ''displayName2'' z.B. in ''default-rules.xml'' hinterlegen. ====REST-API für Client-Zertifikate==== Ü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. =====Gruppenzertifikate===== Die aus der DFN-PKI bekannten Gruppen- und Pseudonymzertifikate können 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|User-Zertifikatbeantragung mittels E-Mail-Einladung]] vorbereiten, dabei als Zertifikatprofil ''GEANT Organisation email signing'' setzen. Dann * ☰->Persons, grünen "+"-Button betätigen * Daten im ersten Dialog ausfüllen und mit OK bestätigen: - ''First Name'' und ''Last Name'' für die hauptverantwortliche Person der Gruppe. - E-Mail-Adresse auf die Gruppen-Mail-Adresse * Im nächsten großen Dialog Feld ''Common Name'' auf den Gruppennamen setzen * Den Button "Save" betätigen * Den neuen Eintrag auswählen, Button "Edit" betätigen. * Im neuen Dialog Reiter "Enrollment Invitations" anwählen * Dort hinter "Invitations" das "+"-Symbol betätigen * 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. * 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. **Achtung:** Die Zertifikate enthalten nun nur noch die E-Mail-Adressen und den Organisationsnamen. Der Gruppennamen (das Feld ''Common Name'') wird nicht mit aufgenommen. Sofern Sie in einer Anwendung (z.B. MS Outlook) Probleme haben, mehrere Ihrer //eigenen// Gruppenzertifikate dieser Art von einander zu unterscheiden, versuchen Sie für diese Gruppenzertifikate jeweils einen unterschiedlichen sog. ''friendlyName'' zu setzen. Zum Setzen vom ''friendlyName'' für ein Gruppenzertifikat in einer .p12-Datei kann auf der Kommandozeile eine Abfolge von ''openssl''-Kommandos verwendet werden, deren letzter Befehl ''openssl pkcs12 -export -name MyFriendlyName ...'' ist, um die neue .p12-Datei entsprechend mit ''friendlyName'' zu erstellen. =====ECC oder RSA?===== Zertifikate mit den ECC-Schlüsseltypen P-384 und P-256 können nur für Signatur und Authentisierung, aber nicht für Verschlüsselung verwendet werden können. =====Automatische Sperrung von Client-Zertifikaten===== ===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. Wenn für eine primäre E-Mail-Adresse erstmals ein Zertifikat beantragt wird, wird die Person mit den Angaben aus dem Antrag in die Liste eingetragen. Wenn für eine primäre E-Mail-Adresse weitere Zertifikate beantragt werden, werden die vorhandenen Personendaten in der Liste mit den Angaben aus den neuen Anträgen aktualisiert. Dabei gilt: * Sekundäre E-Mail-Adressen und der "commonName" können problemlos geändert werden. * Änderungen am "firstName", "middleName" oder "lastName" führen aber zur sofortigen **Sperrung** aller vorher für diese primäre E-Mail Adresse ausgestellten Zertifikate in allen Zertifikatprofilen. Es erfolgt keine Rückfrage und es gibt keinen Hinweis an den Zertifikatinhaber! ===Beschränkung der Anzahl der Zertifikate pro Nutzendem=== 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 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! =====Auswahl des "Key protection Algorithms" in Formularen für .p12-Dateien===== 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. 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.//" * "//Fehler im zugrunde liegenden Sicherheitssystem. Ungültigen Anbietertyp angegeben//" * Aufforderung zum Einstecken einer Smartcard * Das Zertifikat aus dem .p12-Import landet unter Windows im Zertifikatspeicher unter der Kategorie "Andere Personen" und nicht wie erwartet unter der Kategorie "Eigene Zertifikate". * "//Die Nachrichtenschnittstellen haben einen unbekannten Fehler zurückgeliefert//" (MS Outlook) * 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|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. 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.