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:tcsfaq [2021/09/07 08:20] Juergen Brauckmannde:dfnpki:tcsfaq [2024/01/26 16:32] (aktuell) Juergen Brauckmann
Zeile 1: Zeile 1:
-Auf dieser Seite stellen wir den Teilnehmern an der DFN-PKI eine FAQ-Seite zur Einführung in TCS zur VerfügungDiese Seite wird permanent mit den Fragen der Anwender weiter entwickelt. +**Diese FAQ richtet sich primär an die Teilnehmerservices an den an der DFN-PKI teilnehmenden EinrichtungenNicht alle hier beschriebenen Funktionen werden von allen Einrichtungen gleichermaßen umgesetztFalls Sie sich für den Bezug eines Zertifikats interessierenwenden Sie sich bitte an Ihren lokalen Teilnehmerservice an Ihrer Heimateinrichtung.**
- +
-=====Was ist TCS?===== +
- +
-TCS (Trusted Certificate Service) ist ein PKI-Angebot, dass der DFN-Verein über GÉANT bezieht. GÉANT realisiert den Dienst mit Hilfe von externen Anbieterndie über regelmäßige Ausschreibungen gefunden werden. Der aktuelle Anbieter ist Sectigo. +
- +
-Überblick über den Dienst bei GÉANT: [[https://www.geant.org/Services/Trust_identity_and_security/Pages/TCS.aspx]] +
- +
-Der DFN-Verein führt das Angebot zur Zeit bei allen Teilnehmern der DFN-PKI ein.+
  
 =====Wie erhalten Einrichtungen einen Zugang?===== =====Wie erhalten Einrichtungen einen Zugang?=====
  
-Zur Zeit geht der DFN-Verein auf alle bisherigen Teilnehmer der DFN-PKI zu, um ihnen einen Zugang zu TCS zu ermöglichen.+Ein Zugang zu TCS kann über den Kontakt [[mailto:pki@dfn.de|pki@dfn.de]] beauftragt werden.
  
-Das initiale Setup erfolgt dann in direkter Absprache mit dfnpca@dfn-cert.de.+Das initiale Setup erfolgt dann in direkter Absprache mit [[mailto:dfnpca@dfn-cert.de|dfnpca@dfn-cert.de]].
  
 ====Gibt es eine Testumgebung für TCS REST API und die Webseiten?==== ====Gibt es eine Testumgebung für TCS REST API und die Webseiten?====
Zeile 21: Zeile 13:
 =====Erste Schritte===== =====Erste Schritte=====
  
-Überblick über erste Schritte nach Erhalt eines Zugangs: https://doku.tid.dfn.de/de:dfnpki:tcsfaq:ersteschritte+Überblick über erste Schritte nach Erhalt eines Zugangs: [[de:dfnpki:tcsfaq:ersteschritte|Erste Schritte]]
  
 =====Dokumentation===== =====Dokumentation=====
Zeile 27: Zeile 19:
 Bei GÉANT gibt es eine Zusammenstellung von FAQs: [[https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ]] Bei GÉANT gibt es eine Zusammenstellung von FAQs: [[https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ]]
  
-Die Dokumentation von Sectigo zur Administrations-Oberfläche und zu ACME ist zu finden unter https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA01N000000bvJA+Die Dokumentation von Sectigo zur Administrations-Oberfläche und zu ACME ist zu finden unter https://sectigo.com/knowledge-base/detail/Sectigo-Certificate-Manager-SCM-Administrator-s-Guide/kA01N000000bvJA
  
-Die REST-API ist dokumentiert unter https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA01N000000XDkE+Die REST-API ist dokumentiert unter https://sectigo.com/knowledge-base/detail/Sectigo-Certificate-Manager-SCM-REST-API/kA01N000000XDkE 
 + 
 +Sectigo unterhält einen Youtube-Kanal mit vielen Tutorials: https://www.youtube.com/c/Sectigo/videos
  
 =====Datenschutz===== =====Datenschutz=====
  
-Eine Bewertung von GÈANT zu Fragen des Datenschutzes und der DSGVO liegt vor: [[https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ#TCS2020FAQ-Q:HowdoG%C3%89ANTandSectigodealwithGDPR/dataprotection?]]+Hinweise zum Datenschutz und der vertraglichen Konstruktion: 
 +[[de:dfnpki:tcs:datenschutz|Datenschutz]]
  
 =====Funktionsüberblick===== =====Funktionsüberblick=====
  
-Anwender haben Zugriff über die Administrations-Oberfläche unter https://cert-manager.com/customer/DFN+Anwender haben Zugriff über die Administrations-Oberfläche, genannt "Sectigo Certificate-Manager" (SCM), unter https://cert-manager.com/customer/DFN
  
-Dort gibt es, wie in der Java RA-Oberfläche der DFN-PKI, einen direkten Überblick über offene Anträge und ausgestellte Zertifikate und eine Verwaltung von Domains. Es gibt eine Verwaltung von weiteren Administratoren und Abteilungen. Im cert-manager ist die sofortige Ausstellung von neuen Server- und Nutzerzertifikaten möglich.+Dort gibt es, wie in der Java RA-Oberfläche der DFN-PKI, einen direkten Überblick über offene Anträge und ausgestellte Zertifikate und eine Verwaltung von Domains. Es gibt eine Verwaltung von weiteren Administratoren und Abteilungen. Im cert-manager ist die sofortige Ausstellung von neuen Server- und Client-Zertifikaten möglich.
  
 TCS bietet zusätzlich: TCS bietet zusätzlich:
  
-    * Web-Formulare zum Beantragen von Zertifikaten für nicht in cert-manager.com eingeloggte Benutzer per "Access-Code"+    * Web-Formulare zum Beantragen von Zertifikaten für nicht in cert-manager.com eingeloggte Benutzer
     * Eine Ausstellung von Zertifikaten über eine SAML-Integration     * Eine Ausstellung von Zertifikaten über eine SAML-Integration
     * Eine ACME-Schnittstelle     * Eine ACME-Schnittstelle
-    * Eine REST-API, Dokumentation: https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA01N000000XDkE+    * Eine REST-API 
 +     
 +Es gibt **keine** Testumgebung.
  
-Es gibt **keine** Testumgebung, in der Sachen ausprobiert werden könnten. 
-=====Organisationsvalidierung===== 
  
-Der Anbieter muss die Existenz und den Namen der Organisation regelmäßig über ein Register verifizieren. Der aktuelle Validierungszustand ist über Settings->Organizations einsehbar.+=====Rollen, Anmeldung und Abteilungen (Departments)=====
  
-Die Stammdaten der Organisation können nur von der DFN-PCA geändert werden.+In SCM gibt es verschiedene Rollen und Möglichkeiten zur Anmeldung. Es können Abteilungen ("Departments") angelegt werden
 +[[de:dfnpki:tcs:scmrollenundanmeldung|Rollen, Anmeldung, Abteilungen]]
  
-=====Rollen=====+===== Tipps und Tricks in SCM =====
  
-Es wird zwischen verschiedenen Rollen unterschieden, die in sich noch einmal mit unterschiedlichen Privilegien versehen werden können.+[[de:dfnpki:tcs:scmtipstricks|Tipps und Tricks für SCM]]
  
- * RAO und DRAO sind Registration Authority Officer auf Organisations- oder Department-(Abteilungs)-Ebene. Je nach den diesen Accounts bei der Einrichtung zugewiesenen Rechten können RAO/DRAO weitere RAOs/DRAOs anlegen oder modifizieren, und eine Auswahl der Zertifikattypen SSL, Client und Code Signing erstellen. 
  
-Der erste RAO einer Einrichtung wird von der DFN-PCA angelegt. Weitere RAOs oder DRAOs können dann eigenständig angelegt und verwaltet werden.+=====Zugriff per AAI=====
  
-   * Privilegien "Allow ... of peer admin" ermöglichen u.a. das Anlegen oder modifizieren von weiteren RAOs/DRAOs. Diese Privilegien können nicht selbst gesetzt werden, sondern nur von der DFN-PCA nachträglich geändert werden. +Viele Funktionen im cert-manager können auch nach einem Login über die DFN-AAI genutzt werden. Hierzu müssen Voraussetzungen erfüllt sein: [[de:dfnpki:tcs:zugriffperaai|Zugriff per AAI]]
-   * API-Only-User: Ein RAO/DRAO kann auf API-Only eingeschränkt werden (Privileg "WS-API only" im Dialog "Add New Client Admin", Menü Admins, Button Add). Mit diesem Account kann dann ausschl. das REST-API bedient werden. Nach unseren Erkenntnissen sollte diese Checkbox initial noch nicht angekreuzt werden, da der neue Account sich einmal an der Web-Oberfläche anmelden muss um sein Passwort vom Initial-Passwort zu setzen. Erst nach dem Setzen des richtigen Passworts sollte "WS-API only" angekreuzt werden. Da dieses Privileg nur von der DFN-PCA geändert werden kann, ist für die Nutzung dieses Features Kommunikation mit der DFN-PCA erforderlich.+
  
-=====Departments=====+=====Benachrichtigungen=====
  
-Zur weiteren Strukturierung der Organisation können RAOs Abteilungen anlegen. Hierzu Settings->OrganizationsButton Departments wählen.+Um Benachrichtigungen über Ereignisse wie den Ablauf von Zertifikaten oder der Gültigkeit von Domain-Valididierungen zu erhaltenkönnen Benachrichtigungen konfiguriert werden: [[de:dfnpki:tcs:scm_notifications|Benachrichtigungen in SCM]]
  
-**Wichtig:** Unter "Client Certificates" bitte unbedingt "Allow Key Recovery by Master Administrators" herausnehmen!+=====Domains und IPv4-Adressen in Zertifikaten=====
  
-Es können dann DRAOs angelegt werden, die nur innerhalb der zugewiesenen Abteilung Zertifikate verwalten können.+Um Zertifikate zu erhaltenmüssen die entsprechenden Domains oder IPv4-Adressen **vorab** bei Sectigo im System eingetragen werden. 
 +Eine detaillierte Beschreibung ist verfügbar unter: [[de:dfnpki:tcs:domains|Domains und IPv4-Adressen in Zertifikaten]]
  
-=====Domainvalidierung, Domain Control Validation (DCV)===== 
  
-Um Zertifikate zu erhalten, müssen die entspr. Domains unter Settings->Domains->Delegations eingetragen und unter Settings-Domains-DCV validiert werden (Validation Status muss auf "Validated" gesetzt sein).+=====Zertifikate erstellen=====
  
-WichtigNach dem Eintragen und der Validierung müssen die Domains an eine Organization "delegiert" werden. Hierzu entweder über Settings->Organizations per Button Domains oder über Settings->Domains, Submenü Delegations, Button Delegate gehen.+[[de:dfnpki:tcs:servercert|Serverzertifikate]]
  
-Domainvalidierungen können über Settings->Domains, Submenü DCV eingesehen oder neu angestoßen werden.+[[de:dfnpki:tcs:servercert_acme|Serverzertifikate per ACME]]
  
-Nach derzeitigem Kenntnisstand muss zunächst die Hauptdomain eingetragen und validiert werden, z.B. ''example.org''. Nach erfolgreicher Validierung kann dann ein Sternchen-Eintrag ''*.example.org'' erzeugt werden. Nur mit dem Sternchen-Eintrag scheinen Zertifikate zu beliebigen FQDN erzeugt werden können.+[[de:dfnpki:tcs:usercert|Client-Zertifikate]]
  
-Wenn Sie CAA-Records verwenden, so müssen diese bereits zum Zeitpunkt der Domainvalidierung passen, und nicht erst zum Zeitpunkt der Ausstellung von Zertifikaten, siehe [[de:dfnpki:tcsfaq#caa-Records|CAA-Records]]+[[de:dfnpki:tcs:documentsigning|Document Signing]]
  
-Die Validierung von Domains per E-Mail-Challenge funktioniert bei TCS in einem wichtigen Detail andersWährend in der DFN-PKI die E-Mail-Adresse aus dem SOA-Record im DNS zusätzlich zu den Standardadressen ''hostmaster@<domain>'', ''webmaster@<domain>'', ''postmaster@<domain>'', ''admin@<domain>'' und ''administrator@<domain>'' zur Auswahl steht, um E-Mail-Challenges zu versenden, gibt es bei TCS nur die Standardadressen. Dies kann bei Domains, für die gar keine E-Mail-Adressen (und insbesondere keine dieser Standardadressen) aufgesetzt sind, problematisch sein. Hier helfen dann die weiteren Validierungsmethoden von TCS, die direkt auf DNS oder HTTPS aufsetzen.+[[de:dfnpki:tcs:codesigning|Code Signing]]
  
-=====Zertifikattypen=====+[[de:dfnpki:tcs:restapi|REST API]]
  
-====ECC oder RSA?==== 
  
-Bei Serverzertifikaten ist die Wahl des Algorithmus nicht so relevant.+====CA- und Root-Zertifikate in TCS====
  
-Bei Nutzerzertifikaten ist zu beachten, dass Zertifikate mit den ECC-Schlüsseltypen P-384 und P-256 nur für Signatur und Authentisierung, aber nicht für Verschlüsselung erwendet werden können.+Die uns bekannten Root- und CA-Zertifikate in TCS sind dokumentiert unter: [[de:dfnpki:tcs_ca_certs|TCS CA-Zertifikate]]
  
-====Serverzertifikate==== 
-Die Serverzertifikate ("OV Multi-Domain") aus TCS enthalten sowohl den Zertifikatzweck serverAuth als auch clientAuth. Es können also prinzipiell alle Zwecke mit dem Standard-Zertifikatprofile abgedeckt werden. Nicht verfügbar sind die Funktionalitäten aus: Webserver mustStaple, DomainController 
  
  
-====OV SSL oder OV Multi Domain?====+=====CAA-Records=====
  
-Wir empfehlen in jedem Fall OV Multi Domain zu verwenden. Im Zertifikatprofil OV Multi Domain sind mehrere Servernamen im Alternative Name möglichz.B. fachbereich1.example.org, fachbereich2.example.org+Wenn Sie CAA-Records im DNS setzen möchtenum die Ausstellung von Zertifikaten auf bestimmte CAs einzuschränken:
  
-Im Zertifikatprofil OV SSL wird automatisch jedem Zertifikat ein zweiter, in den meisten Fällen sicherlich unerwünschter Alternativer Name "www." hinzugefügt.+[[de:dfnpki:tcs:caa|CAA]]
  
-Beispiel: Antrag enthält "fachbereich1.example.org" => Das ausgestellte Zertifikat enthält die Namen "fachbereich1.example.org" und "www.fachbereich1.example.org".+=====Zertifikate sperren (Revoke, Revocation)=====
  
 +Zertifikate sollen üblicherweise von einem RAO oder DRAO in https://cert-manager.com/customer/DFN gesperrt werden.
  
-Es gibt eine Größenbeschränkung des CSR auf 32kEs gibt Dokumentationsfundstücke bei Sectigo, die ein Limit der Anzahl der alternativen Namen auf 250 beschreibenDiese Dokumentation ist nicht korrekt, in der Praxis konnten wir auch schon 400 alternative Namen aufnehmen. Mehr sind (innerhalb der Grenzen der CSR-Größesicherlich auch noch möglich+Die [[de:dfnpki:tcs:servercert_acme#acme-zertifikate_sperren|Sperrmechanismen von ACME]] (z.Bmit certbot revokestehen für per ACME ausgestellte Zertifikate ebenfalls zur Verfügung.
  
-====Extended Validation Zertifikate (EV)====+Unter der folgenden URL steht ein Sperrinterface bereit, in dem Sperranträge gestellt werden können: 
 +https://secure.sectigo.com/products/RevocationPortal
  
-EV-Zertifikate können nur erstellt werdennachdem in cert-manager ein sog. EV Anchor angelegt wurde. Dies ist ein spezielles administratives Zertifikatdessen Ausstellung von allen Prozeduren zur besonderen Prüfung nach EV-Standard begleitet wurde.+Hier sind allerdings weitere Authentifizierungsschritte erforderlichwie beispielsweise die Beantwortung einer E-Mail-Challengedie Bereitstellung des Private Key oder die Signierung eines vorgegebenen Datenobjektes.
  
-  * Bitte versuchen Sie auf keinen Fall, ein normales EV-Zertifikat vor der Erstellung eines EV Anchors zu beantragen. 
  
-  * Vor der Erstellung eines EV-Anchors müssen die EV-Informationen unter Settings->Organizations->Edit Tab "EV Details" korrekt sein. Diese EV Details müssen von der DFN-PCA gesetzt werden, allerdings benötigen wir Ihre Mithilfe. 
  
-Die Anleitung im GÈANT FAQ ist zu finden unter: [[https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ#TCS2020FAQ-Q:HowdoIcreateanEVAnchor?]] +======Audits======
-Versuchen Sie auf keinen Fall mehrere EV Anchor zu erstellen.+
  
-====Nutzerzertifikate====+Im Gegensatz zur DFN-PKI sind in GÉANT TCS keine regelmäßigen Audits der RA-Tätigkeit von Teilnehmern vorgesehen.
  
-Nutzerzertifikate ("Client Certificate") enthalten clientAuth und E-Mail Protectionund sind damit ebenfalls universell einsetzbar.+Im [[https://wiki.geant.org/display/TCSNT/TCS+Repository|TCS Certification Practice Statement PersonaleScience Personal and Document Signing Certificates]] wird in Kapitel 9.6.2 vereinbart:
  
-====Automatische Sperrung von Nutzerzertifikaten==== +<code>The Subscriber agrees to provide on request full documentation to the Member and/or the GÉANT Association about the procedures used to populate and maintain the identity related information in its IdP.
-===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 (GEANT Personal, GEANT IGTF-MICS und GEANT IGTF-MICS-Robot Personal). Es erfolgt keine Rückfrage und es gibt keinen Hinweis an den Zertifikatinhaber! +
- +
- +
-===Beschränkung der Anzahl der Zertifikate pro Nutzer=== +
- +
-Zusätzlich kennt das System eine Beschränkung der Anzahl der gleichzeitig gültigen Nutzerzertifikate pro Person und Zertifikatprofil: +
- +
-Pro Person können maximal zwei Zertifikate je Zertifikatprofil GEANT Personal, GEANT IGTF-MICS und GEANT IGTF-MICS-Robot Personal 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! +
-====Code Signing==== +
- +
-=== Code Signing über cert-manager === +
- +
-Die über die Oberfläche beziehbaren Code-Signing Zertifikate sind für die Signatur von Java JARs & MS Office Macros verwendbar. +
- +
-Die Zertifikatprofile ''Code Signing'' und ''GÉANT Code Signing'' unterscheiden sich in keinem Praxis-relevanten Aspekt. Im GÉANT-Profil wird als O=-Attribut der "Secondary Organization Name" verwendet (siehe Settings->Organizations). +
- +
-=== EV Code Signing === +
- +
-EV Code Signing-Zertifikate, denen beispielsweise in Microsoft SmartScreen sofort vertraut wird, müssen über einen separaten Antragsweg bestellt und zusätzlich bezahlt werden: [[https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ#TCS2020FAQ-Q:HowDoIOrderEVCodeSigningCertificates?]] +
- +
-Es müssen PDF-Formulare ausgefüllt und an den Sectigo-Support gesandt werden. Unter anderem muss die Organisation noch einmal validiert werden, auch wenn sie innerhalb von cert-manager bereits geprüft ist. +
-====Document Signing==== +
-===Tauglichkeit normaler Nutzerzertifikate=== +
-Document Signing, z.B. in Adobe, ist mit den normalen Nutzerzertifikaten prinzipiell möglich. Allerdings sind gegebenenfalls spezielle Einstellungen zu treffen, um die Vertrauenswürdigkeit der Signaturen darzustellen. Bei Adobe muss beispielsweise sowohl die Windows Integration der vertrauenswürdigen Zertifikate eingestellt werden, als auch die CA-Zertifikate "GEANT Personal CA 4" und "GEANT eScience Personal CA4" explizit als vertrauenswürdig markiert werden: +
- +
-  * Einstellungen->Unterschriften->Überprüfung->Windows Integration +
-  * Einstellungen->Unterschriften->Identitäten und vertrauenswürdige Zertifikate->Vertrauenswürdige Zertifikate, GEANT Personal CA 4 auswählen, Editieren, "Dieses Zertifikat als vertrauenswürdigen Stamm verwenden" +
- +
-Diese Einstellungen müssen von jeder Person vorgenommen werden, die die Signaturen prüfen soll. +
- +
-==="Echte" Document Signing Zertifikate=== +
-Für spezielle Document Signing Zertifikate, die voreingestellte Vertrauenswürdigkeit in Adobe haben, gibt es einen separaten Antragsweg außerhalb von cert-manager. +
- +
-Die Zertifikate kosten ca. 130,- Euro für 3 Jahre. Der Betrag ist während des Antragsprozesses direkt per Kreditkarte zu begleichen. Neben diesem Betrag entstehen zusätzliche, weitere Kosten und Aufwände, da von Sectigo eine Identitätsbestätigung der Antragsstellenden durch eine dritte Partei (Notariate, Rechtsanwaltskanzleien o.ä) gefordert wird. +
- +
-Im Zuge des Antragsprozesses wird von Sectigo eine Kopie eines Ausweisdokumentes verlangt. +
- +
-Bisherige Erfahrungen zeigen, dass Sectigo bei den bestätigenden Notariaten/Kanzleien zurückruft und eine mündliche Bestätigung des Vorgangs einholen möchte. Zur Not wird für diese Nachfrage auch E-Mail verwendet. Es werden Adressdaten genutzt, die in einem Register, bspw. der Bundesrechtsanwaltskammer, aufgeführt sind. +
- +
-Der DN der ausgestellten Zertifikate enthält je nach gewähltem Zertifikattyp entweder CN=<Einrichtung(Typ "Company") oder CN=<Name des Antragsstellers> (Typ "Individual"). +
- +
-Das Zertifikat wird von Sectigo auf Crypto-Token erstellt und versandt. +
- +
-Die Dokumentation bei GÉANT: [[https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ#TCS2020FAQ-Q:AreDocumentSigningCertificatesavailableviaSectigo?]] +
- +
-====Grid-Zertifikate (IGTF)==== +
- +
-  * Für Nutzerzertifikate, die um Grid-Umfeld verwendet werden sollen, verwenden Sie bitte eines der IGTF-Profile. +
-    * **Wichtig:** Nur bei dem Antragsweg über SAML (s.u.) wird der DN korrekt gebildet und enthält ''DC = org, DC = terena, DC = tcs, C = DE, O = <Einrichtung>''. Bei anderen Antragswegen (z.B. E-Mail Invitation) entspricht der DN nicht den im Grid-Computing verwendeten Konventionen; eventuell ist das Zertifikat dann im Grid-Umfeld nur eingeschränkt nutzbar. +
- +
-  * Für Serverzertifikate (Hostzertifikate), die im Grid-Umfeld verwendet werden sollen, verwenden Sie bitte das IGTF-Profil ''GÉANT IGTF Multi-Domain''+
- +
-=====Identifizierung und Dokumentation===== +
-====Welche Anforderungen bestehen an die Identifizierung und Dokumentation für persönliche Zertifikate (client certificates, Nutzerzertifikate)?==== +
- +
-Die Anforderungen an die Identifizierung und die Dokumentation für 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.org|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. +
- +
-====Unterschiede GÉANT Personal und GÉANT IGTF==== +
- +
-Formal unterscheiden sich die Anforderungen an die Ausstellung von Nutzerzertifikaten für die Zertifikatprofile "GÈANT Personal..." und "GÈANT IGTF...". Erstere haben etwas niedrigere Anforderungen, so ist beispielsweise keine direkte persönliche Identifizierung gefordert, sondern eine Identifizierung anhand einer Kopie eines Lichtbildausweises. +
- +
-Allerdings lässt sich bei den in TCS angebotenen Formularen zur Beantragung in der Regel nicht verhindern, dass Personen GÉANT IGTF-Zertifikate beantragen. Dies bedeutet, dass Sie in der Praxis immer die höheren Anforderungen nach IGTF erfüllen sollten. +
- +
-==== Vergleich mit DFN-AAI Advanced ==== +
- +
-Die Regeln der DFN-AAI Advanced (https://doku.tid.dfn.de/de:degrees_of_reliance) und die Regeln zur Identifizierung von Personen in TCS sind nicht deckungsgleich. +
- +
-Insbesondere lässt die DFN-AAI Advanced "etablierte Einschreibungs- und Einstellungsprozesse" zu. Ob die an Ihrer Einrichtung praktizierten Verfahren im Rahmen der DFN-AAI Advanced 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'', siehe [[de:dfnpki:tcsfaq#nutzerzertifikate1|SAML für die Beantragung von Nutzerzertifikaten]]) +
- +
-====Welche Anforderung bestehen bei Serverzertifikaten (SSL OV)?==== +
- +
-Die Anforderungen an die Identifizierung und die Dokumentation für Serverzertifikate sind im TCS Certification Practice Statement - Server, eScience Server and Code Signing Certificates festgehalten: +
- +
-[[https://wiki.geant.org/display/TCSNT/TCS+Repository]] +
- +
-=====Beantragen von Zertifikaten ohne Login im cert-manager: Web-Formulare mit Access-Code===== +
- +
-Mit Web-Formularen können Nutzer ohne eigenen Login in cert-manager Zertifikate beantragen. Zur Nutzung eines Web-Formulars ist ein sogenannter "Access Codes" notwendig. Jeder, der diesen Access Code kennt, kann Zertifikate beantragen. +
- +
-Access Codes werden von einem RAO unter Settings->Enrollment Endpoints, SSL-Web Form bzw. Client Certificate Web Form mit dem Button "Accounts" erstellt. +
- +
- +
-**Bitte richten Sie keine Accounts zur Nutzung von Web-Formularen für Nutzerzertifikate ein**. Die Nutzer können bei diesem Antragsweg beliebige Vor- und Nachnamen angeben, und Sie haben keine Möglichkeit, diese vor Ausstellung zu verifizieren. Der korrekte Weg für Nutzerzertifikate in TCS ist die Anbindung eines IdP aus der DFN-AAI, siehe hierzu die Beschreibung der Möglichkeiten über SAML. +
- +
-**Bei Accounts für SSL Web Forms setzen Sie bitte auf keinen Fall die Checkbox "Automatically Approve Requests"**. Genehmigen Sie eingehende Requests immer manuell nach Prüfung über out-of-band-Methoden (z.B. eine informelle E-Mail). +
- +
-Die URL ist für alle Web-Formulare aller Einrichtungen im DFN-Mandanten von TCS identisch: https://cert-manager.com/customer/DFN/ssl +
- +
-Erst der Access Code sorgt für die Zuordnung eines Antrags zu Ihrer Einrichtung. +
- +
-=====Wie können Zertifikate mit mehreren Servernamen erstellt werden?===== +
- +
-Zertifikate mit mehreren Servernamen (FQDN) können mit einem der "Multidomain"-Profile erstellt werden. In den Profilen ohne "Multidomain" ist nur ein Servername möglich. +
- +
-=====Was ist ein "External Requester"?===== +
- +
-Ein External Requester wird optional bei den Antragsformularen für Serverzertifikate abgefragt. Hier kann schlicht eine zusätzliche Mailadresse angegeben werden, die Benachrichtigungen zum Zertifikat erhält. +
- +
-=====Wie können Wildcard-Zertifikate erzeugt werden?===== +
- +
-Im Profil "Wildcard SSL" können direkt Wildcard-Zertifikate erzeugt werden. Es ist ein CSR der Form *.example.org einzureichen. +
- +
-=====Anmeldung an cert-manager===== +
-====Mit Nutzername/Passwort==== +
-Anmeldung mit Nutzername/Passwort ist der Default. +
-====Mit Zertifikat==== +
-Unter Admins->Edit kann für jeden RAO oder DRAO, der ein GÉANT Nutzerzertifikat besitzt, eine zertifikatbasierte Authentifizierung eingestellt werden. Diese Anmeldung ist **zusätzlich** zu dem vorhandenen Nutzername/Passwort erforderlich. +
- +
-**Achtung:** Geht das Zertifikat verloren, wird es gesperrt oder läuft es ab, ist für den RAO oder DRAO kein Zugriff mehr möglich. Eine andere Person mit gleichen oder größeren Rechten muss in dem Fall die zertifikatbasierte Authentifizierung abschalten oder ändern. +
- +
-Besonders tückische Falle: Die automatische Sperrung, wenn bereits zwei Nutzerzertifikate existieren, siehe [[https://doku.tid.dfn.de/de:dfnpki:tcsfaq#beschraenkung_der_anzahl_der_zertifikate_pro_nutzer|Beschränkung der Anzahl der Zertifikate]] +
-====SAML für Login in cert-manager.com==== +
- +
-Über den Button "Sign in with our Institution" unterhalb der Eingabefelder für Nutzername und Passwort können sich RAOs oder DRAOs in cert-manager.com über die AAI einloggen. Eine Beschreibung der Voraussetzungen ist zu finden unter: [[https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ#TCS2020FAQ-ToenableSAMLforadminaccesstoSCM:]] +
- +
-Hierbei gibt es zwei verschiedene Wege:  +
-  - Bei einem per Admins, Button "Add", manuell angelegten Account mit Passwort kann zusätzlich das Feld "Identity Provider" auf "Your Institution" gesetzt werden, und "IdP Person Id" auf den Wert des Attributes eduPersonPrincipalName. Anschließend kann sich dieser Account per Nutzername/Password und alternativ auch per SAML einloggen. +
-  - Mit dem Weg Admins, Button "Add IdP User", kann ein Account ohne Passwort angelegt werde, der sich nur über den IdP einloggen kann. Zur Zeit müssen diese Accounts noch von der DFN-PCA manuell freigeschaltet werden. Ohne Freischaltung ist kein Login möglich. +
- +
-=====SAML für das Beantragen von Zertifikaten===== +
- +
-====Tests==== +
-Unter https://cert-manager.com/customer/DFN/ssocheck/ steht ein Test-SP von Sectigo bereit, mit dem die übergebenen Attribute eingesehen werden können. +
- +
-Die DFN-AAI stellt in der //DFN-AAI Testföderation// ebenfalls [[https://doku.tid.dfn.de/de:functionaltest_idp|Test-SPs]] bereit, insbesondere https://testsp3.aai.dfn.de, mit denen die übergebenen Attribute eingesehen werden können. Dabei ist zu beachten, dass sich die lokalen Attribute-Release-Regeln im IdP zwischen dem Sectigo-SP und den Test-SPs der DFN-AAI Testföderation unterscheiden können, und daher die IdP-Konfiguration für Tests sehr genau betrachtet werden muss, um aussagekräftige Testergebnisse zu bekommen. +
- +
-====Umgang mit Multi-Valued E-Mail-Adressen==== +
- +
-Der SP von Sectigo unterstützt leider ausschließlich single-valued mail-Attribute. +
- +
-Wenn Ihr IdP standard-mäßig multi-value mail-Attribute herausgibt, kann folgendermaßen vorgegangen werden: +
-  * Vorhalten eines Feldes "idmcertrequestmail" im Identitätsmanagement, Befüllen mit der Default-Mail-Adresse +
-  * Definition eines Attributes "singlemail" im IdP +
-  * Aufstellen einer SP-spezifischen AttributeFilterPolicy +
-  * Mappen des Attributes singlemail auf mail +
- +
-<code> +
-<!-- attribute-filter.xml --> +
-<!-- Definition des zusätzlichen Attributes --> +
-<AttributeDefinition id="singlemail" xsi:type="Simple"> +
-<InputDataConnector ref="myLDAP" attributeNames="idmcertrequestmail"/> +
-</AttributeDefinition>+
 </code> </code>
  
-In der Attribute-Filter werden alle Filter der Reihe nach abgearbeitet. Falls es wie bei uns vorher schon eine allgemeine Freigabe für das E-Mail Attribut gegeben, hat muss diese wieder überschrieben werden.+=====Statusmeldungen und Wartungsankündigungen=====
  
-<code> +Statusmeldungen und Wartungsankündigungen der Sectigo-Services sind sichtbar über: https://sectigo.status.io
-<!-- attribute-filter.xml --> +
-<!--  Release some attributes to Sectigo Certificate Manager  --> +
-<AttributeFilterPolicy id="SectigoCertificateManager"> +
-<PolicyRequirementRule xsi:type="Requester" value="https://cert-manager.com/shibboleth"/>+
  
-<AttributeRule attributeID="mail"> +Die Meldungen können dort auch als E-Mail und RSS-Feed (https://status.io/pages/5938a0dbef3e6af26b001921/rss) abonniert werden.
-   <DenyValueRule xsi:type="ANY"/+
-</AttributeRule> +
-<AttributeRule attributeID="singlemail"> +
-   <PermitValueRule xsi:type="ANY"/+
-</AttributeRule>+
  
-</AttributeFilterPolicy> +=====Support=====
-</code>+
  
-Je nach eingesetzter IdP Version müssen an geeigneter Stelle noch die OID + Beschreibungen gesetzt werden: +Wir helfen auch bei technischen Schwierigkeiten mit den TCS-Systemen gerne weiter[[mailto:dfnpca@dfn-cert.de|dfnpca@dfn-cert.de]]
-<code> +
-<bean parent="shibboleth.TranscodingProperties"> +
-<property name="properties"> +
-<props merge="true"> +
-<prop key="id">singlemail</prop> +
-<prop key="transcoder">SAML2StringTranscoder SAML1StringTranscoder</prop> +
-<prop key="saml2.name">urn:oid:0.9.2342.19200300.100.1.3</prop> +
-<prop key="saml1.name">urn:mace:dir:attribute-def:mail</prop> +
-<prop key="displayName.en">E-mail</prop> +
-<prop key="displayName.de">E-Mail</prop> +
-<prop key="displayName.fr">Email</prop> +
-<prop key="displayName.it">E-mail</prop> +
-<prop key="displayName.ja">メールアドレス</prop> +
-<prop key="description.en">E-MailPreferred address for e-mail to be sent to this person</prop> +
-<prop key="description.de">E-Mail-Adresse</prop> +
-<prop key="description.de-ch">E-Mail Adresse</prop> +
-<prop key="description.fr">Adresse de courrier électronique</prop> +
-<prop key="description.it">E-Mail: l'indirizzo e-mail preferito dall'utente</prop> +
-<prop key="description.ja">メールアドレス</prop> +
-</props> +
-</property> +
-</bean> +
-</code>+
  
 +Ein direkter Kontakt mit dem englischsprachigen Sectigo Support ist auch möglich. Das Support-Portal von Sectigo ist erreichbar unter: https://sectigo.com/support-ticket 
  
 +Bitte unbedingt den folgenden Hinweis einfügen: "We are a DFN member of the GEANT TCS service, using the SCM instance https://cert-manager.com/customer/DFN."
  
-====Serverzertifikate====+Es ist zu empfehlen, vor einer direkten Kontaktaufnahme zum Sectigo Support mit uns zu sprechen.
  
-Über diesen Weg können direkt per AAI-Login Serverzertifikate beantragt werden.+===Support-Tickets für die Validierung (DCV) von IP-Adressen=== 
 +Sofern Sie ein Ticket für den speziellen [[de:dfnpki:tcs:domains#ip-adressen_in_zertifikaten|DCV-Vorgang zur Validierung von IP-Adressen]] erstellen wollen, wählen Sie bitte für das Ticket //Case type: "Technical Support"// und //Case reason: "Sectigo Certificate Manager (SCM)"// aus, damit das Ticket gleich in die korrekte Supportschlange eingestellt wird.
  
-Der IdP muss in eduGAIN eingebunden sein. Über Settings->Enrollment Endpoints und einen Klick auf den "Add"-Button muss ein Enrollment Endpoint vom Typ "SAML SSL self-enrollment form" angelegt werden. Die über diesen Enrollment Endpoint beantragbaren Zertifikatprofile müssen zugewiesen werdentypischer Weise "OV Multi-Domain" und ggf. weitere+===Support-Tickets für Anträge von Code-Signing-Zertifikate=== 
 +Sofern Sie ein Ticket für die Bearbeitung von [[de:dfnpki:tcs:codesigning|Anträgen von Code-Signing-Zertifikaten]] erstellen wollenwählen Sie bitte für das Ticket //Case type: "Validation Support"// und //Case reason: "Code Signing Certificate"// aus.
  
-Mit der Checkbox "Automatically Approve Requests" gibt es die Option, zu derart authentifizierten Anträge direkt das Zertifikat zu erstellenWir empfehlen, diese Einstellung nur nach reichlicher Überlegung zu treffen, da es nach unserem Kenntnisstand keine Möglichkeit gibt, die akzeptierten Nutzer eines IdP einzuschränken. Hiermit kann dann jeder Nutzer in Ihrem IdP jedes Serverzertifikat erstellen. Wenn Sie hier "Automatically Approve Requests" aktivieren, dann **müssen** Sie die unten beschriebene "URI Extension" als //eine Art Passwort zur automatischen Zertifikatausstellung// sehen, die entsprechend komplex ausfallen sollte.+Die Order Number ist zwingend anzugeben. Sie ist im SCM unter ☰→Certificates→Code Signing einsehbar.
  
-Ist diese Checkbox nicht aktiviert, müssen die Anträge von einem RAO oder DRAO über Certificates->Approve freigeschaltet werden.+=====E-Mail-Verteilerliste dfnpki-d=====
  
-Über die "URI Extension" wird eine einrichtungsspezifische URL angelegt, über die die Beantragung möglich ist. Diese URI Extension können Sie selbst z.B. als "sprechenden" oder sehr zufälligen Passwort-artigen URI-Teil wählen. Der endgültige Beantragungs-Link bildet sich nach dem Muster "[[de:dfnpki:tcsfaq#serverzertifikate1|https://cert-manager.com/customer/DFN/idp/ssl/<URI-EXTENSION>/select]]" also z.B. "[[de:dfnpki:tcsfaq#serverzertifikate1|https://cert-manager.com/customer/DFN/idp/ssl/Uni-Musterstadt-Server-Zertifikat-Antrag-SAML/select]]" oder "[[de:dfnpki:tcsfaq#serverzertifikate1|https://cert-manager.com/customer/DFN/idp/ssl/WO4BkhxlFtNCN4toQxcXWB/select]]".+Auf [[https://listserv.dfn.de]] ist die E-Mail-Verteilerliste mailto:dfnpki-d@listserv.dfn.de eingerichtet. Diese unmoderierte Liste soll den Austausch **unter den Teilnehmern an der DFN-PKI** befördern und die Diskussion von Problemen und die Verbreitung von Lösungsvorschlägen ermöglichen.
  
-Über die optionalen "Hilfe"-Einstellungen können Sie auf eigene InfobzwAnleitungs-Web-Seiten Ihrer Einrichtung verweisen, auf denen Sie Ihre lokalen Prozesse zur Beantragung von Serverzertifikaten über TCS mittels DFN-AAI-Login (SAML) beschreiben. +Eine Anmeldung ist **für DFN-PKI-Teilnehmer** möglich unter [[https://www.listserv.dfn.de/sympa/info/dfnpki-d]].
-====Nutzerzertifikate====+
  
-Über diesen Weg können Nutzer direkt per AAI-Login Nutzerzertifikate beziehen. Die Zertifikate werden automatisch ohne weiteren Genehmigungsschritt ausgestellt. 
- 
-In der Verwaltungsoberfläche müssen unter Settings->Organizations->Edit Tab General die Felder Secondary Organization Name und Academic code (SCHAC Home Organization) gesetzt sein. Welchen Wert der SAML-IdP Ihrer Einrichtung für dieses Attribut ausliefert, können Sie evtl. schon der Ausgabe von https://cert-manager.com/customer/DFN/ssocheck/ entnehmen. Oft entspricht dieser Wert der Haupt-Domain einer Einrichtung, also z.B. ''uni-musterstadt.de''. 
- 
-Der IdP muss in eduGAIN eingebunden sein und alle Attribute wie in folgender Beschreibung von GÈANT freigeben: [[https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ#TCS2020FAQ-TouseSAMLinordertoallowuserstoorderclientcertificates:]] 
- 
- 
-Insbesondere muss ein eduPersonEntitlement ''urn:mace:terena.org:tcs:personal-user'' gesetzt werden. 
- 
-Bitte beachten Sie die Identifizierungsvoraussetzungen, wenn Sie über diesen Weg IGTF-Zertifikate ausstellen (siehe FAQ "Identifizierung und Dokumentation"). 
- 
- 
-Wenn diese Voraussetzungen gegeben sind, können über https://cert-manager.com/customer/DFN/idp/clientgeant Zertifikate bezogen werden.  
- 
-Die Zertifikate werden automatisiert, ohne Einwirkung eines RAO oder DRAO ausgestellt. 
- 
-Achtung: Unter Settings->Enrollment Endpoints gibt es die (theoretische) Option, einen individuellen SAML Client Endpoint anzulegen. Dieser Weg führt nicht zum Erfolg, hierüber ist keine Zertifikatausstellung möglich. 
- 
-Achtung: Für Zertifikate, die auf diesem Wege ausgestellt werden, ist kein Key-Escrow möglich! 
-=====ACME===== 
-====ACME-Accounts==== 
- 
-Zur Nutzung von ACME müssen im cert-manager.com spezielle ACME-Accounts angelegt werden. Hierzu muss unter Settings->Enrollment Endpoints zu einem der ACME-Endpoints der Button Accounts betätigt werden. Dann per Button Add einen neuen Account anlegen. 
- 
-Achtung: Zustände von ACME-Accounts sind anscheinend nicht notwendigerweise komplett synchron zu Hintergrundsystemen bei Sectigo. Im Test konnte bspw. ein ACME-Account nicht direkt, sondern erst nach einer Wartezeit über Nacht gelöscht werden. 
- 
-====Ausstellen==== 
- 
-Vorausgesetzt, dass die dem Account zugewiesene Domain validiert und delegiert ist, können direkt im Anschluss Zertifikate erzeugt werden: 
- 
-<code>certbot certonly --standalone --non-interactive --agree-tos --email <Email-Adresse> --server <Sectigo-Server> --eab-kid <Wert von eab-kid> --eab-hmac-key <Wert von eab-hmac-key> --domain <FQDN> </code> 
- 
-Es können für beliebig viele FQDNs, die innerhalb der dem Account zugewiesenen Domains liegen, Zertifikate erstellt werden. 
- 
-Der ACME-Account ist anschließend auf dem System, auf dem die o.g. Zeile aufgerufen wurde, mit einem dort abgelegten Account-Key verknüpft und kann nicht ohne weiteres auf anderen Systemen durch einfache erneute Eingabe von eab-kid und eab-hmac-key verwendet werden. 
- 
-Um einen ACME-Account auf mehreren Systemen zu verwenden, muss die Account-Information des ACME-Clients kopiert werden. Für certbot liegen die Account-Informationen in /etc/letsencrypt/accounts/acme.sectigo.com 
- 
-Da die ACME-Accounts in der Regel unlimitierte Fähigkeiten zum Ausstellen von Zertifikaten haben, ist sorgfältig abzuwägen ob die Account-Infomationen zwischen mehreren Servern geteilt werden sollten oder aber besser mit separaten ACME-Accounts gearbeitet werden soll. 
- 
-Ein Ansible-Gerüst zum zentralen Erstellen eines ACME-Accounts per REST-API und zum Bezug von Zertifikaten per ACME findet sich unter: https://github.com/francescm/acme-ansible-debian-sectigo 
-====ACME-Zertifikate sperren==== 
- 
-Per ACME ausgestellte Zertifikate können nur per ACME-Client wie certbot gesperrt werden. certbot benötigt Zugriff auf die Account-Informationen von der initialen Ausstellung des Zertifikats. Wenn diese Voraussetzung gegeben ist, kann folgendermaßen gesperrt werden: 
- 
-<code>certbot revoke --cert-path <Pfad zum zu sperrenden Zertifikat> --server <Sectigo-Server></code> 
- 
-=====REST-API===== 
- 
-Die Systeme von Sectigo können per REST-API angesprochen werden. Eine Dokumentation hierzu finden Sie unter: https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA01N000000XDkE 
- 
-Die REST-API kann nur dann zum Enrollment verwendet werden, wenn unter Settings->Organizations per Button Edit in den Tabs "SSL Certificate" bzw. "Client Certificate" die Checkbox "Web-API" angekreuzt ist und ein Secret-Key eingetragen ist. Der Secret-Key wird zwar nur für eine veraltete SOAP-API aktiv verwendet, muss aber trotzdem vergeben werden. 
- 
-Es ist ein Login/Passwort eines im Cert-Manager angelegten Account zu übergeben. Die in der Dokumentation angegebene Client-Authentifizierung per Zertifikat für das REST-API ist noch nicht getestet. 
- 
-Tipp: Man kann einen Account in seiner Rolle so einschränken, dass ausschließlich der REST-API-Zugang verwendet werden kann. Hierzu unter Admins-><Auswahl>->Edit die Checkbox "WS API Only" ankreuzen. (Wichtig: Erst nachträglich nach der Vergabe des endgültigen Passworts setzen!) 
- 
-Beispiel für die Beantragung von Serverzertifikaten: 
- 
-<code>curl 'https://cert-manager.com/api/ssl/v1/enroll' -i -X POST \ 
-    -H "Content-Type: application/json;charset=utf-8" \ 
-    -H "login: <account>" \ 
-    -H "password: <passwort>" \ 
-    -H "customerUri: DFN" \ 
-    -d '{"orgId":<OrgId>,"subjAltNames":"<FQDN des Servers>","certType":<Nummer des Zertifikatprofils>,"numberServers":0,"serverType":-1,"term":365,"comments":"","externalRequester":"","customFields": [],"csr":"-----BEGIN CERTIFICATE REQUEST-----\nMIICYjCCAU...N818=\n-----END CERTIFICATE REQUEST-----"}'</code> 
- 
-Die <OrgId> ist direkt im cert-manager.com ablesbar: Settings->Organizations, Button Edit, Tab General 
- 
-Die <Nummer des Zertifikatprofils> muss einmalig mit folgendem Aufruf ermittelt werden: 
- 
-<code>curl 'https://cert-manager.com/api/ssl/v1/types' -i -X GET \ 
-    -H "Content-Type: application/json;charset=utf-8" \ 
-    -H "login: <account>" \ 
-    -H "password: <passwort>" \ 
-    -H "customerUri: DFN" \</code> 
- 
-Ausgestellte Zertifikate können mit folgendem Aufruf abgeholt werden: 
- 
-<code>curl  'https://cert-manager.com/api/ssl/v1/collect/<Antragsnummer>/<Format>' -i -X GET \ 
-    -H "Content-Type: application/json;charset=utf-8" \ 
-    -H "login: <account>" \ 
-    -H "password: <passwort>" \ 
-    -H "customerUri: DFN" \</code> 
- 
-<Antragsnummer> wurde bei einem vorherigen Aufruf von ...enroll als Rückgabewert zurückgeliefert. 
- 
-<Format> spezifiziert das Rückgabeformat, z.B. "pem", weitere mögliche Werte siehe https://sectigo.com/knowledge-base/detail/SCM-Sectigo-Certificate-Manager-REST-API/kA01N000000XDkE 
- 
-Für Nutzerzertifikate ist die Beantragung ähnlich aufgebaut. Die Aufrufe müssen an https://cert-manager.com/api/smime/v1/types, ....smime/v1/enroll und ....smime/v1/collect geschickt werden. Für weitere Details zu den Parametern ist die API-Dokumentation von Sectigo heranzuziehen. 
- 
-=====Antragsweg "Web-Formular": Schlüsselerzeugung und -hinterlegung bei Nutzerzertifikaten===== 
- 
-Für den (nicht empfehlenswerten) Antragsweg "Web-Formular" ist es möglich, Key Escrow zu konfigurieren. Bei der Einrichtung einer Organisation oder eines Departments kann ausgewählt werden, ob für die auf Serverseite erzeugten Schlüssel eine Schlüsselhinterlegung stattfinden soll. Wenn ja, wird vor dem Ausstellen von Nutzerzertifikaten von der Organisation oder dem Department durch die Rollen RAO oder DRAO ein Master Encryption Key erzeugt. Dieser Master Encryption Key liegt anschließend ausschließlich innerhalb der Organisation oder des Departments vor. 
- 
-Die geheimen Schlüssel der Nutzer werden dann an diesen Master Encryption Key verschlüsselt. 
- 
-Ein RAO oder DAO kann geheime Schlüssel von Nutzern wiederherstellen, indem der Master Encryption Key beim Wiederherstellungsprozess per Hand in ein entspr. Formular in cert-manager eingegeben wird. Zertifikate, deren Schlüssel so wiederhergestellt wurden, werden automatisch gesperrt. 
- 
-Achtung: Dies betrifft nur den Antragsweg "Web-Formular", nicht den Weg über "SAML"! 
- 
-=====CAA-Records===== 
- 
-Wenn Sie CAA-Records setzen möchten, um die Ausstellung von Zertifikaten auf bestimmte CAs einzuschränken, verwenden Sie für TCS: 
- 
-<code>muster-uni.de.       IN    CAA    0 issue "sectigo.com"</code> 
- 
- 
-Der CAA-Record muss bereits zum Zeitpunkt der Domain-Freischaltung passen, nicht erst zum Zeitpunkt der konkreten Zertifikatausstellung. 
- 
-=====Sperrinterface===== 
- 
-Zertifikate sollen hauptsächlich von einem RAO oder DRAO in https://cert-manager.com/customer/DFN gesperrt werden. 
- 
-Die Sperrmechanismen von ACME (z.B. mit certbot revoke) stehen für per ACME ausgestellte Zertifikate ebenfalls zur Verfügung. 
- 
-Unter der folgenden URL steht ein Sperrinterface bereit, in dem Sperranträge gestellt werden können: 
-https://secure.sectigo.com/products/RevocationPortal 
- 
-Hier sind allerdings weitere Authentifizierungsschritte erforderlich, wie beispielsweise die Beantwortung einer E-Mail-Challenge, die Bereitstellung des private Key oder die Signierung eines vorgegebenen Datenobjektes. 
- 
- 
-======Audits====== 
- 
-Im Gegensatz zur DFN-PKI sind in GÉANT TCS keine regelmäßigen Audits der RA-Tätigkeit von Teilnehmern vorgesehen. 
- 
-=====Status und Support===== 
- 
-Wir helfen gerne per dfnpca@dfn-cert.de 
- 
-Ein direkter Kontakt mit dem Sectigo Support ist auch möglich, es ist aber zu empfehlen, zunächst mit uns zu sprechen. Das Support-Portal von Sectigo ist erreichbar unter: https://sectigo.com/support-ticket 
- 
-Bitte unbedingt den folgenden Hinweis einfügen: "We are a DFN member of the GEANT TCS service, using the SCM instance https://cert-manager.com/customer/DFN." 
  
-Statusmeldungen der Sectigo-Services sind sichtbar über: https://sectigo.status.io 
  • Zuletzt geändert: vor 3 Jahren