Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:dfnpki:tcsfaq [2021/04/29 13:49] – [REST-API] Juergen Brauckmann
+++ de:dfnpki:tcsfaq [2024/04/15 16:13] (aktuell) – [E-Mail-Verteilerliste dfnpki-d] Reimer Karlsen-Masur
@@ 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ügung. Diese 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 Einrichtungen. Nicht alle hier beschriebenen Funktionen werden von allen Einrichtungen gleichermaßen umgesetzt. Falls Sie sich für den Bezug eines Zertifikats interessieren, wenden Sie sich bitte an Ihren lokalen Teilnehmerservice an Ihrer Heimateinrichtung.**
-=====Was ist TCS?=====
+=====Wie erhalten Einrichtungen einen Zugang?=====
-TCS (Trust Certificate Service) ist ein PKI-Angebot, dass der DFN-Verein über GÉANT bezieht. GÉANT realisiert den Dienst mit Hilfe von externen Anbietern, die über regelmäßige Ausschreibungen gefunden werden. Der aktuelle Anbieter ist Sectigo.
+Ein Zugang zu TCS kann über den Kontakt [[pki@dfn.de|pki@dfn.de]] beauftragt werden.
-Überblick über den Dienst bei GÉANT: https://www.geant.org/Services/Trust_identity_and_security/Pages/TCS.aspx
+Das initiale Setup erfolgt dann in direkter Absprache mit [[dfnpca@dfn-cert.de|dfnpca@dfn-cert.de]].
-Der DFN-Verein führt das Angebot zur Zeit in einer Pilotphase ein.
+====Gibt es eine Testumgebung für TCS REST API und die Webseiten?====
-=====Was bedeutet Pilotphase?=====
+Der TCS-Anbieter Sectigo stellt keine Testumgebung zur Verfügung.
-In der Pilotphase werden die Prozesse zum Ausrollen des Angebots an alle Teilnehmer der DFN-PKI mit einem eingeschränkten Nutzerkreis erprobt. Die Erprobung ist nicht nur in Bezug auf die internen Prozesse der DFN-PCA zur Versorgung der Teilnehmer notwendig, sondern auch zur Einschätzung der Abläufe und Vorgehensweisen des TCS-Anbieters insbesondere im Bereich der Organisationsvalidierung.
+=====Erste Schritte=====
-Hierdurch kann leider noch nicht jeder Einrichtung, die dies wünscht, sofort ein Zugang gegeben werden, da der voraussichtlich entstehende Support-Aufwand nicht abgedeckt werden kann.
+Überblick über erste Schritte nach Erhalt eines Zugangs: [[de:dfnpki:tcsfaq:ersteschritte|Erste Schritte]]
-Wenn genügend Erfahrungen vorliegen, wird das Angebot an alle Teilnehmer der DFN-PKI ausgerollt. Nach derzeitigem Stand wird dies im Sommer 2021 der Fall sein.
+=====Dokumentation=====
-=====Wie erhalten Einrichtungen einen Zugang?=====
+Bei GÉANT gibt es eine Zusammenstellung von FAQs: [[https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ]]
-Nach Abschluss der Pilotphase (voraussichtlich Sommer 2021) wird der DFN-Verein auf alle Teilnehmer der DFN-PKI zukommen, um einen Zugang zu TCS zu geben.
-Voraussetzung ist der Abschluss einer Dienstvereinbarung. Das initiale Setup erfolgt dann in direkter Absprache mit dfnpca@dfn-cert.de.
-=====Dokumentation=====
-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://sectigo.com/knowledge-base/detail/Sectigo-Certificate-Manager-SCM-Administrator-s-Guide/kA01N000000bvJA
-Die Dokumentation von Sectigo zur Administrations-Oberfläche und zu ACME ist zu finden unter https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA01N000000bvJA
+Die REST-API ist dokumentiert unter https://sectigo.com/knowledge-base/detail/Sectigo-Certificate-Manager-SCM-REST-API/kA01N000000XDkE
-Die REST-API ist dokumentiert unter https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA01N000000XDkE
+Sectigo unterhält einen Youtube-Kanal mit vielen Tutorials: https://www.youtube.com/c/Sectigo/videos
 =====Datenschutz=====
-Eine Bewertung von GÈANT zu Fragen zu Datenschutz und 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=====
-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:
-    * 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 ACME-Schnittstele
+    * Eine ACME-Schnittstelle
-    * Eine REST-API. Dokumentation: https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA01N000000XDkE
+    * Eine REST-API
+Es gibt **keine** Testumgebung.
-=====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. Es ist keine weitere Kommunikation mit der DFN-PCA erforderlich.
+=====Zugriff per AAI=====
-   * Privilegien ermöglichen u.a. das Anlegen oder modifizieren von weiteren RAOs/DRAOs. Die meisten Privilegien können nach der Erstellung eines Accounts nur noch von der DFN-PCA 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->Organizations, Button Departments wählen.
+Um Benachrichtigungen über Ereignisse wie den Ablauf von Zertifikaten oder der Gültigkeit von Domain-Valididierungen zu erhalten, können Benachrichtigungen konfiguriert werden: [[de:dfnpki:tcs:scm_notifications|Benachrichtigungen in SCM]]
-Es können dann DRAOs angelegt werden, die nur innerhalb der zugewiesenen Abteilung Zertifikate verwalten können.
+=====Domains und IPv4-Adressen in Zertifikaten=====
-=====Domainvalidierung, Domain Control Validation (DCV)=====
+Um Zertifikate zu erhalten, mü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]]
-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).
-Wichtig: Nach 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.
+=====Zertifikate erstellen=====
-Domainvalidierungen können über Settings->Domains, Submenü DCV eingesehen oder neu angestoßen werden.
+[[de:dfnpki:tcs:servercert|Serverzertifikate]]
-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:servercert_acme|Serverzertifikate per ACME]]
-=====Zertifikattypen=====
+[[de:dfnpki:tcs:usercert|Client-Zertifikate]]
-====Welchen Zertifikattyp für welchen Zweck/Service?====
-	* 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?
+[[de:dfnpki:tcs:documentsigning|Document Signing]]
-	* Die Nutzerzertifikate ("Client Certificate") enthalten clientAuth und E-Mail Protection, und sind damit ebenfalls universell einsetzbar.
-	* Die Code-Signing Zertifikate sind für die Signatur von Java JARs & MS Office Macros verwendbar. Für höherwertigen Trust müssen EV Code-Signing-Zertifikate separat bestellt werden. https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ#TCS2020FAQ-Q:HowDoIOrderEVCodeSigningCertificates
-====OV SSL oder OV Multi Domain?====
+[[de:dfnpki:tcs:codesigning|Code Signing]]
-Wir empfehlen in jedem Fall OV Multi Domain zu verwenden. Im Zertifikatprofil OV Multi Domain sind mehrere Servernamen möglich, z.B. fachbereich1.example.org, fachbereich2.example.org
+[[de:dfnpki:tcs:restapi|REST API]]
-Im Zertifikatprofil OV SSL wird automatisch jedem Zertifikat ein zweiter, in den meisten Fällen sicherlich unerwünschter Alternativer Name "www." hinzugefügt.
-Beispiel: Antrag enthält fachbereich1.example.org => Das ausgestellte Zertifikat enthält die Namen fachbereich1.example.org und !www.fachbereich1.example.org.
+====CA- und Root-Zertifikate in TCS====
-====Extended Validation Zertifikate (EV)====
+Die uns bekannten Root- und CA-Zertifikate in TCS sind dokumentiert unter: [[de:dfnpki:tcs_ca_certs|TCS CA-Zertifikate]]
-EV-Zertifikate können nur erstellt werden, nachdem in cert-manager ein sog. EV Anchor angelegt wurde. Dies ist ein spezielles administratives Zertifikat, dessen Ausstellung von allen Prozeduren zur besonderen Prüfung nach EV-Standard begleitet wurde.
-  * 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.
+=====CAA-Records=====
-Die Anleitung im GÈANT FAQ ist zu finden unter: https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ#TCS2020FAQ-Q:HowdoIcreateanEVAnchor?
+Wenn Sie CAA-Records im DNS setzen möchten, um die Ausstellung von Zertifikaten auf bestimmte CAs einzuschränken:
-Versuchen Sie auf keinen Fall mehrere EV Anchor zu erstellen.
-====Document Signing====
+[[de:dfnpki:tcs:caa|CAA]]
-Für spezielle Document Signing Zertifikate, die voreingestellten Trust in Adobe haben, gibt es einen separaten Antragsweg außerhalb von cert-manager. Es entstehen zusätzliche Kosten, da von Sectigo ein Crypto-Token erstellt und versandt wird.
+=====Zertifikate sperren (Revoke, Revocation)=====
-https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ#TCS2020FAQ-Q:AreDocumentSigningCertificatesavailableviaSectigo?
+Zertifikate sollen üblicherweise von einem RAO oder DRAO in https://cert-manager.com/customer/DFN gesperrt werden.
-====Grid-Zertifikate (IGTF)====
+Die [[de:dfnpki:tcs:servercert_acme#acme-zertifikate_sperren|Sperrmechanismen von ACME]] (z.B. mit certbot revoke) stehen für per ACME ausgestellte Zertifikate ebenfalls zur Verfügung.
-Für Nutzerzertifikate, die um Grid-Umfeld verwendet werden sollen, verwenden Sie bitte eines der IGTF-Profile.
+Unter der folgenden URL steht ein Sperrinterface bereit, in dem Sperranträge gestellt werden können:
+https://secure.sectigo.com/products/RevocationPortal
-Die Serverzertifikate aus den Standard-Profilen (z.B. "OV Multi Domain") sind direkt im Grid-Umfeld verwendbar.
+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.
-=====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
+======Audits======
-Die höchsten Anforderungen bestehen bei "TCS eScience Personal" Zertifikaten, die nach den Regeln der IGTF ausgestellt werden. Hiervon sind die Zertifikatprofile IGTF MICS und IGTF Classic betroffen, die jeweils eine persönliche Identifizierung voraussetzen. Die exakten Regeln sind bei der IGTF nachzulesen: https://www.igtf.net/ap/mics/IGTF-AP-MICS-1.3 und https://www.eugridpma.org/guidelines/authn-assurance/igtf-authn-assurance-1.1.pdf
+Im Gegensatz zur DFN-PKI sind in GÉANT TCS keine regelmäßigen Audits der RA-Tätigkeit von Teilnehmern vorgesehen.
-====Welche Anforderung bestehen bei Serverzertifikaten (SSL OV)?====
+Im [[https://wiki.geant.org/display/TCSNT/TCS+Repository|TCS Certification Practice Statement - Personal, eScience Personal and Document Signing Certificates]] wird in Kapitel 9.6.2 vereinbart:
-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:
+<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.
+</code>
-https://wiki.geant.org/display/TCSNT/TCS+Repository
+=====Statusmeldungen und Wartungsankündigungen=====
-=====Beantragen von Zertifikaten ohne Login im cert-manager: Web-Formulare mit Access-Code=====
+Statusmeldungen und Wartungsankündigungen der Sectigo-Services sind sichtbar über: https://sectigo.status.io
-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.
+Die Meldungen können dort auch als E-Mail und RSS-Feed (https://status.io/pages/5938a0dbef3e6af26b001921/rss) abonniert werden.
-Access Codes werden von einem RAO unter Settings->Enrollment Endpoints, SSL-Web Form bzw. Client Certificate Web Form mit dem Button "Accounts" erstellt.
+=====Support=====
+Wir helfen auch bei technischen Schwierigkeiten mit den TCS-Systemen gerne weiter: [[dfnpca@dfn-cert.de|dfnpca@dfn-cert.de]]
-**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.
+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
-**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).
+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."
-Die URL ist für alle Web-Formulare aller Einrichtungen im DFN-Mandanten von TCS identisch: https://cert-manager.com/customer/DFN/ssl
+Es ist zu empfehlen, vor einer direkten Kontaktaufnahme zum Sectigo Support mit uns zu sprechen.
-Erst der Access Code sorgt für die Zuordnung eines Antrags zu Ihrer Einrichtung.
+===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.
-=====Wie können Zertifikate mit mehreren Servernamen erstellt werden?=====
+===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 wollen, wählen Sie bitte für das Ticket //Case type: "Validation Support"// und //Case reason: "Code Signing Certificate"// aus.
-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.
+Die Order Number ist zwingend anzugeben. Sie ist im SCM unter ☰→Certificates→Code Signing einsehbar.
-=====Was ist ein "External Requester"?=====
+=====E-Mail-Verteilerliste dfnpki-d=====
-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.
+Auf [[https://listserv.dfn.de]] ist die E-Mail-Verteilerliste 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.
-=====Wie können Wildcard-Zertifikate erzeugt werden?=====
+Eine Anmeldung ist **für DFN-PKI-Teilnehmer** möglich unter [[https://www.listserv.dfn.de/sympa/info/dfnpki-d]].
-Im Profil "Wildcard SSL" können direkt Wildcard-Zertifikate erzeugt werden. Es ist ein CSR der Form *.example.org einzureichen.
-=====SAML=====
-Ein Einrichtungs-eigener IdP aus der DFN-AAI kann für drei verschiedene Zwecke an das TCS-System angebunden werden.
-Unter https://cert-manager.com/customer/DFN/ssocheck/ steht ein Test-SP bereit, mit dem die übergebenen Attribute eingesehen werden können.
-====SAML für Login in cert-manager.com====
-Mit diesem Weg können sich RAOs oder DRAOs in cert-manager.com 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 die Beantragung von Serverzertifikaten====
-Über diesen Weg können direkt per AAI-Login Serverzertifikate beantragt werden.
-Der IdP muss in eduGain eingebunden sein. Über Settings->Enrollment Endpoints muss ein SAML SSL Endpoint angelegt werden. Über die URI Extension wird eine einrichtungsspezifische URL angelegt, über die die Beantragung möglich ist.
-Mit der Checkbox "Automatically Approve Requests" gibt es die Option, zu derart authentifizierten Anträge direkt das Zertifikat zu erstellen. Wir 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.
-Ist diese Checkbox nicht aktiviert, müssen die Anträge von einem RAO oder DRAO über Certificates->Approve freigeschaltet werden.
-====SAML für die Beantragung von Nutzerzertifikaten====
-Ü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.
-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.
-=====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, kann direkt im Anschluss ein Zertifikat 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 <Servername> </code>
-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
-Achtung: Per ACME ausgestellte Zertifikate sind nicht in cert-manager.com sichtbar!
-====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 entweder Nutzername/Passwort eines im Cert-Manager angelegten Nutzers zu übergeben, oder aber eine Client-Authentifizierung per Zertifikat.
-Tipp: Man kann einen Nutzer 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' -H "password: $PASS" -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>' -H "password: $PASS" -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.
-=====Schlüsselerzeugung bei Nutzerzertifikaten=====
-Die Schüsselerzeugung bei Nutzerzertifikaten ("Client Certificates") geschieht bei den Antragswegen "Web-Formular" und SAML" auf Seiten der Server von Sectigo, wenn nicht explizit ein manuell erstellter PKCS#10-Request hochgeladen wird.
-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.
-=====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>
-=====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 https://cert-manager.com/customer/DFN SCM instance."