Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision |
de:dfnpki:tcsfaq [2021/05/26 10:32] – [Domainvalidierung, Domain Control Validation (DCV)] Juergen Brauckmann | de:dfnpki:tcsfaq [2023/09/05 18:20] – Juergen Brauckmann |
---|
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. | 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?===== | =====Was ist TCS?===== |
| |
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. | TCS (Trusted Certificate Service) ist ein PKI-Angebot, das 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. Überblick über den Dienst bei GÉANT: [[https://security.geant.org/trusted-certificate-services/]] |
| |
Ü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 für alle Teilnehmer der DFN-PKI ein. TCS wird die bisherige DFN-PKI "Global" mittelfristig ablösen. |
| |
Der DFN-Verein führt das Angebot zur Zeit in einer Pilotphase ein. | =====Wie erhalten Einrichtungen einen Zugang?===== |
| |
=====Was bedeutet Pilotphase?===== | Zur Zeit geht der DFN-Verein auf alle bisherigen Teilnehmer der DFN-PKI zu, um ihnen einen Zugang zu TCS zu ermöglichen. |
| |
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. | Das initiale Setup erfolgt dann in direkter Absprache mit [[mailto:dfnpca@dfn-cert.de|dfnpca@dfn-cert.de]]. |
| |
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. | ====Gibt es eine Testumgebung für TCS REST API und die Webseiten?==== |
| |
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. | Der TCS-Anbieter Sectigo stellt keine Testumgebung zur Verfügung. |
| |
=====Wie erhalten Einrichtungen einen Zugang?===== | =====Erste Schritte===== |
| |
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. | Überblick über erste Schritte nach Erhalt eines Zugangs: https://doku.tid.dfn.de/de:dfnpki:tcsfaq:ersteschritte |
| |
Voraussetzung ist der Abschluss einer Dienstvereinbarung. Das initiale Setup erfolgt dann in direkter Absprache mit dfnpca@dfn-cert.de. | |
| |
=====Dokumentation===== | =====Dokumentation===== |
| |
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 zu Datenschutz und DSGVO liegt vor: https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ#TCS2020FAQ-Q:HowdoG%C3%89ANTandSectigodealwithGDPR/dataprotection? | 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?]]. |
| |
| Die Bewertung von GÉANT wurde von der Forschungsstelle Recht im DFN überprüft. Das Ergebnis der Prüfung ist hier verfügbar: [[https://www2.dfn.de/fileadmin/3Beratung/Recht/Stellungnahmen/20220119_Stellungnahme_Datenschutzhinweise_Sectigo.pdf]]. |
| |
| Darüber hinaus wird häufiger die Frage gestellt, ob eine Auftragsverarbeitungsvereinbarung zur Nutzung des Dienstes vom DFN-Verein oder von Sectigo direkt angeboten wird. Dies ist mit der folgenden Begründung nicht notwendig und wird daher auch weder vom DFN-Verein noch von Sectigo angeboten: |
| |
| Im Rahmen der GÉANT TCS erfolgt die vertragliche Vereinbarung (Sectigo Certificate Subscriber Agreement) über die Bereitstellung des Sectigo Certificate direkt zwischen Sectigo und dem betroffenen Angehörigen des DFN-Teilnehmers. Ausschließlich in diesem Verhältnis werden personenbezogene Daten zur Erstellung und Verwaltung des Sectigo Certificate verarbeitet. Folglich haben weder GÉANT noch der DFN-Verein irgendeinen Zugriff oder Einfluss auf die Verarbeitung personenbezogener Daten bei Sectigo. Beiden steht zudem in Bezug auf die Verarbeitung bei Sectigo keinerlei Weisungsrecht zu. Das Rahmenvertragswerk zwischen DFN-Verein, GÉANT und Sectigo beschränkt sich auf die wirtschaftlichen Konditionen, zu denen Angehörige von DFN-Teilnehmern Produkte von Sectigo in Anspruch nehmen können. Sectigo entscheidet somit allein über Art, Umfang und Dauer der Verarbeitung aufgrund des Subscriber Agreement mit dem betroffenen Angehörigen des DFN-Teilnehmers und ist somit als Verantwortlicher im Sinne des Art. 4 Nr. 7 DS-GVO anzusehen. Dies schließt die Eigenschaft als Auftragsverarbeiter aus, so dass hier gemäß Art. 28 Abs. 10 DS-GVO schon keine rechtliche Möglichkeit zum Abschluss einer Auftragsverarbeitung besteht. |
=====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 Nutzerzertifikaten möglich. |
* 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 per "Access-Code" |
* Eine Ausstellung von Zertifikaten über eine SAML-Integration | * 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, Dokumentation: https://sectigo.com/knowledge-base/detail/Sectigo-Certificate-Manager-SCM-REST-API/kA01N000000XDkE |
| |
| Es gibt **keine** Testumgebung, in der Sachen ausprobiert werden könnten. |
=====Organisationsvalidierung===== | =====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. | Der Anbieter muss die Existenz und den Namen der Organisation regelmäßig über ein Register verifizieren. Der aktuelle Validierungszustand ist über das linke Seiten-Menü "Organizations" einsehbar. |
| |
Die Stammdaten der Organisation können nur von der DFN-PCA geändert werden. | Die Stammdaten der Organisation können nur von der DFN-PCA geändert werden. |
| |
=====Rollen===== | |
| |
| =====Admins, Rollen & Privilegien===== |
| |
| Im linken Seitenmenü können unter ☰->Settings->Admins weitere Accounts angelegt werden. Standard (D)RAO-Accounts mit Login via Account-Name/Passwort werden dort über das grüne "+"-Symbol angelegt. |
| |
Es wird zwischen verschiedenen Rollen unterschieden, die in sich noch einmal mit unterschiedlichen Privilegien versehen werden können. | Es wird zwischen verschiedenen Rollen unterschieden, die in sich noch einmal mit unterschiedlichen Privilegien versehen werden können. |
| |
* 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. | * 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, modifizieren oder löschen, und eine Auswahl der Zertifikattypen SSL, Client und Code Signing erstellen. |
| |
| * MRAO sind die Main Registration Authority Officer auf übergeordneter DFN-Ebene. Die MRAO-Rolle wird nicht an Personen außerhalb der DFN-PCA vergeben. Das Privileg ''Approve domain delegation'' ist ausschließlich MRAOs vorbehalten. Die MRAOs können über die üblichen Kontakte zur DFN-PCA erreicht werden, z.B. per E-Mail an [[mailto:dfnpca@dfn-cert.de|dfnpca@dfn-cert.de]]. |
| |
| Der erste RAO-Account einer Einrichtung wird von der DFN-PCA angelegt. Dieser erste RAO-Account erhält automatisch die von uns vergebenen höchstmöglichen Privilegien im SCM. Weitere RAOs oder DRAOs können dann eigenständig angelegt und verwaltet werden. |
| |
| * Privilegien ''Allow ... of peer admin'' ermöglichen auf Organisationsebene u.a. das Anlegen, Modifizieren oder Löschen von weiteren RAO-Accounts durch einen RAO-Account, analog auf Department-Ebene von weiteren DRAO-Accounts durch einen DRAO-Account. DRAO-Accounts können von jedem RAO-Account aus angelegt, modifiziert und gelöscht werden. |
| * ''Allow to manage organizations/departments'': Mit diesem Privileg darf ein RAO-Account die Organisations- und Department-Details ändern. Mit dieser Berechtigung darf ein DRAO-Account die Department-Details ändern. |
| * Mit dem Privileg ''Allow DCV'' (Domain Control Validation) kann die [[de:dfnpki:tcsfaq#domainvalidierung_domain_control_validation_dcv|Domainvalidierung]] gesteuert werden. **Achtung:** Auch ohne dieses Privileg ist das Eintragen von Domains und in bestimmten Situationen auch deren unmittelbare Verwendung möglich. |
| * Das Privileg ''Approve domain delegation'' ist ausschließlich MRAO-Accounts vorbehalten. |
| * ''Allow certificate revocation'': Mit diesem Privileg darf ein RAO/DRAO-Account die für diesen SCM-Account sichtbaren Zertifikate (also auf Organisations- und/oder Department-Ebene) sperren. |
| * WS-API only: Ein RAO/DRAO-Account kann auf eine ausschließliche API-Nutzung eingeschränkt werden (Privileg ''WS API use only'' im Dialog "Add New Client Admin", Menü ☰->Settings->Admins, Button "+"). Mit diesem Account kann dann ausschl. das REST-API bedient werden. Wichtig: Nach unseren Erkenntnissen sollte diese Checkbox erst nachträglich **nach** dem Ändern des Anfangspasswortes 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 use only'' über ☰->Settings->Admins-><Auswahl>->Edit unten im Karteireiter "Role & Privileges" angekreuzt werden. Zur Einbindung weiterer Personen mit "WS-API only"-RAO-Account legen Sie bitte zuerst einen RAO-Account an, sofern kein bestehender RAO-Account geändert werden soll, loggen sich einmal ein, um das Anfangspasswort zu ändern. Weitere Einstellungen, die unbedingt vorgenommen werden müssen, bevor das REST-API genutzt werden kann, finden sich in [[de:dfnpki:tcsfaq#rest-api|REST-API]]. |
| * E-Mail-Adressen von SCM-Admin-Accounts dürfen keine großen Buchstaben (A-Z) enthalten. Kleinschreibung (a-z) wird akzeptiert. |
| |
| Für andere/neue RAO-Accounts können die meisten Privilegien nur dann durch einen RAO-Account selbst verwaltet werden, wenn dieser RAO-Account das Privileg ''Allow editing of peer admin users''/''Allow creation of peer admin users'' besitzt und das zu vergebene Privileg selbst bereits besitzt. |
| |
| Die meisten Privilegien können für DRAO-Accounts mit einem RAO-Account selbst verwaltet werden. Um einen DRAO-Account anzulegen, muss allerdings vorher bereits ein Department eingerichtet worden sein. |
| |
| Für andere/neue DRAO-Accounts können die meisten Privilegien nur dann durch einen DRAO-Account selbst verwaltet werden, wenn dieser DRAO-Account das Privileg ''Allow editing of peer admin users''/''Allow creation of peer admin users'' besitzt und das zu vergebene Privileg selbst bereits besitzt. |
| |
| DRAOs melden sich zum Umsetzen von Privilegien, die sie selbst nicht umsetzen können bei den zuständigen RAOs oder bei einem "Peer"-DRAO mit den entsprechenden Änderungsprivilegien, die das zu vergebene Privileg bereits haben. |
| |
| RAOs melden sich zum Umsetzen von Privilegien, die sie selbst nicht umsetzen können bei den zuständigen "Peer"-RAOs mit den entsprechenden Änderungsprivilegien, die das zu vergebene Privileg bereits haben. |
| |
| Falls das aus Gründen nicht möglich ist, melden Sie sich zum Umsetzen von Privilegien bitte per E-Mail bei [[mailto:dfnpca@dfn-cert.de|dfnpca@dfn-cert.de]]. Wir klären die Situation dann mit den benannten handlungsberechtigten Personen für DFN-PKI-Belange in Ihrer Einrichtung oder mit den bestehenden RAOs der Einrichtung mit den höchsten Privilegien im SCM. |
| |
| |
| |
| ====Passworte==== |
| |
| Vorsicht bei der Vergabe von Passworten: Zeichen außerhalb von 7-bit ASCII können zwar beim Setzen des Passwortes genutzt werden, das Einloggen schlägt aber fehl. D.h., Standard-Sonderzeichen wie ''#$%&'' usw. können verwendet werden, Umlaute oder 8-Bit-Zeichen wie ''§'' oder ''€'' aber nicht. |
| |
| ====Anmeldung mit Zertifikat==== |
| Unter ☰->Settings->Admins-><Auswahl>->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]] |
| ====Anmeldung mit SAML==== |
| |
| Über den Button "Sign in with your 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:]] |
| |
| Weitere Voraussetzungen finden Sie unter [[de:dfnpki:tcsfaq#zugriff_per_aai|Zugriff per AAI]] |
| |
| Um einen Account für das Einloggen vorzubereiten, gibt es zwei verschiedene Wege: |
| - Bei einem per ☰->Settings->Admins, Button "Add", manuell angelegten Account mit Passwort kann zusätzlich das Feld "Identity Provider" auf "Your Institution" gesetzt werden, und "EPPN" auf den Wert des Attributes eduPersonPrincipalName. Anschließend kann sich dieser Account per Nutzername/Password und alternativ auch per SAML über den einrichtungseigenen IdP einloggen. |
| - Mit dem Weg ☰->Settings->Admins, Button "Add IdP User", kann ein Account ohne Passwort angelegt werden, der sich nur über den IdP einloggen kann. Ein neu angelegter Account muss von einem anderen Admin freigeschaltet werden. Ohne Freischaltung ist kein Login möglich. |
| * Ein neu angelegter IdP User in der Organisation muss von der DFN-PCA freigeschaltet werden. Beauftragen Sie die Freischaltung bitte einfach per E-Mail an [[mailto:dfnpca@dfn-cert.de|dfnpca@dfn-cert.de]]. |
| * Ein von einem RAO neue angelegter IdP User in einem Department kann von einem zweiten RAO direkt freigeschaltet werden. |
| |
Der erste RAO einer Einrichtung wird von der DFN-PCA angelegt. Weitere RAOs oder DRAOs können dann eigenständig angelegt und verwaltet werden. | Ihr IdP muss mindestens ''schacHomeOrganization'', ''eduPersonPrincipalName'' (''ePPN'') und ''mail'' an Sectigo übertragen. Die übertragenen Attribute können Sie einsehen unter: https://cert-manager.com/customer/DFN/ssocheck/ |
| |
* 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. | |
* 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===== | =====Departments===== |
| |
Zur weiteren Strukturierung der Organisation können RAOs Abteilungen anlegen. Hierzu Settings->Organizations, Button Departments wählen. | Zur weiteren Strukturierung der Organisation können RAOs Abteilungen anlegen. Hierzu im linken Seiten-Menü "Organizations" die eigene Organisation anwählen, und dann den Button Departments betätigen. |
| |
**Wichtig:** Unter "Client Certificates" bitte unbedingt "Allow Key Recovery by Master Administrators" herausnehmen! | Bitte beim Eintragen des Secondary Organization Names darauf achten, dass dessen Länge unter 64 Zeichen bleibt. Es wird sonst zu mysteriösen Fehlern bei der Zertifikatbeantragung kommen. |
| |
Es können dann DRAOs angelegt werden, die nur innerhalb der zugewiesenen Abteilung Zertifikate verwalten können. | **Wichtig:** Unter "Client Certificates" bitte unbedingt alle Punkte "Allow Key Recovery by..." herausnehmen! Es kommt sonst zu mysteriösen Fehlern bei der Zertifikatbeantragung. |
| |
=====Domainvalidierung, Domain Control Validation (DCV)===== | Im Anschluss können über ☰->Settings->Admins weitere Zugänge ("DRAOs") angelegt werden, die innerhalb der zugewiesenen Abteilung Zertifikate verwalten können. |
| |
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). | Entgegen der Intuition unterliegen DRAOs keiner besonderen Beschränkung in der Domain-Verwaltung. |
| |
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. | =====Zugriff per AAI===== |
| ====Voraussetzungen==== |
| Viele Funktionen im cert-manager können auch nach einem Login über die DFN-AAI genutzt werden. Hierzu müssen die folgenden Voraussetzungen erfüllt sein: |
| |
Domainvalidierungen können über Settings->Domains, Submenü DCV eingesehen oder neu angestoßen werden. | * In der Verwaltungsoberfläche müssen unter ☰->Organizations-><Auswahl>->✎ die Felder Secondary Organization Name und Academic code (SCHAC Home Organization) gesetzt sein. |
| * Wenn kein Academic code (SCHAC Home Organization) gesetzt ist, senden Sie bitte den entspr. Wert per E-Mail an [[mailto:dfnpca@dfn-cert.de|dfnpca@dfn-cert.de]]. |
| * Welcher Wert zu setzen ist, 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''. Im Zweifel wenden Sie sich bitte an Ihre haus-interne AAI-Administration. |
| * Ihr Identity-Provider muss in eduGAIN eingebunden sein |
| * Ihr Identity-Provider muss mindestens die Attribute ''schacHomeOrganization'', ''mail'' und ''eduPersonPrincipalName'' (''ePPN'') an den Service-Provider von Sectigo ausliefern. |
| * Für eine AttributeFilterPolicy für Ihren Identity-Provider, die die gewünschten Attribute an Sectigo überträgt, siehe https://doku.tid.dfn.de/de:shibidp:config-attributes-tcs |
| |
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. | Die Konfiguration erfordert in der Regel die Mithilfe Ihrer AAI-Administration, da oft die Attributfreigaben anzupassen sind und gegebenenfalls ein Entitlement gesetzt werden muss. |
| ====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 |
| |
| Definition des Attributs: |
| <code> |
| <!-- attribute-resolver.xml --> |
| <!-- Definition des zusätzlichen Attributes --> |
| <AttributeDefinition id="singlemail" xsi:type="Simple"> |
| <InputDataConnector ref="myLDAP" attributeNames="idmcertrequestmail"/> |
| </AttributeDefinition> |
| </code> |
| |
| Die Attribut-Filter werden der Reihe nach abgearbeitet. Falls es wie üblich schon eine allgemeine Freigabe für das E-Mail Attribut gibt, muss diese speziell für den SP ''cert-manager.com/shibboleth'' überschrieben werden: |
| |
| <code> |
| <!-- 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"> |
| <DenyValueRule xsi:type="ANY"/> |
| </AttributeRule> |
| <AttributeRule attributeID="singlemail"> |
| <PermitValueRule xsi:type="ANY"/> |
| </AttributeRule> |
| |
| </AttributeFilterPolicy> |
| </code> |
| |
| Je nach eingesetzter IdP Version müssen an geeigneter Stelle noch die OID + Beschreibungen gesetzt werden: |
| <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-Mail: Preferred 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> |
| |
| =====Domains und IPv4-Adressen in Zertifikaten===== |
| |
| Um Zertifikate zu erhalten, müssen die entsprechenden Domains oder IPv4-Adressen im SCM unter ☰->Domains eingetragen und delegiert werden. Jeder Eintrag muss über "Domain Control Validation" (DCV) validiert werden (Status muss auf "Validated" gesetzt sein). |
| |
| Für Domains gilt: Es muss zunächst die Hauptdomain eingetragen, delegiert (Delegate) und validiert (DCV) werden, z.B. ''example.org''. Nach erfolgreicher Validierung (DCV) kann dann ein Sternchen-Eintrag ''*.example.org'' eingetragen werden. Nur mit dem Sternchen-Eintrag können später Zertifikate zu beliebigen FQDNs unterhalb der Hauptdomain erzeugt werden. |
| |
| Wenn Sie CAA-Records im DNS verwenden, um die Zertifikatausstellung zu kontrollieren, so müssen die CAA-Records bereits zum Zeitpunkt der Domainvalidierung passen, und nicht erst zum Zeitpunkt der Ausstellung von Zertifikaten, siehe [[de:dfnpki:tcsfaq#caa-Records|CAA-Records]]. |
| |
| Die Validierung von IPv4-Adressen erfordert in einem etwas aufwändigeren Verfahren einen manuellen Kontakt mit dem Support. IPv6-Adressen in Zertifikaten werden im Rahmen von GÉANT TCS leider nicht unterstützt. |
| ====Domain/IPv4-Adress-Delegation==== |
| |
| ===Domains/IPv4-Adressen im SCM eintragen=== |
| |
| Im SCM können Domains und IPv4-Adressen unter ☰->Domains über das grüne "+"-Symbol auf Organisations- und/oder Department-Ebene für eine beliebige Kombination von Zertifikattypen (''SSL''-Serverzertifikate, ''Client Certificates'' und ''Code Signing''-Zertifikate) hinzugefügt werden. Wird eine Domain bzw. IP-Adresse hinzugefügt löst dieses automatisch eine Delegationsanfrage bei der DFN-PCA aus. Sobald diese Anfrage genehmigt ist, können Sie mit der Domain Control Validation (DCV) weiter machen, falls die DCV nicht bereits vorher im System durchgeführt wurde und an den neuen Eintrag "vererbt" wird. |
| |
| ===Delegationen verwalten=== |
| |
| Solange für einen Domains/IP-Address-Eintrag mindestens eine Delegation an die eigene Einrichtung bzw. das eigene Department bestehen bleibt, können diese von (D)RAOs unter ☰->Domains--><Domain-Auswahl>-->[Delegate]-Button über eine Checkbox-Matrix innerhalb der Einrichtung bzw. des Departments verwaltet werden. |
| |
| ===Domains/IP-Addressen aus SCM entfernen=== |
| |
| (D)RAOs können selbständig keine Domains bzw. IP-Adressen aus dem SCM entfernen/löschen. |
| |
| Die Entfernung einer Domain bzw. IP-Adressen impliziert die Entfernung aller dazugehörigen Delegationen. |
| |
| Um eine bereits eingetragene Domain bzw. IP-Adresse wieder aus dem SCM zu entfernen, senden Sie bitte eine E-Mail an [[mailto:dfnpca@dfn-cert.de|dfnpca@dfn-cert.de]]. |
| |
| ====Domainvalidierung, Domain Control Validation (DCV)==== |
| |
| Um Zertifikate zu erhalten, müssen die entsprechenden Domains im SCM unter ☰->Domains eingetragen werden. Nach der Eintragung muss jede Domain über "Domain Control Validation" (DCV) validiert werden (Status muss auf "Validated" gesetzt sein). |
| |
| **Ausnahme:** Wenn die eingetragene Domain ein FQDN ist und //ausschließlich// über das ACME-Protokoll mit einem Zertifikat versorgt werden soll, kann auf die Validierung (DCV) im SCM verzichtet werden. Der FQDN wird dann automatisch im Rahmen des ACME-Protokolls validiert. |
| |
| Die Domainvalidierung muss bei Sectigo alle 365 Tage wiederholt werden. Das Ablaufdatum ist im cert-manager sichtbar. |
| |
| Sofern die delegierte Domain eine **Wildcard-Domain** ist, z.B. ''*.example.org'', muss die Domainvalidierung mit einer der beiden DCV-Methoden ''E-Mail'' oder ''CNAME'' verwendet werden, damit die Wildcard-Domain voll validiert wird. |
| |
| ===Validierungsmethoden=== |
| |
| ==E-Mail== |
| |
| Domains können wie in der DFN-PKI über die Standardadressen ''hostmaster@'', ''webmaster@'', ''postmaster@'', ''admin@'' und ''administrator@'' validiert werden. Diese Standardadressen müssen in der zu validierenden Domain liegen; die zu validierende Domain muss für den E-Mail-Empfang auf diesen Adressen eingerichtet sein. |
| |
| Die E-Mail-Adresse aus dem SOA-Record im DNS steht **nicht** zur Verfügung. Wenn in der zu validierenden Domain kein Mail-Empfang möglich ist, muss eine der anderen Validierungsmethoden verwendet werden. |
| |
| ==DNS bzw. CNAME== |
| |
| Bei der CNAME-Methode muss im DNS ein von Sectigo vorgegebener CNAME für die Domain hinterlegt werden. Beispiel: |
| <code> |
| _230283408052380233432bdcad080132.example.org. CNAME 232187932234324bcadd98.9802843242dfa23098.sectigo.com. |
| </code> |
| |
| **Achtung**: Die zeitliche Abfolge der Schritte im DCV-Ablauf mittels CNAME ist entscheidend: **Zuerst** muss der vom SCM vorgegebene Alias-Name und dessen CNAME-Record von außen im DNS sichtbar sein, **erst danach** darf im SCM-DCV-Dialog auf "Submit" geklickt werden. (Analoges gilt für DCV mittels CNAME per REST-API.) |
| |
| Nach dem "Submitten" werden die DNS-Resolver von TCS automatisch innerhalb der nächsten Stunde drei Mal versuchen, den Alias-Namen aufzulösen. Falls das fehlschlägt, werden keine weiteren automatischen Versuche unternommen. In so einem Fall sollte dann der DCV-Vorgang zurückgesetzt (Mülltonnen-Symbol neben "DCV Order Status" im SCM oder entsprechender REST-API-Aufruf) und neu eingeleitet werden, wobei dann vom SCM ein anderes Alias-Name/CNAME-Paar vorgegeben werden wird. |
| |
| Nach erfolgter Validierung kann der CNAME wieder entfernt werden. Es ist davon auszugehen, dass bei einer Revalidierung (alle 365 Tage) ein anderer CNAME gesetzt werden muss. |
| |
| ==HTTP/HTTPS== |
| |
| Bei der HTTP- bzw. HTTPS-Methode muss auf dem Webserver eine von Sectigo vorgegebene Datei unter einer vorgegebenen URL abgelegt werden. |
| |
| **Achtung:** Mit dieser Methode wird nur der FQDN selbst validiert; es können keine Zertifikate für Subdomains oder Wildcards zu dem validierten Namen ausgestellt werden. |
| |
| HTTP/HTTPS sind die einzigen zugelassenen Methoden für die Validierung von IPv4-Adressen. |
| |
| ===TCS' DNS-Resolver (DCV)=== |
| |
| Für DCV nutzt TCS DNS-Resolver, die von den Quelladressen ''91.199.212.132'', ''91.199.212.133'', ''91.199.212.151'', ''91.199.212.176'', ''91.199.212.148'' oder ''2a0e:ac00:0231:8080:d00c:12ff:fe51:5511'' aus ankommen. (Stand 01/2023) |
| |
| ====Domains und Departments==== |
| |
| Department-Administratoren (DRAOs) unterliegen keiner besonderen Beschränkung in der Domain-Verwaltung. Sie können neue Domains eintragen und abhängig vom Recht ''DCV'' auch validieren lassen. |
| |
| Ist eine von einem DRAO eingetragene Domain bereits Ihrer Organisation zugewiesen und gibt es eine gültige Domain Control Validation, steht die Domain quasi sofort im Department zur Ausstellung von Zertifikaten zur Verfügung. Das gleiche gilt für im Department eingetragen Sub-Domains von bereits der Organisation zugewiesenen Parent-Domains. |
| |
| Wenn Sie Domains in eingerichteten Departments kontrollieren wollen, müssen Sie sich z.B. E-Mail Benachrichtigungen über Domain-Delegationen konfigurieren (☰→Settings→Email Notifications, Typ Domain Approved) |
| |
| |
| ====Umlaut-Domains, internationalisierte Domain-Namen (IDN), Punycode==== |
| |
| Umlaut-Domains können in deren jeweiliger Punycode-Schreibweise in die Domain-Verwaltung vom SCM aufgenommen werden und dann ganz normal wie Domains ohne Umlaute behandelt werden. |
| |
| ====IP-Adressen in Zertifikaten==== |
| |
| TCS erlaubt es aktuell, ausschließlich IPv4-Adressen in Zertifikate aufzunehmen. |
| |
| Um eine IP-Adresse in Zertifikate in den ''CommonName'' oder in den ''subjectAlternativeName'' (Typ ''ip'') aufnehmen zu können, ist wie folgt vorzugehen: |
| - IPv4-Adresse wie eine Domain im SCM unter ☰->Domains hinzufügen. Dieses löst automatisch eine Domain-Delegationsanfrage bei der DFN-PCA aus. |
| - Bestätigung der Domain-Delegation abwarten. |
| - Den DCV-Prozess für die IP-Adresse mit der Methode ''HTTP'' oder ''HTTPS'' einleiten, |
| - die dabei von Sectigo angegebene Datei mit dem angegeben Inhalt auf einen Web-Server über HTTP oder HTTPS (je nach ausgewählter DCV-Methode) unter der eingetragenen IP-Adresse und der angegeben URL zur Verfügung stellen. |
| - Den begonnenen DCV-Vorgang wieder aufrufen und ''submitten''. |
| - Den [[de:dfnpki:tcsfaq#support|Sectigo-Support]] mit einem Ticket (//Case type: "Technical Support"; Case reason: "Sectigo Certificate Manager (SCM)"//) darüber informieren, dass es einen offenen DCV-Vorgang mit der Methode HTTP/HTTPS für die IP-Adresse gibt, und darum bitten, diesen zu prüfen. |
| |
| Der Weg über den Support ist auch bei jeder turnusmäßigen, jährlichen Erneuerung der Validierung zu wiederholen. |
| |
| Es können nur einzelne IPv4-Adressen eingetragen werden, keine Adressbereiche. |
| |
| IPv6-Adressen in Zertifikaten werden von TCS nicht unterstützt. |
| |
| |
| =====Zertifikate erstellen===== |
| |
| ====Serverzertifikate==== |
| |
| ===Direkt im cert-manager=== |
| |
| Sie können als eingeloggter RAO oder DRAO direkt im cert-manager Serverzertifikate beantragen und ausstellen. |
| |
| Wählen Sie hierzu unter ☰->Certificates->SSL Certificates den grünen Button "+", und folgen Sie dem Formular. Sie müssen in jedem Fall selbst einen CSR vorbereiten und hochladen. Die theoretisch im cert-manager angebotenen Methoden "Generation of CSR..." stehen in GÉANT TCS nicht zur Verfügung und können nicht angewählt werden. |
| |
| Wählen Sie im Regelfall das Zertifikatprofil ''OV Multi-Domain''. Wählen Sie **nicht** das Zertifikatprofil ''EV Anchor'', es sei denn, Sie wollen den speziellen EV-Prozess starten. Potentielle **Falle** hierbei: Das Zertifikatprofil ''EV Anchor'' ist in der Auswahlliste an erster Stelle und vorausgewählt und es gibt auch noch das Zertifikatprofil ''EV Multi-Domain'', das ebenfalls für Standard-SSL-Zertifikate nicht genutzt werden sollte. |
| |
| ===Über die AAI==== |
| |
| Wenn Ihre Einrichtung in die DFN-AAI eingebunden ist und Ihr IdP die Voraussetzungen erfüllt (siehe [[de:dfnpki:tcsfaq#zugriff_per_aai|Zugriff per AAI]]), können Sie ein Formular aufsetzen, über das nach AAI-Authentifizierung Serverzertifikate beantragt werden können. |
| |
| - 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 "SSL 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/ssl/<URI Extension>%%'' |
| - Im selben Dialog unter Tab "Configuration" den Authentication Type "Identity Provider" anwählen. |
| - Mit "Save" abspeichern |
| - Das neue Formular auswählen |
| - 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 auswählen |
| - meist "OV Multi-Domain" |
| - "Browser" erzeugt den Schlüssel im Browser des Antragsstellenden. **Achtung**: Diese Methode erfordert eine enge zeitliche Synchronisation mit dem genehmigenden RAO/DRAO, da der Schlüssel nur temporär, sehr flüchtig beim Antragsstellenden vorliegt. Des Weiteren ist die Methode nicht ohne weiteres für Apache oder nginx geeignet, da das Zertifikat nur als PKCS12-Datei zum Download angeboten wird. |
| - Als "CSR Generation Method" üblicherweise den Wert "Provided by User" auswählen. |
| - "Browser" erzeugt den Schlüssel im Browser des Antragsstellenden. **Achtung**: Diese Methode erfordert eine enge zeitliche Synchronisation mit dem genehmigenden RAO/DRAO, da der Schlüssel nur temporär, sehr flüchtig beim Antragsstellenden vorliegt. Des Weiteren ist die Methode nicht ohne weiteres für Apache oder nginx geeignet, da das Zertifikat nur als PKCS12-Datei zum Download angeboten wird. |
| - "Automatically Approve Request" **nicht** anwählen |
| - Als "Authorization Method" den Wert "IdP Assertions Mapping" auswählen. **Nicht ''none'' verwenden!** |
| - Dann den Button ''Edit'' anwählen |
| - Hinzufügen von "''schacHomeOrganization'' matches ''<xyz.de>''", mit Plus und Save bestätigen. |
| - Wenn Sie diesen Schritt auslassen, können User aus beliebigen Identity-Providern Anträge bei Ihnen einreichen! |
| - Den Account insgesamt mittels "Save"-button abspeichern. |
| |
| Bitte keine fremden ''Enrollment Forms'' löschen! |
| |
| Anträge können nun unter der per "URI-Extension" definierten URL eingereicht werden. ''%%https://cert-manager.com/customer/DFN/ssl/<URI Extension>%%'' |
| |
| Die eingereichten Anträge müssen von einem RAO oder DRAO über ☰->Certificates->SSL Certificates-><Auswahl>->Approve Button genehmigt werden. |
| |
| |
| ===SSL Web Form=== |
| |
| Mit Web-Formularen können Personen ohne eigenen Login für den cert-manager Zertifikate beantragen. Zur Nutzung eines Web-Formulars ist ein sogenannter "Access Code" notwendig. Jeder, der diesen Access Code kennt, kann Zertifikate beantragen. |
| |
| - 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 "SSL 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/ssl/<URI Extension>%%'' |
| - Im selben Dialog unter Tab "Configuration" den Authentication Type "Email Confirmation" anwählen. |
| - Mit "Save" abspeichern |
| - Das neue Formular auswählen |
| - 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 auswhlen |
| - meist "OV Multi-Domain" |
| - Als "CSR Generation Method" üblicherweise den Wert "Provided by User" auswählen. |
| - "Browser" erzeugt den Schlüssel im Browser des Antragsstellenden. **Achtung**: Diese Methode erfordert eine enge zeitliche Synchronisation mit dem genehmigenden RAO/DRAO, da der Schlüssel nur temporär, sehr flüchtig beim Antragsstellenden vorliegt. Des Weiteren ist die Methode nicht ohne weiteres für Apache oder nginx geeignet, da das Zertifikat nur als PKCS12-Datei zum Download angeboten wird. |
| - "Automatically Approve Request" **auf keinen Fall** anwählen. |
| - Als "Authorization Method" den Wert "Access Code" auswählen. **Nicht ''none'' verwenden!** |
| - Einen Access Code eintragen |
| - Den Account mittels "Save"-button abspeichern. |
| |
| Bitte keine fremden ''Enrollment Forms'' löschen! |
| |
| Anträge können nun unter der per "URI-Extension" definierten URL eingereicht werden. ''%%https://cert-manager.com/customer/DFN/ssl/<URI Extension>%%'' |
| |
| Antragstellende werden zunächst durch eine E-Mail-Challenge geführt, mit der ihre E-Mail-Adresse verifiziert wird. Anschließend müssen sie den Access Code präsentieren, um dann mit den Parametern des hier angelegten Accounts Zertifikate beantragen zu können. |
| |
| Die eingereichten Anträge müssen von einem RAO oder DRAO über ☰->Certificates->SSL Certificates-><Auswahl>->Approve Button genehmigt werden. |
| |
| ===ACME=== |
| |
| Es stehen Endpunkte für das ACME-Protokoll zur Verfügung, mit denen mit Standard-Clients automatisiert Serverzertifikate bezogen werden können. Hinweise hierzu unter [[de:dfnpki:tcsfaq#acme1|ACME]] |
| |
| |
| ===REST-API für Serverzertifikate=== |
| |
| Über das REST API können mit selbst erstellter Software oder Skripten Serverzertifikate erstellt werden. Hinweise hierzu unter [[de:dfnpki:tcsfaq#rest-api|REST-API]] |
| |
| |
| ====Nutzerzertifikate==== |
| |
| ===E-Mail-Einladung=== |
| |
| **Achtung: Seit 28.08.23 ist aufgrund der Umstellung auf neue Richtlinien ("S/MIME-BRs") |
| die Erstellung von Nutzerzertifikaten gestört. Die folgenden Schritte führen nicht generell zum Erfolg.** |
| |
| Die Erstellung von Nutzerzertifikaten 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 and encryption", dieses mit Auswahl von Laufzeit, Algorithmus und Schlüssellänge durch den Antragsstellenden |
| * alternativ "GEANT Organisation signing and encryption - 2 Years RSA 4096" mit Limitierung auf 4096 Bit RSA mit 2 Jahr Laufzeit. * Als "CSR Generation Method" den Wert "Browser" oder "Server" auswählen. |
| * "Server" erzeugt den Schlüssel auf Sectigo-Seite |
| * "Browser" erzeugt den Schlüssel im Browser des Antragsstellenden |
| * "Allow empty PKCS12 Password" **nicht** aktivieren. |
| * Als "Authorization Method" den Wert "none" auswählen. **Achtung**: Bitte auf keinen Fall Authorization Method ''Access Code'' im Zusammenhang mit client certificates verwenden! Die Nutzenden können bei diesem Antragsweg beliebige Vor- und Nachnamen angeben. Es wird lediglich die E-Mail-Adresse verifiziert, und das Zertifikat anschließend automatisch ausgestellt. Sie haben keine Möglichkeit, Vor- und Nachnamen vor Ausstellung zu verifizieren. |
| * Mit "Save" abspeichern. |
| |
| |
| |
| 2. Anschließend werden unterhalb von ☰->Persons neue Einträge für Personen angelegt: |
| |
| * Mit dem grünen "+"-Button kann eine einzelne Person angelegt werden. |
| |
| * Zunächst die Felder ''First Name'', ''Last Name'' und ''Email Address'' ausfüllen |
| * Im folgenden Dialog den ''Common Name'' setzen |
| * Wenn die Person Zertifikate vom Typ ''GÉANT Personal email signing and encryption'' erhalten soll (inklusive vorname/Nachname im Zertifikat), so muss der Validation Type auf ''HIGH'' gesetzt werden. Voraussetzung ist, dass in Ihrer Einrichtung eine Identifizierung der Person stattgefunden hat, siehe hierzu auch [[de:dfnpki:tcsfaq##identifizierung_und_dokumentation|Identifizierung und Dokumentation]] |
| |
| * Mit dem Upload-Symbol neben dem "+"-Button kann eine CSV-Datei 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: |
| <code> |
| <Vorname>;;<Nachname>;<E-Mail-Adresse>;;High;<Organisationsname>;;<Secret ID (Passwort)>;;DE;;<eduPersonPrincipalName>;<Common Name> |
| </code> |
| Als Beispiel: |
| <code> |
| Erika;;Mustermann;brauckmann@dfn-cert.de;;High;Example GmbH;;AL07rQCsofFQfrJqqmAn ;;DE;;mustermannbrauckmann@example.org;Erika Mustermann |
| </code> |
| |
| |
| 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. **Hinweis:** Die Liste der angezeigten Enrollment Endpoints umfasst zur Zeit leider auch fremde Endpoints anderer Einrichtungen. Dieser Bug ist Sectigo bereits bekannt. |
| * 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: [[de:dfnpki:tcsfaq#identifizierung_und_dokumentation|Identifizierung und Dokumentation]]. |
| |
| |
| Hinweise zur [[de:dfnpki:tcsfaq#auswahl_des_verschluesselungsalgorithmus_fuer_p12-dateien_pkcs_12|Auswahl und Problematik des Verschlüsselungsalgorithmus]] durch die beantragende Person für ggf. über das Zertifikatantragsformular erzeugte .p12-Dateien (PKCS#12). |
| |
| ==Erneuerung== |
| |
| Über die selbst definierte URL des Enrollment Forms können Zertifikate jederzeit erneut beantragt werden. |
| |
| |
| ===Über die AAI=== |
| |
| Unter der URL https://cert-manager.com/customer/DFN/idp/clientgeant können Nutzerzertifikate direkt per AAI-Login bezogen werden. Die Zertifikate werden automatisiert ohne Einwirkung eines RAO oder DRAO ausgestellt. |
| |
| |
| Um https://cert-manager.com/customer/DFN/idp/clientgeant nutzen zu können, sind vorbereitende Konfigurationsarbeiten notwendig. Diese erfordern zwingend die Mithilfe Ihrer AAI-Administration, da in der Regel die Attributfreigaben anzupassen sind und für berechtigte Personen ein Entitlement gesetzt werden muss. |
| |
| Die folgenden Voraussetzungen müssen erfüllt sein: |
| * Grundkonfiguration siehe [[de:dfnpki:tcsfaq#zugriff_per_aai|Zugriff per AAI]] |
| * Ihr Identity-Provider muss alle Attribute wie in folgender Beschreibung von GÉANT freigeben: [[https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ#TCS2020FAQ-TouseSAMLinordertoallowuserstoorderclientcertificates:]] |
| * Ein Konfigurationsbeispiel für Ihren Identity-Provider finden Sie unter: [[de:shibidp:config-attributes-tcs?s[]=cert&s[]=manager]] |
| * Insbesondere muss ein eduPersonEntitlement ''urn:mace:terena.org:tcs:personal-user'' gesetzt werden. Bitte beachten Sie die Identifizierungsvoraussetzungen, bevor Sie das Entitlement setzen: [[de:dfnpki:tcsfaq#identifizierung_und_dokumentation|Identifizierung und Dokumentation]]. |
| * Die Fehlermeldung ''You are not allowed to self enroll.'' ist ein Symptom für ein nicht übertragenes eduPersonEntitlement ''urn:mace:terena.org:tcs:personal-user''. Der [[de:dfnpki:tcsfaq#tests|SSOcheck]] gibt Auskunft, welche Attribute tatsächlich an TCS übertragen werden. |
| |
| |
| |
| Für die Schlüsselerzeugung im AAI-Workflow gibt es in dem angebotenen Formular eine Wahlmöglichkeit: |
| * Entweder wird der private Schlüssel von Sectigo erzeugt |
| * oder aber vom Beantragenden vorab zusammen mit einem CSR generiert. Der erstellte CSR kann dann im Formular zur Zertifikaterstellung hochgeladen werden. |
| |
| |
| |
| **Achtung:** Es gibt für Client Certificates alternative Wege mit AAI-Bezug, die aber **nicht verwendet** werden sollen. (Individuelle ''Client certificate enrollment form'' mit Authentifizierung "Identity Provider"). Diese Wege erlauben den Nutzenden beliebige Vor- und Nachnamen anzugeben. Es wird lediglich die E-Mail-Adresse aus dem IdP übernommen, und das Zertifikat anschließend automatisch ausgestellt. Sie haben keine Möglichkeit, Vor- und Nachnamen vor Ausstellung zu verifizieren. |
| |
| Der korrekte Weg zu Client Certificates mit der AAI ist über https://cert-manager.com/customer/DFN/idp/clientgeant |
| |
| Hinweise zur [[de:dfnpki:tcsfaq#auswahl_des_verschluesselungsalgorithmus_fuer_p12-dateien_pkcs_12|Auswahl und Problematik des Verschlüsselungsalgorithmus]] durch die beantragende Person für ggf. über das Zertifikatantragsformular erzeugte .p12-Dateien (PKCS#12). |
| |
| ==Erneuerung== |
| |
| Über https://cert-manager.com/customer/DFN/idp/clientgeant können Zertifikate jederzeit erneut beantragt werden. |
| |
| |
| == Alternativer ''displayName'' aus dem IdP == |
| |
| Wenn der IdP keinen verwendbaren ''displayName'' liefert und die Werte nicht korrigiert werden können oder sollen, so kann ein eigenes Attribut unter dem entsprechenden SAML2-Namen ''urn:oid:2.16.840.1.113730.3.1.241'' bereitgestellt werden, hier am Beispiel von Shibboleth: |
| - In ''attribute-resolver.xml'' ein eigenes neues Attribut definieren (mit einer eigenen ''id''), z.B. ''id=″displayName2″'' vom ''xsi:type=″Template″'', siehe [[https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631563/TemplateAttributeDefinition]] |
| - Attribut ''displayName2'' in der Datei ''attribute-filter.xml'' für Sectigo freigeben (statt ''displayName'') |
| - In ''/opt/shibboleth-idp/conf/attributes/'' aus ''inetOrgPerson.xml'' die Bean-Definition für ''<prop key=″id″>displayName</prop>'' kopieren und mit dem neuen Attributnamen ''displayName2'' z.B. in ''default-rules.xml'' hinterlegen. |
| |
| |
| ===REST-API für Nutzerzertifikate=== |
| |
| Über das REST API können mit selbst erstellter Software oder Skripten Nutzerzertifikate erstellt werden. Hinweise hierzu unter [[de:dfnpki:tcsfaq#rest-api|REST-API]] |
| |
| Die Schlüsselerzeugung findet stets auf Seiten des Clients und nicht bei Sectigo statt. |
| |
| |
| |
| |
| ====Code Signing-Zertifikate==== |
| |
| ===E-Mail-Einladung=== |
| |
| Für die Erstellung von Code Signing-Zertifikaten ist eine gewisse Vorbereitung notwendig. Insbesondere muss in einem ''Enrollment Form'' ein ''Code Signing certificate enrollment form'' angelegt werden: |
| |
| - Im SCM unter ☰->Enrollment->Enrollment Forms |
| - Mit dem grünen Button "+" oben rechts **ein neues** nur Ihrer Einrichtung zugehöriges Enrollment Form erzeugen |
| - Einen sprechenden Namen vergeben, der auf Ihre Einrichtung hinweist |
| - Als Typ "Code Signing 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/cs/<URI Extension>%%'' |
| - Mit "Save" abspeichern |
| - Oben auf "Accounts" klicken. |
| - Im daraufhin geöffneten Popup-Fenster über mit dem grünen "+"-Button einen neuen "Code Signing Web Form Account" hinzufügen. |
| - Einen sprechenden Namen für den Code Signing Web Form Account vergeben, der auf Ihre Einrichtung hindeutet. |
| - Als "Organization" Ihre Einrichtung aus der Drop-Down-Liste auswählen (und ggf. auch ein Department setzen, wenn der Code Signing Web Form Account ausschließlich auf Department-Level eingerichtet werden soll). |
| - Als Zertifikatprofile stehen ''Code Signing'' und ''GÉANT Code Signing Certificate'' sowie ''GÉANT OV Code Signing (Key Attestation) - 1 year'', ''GÉANT OV Code Signing (Key Attestation) - 2 years'' und ''GÉANT OV Code Signing (Key Attestation) - 3 years'' zur Auswahl. Das gewählte Zertifikatsprofil beeinflusst neben der Zertifikatlaufzeit insbesondere die Auslieferung bzw. Bereitstellung des Zertifikats und damit auch die Lieferzeit: |
| - ''Code Signing'' und ''GÉANT Code Signing Certificate'': Diese beiden Zertifikatprofile unterscheiden sich in keinem Praxis-relevanten Aspekt. Im GÉANT-Profil wird als O=-Attribut der "Secondary Organization Name" verwendet (siehe ☰->Organizations-><Auswahl>->✎). Die Code Signing-Zertifikate sind für ein Jahr gültig. Sectigo erzeugt den Schlüssel und liefert diesen zusammen mit dem Zertifikat auf Hardware-Token per Versand aus. Für realistische Bearbeitungs- und Lieferzeiten aus Nordamerika haben wir aktuell keine Erfahrungswerte vorliegen. Die Kosten für Hardware-Token und Versand werden aktuell von GÉANT getragen. (Wir testen dieses Verfahren gerade aus.) |
| - ''GÉANT OV Code Signing (**Key Attestation**) ...''-Familie: Diese Code Signing-Zertifikate sind je nach Profilauswahl ein bis drei Jahre gültig. Sectigo liefert das Zertifikat zum direkten Download aus. Für die Bearbeitungszeit haben wir aktuell keine Erfahrungswerte vorliegen. Diese Zertifikate können ausschließlich in Hardware-Token genutzt werden, die von Sectigo explizit für eine **Key Attestation** zugelassen sind, aktuell sind das Luna Network Attached HSM 7.x und YubiKey 5 FIPS Series. Für die Zertifikatbeantragung wird im Web-Zertifikatantragsformular neben einem Certificate Signing Request (CSR) im PKCS#10 PEM-Format eben die **Key Attestation** benötigt. Wie insbesondere die **Key Attestation** erstellt wird, ist im "Code Signing Guide for Partners" im Abschnitt 3.1 für Luna HSMs und im Abschnitt 3.2 für die YubiKeys dokumentiert, herunterladbar unten auf der Web-Seite [[https://sectigo.com/knowledge-base/detail/Changes-to-Sectigo-Code-Signing-Offerings/kA03l000000BoIs]]. Siehe auch unsere eigene Beschreibung im folgenden Kapitel. |
| - Gewünschtes Zertifikatprofil aus der Drop-Down-Liste auswählen. |
| - Als "CSR Generation Method" den Wert "Sectigo Shipped FIPS certified USB Token/Key" (nur ''Code Signing'' und ''GÉANT Code Signing Certificate'') bzw. "Provided by user" (nur ''GÉANT OV Code Signing (**Key Attestation**) ...''-Familie) auswählen. |
| - Mit "Save" abspeichern. |
| |
| Bitte keine fremden ''Enrollment Forms'' löschen! |
| |
| Alte Enrollment Forms und darin bestehende Code Signing Web Form Accounts sollten nur nach sorgfältiger Abwägung gelöscht werden, da diese unter ihrer URL noch Selbstverwaltungsmöglichkeiten (insb. Sperrung) der bereits unter diesen Enrollment Forms und Account ausgestellten Code Signing-Zertifikate bieten. |
| |
| Dann zum manuellen Auslösen der einzelnen Einladungs-Mails durch (D)RAOs unterhalb von ☰->Certificates->Code Signing Certificates: |
| |
| - Mit dem "Invitations"-Button oben rechts wird ein Popup-Fenster mit einer Übersicht über die ausstehenden Einladungen für die Beantragung von Code Signing-Zertifikaten angezeigt. |
| - Mit dem grünen "+"-Button in dem Popup-Fenster kann eine einzelne Person (bestimmt durch eine E-Mail-Adresse) zur Beantragung eines Code Signing-Zertifikats per E-Mail eingeladen werden. |
| - Es muss die E-Mail-Adresse angegeben werden, an die die Einladungs-E-Mail verschickt wird. |
| - Es muss der "Enrollment Endpoint" ausgewählt werden, der im obigen Schritt angelegt worden ist. **Hinweis**: Die Liste der angezeigten Enrollment Endpoints kann zur Zeit unter Umständen leider auch fremde Endpoints anderer Einrichtungen enthalten. |
| - Es muss einer der vorher von der Einrichtung/Department angelegten "Code Signing Web Form Accounts" ausgewählt werden. |
| - Abschließend auf den "Send"-Button klicken, um die Einladungs-E-Mail zu versenden. |
| |
| Die eingegangenen Zertifikatanträge für Code Signing-Zertifikate bzw. die ausgestellten Code Signing-Zertifikate sind im SCM unterhalb von ☰->Certificates->Code Signing Certificates sichtbar und werden automatisch von Sectigo bearbeitet. |
| |
| ===Erzeugen einer Key Attestation mit Yubikey FIPS=== |
| |
| Für die Beantragung von Code Signing Zertifikaten auf einem selbst beschafften Yubikey FIPS muss wie folgt vorgegangen werden: |
| |
| 0. Bei der Beschaffung: Unbedingt die Variante Yubikey 5 **FIPS** wählen. Yubikeys ohne den Zusatz FIPS können die erforderliche Key Attestation nicht erzeugen. |
| |
| 1. Yubikey vorbereiten: |
| * ggf PIV anschalten |
| * PIN setzen. Achtung: Es gibt Werkzeuge, die das Setzen von PINs mit einer Länge von mehr als 8 Zeichen erlauben. Diese werden von der PKCS11-Library ykcs11 *nicht* unterstützt, dort funktionieren nur PINs mit 6-8 Zeichen. |
| * Default PIV Management Key vom Default 010203040506070801020304050607080102030405060708 auf was "richtiges" umsetzen |
| * PUK setzen. |
| |
| 2. Schlüssel erzeugen und den öffentlichen Teil in eine Datei ausgeben: |
| <code> |
| yubico-piv-tool -a generate --slot=9c -k -A ECCP384 -o PublicKeyFile.key |
| </code> |
| |
| 3. CSR erzeugen und in eine Datei ausgeben: |
| <code> |
| yubico-piv-tool -a verify-pin -a request-certificate --slot=9c -i PublicKeyFile.key -S <subject dn> -o request.csr |
| </code> |
| |
| (-S <subject_dn> mit Slash am Ende, z.B. -S "/CN=Jane Doe/") |
| |
| 4. Key Attestation erzeugen: |
| <code> |
| yubico-piv-tool --action=attest --slot=9c > Slot9cAttestation.pem |
| </code> |
| (funktioniert nur für Onboard erzeugte Keys, nicht für importierte) |
| |
| 5. Intermediate aus dem Yubikey auslesen |
| <code> |
| yubico-piv-tool --action=read-certificate --slot=f9 > intermediate.pem |
| </code> |
| |
| 6. Attestation-Bundle für Sectigo Webinterface erzeugen |
| <code> |
| cat Slot9cAttestation.pem intermediate.pem > attestation_bundle.pem |
| base64 -w 64 attestation_bundle.pem > attestation_bundle.b64 |
| </code> |
| Oder Windows: |
| <code> |
| type Slot9aAttestation.pem intermediate.pem > attestation.pem |
| certutil -encode attestation.pem attestation_bundle.pem |
| findstr /v CERTIFICATE attestation_bundle.pem > attestation_bundle.b64 |
| </code> |
| |
| |
| 7. Antrag stellen: |
| * Die Datei request.csr aus Schritt 3 als CSR in das Formular eingeben |
| * Den Inhalt der Datei attestation_bundle.b64 aus Schritt 6 in das Feld "Key Attestation" eingeben |
| |
| 8. Sectigo stellt das Zertifikat aus |
| |
| 9. Aufspielen der von Sectigo gelieferten Zertifikatdatei aus dem Link "as Certificate only, PEM encoded:" auf den Yubikey, z.B. mit dem YubiKey Manager |
| |
| ===Code Signing mit Yubikey FIPS=== |
| |
| **Windows:** Anleitung von Yubico für Windows Code Signing: https://support.yubico.com/hc/en-us/articles/360016614840-Code-Signing-with-the-YubiKey-on-Windows |
| |
| **Java-Code:** Signieren von Java-Code mit jarsigner: |
| * Installation der Yubico PKCS#11-Library "ykcs11" |
| * Abspeichern des von Sectigo gelieferten Zertifikats per Link aus der Auslieferungs-E-Mail "as Certificate (w/ issuer after)" als Datei "certchain.pem" |
| * Datei ykcs11.conf anlegen mit Inhalt: |
| <code> |
| name = ykcs11 |
| library = <Pfad zur libykcs11.so> |
| </code> |
| * Signieren per Aufruf: |
| <code> |
| jarsigner -keystore NONE -certchain certchain.pem -storetype PKCS11 -providerClass sun.security.pkcs11.SunPKCS11 -providerArg ykcs11.conf <Zu signierende JAR> "X.509 Certificate for Digital Signature" |
| </code> |
| |
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]] | |
=====Zertifikattypen===== | =====Zertifikattypen===== |
====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 | ====ECC oder RSA?==== |
* 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 | Bei Serverzertifikaten ist der Algorithmus entsprechend den Fähigkeiten der Server-Software zu wählen. In den meisten Fällen wird heutzutage ECC genutzt werden können. Benutzen Sie auf jeden Fall das unkomprimierte EC-Schlüsselformat (z.B. ''openssl''-Option ''-conv_form uncompressed'', was auch eigentlich die Default-Einstellung von ''openssl'' ist). |
| |
| 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 verwendet werden können. |
| |
| ====Profile für Serverzertifikate==== |
| Die Serverzertifikate aus TCS enthalten sowohl den Zertifikatzweck ''serverAuth'' als auch ''clientAuth''. Es können also prinzipiell alle Zwecke mit dem Standard-Zertifikatprofil abgedeckt werden. |
| |
| Dies gilt für alle Profile (OV Multi-Domain, OV SSL, usw.) und alle Bezugswege (cert-manager, auch ACME). |
| |
| Wählen Sie auf keinen Fall das Zertifikatprofil ''EV Anchor'', es sei denn, Sie wollen den [[de:dfnpki:tcsfaq#extended_validation_zertifikate_ev|speziellen EV-Prozess]] starten. |
| |
| **Nicht verfügbar** sind die Funktionalitäten aus den folgenden Profilen der DFN-PKI Global: ''Webserver mustStaple'', ''DomainController'' und ''Exchange Server''. Sofern für einen Exchange-Server oder Domänen-Controller //zusätzliche// Zertifikatzwecke (''extendedKeyUsage'' bzw. andere Zertifikaterweiterungen) außer ''serverAuth'' und ''clientAuth'' zwingend benötigt werden, können Sie auf die Zertifikate aus der ''[[https://www.pki.dfn.de/dfn-verein-community-pki|DFN-Verein Community PKI]]'' zurückgreifen, die allerdings ohne Browser- und Betriebssystemverankerung daherkommen. |
| |
| |
| [[de:dfnpki:tcsfaq#ip-adressen_in_zertifikaten|IP-Adressen können in Serverzertifikate aus TCS aufgenommen werden.]] |
| |
| ====Signaturalgorithmen in Serverzertifikaten mit RSA-Schlüsseln (sha256WithRSAEncryption, sha384WithRSAEncryption)==== |
| |
| Sofern Serverzertifikate mit einen RSA-Schlüssel beantragt werden, werden diese standardmäßig mit dem Signaturalgorithmus ''sha384WithRSAEncryption'' signiert. Das betrifft u.a. das Zertifikatprofil ''OV Multi Domain''. Es gibt keine explizite Möglichkeit, den Signaturalgorithmus' für ein Zertifikat zu beeinflussen. |
| |
| Falls aus technischen Gründen für ein RSA-basiertes Serverzertifikat der Signaturalgorithmus ''sha256WithRSAEncryption'' zwingend erforderlich ist, kann dieses mittels [[de:dfnpki:tcsfaq#acme|ACME]] im Endpunkt "OV" beantragt werden. Per ACME im Endpunkt "OV" ausgestellte Serverzertifikate mit RSA-Schlüsseln werden aktuell mit dem Signaturalgorithmus ''sha256WithRSAEncryption'' signiert. |
| |
| (**Achtung:** Wirklich nur Endpunkt "OV". Der Endpunkt "GEANTOV" arbeitet mit ''sha384WithRSAEncryption''.) |
| |
====OV SSL oder OV Multi Domain?==== | ====OV SSL oder OV Multi Domain?==== |
| |
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 | Wir empfehlen in jedem Fall OV Multi Domain zu verwenden. Im Zertifikatprofil OV Multi Domain sind mehrere Servernamen im Alternative Name möglich, z.B. ''fachbereich1.example.org'', ''fachbereich2.example.org''. Selbst Wildcard-Zertifikate können mit OV Multi Domain erstellt werden. |
| |
Im Zertifikatprofil OV SSL wird automatisch jedem Zertifikat ein zweiter, in den meisten Fällen sicherlich unerwünschter Alternativer Name "www." hinzugefügt. | 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. | Beispiel: Antrag enthält ''fachbereich1.example.org'' => Das ausgestellte Zertifikat enthält die Namen ''fachbereich1.example.org'' und ''www.fachbereich1.example.org''. |
| |
| |
| Es gibt eine Größenbeschränkung des CSR auf 32k. Es gibt Dokumentationsfundstücke bei Sectigo, die ein Limit der Anzahl der alternativen Namen auf 250 beschreiben. Diese Dokumentation ist nicht korrekt, in der Praxis konnten wir auch schon 400 alternative Namen aufnehmen. Die Größe für akzeptierte CSR liegt irgendwo zwischen 15000 und 19000 Byte. |
| |
| ====Wildcard-Zertifikate==== |
| |
| Voraussetzung für ein Wildcard-Zertifikat ist eine im cert-manager eingetragene Domain, die mit den Methoden EMAIL oder CNAME validiert wurde. Für Domains, die per HTTP/HTTPS validiert wurden, können keine Wildcard-Zertifikate ausgestellt werden. |
| |
| Für Wildcard-Zertifikate wählen Sie günstigerweise immer das Profil "OV Multi Domain". In diesem Profil können auch Wildcard-Namen frei sowohl im SubjectAltName als auch im CN verwendet werden. |
| |
| Im Profil "Wildcard SSL" können keine weiteren SubjectAltNames können nicht angegeben werden. Die "Wildcard SSL"-Zertifikate werden ausschließlich mit dem Wildcard-Namen und der Basis-Domain ausgestellt. |
| |
| ====VoIP-Zertifikate für DFNFernsprechen==== |
| |
| GÉANT TCS Zertifikate sind **nicht** für die Verschlüsselung von VoIP-Anschlüssen im Rahmen von DFNFernsprechen vorgesehen. |
| |
| Die SBCs des DFNFernsprechen-Dienstleisters akzeptieren sowohl Zertifikate aus der DFN-PKI Global als auch Zertifikate aus der **DFN-Verein Community PKI**, siehe https://www2.dfn.de/dienstleistungen/dfnfernsprechen/voip/verschluesselung |
| |
====Extended Validation Zertifikate (EV)==== | ====Extended Validation Zertifikate (EV)==== |
* Bitte versuchen Sie auf keinen Fall, ein normales EV-Zertifikat vor der Erstellung eines EV Anchors zu beantragen. | * 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. | * Vor der Erstellung eines EV-Anchors müssen die EV-Informationen unter ☰->Organizations-><Auswahl>->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? | Die Anleitung im GÉANT FAQ ist zu finden unter: [[https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ#TCS2020FAQ-Q:HowdoIcreateanEVAnchor?]] |
Versuchen Sie auf keinen Fall mehrere EV Anchor zu erstellen. | Versuchen Sie auf keinen Fall mehrere EV Anchor zu erstellen. |
| |
====Document Signing==== | ====Automatische Sperrung von Nutzerzertifikaten==== |
| ===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. |
| |
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. | 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. |
| |
https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ#TCS2020FAQ-Q:AreDocumentSigningCertificatesavailableviaSectigo? | 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. |
| |
====Grid-Zertifikate (IGTF)==== | Dabei gilt: |
| |
Für Nutzerzertifikate, die um Grid-Umfeld verwendet werden sollen, verwenden Sie bitte eines der IGTF-Profile. | * Sekundäre E-Mail-Adressen und der "commonName" können problemlos geändert werden. |
| |
Die Serverzertifikate aus den Standard-Profilen (z.B. "OV Multi Domain") sind direkt im Grid-Umfeld verwendbar. | * Ä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! |
| |
=====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: | ===Beschränkung der Anzahl der Zertifikate pro Nutzer=== |
| |
https://wiki.geant.org/display/TCSNT/TCS+Repository | Zusätzlich kennt das System eine Beschränkung der Anzahl der gleichzeitig gültigen Nutzerzertifikate pro Person und Zertifikatprofil: |
| |
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 | Pro Person können maximal fünf Zertifikate je Zertifikatprofil GEANT Personal, GEANT IGTF-MICS und GEANT IGTF-MICS-Robot Personal erstellt werden. |
| |
====Welche Anforderung bestehen bei Serverzertifikaten (SSL OV)?==== | 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! |
| |
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: | ====Auswahl des Verschlüsselungsalgorithmus für .p12-Dateien (PKCS#12)==== |
| |
https://wiki.geant.org/display/TCSNT/TCS+Repository | Sofern bei der Beantragung von Nutzerzertifikaten die Schlüsselerzeugung durch TCS (entweder direkt im Browser der Antrags-Web-Seiten oder auf dem Server des TCS-Dienstleisters) ausgeführt wird, kann die das Zertifikat beantragende Person aus einer Drop-Down-Liste das kryptografische Verfahren zur Sicherung des privaten Schlüssels (''Choose key protection algorithm'') in der dabei vom System erzeugten herunterzuladenen .p12-Datei auswählen. 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. |
| |
=====Beantragen von Zertifikaten ohne Login im cert-manager: Web-Formulare mit Access-Code===== | Auf einigen Systemen (z.B. Windows, iOS) kann es dann später beim Import einer mittels ''Secure AES256-SHA256'' gesicherten .p12-Datei zu Fehlern wie z.B. "//Das eingegebene Kennwort ist falsch.//", "//Fehler im zugrunde liegenden Sicherheitssystem. Ungültigen Anbietertyp angegeben//", der Aufforderung zum Einstecken einer Smartcard und ähnlichen Fehlermeldungen kommen. |
| |
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. | In so einem Fehlerfall hilft es, die betroffene .p12-Datei zunächst in den Zertifikat-Manager (unter dem Karteireiter ''Ihre Zertifikate'') vom Firefox-Browser zu importieren und dann von dort direkt wieder in eine //neue// .p12-Datei zu exportieren. Sofern das Nutzerzertifikat nicht ebenfalls im Firefox zur SSL-Client-Authentisierung genutzt werden soll, sollte dieses dann aus dem Zertifikat-Manager von Firefox wieder gelöscht werden. 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 ''Choose key protection algorithm''-Methode ''Compatible TripleDES-SHA1'' ausgewählt werden muss. |
| |
Access Codes werden von einem RAO unter Settings->Enrollment Endpoints, SSL-Web Form bzw. Client Certificate Web Form mit dem Button "Accounts" erstellt. | Die organisations-spezifische Dokumentation und Anleitung zur Nutzerzertifikatbeantragung sollte ggf. einen Hinweis auf diese möglichen Inkompatibilitäten enthalten. |
| |
| ====Code Signing==== |
| |
**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. | === Code Signing über cert-manager === |
| |
**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 über die Oberfläche beziehbaren CodeSigning-Zertifikate sind für die Signatur von Java JARs & MS Office Macros verwendbar. |
| |
Die URL ist für alle Web-Formulare aller Einrichtungen im DFN-Mandanten von TCS identisch: https://cert-manager.com/customer/DFN/ssl | Die [[de:dfnpki:tcsfaq#code_signing-zertifikate|Beantragung von CodeSigning-Zertifikaten wird über individuelle Einladungs-E-Mails]] eingeleitet. |
| |
Erst der Access Code sorgt für die Zuordnung eines Antrags zu Ihrer Einrichtung. | === EV Code Signing === |
| |
=====Wie können Zertifikate mit mehreren Servernamen erstellt werden?===== | EV Code Signing-Zertifikate, denen beispielsweise in Microsoft SmartScreen sofort vertraut wird, müssen über einen separaten Antragsweg bestellt und zusätzlich bezahlt 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. | Die Beantragung erfolgt außerhalb des Cert-Managers. Eine Anleitung findet sich unter [[https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ#TCS2020FAQ-Q:HowDoIOrderEVCodeSigningCertificates?]] (Hinter dem Link "GUIDE" versteckt sich eine ausführliche Anleitung als PDF-Dokument) |
| |
=====Was ist ein "External Requester"?===== | ====Document Signing==== |
| ===Rechtliche Grundlagen=== |
| Erläuterungen zu dem rechtlichen Aspekt finden Sie unter: [[de:dfnpki:sigsie_faq|Rechtliche Grundlagen elektronischer Signaturen]] |
| |
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. | Eine Präsentation ist verfügbar unter: {{ :de:dfnpki:dokumentensignatur_2022.pdf |Technische und rechtliche Aspekte bei Dokumentensignaturen}} |
| |
=====Wie können Wildcard-Zertifikate erzeugt werden?===== | ===Tauglichkeit normaler Nutzerzertifikate=== |
| Document Signing, z.B. in Adobe, ist mit den normalen Nutzerzertifikaten zwar technisch möglich, es müssen aber recht hohe Hürden überwunden werden. Insbesondere sind bei den Prüfern der Signaturen spezielle Einstellungen zu treffen, um die Vertrauenswürdigkeit der Signaturen darzustellen. |
| |
Im Profil "Wildcard SSL" können direkt Wildcard-Zertifikate erzeugt werden. Es ist ein CSR der Form *.example.org einzureichen. | Eine sehr detaillierte Anleitung wird von der Universität Münster zur Verfügung gestellt: https://www.uni-muenster.de/CA/de/howto-setup-acroread.html |
| |
=====SAML===== | Diese Einstellungen müssen von jeder Person vorgenommen werden, die die Signaturen prüfen soll. |
| |
Ein Einrichtungs-eigener IdP aus der DFN-AAI kann für drei verschiedene Zwecke an das TCS-System angebunden werden. | Zur rechtlichen Bewertung der auf diese Art erzeugten Signaturen ("Fortgeschritten nach eIDAS") können wir keine Aussage treffen. Die Ansprüche an qualifizierte Signaturen werden keinesfalls erfüllt. |
| |
| ===Document Signing Zertifikate=== |
| Im Rahmen von TCS können von Sectigo kostenpflichtige, rabattierte Document Signing Zertifikate bezogen werden, denen ohne weitere Konfigurationsarbeiten direkt in Adobe vertraut wird. Diese Zertifikate sind über die Adobe Approved Trust List verankert. |
| |
Unter https://cert-manager.com/customer/DFN/ssocheck/ steht ein Test-SP bereit, mit dem die übergebenen Attribute eingesehen werden können. | Den Ansprüchen von qualifizierten Signaturen genügen die mit diesen Zertifikaten erzeugten Signaturen aus formalen Gründen nicht. Zur weiteren rechtlichen Bewertung ("Fortgeschritten nach eIDAS") können wir keine Aussage treffen. |
| |
====SAML für Login in cert-manager.com==== | Für den Bezug dieser Zertifikate gibt es einen separaten Antragsweg außerhalb von cert-manager. |
| |
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: | Die Zertifikate kosten ca. 130,- Euro für 3 Jahre. Der Betrag ist während des Antragsprozesses direkt per Kreditkarte oder PayPal 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. 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. |
| |
Hierbei gibt es zwei verschiedene Wege: | Im Zuge des Antragsprozesses wird von Sectigo die Einsendung einer Kopie eines Ausweisdokumentes verlangt. Das Zertifikat wird von Sectigo auf Crypto-Token erstellt und versandt. Der DN der ausgestellten Zertifikate enthält je nach gewähltem Zertifikattyp entweder CN=<Einrichtung> (Typ "Company") oder CN=<Name des Antragsstellers> (Typ "Individual"). |
- 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==== | Die Beantragung führen Sie bitte wie in der Dokumentation von GÉANT dargestellt durch: [[https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ#TCS2020FAQ-Q:AreDocumentSigningCertificatesavailableviaSectigo?]] (Hinter dem Link "GUIDE" verbirgt sich eine ausführliche PDF-Dokumentation) |
| |
Über diesen Weg können direkt per AAI-Login Serverzertifikate beantragt werden. | ===Qualifizierte Zertifikate=== |
| |
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. | Sectigo hat auch ein Angebot für qualifizierte Zertifikate, die über die EU Trusted List auch in Adobe verankert sind. Dieses Angebot ist aber nicht Bestandteil des derzeitigen Leistungsumfangs von TCS und ist nicht rabattiert. |
| |
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. | Auch die qualifizierten Zertifikate müssen über einen separaten Antragsweg außerhalb von cert-manager bezogen werden. |
| |
Ist diese Checkbox nicht aktiviert, müssen die Anträge von einem RAO oder DRAO über Certificates->Approve freigeschaltet werden. | ====Grid-Zertifikate (IGTF)==== |
| |
====SAML für die Beantragung von Nutzerzertifikaten==== | * Für Nutzerzertifikate, die im 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. |
| |
Über diesen Weg können Nutzer direkt per AAI-Login Nutzerzertifikate beziehen. Die Zertifikate werden automatisch ohne weiteren Genehmigungsschritt ausgestellt. | * Für Serverzertifikate (Hostzertifikate), die im Grid-Umfeld verwendet werden sollen, verwenden Sie bitte das IGTF-Profil ''GÉANT IGTF Multi-Domain''. |
| |
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. | ====Gruppenzertifikate==== |
| Die aus der DFN-PKI bekannten Gruppen- und Pseudonymzertifikate können |
| in TCS abgebildet werden, indem im SCM wie folgt vorgegangen wird: |
| |
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: | Zunächst die [[de:dfnpki:tcsfaq#e-mail-einladung|Nutzerzertifikatbeantragung mittels E-Mail-Einladung]] vorbereiten. Dann |
| |
| * ☰->Persons, grünen "+"-Button betätigen |
| * Daten im ersten Dialog ausfüllen und mit OK bestätigen: |
| - ''First Name'' und ''Last Name'' für die hauptverantwortliche Person der Gruppe. |
| - E-Mail-Adresse auf die Gruppen-Mail-Adresse |
| * Im nächsten großen Dialog Feld ''Common Name'' auf den Gruppennamen setzen |
| * Den Button "Save" betätigen |
| * Den neuen Eintrag auswählen, Button "Edit" betätigen. |
| * Im neuen Dialog Reiter "Enrollment Invitations" anwählen |
| * Dort hinter "Invitations" das "+"-Symbol betätigen |
| * Das gewünschte ''Enrollment Form auswählen'', das im ersten Schritt angelegt wurde ([[de:dfnpki:tcsfaq#e-mail-einladung|Nutzerzertifikatbeantragung 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. |
| |
Insbesondere muss ein eduPersonEntitlement urn:mace:terena.org:tcs:personal-user gesetzt werden. | ====CA- und Root-Zertifikate in TCS==== |
| |
Bitte beachten Sie die Identifizierungsvoraussetzungen, wenn Sie über diesen Weg IGTF-Zertifikate ausstellen (siehe FAQ "Identifizierung und Dokumentation"). | Die uns bekannten Root- und CA-Zertifikate in TCS sind dokumentiert unter: [[de:dfnpki:tcs_ca_certs|TCS CA-Zertifikate]] |
| |
| ====SCM-Download-Formate für Zertifikate==== |
| |
Wenn diese Voraussetzungen gegeben sind, können über https://cert-manager.com/customer/DFN/idp/clientgeant Zertifikate bezogen werden. | SCM und Zertifikat-E-Mails bieten mehrere Download-Formate für die Zertifikate an: |
| |
Die Zertifikate werden automatisiert, ohne Einwirkung eines RAO oder DRAO ausgestellt. | - Server-Zertifikate: |
| - ''as Certificate only, PEM encoded'' enthält ausschließlich das Server-Zertifikat im PEM-Format (''–––––BEGIN CERTIFICATE––––– [...] –––––END CERTIFICATE–––––''). |
| - ''as Certificate (w/ issuer after), PEM encoded'' enthält als erstes das Server-Zertifikat, dann das Issuing-CA-Zertifikat und dann weitere Intermediate-CA-Zertifikate der CA-Kette, allerdings nicht das Root-CA-Zertifikat, alle Zertifikate jeweils für sich im PEM-Format (''–––––BEGIN CERTIFICATE––––– [...] –––––END CERTIFICATE–––––''). Dieses Format kann gut für die Konfiguration von z.B. **Apache-** und **Nginx-Web-Servern** verwendet werden. |
| - ''as Certificate (w/ chain), PEM encoded'' enthält als erstes das Root-CA-Zertifikat, es folgen die Intermediate-CA-Zertifikate, das Issuing-CA-Zertifikat der CA-Kette und als letztes das Server-Zertifikat, alle Zertifikate jeweils für sich im PEM-Format (''–––––BEGIN CERTIFICATE––––– [...] –––––END CERTIFICATE–––––''). |
| - ''as PKCS#7'' enthält eine binäre PKCS#7-Struktur, bestehend aus als erstes dem Server-Zertifikat, dann dem Issuing-CA-Zertifikat und dann weitere Intermediate-CA-Zertifikate der CA-Kette und am Ende dem Root-CA-Zertifikat. Dieses Format kann gut für die Konfiguration von z.B. **Microsoft IIS-Web-Servern** verwendet werden. |
| - ''PKCS#7, PEM encoded'' enthält eine PEM-formatierte PKCS#7-Struktur, bestehend aus als erstes dem Server-Zertifikat, dann dem Issuing-CA-Zertifikat und dann weitere Intermediate-CA-Zertifikate der CA-Kette und am Ende dem Root-CA-Zertifikat. |
| |
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. | - CA-Zertifikate: |
| - ''as Root/Intermediate(s) only, PEM encoded'' enthält die CA-Zertifikatskette (ohne das Server-Zertifikat) von der Root-CA (zuerst) bis hin zur Issuing-CA des Server-Zertifikats, alle Zertifikate jeweils für sich im PEM-Format (''–––––BEGIN CERTIFICATE––––– [...] –––––END CERTIFICATE–––––''). |
| - ''as Intermediate(s)/Root only, PEM encoded'' enthält die CA-Zertifikatskette (ohne das Server-Zertifikat) von der Issuing-CA des Server-Zertifikats (zuerst) bis hin zum Root-CA-Zertifikat, alle Zertifikate jeweils für sich im PEM-Format (''–––––BEGIN CERTIFICATE––––– [...] –––––END CERTIFICATE–––––''). |
| |
| =====Identifizierung und Dokumentation===== |
| |
| Die Anforderungen an die Identifizierung und die Dokumentation für persönliche Zertifikate (client certificates, Nutzerzertifikate) sind im TCS Certification Practice Statement - Personal, eScience Personal and Document Signing Certificates festgehalten: [[https://wiki.geant.org/display/TCSNT/TCS+Repository]] |
| |
| Die dort für "TCS eScience Personal" referenzierten Anforderungen der [[https://www.igtf.net|IGTF]] finden sich im Dokument "IGTF Levels of Authentication Assurance": https://www.eugridpma.org/guidelines/authn-assurance/igtf-authn-assurance-1.1.pdf |
| |
| Die wichtigsten Punkte: |
| |
| * Vor der Ausstellung eines Zertifikats soll eine persönliche Identifizierung mit einem Lichtbildausweis oder andere gültigen offiziellen Dokumenten durchgeführt werden. |
| * Alternativ ist auch eine Video-Identifizierung oder eine Identifizierung über einen Notar möglich. |
| * Alternativ genügt auch eine bestehende andauernde Beziehung zum Zertifikatnehmer, z.B im Rahmen eines Beschäftigungsverhältnisses, wenn hierdurch der Account im IdM (und damit der AAI) gesichert ist und zu Beginn eine Prüfung der Identität mit einem vergleichbaren Niveau, wie oben beschrieben, stattgefunden hat. |
| |
| Im Unterschied zur DFN-PKI "Global" muss eine Identifizierung **nicht** von speziell benannten Teilnehmerservice-Mitarbeitern durchgeführt und auch **nicht** regelmäßig wiederholt werden. Eine Feststellung der Identität z.B. im Rahmen von Einstellungsprozessen reicht aus. |
| |
| Die Dokumentation der Identifizierung muss nicht über die Verfahren hinausgehen, die für die üblichen Einrichtungs-internen Prozesse im Rahmen eines Beschäftigungsverhältnisses oder eines Studiums notwendig |
| sind. Die Einrichtung muss mit ihrer Dokumentation in der Lage sein, den Namen im Zertifikat auf eine konkrete Person zurückzuführen. |
| |
| ====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 ==== |
| |
| Die Regeln zur [[de:aai:assurance|Identity Assurance in der DFN-AAI]] und die Regeln zur Identifizierung von Personen in TCS sind nicht deckungsgleich. |
| |
| In der DFN-AAI gilt das [[https://wiki.refeds.org/display/ASS/REFEDS+Assurance+Framework+ver+1.0|REFEDS Assurance Framework]] mit seinen verschiedenen Einstufungen. Ob die an Ihrer Einrichtung praktizierten Verfahren im Rahmen der DFN-AAI den oben genannten Regeln von GÉANT TCS genügen, kann darum nicht pauschal beantwortet werden, sondern muss von Ihnen bewertet werden. |
| |
| Vor einer gründlichen Prüfung der internen Prozesse sollten darum auf keinen Fall pauschal alle Personen in Ihrem IdP für den Zertifikatbezug freigeschaltet werden (Setzen des Attributs eduPersonEntitlement mit |
| Wert ''urn:mace:terena.org:tcs:personal-user'') |
| |
| =====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. |
| |
Achtung: Für Zertifikate, die auf diesem Wege ausgestellt werden, ist kein Key-Escrow möglich! | |
=====ACME===== | =====ACME===== |
| ====ACME Clients==== |
| |
| Zum Bezug von Zertifikaten per ACME stehen eine Fülle von clients zur Verfügung. Neben dem bekannten ''certbot'' können auch andere Clients wie ''acme.sh'' oder ''win-acme'' verwendet werden. |
| |
| Einzige Voraussetzung: Es muss ein Mechanismus namens "External Account Binding" unterstützt werden (bei ''GetSSL'' beispielsweise mit Stand 09/2021 nur mit einem Patch). |
====ACME-Accounts==== | ====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. | Zur Nutzung von ACME müssen im cert-manager.com spezielle ACME-Accounts angelegt werden. Hierzu muss unter ☰->Enrollment->ACME 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. | Nach dem Anlegen hat ein Account zunächst den Zustand ''pending''. Sobald der Account mit einem ACME-Client verwendet wurde, wechselt er in den Zustand ''valid''. |
| |
| |
| ====Domains in ACME-Accounts==== |
| |
| Einem ACME-Account müssen vor dessen Nutzung bereits delegierte Domains zugeordnet werden. Die Domains müssen nicht notwendigerweise bereits validiert sein. |
| |
| * Für nicht validierte Domains muss im Laufe der Zertifikatausstellung eine ACME-Challenge beantwortet werden (automatisch durch den ACME-Client). Im Standard-Fall ist dafür eine Inbound-Verbindung von Sectigo zu einem Webserver auf dem zu zertifizierenden Domainnnamen erforderlich. |
| |
| * Für bereits validierte Domains ist keine ACME-Challenge und damit keine Inbound-Verbindung erforderlich. |
| |
| Es ist zu beachten, dass einem ACME-Account **keine** Stern-Domains (z.B. ''*.example.org'') zugeordnet werden dürfen. Die Zuordnung von solchen Stern-Domains hat im Kontext von ACME-Accounts keinen weiteren "Wildcard-Effekt". |
| |
| Die Zuordnung von Nicht-Stern-Domains (z.B. ''example.org'') genügt im Kontext von ACME-Accounts bereits vollständig aus, um sowohl Zertifikate für die eingetragene Domain selbst (in diesem Beispiel also ''example.org'') **als auch** für **alle** unterhalb von der explizit eingetragenen Domain möglichen FQDNs (auch unter Sub-Domains) (z.B. ''www.example.org'' und ''blog.it.example.org'') per ACME auszustellen. Siehe auch [[de:dfnpki:tcsfaq#schutz_von_acme-accounts|Schutz von ACME-Accounts]]. |
| |
| Eine häufige Fehlermeldung durch einen ACME-Client im Zusammenhang mit fälschlich zugewiesenen Stern-Domains im ACME-Kontext ist ''The client lacks sufficient authorization...''. Weitere Details dazu finden sich auch in der SCM-Knowledgebase unter https://sectigo.com/knowledge-base/detail/Sectigo-Certificate-Manager-SCM-ACME-error-The-client-lacks-sufficient-authorization/kA03l00000117Sy. |
| |
| ====Schutz von ACME-Accounts==== |
| |
| Die Daten eines ACME-Accounts (konkret die Werte ''eab-kid'' und ''eab-hmac-key'') sollten mindestens wie private Schlüssel für Serverzertifikate behandelt und geschützt werden. Dies gilt auch für die Daten in der Installation des ACME-Clients, z.B. das Verzeichnis ''/etc/letsencrypt''. |
| |
| Je nach Domains, die dem ACME-Account zugewiesen wurden, hat eine Komprimittierung des Accounts oder der Installationsdaten sogar deutlich größere Auswirkungen. Denn: In ACME-Accounts können für alle zugewiesenen einfachen Domainnamen beliebige Zertifikate unter weiteren Sub-Domains ausgestellt werden. |
| |
| Beispiel: Wenn Sie für Ihren Haupt-Webserver Zertifikate für ''example.org'' und ''www.example.org'' benötigen und einen entsprechenden ACME-Account mit diesen zugewiesenen Domainnamen erstellen, erlauben Sie automatisch die Ausstellung von Zertifikaten auf weiteren beliebigen Sub-Domains wie ''internal.it.example.org''. |
| |
| Dieser ACME-Account ist dann je nach Risikoanalyse nicht unbedingt dafür geeignet, in einer ausgelagerten Hosting-Umgebung betrieben zu werden, und sollte eher auf einer spezialisierten, geschützten "cerbot-Maschine" verwendet werden. |
| |
====Ausstellen==== | ====Ausstellen==== |
| |
Vorausgesetzt, dass die dem Account zugewiesene Domain validiert und delegiert ist, kann direkt im Anschluss ein Zertifikat erzeugt werden: | 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 <Servername> </code> | <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> |
| |
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. | Es können für beliebig viele FQDNs, die innerhalb der dem Account zugewiesenen Domains liegen, Zertifikate erstellt 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. | 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 | 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==== | ====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: | Per ACME ausgestellte Zertifikate können per ACME-Client (z.B. 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> | <code>certbot revoke --cert-path <Pfad zum zu sperrenden Zertifikat> --server <Sectigo-Server></code> |
| |
| Eine Sperrung per Cert-Manager ist auch möglich. Der unverständliche Informationsdialog kann ignoriert werden. |
| |
| ====ACME-Fehlermeldungen==== |
| |
| ===The identifiers are not all linked to the same preauthorized Subject organization name/address=== |
| |
| Certbot meldet ''The identifiers are not all linked to the same preauthorized Subject organization name/address''. Geben Sie certbot explizit die Account-ID mit der Option ''--account ACCOUNT_ID'' mit oder räumen Sie im certbot-Verzeichnis ''/etc/letsencrypt/accounts/acme.sectigo.com'' auf und löschen Sie dort überflüssiges. |
| |
=====REST-API===== | =====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 Systeme von Sectigo können per REST-API angesprochen werden. Eine Dokumentation hierzu finden Sie unter: https://sectigo.com/knowledge-base/detail/Sectigo-Certificate-Manager-SCM-REST-API/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. | Das REST-API kann nur dann zum Enrollment verwendet werden, wenn unter ☰->Organizations-><Auswahl> per Button Edit im Tab "Certificate Settings" in den Abschnitten "SSL Certificates" bzw. "Client Certificates" 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. Dieser Secret-Key darf maximal 20 Zeichen lang sein, ansonsten kommt es erfahrungsgemäß bei der Verwendung des REST-APIs zu wenig aussagekräftigen "Internal Error"-Fehlern. |
| |
Es ist entweder Nutzername/Passwort eines im Cert-Manager angelegten Nutzers zu übergeben, oder aber eine Client-Authentifizierung per Zertifikat. | Es ist ein Login/Passwort eines im Cert-Manager angelegten Accounts zu übergeben, dessen |
| Anfangspasswort bereits geändert wurde. Die in der Dokumentation angegebene Client-Authentifizierung per Zertifikat für das REST-API ist noch nicht getestet. |
| |
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!) | Tipp: Man kann einen Account in seiner Rolle so einschränken, dass ausschließlich der REST-API-Zugang verwendet werden kann, siehe [[de:dfnpki:tcsfaq#admins_rollen_privilegien|Admins, Rollen & Privilegien]] |
| |
Beispiel für die Beantragung von Serverzertifikaten: | Beispiel für die Beantragung von **Serverzertifikaten**: |
| |
<code>curl 'https://cert-manager.com/api/ssl/v1/enroll' -i -X POST \ | <code>curl 'https://cert-manager.com/api/ssl/v1/enroll' -i -X POST \ |
-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> | -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 <OrgId> (ID) ist direkt im cert-manager.com ablesbar: ☰->Organizations-><Organisationsauswahl>->Button Edit. Für DRAO-Accounts muss auf Department-Ebene die <OrgId> (ID) entsprechend vom zugehörigen Departement des DRAO-Accounts hergenommen werden: ☰->Organizations-><Organisationsauswahl>->Button Edit-><Department-Auswahl>->Button Edit. |
| |
Die <Nummer des Zertifikatprofils> muss einmalig mit folgendem Aufruf ermittelt werden: | 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 \ | <code>curl 'https://cert-manager.com/api/ssl/v1/types' -i -X GET \ |
-H "Content-Type: application/json;charset=utf-8" \ | -H "Content-Type: application/json;charset=utf-8" \ |
-H "login: <account>" \ | -H "login: <account>" \ |
Ausgestellte Zertifikate können mit folgendem Aufruf abgeholt werden: | 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 \ | <code>curl 'https://cert-manager.com/api/ssl/v1/collect/<Antragsnummer>/<Format>' -i -X GET \ |
-H "Content-Type: application/json;charset=utf-8" \ | -H "Content-Type: application/json;charset=utf-8" \ |
-H "login: <account>" \ | -H "login: <account>" \ |
<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 | <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. | 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 und -hinterlegung bei Nutzerzertifikaten===== | Beispielaufruf zur Beantragung eines Nutzerzertifikats: |
| |
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. | <code>curl 'https://cert-manager.com/api/smime/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>, "certType":<Nummer des Zertifikatprofils z.B. 15870>,\ |
| "email":"<e-mail-adresse>",\ |
| "firstName":"<vorname>", "lastName":"<nachname>",\ |
| "term":<Gültigkeit in Tagen, je Nach Zertifikatprofil entweder 365, 730 oder 1095>,\ |
| ...,\ |
| "csr":"-----BEGIN CERTIFICATE REQUEST-----\nMIICYjCCAU...N818=\n-----END CERTIFICATE REQUEST-----"}</code> |
| =====CAA-Records===== |
| |
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. | Wenn Sie CAA-Records im DNS setzen möchten, um die Ausstellung von Zertifikaten auf bestimmte CAs einzuschränken, verwenden Sie für TCS den ''issue''-Wert ''sectigo.com'': |
| |
Die geheimen Schlüssel der Nutzer werden dann an diesen Master Encryption Key verschlüsselt. | <code> |
| muster-uni.de. IN CAA 0 issue "sectigo.com" |
| muster-uni.de. IN CAA 0 issue "pki.dfn.de" |
| </code> |
| |
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. | Der CAA-Record muss bereits zum Zeitpunkt der Domain-Freischaltung passen, nicht erst zum Zeitpunkt der konkreten Zertifikatausstellung. |
| |
Achtung: Dies ist beim Antragsweg "SAML" für Nutzerzertifikate nicht möglich! | Ist für eine betrachtete Domain (Alias-Domain) ein CNAME im DNS definiert, so müssen die CAA-Records für den CNAME die Ausstellung von Zertifikaten durch TCS erlauben: |
| |
=====CAA-Records===== | <code> |
| muster-uni.edu. IN CNAME muster-uni.de. |
| |
Wenn Sie CAA-Records setzen möchten, um die Ausstellung von Zertifikaten auf bestimmte CAs einzuschränken, verwenden Sie für TCS: | muster-uni.de. IN CAA 0 issue "sectigo.com" |
| muster-uni.de. IN CAA 0 issue "pki.dfn.de" |
| </code> |
| |
<code>muster-uni.de. IN CAA 0 issue "sectigo.com"</code> | ====TCS' DNS-Resolver (CAA)==== |
| |
| Für CAA nutzt TCS DNS-Resolver, die von den Quelladressen ''91.199.212.132'' oder ''91.199.212.148'' aus ankommen. (Stand 01/2023) |
| |
| =====Zertifikate sperren (Revoke, Revocation)===== |
| |
| Zertifikate sollen hauptsächlich von einem RAO oder DRAO in https://cert-manager.com/customer/DFN gesperrt werden. |
| |
| Die [[de:dfnpki:tcsfaq#acme-zertifikate_sperren|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. |
| |
| =====Sectigo Certificate Manager (SCM)===== |
| |
| ====Automatische Benachrichtigungen (Notifications) durch den SCM==== |
| |
| Im SCM können automatische Benachrichtigungen (Notifications) zu bestimmten Ereignissen konfiguriert werden. Die Textvorlagen dazu können zum Teil auf Organisations- und Department-Ebene angepasst werden. |
| |
| ===Aktivieren von Benachrichtigungen=== |
| |
| - Im SCM über ☰->Settings->Notifications->das grüne "+"-Symbol oben rechts eine Benachrichtigung hinzufügen, |
| - dabei einen Namen für die Benachrichtigung vergeben und den Benachrichtigungstyp auswählen. Es stehen mehrere Benachrichtigungstypen zur Auswahl. |
| - Wir empfehlen Benachrichtigungen für die Typen ''SSL Expiration'', ''Client Certificate Expiration'', ''Code Signing Certificate Expiration'' und ''DCV Expiration'' einzurichten. |
| - Im nächsten Schritt können je nach Benachrichtigungstyp unterschiedliche (Empfangs-)Optionen definiert werden. |
| - Falls einzelne Benachrichtigungstypen nicht sichtbar sind, liegt das daran, dass Ihr (D)RAO-Account nicht über die entsprechenden Berechtigungen verfügt. |
| - Beim Einrichten einer ''DCV ...''-Benachrichtigung, bitte nicht die Benachrichtigung für ''Owner'' aktivieren. Die Benachrichtigung der ''Owner'' erreicht nur die MRAOs/DFN-PCA. |
| - Sofern Funktions-E-Mail-Adressen (z.B. ein Ticket-System) benachrichtigt werden sollen, können diese über ''Additional recipients'' hinzugefügt werden. |
| |
| ===Anpassen von Benachrichtigungsvorlagen=== |
| |
| Benachrichtigungstexte können in den ''Notification Templates'' angepasst werden. |
| |
| Im SCM über ☰->Organisations-><Auswahl>->Button [Notification Templates]->das grüne "+"-Symbol oben rechts eine Vorlage hinzufügen. Dabei den Empfangstyp (in der Regel wohl ''Email'') und den Benachrichtigungstyp auswählen. Dann kann der Standardvorlagentext angepasst werden. |
| |
| Neben der Möglichkeit, Benachrichtigungen per E-Mail zu versenden, stehen auch ''MS Teams-'', ''Webhook-'' und ''Slack-''Mechanismen zur Auswahl. |
| |
| ====Tipps & Tricks==== |
| |
| ===Fehlende Icons/Symbole=== |
| |
| Werden im SCM an einigen Stellen Alternativtexte oder Platzhalter anstatt Icons oder Symbole angezeigt, so kann das daran liegen, dass der verwendete Browser (z.B. Firefox) so konfiguriert ist, dass dieser ausschließlich "eigene" Schriftarten verwendet. Die fehlenden Icons und Symbole sind allerdings als Zeichen aus einem Symbolzeichensatz realisiert, den die Web-Seiten mitbringen. Erlauben Sie die Verwendung von eigenen Zeichensätzen der Web-Seiten unter den erweiterten Font- und Farbeinstellungen des Browsers: "[x] Allow pages to choose their own fonts, instead of your selections above". |
| |
| ===Filtereinstellungen zurücksetzen === |
| |
| In den unterschiedlichen Übersichtslisten des SCMs können verschiedene Ansichtsfilter gesetzt werden, die auch über Login-Sessions hinweg persistent bleiben. Hat man aus Versehen einen Filter gesetzt, der zu Zeitüberschreitungsfehlern oder gar internen Server-Fehlern führt und daher nicht mehr über die normale Filterkonfiguration zurücksetzbar ist, so können über die Profil-Verwaltung des eigenen Accounts unter "My Profile" die "Grid settings" auf die Standardeinstellungen zurückgesetzt werden. Diese Funktion setzt sowohl alle Tabellenansichten (insb. die Spaltenauswahl) in den Übersichtslisten zurück als auch alle gesetzten Ansichtsfilter. |
| |
| ======Audits====== |
| |
| Im Gegensatz zur DFN-PKI sind in GÉANT TCS keine regelmäßigen Audits der RA-Tätigkeit von Teilnehmern vorgesehen. |
| |
| =====Status von TCS===== |
| |
| Statusmeldungen und Wartungsankündigungen der Sectigo-Services sind sichtbar über: https://sectigo.status.io |
| |
| Die Meldungen können dort auch als E-Mail und RSS-Feed (https://status.io/pages/5938a0dbef3e6af26b001921/rss) abonniert werden. |
| |
Der CAA-Record muss bereits zum Zeitpunkt der Domain-Freischaltung passen, nicht erst zum Zeitpunkt der konkreten Zertifikatausstellung. | |
=====Support===== | =====Support===== |
| |
Wir helfen gerne per dfnpca@dfn-cert.de | Wir helfen auch bei technischen Schwierigkeiten mit den TCS-Systemen gerne weiter, z.B. per Mail: [[mailto:dfnpca@dfn-cert.de|dfnpca@dfn-cert.de]] |
| |
| 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." |
| |
| Es ist zu empfehlen, vor einer direkten Kontaktaufnahme zum Sectigo Support mit uns zu sprechen. |
| |
| ===Support-Tickets für die Validierung (DCV) von IP-Adressen=== |
| Sofern Sie ein Ticket für den speziellen [[de:dfnpki:tcsfaq#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. |
| |
| =====E-Mail-Verteilerliste dfnpki-d===== |
| |
| 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. |
| |
| Eine Anmeldung ist **für DFN-PKI-Teilnehmer** möglich unter [[https://www.listserv.dfn.de/sympa/info/dfnpki-d]]. |
| |
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." | |