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 DFN-Verein Community-PKI

Die folgenden Zertifikattypen stehen für sichere E-Mail / S/MIME zur Verfügung:

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: Über die AAI (''idp/clientgeant'', E-Mail-Einladung oder REST-API ausgestellt werden.

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 Identifizierung und Dokumentation.

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 E-Mail-Einladung oder REST-API ausgestellt werden. In idp/clientgeant steht dieser Typ nicht zur Verfügung.

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.

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.

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 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.

Die Regeln zur Identity Assurance in der DFN-AAI und die Regeln zur Identifizierung von Personen in TCS sind nicht deckungsgleich.

In der DFN-AAI gilt das 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)

Es stehen verschiedene Wege zur Verfügung, um Client-Zertifikate auszustellen.

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/<URI Extension>
  • 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 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:

<Vorname>;;<Nachname>;<E-Mail-Adresse>;;High;<Organisationsname>;;<Secret ID (Passwort)>;;DE;;<eduPersonPrincipalName>;<Common Name>

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/<URI Extension>)
  • Mit der URL kann die Person nach einer E-Mail-Challenge direkt das Zertifikat beziehen.

Bitte beachten Sie die Identifizierungsvoraussetzungen, bevor Sie Personen anlegen: Identifizierung und Dokumentation.

Hinweise zur Auswahl und Problematik des Verschlüsselungsalgorithmus durch die beantragende Person für ggf. über das Zertifikatantragsformular erzeugte .p12-Dateien (PKCS#12).

Über die selbst definierte URL des Enrollment Forms können Zertifikate jederzeit erneut beantragt werden.

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 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: config-attributes-tcs
• Insbesondere muss ein eduPersonEntitlement urn:mace:terena.org:tcs:personal-user gesetzt werden. Bitte beachten Sie die Identifizierungsvoraussetzungen, bevor Sie das Entitlement setzen: 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 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 Auswahl und Problematik des Verschlüsselungsalgorithmus durch die beantragende Person für ggf. über das Zertifikatantragsformular erzeugte .p12-Dateien (PKCS#12).

Über https://cert-manager.com/customer/DFN/idp/clientgeant können Zertifikate jederzeit erneut beantragt werden.

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:

1. 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
2. Attribut displayName2 in der Datei attribute-filter.xml für Sectigo freigeben (statt displayName)
3. In /opt/shibboleth-idp/conf/attributes/ aus inetOrgPerson.xml die Bean-Definition für <prop key=″id″>displayName</prop> kopieren und mit dem neuen Attributnamen displayName2 z.B. in default-rules.xml hinterlegen.

Über das REST API können mit selbst erstellter Software oder Skripten Client-Zertifikate erstellt werden. Hinweise hierzu unter REST-API

Die Schlüsselerzeugung findet stets auf Seiten des Clients und nicht bei Sectigo statt.

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 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:
  1. First Name und Last Name für die hauptverantwortliche Person der Gruppe.
  2. 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 (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.

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.

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!

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!

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 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.