Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision |
de:dfnpki:tcsfaq [2022/07/28 18:38] – [Gruppenzertifikate] Reimer Karlsen-Masur | de:dfnpki:tcsfaq [2023/09/12 17:25] – 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. | |
| |
**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.** | **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 (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://www.geant.org/Services/Trust_identity_and_security/Pages/TCS.aspx]] | 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/]] |
| |
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 für alle Teilnehmer der DFN-PKI ein. TCS wird die bisherige DFN-PKI "Global" mittelfristig ablösen. |
Zur Zeit geht der DFN-Verein auf alle bisherigen Teilnehmer der DFN-PKI zu, um ihnen einen Zugang zu TCS zu ermöglichen. | Zur Zeit geht der DFN-Verein auf alle bisherigen Teilnehmer der DFN-PKI zu, um ihnen einen Zugang zu TCS zu ermöglichen. |
| |
Das initiale Setup erfolgt dann in direkter Absprache mit ''dfnpca@dfn-cert.de''. | Das initiale Setup erfolgt dann in direkter Absprache mit [[mailto:dfnpca@dfn-cert.de|dfnpca@dfn-cert.de]]. |
| |
====Gibt es eine Testumgebung für TCS REST API und die Webseiten?==== | ====Gibt es eine Testumgebung für TCS REST API und die Webseiten?==== |
=====Erste Schritte===== | =====Erste Schritte===== |
| |
Überblick über erste Schritte nach Erhalt eines Zugangs: https://doku.tid.dfn.de/de:dfnpki:tcsfaq:ersteschritte | Überblick über erste Schritte nach Erhalt eines Zugangs: [[de:dfnpki:tcsfaq:ersteschritte|Erste Schritte]] |
| |
=====Dokumentation===== | =====Dokumentation===== |
Die REST-API ist dokumentiert unter https://sectigo.com/knowledge-base/detail/Sectigo-Certificate-Manager-SCM-REST-API/kA01N000000XDkE | Die REST-API ist dokumentiert unter https://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 |
| |
Sectigo unterhält einen Youtube-Kanal mit vielen Tutorials: https://www.youtube.com/c/Sectigo/videos | |
=====Datenschutz===== | =====Datenschutz===== |
| |
Eine Bewertung von GÉANT zu Fragen des Datenschutzes und der DSGVO liegt vor: [[https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ#TCS2020FAQ-Q:HowdoG%C3%89ANTandSectigodealwithGDPR/dataprotection?]]. | Hinweise zum Datenschutz und der vertraglichen Konstruktion: |
| [[de:dfnpki:tcs:datenschutz|Datenschutz]] |
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]]. | |
| |
=====Funktionsüberblick===== | =====Funktionsüberblick===== |
TCS bietet zusätzlich: | TCS bietet zusätzlich: |
| |
* Web-Formulare zum Beantragen von Zertifikaten für nicht in cert-manager.com eingeloggte Benutzer per "Access-Code" | * Web-Formulare zum Beantragen von Zertifikaten für nicht in cert-manager.com eingeloggte Benutzer |
* Eine Ausstellung von Zertifikaten über eine SAML-Integration | * Eine Ausstellung von Zertifikaten über eine SAML-Integration |
* Eine ACME-Schnittstelle | * Eine ACME-Schnittstelle |
* Eine REST-API, Dokumentation: https://sectigo.com/knowledge-base/detail/Sectigo-Certificate-Manager-SCM-REST-API/kA01N000000XDkE | * Eine REST-API |
| |
| Es gibt **keine** Testumgebung. |
| |
Es gibt **keine** Testumgebung, in der Sachen ausprobiert werden könnten. | |
=====Organisationsvalidierung===== | |
| |
Der Anbieter muss die Existenz und den Namen der Organisation regelmäßig über ein Register verifizieren. Der aktuelle Validierungszustand ist über das linke Seiten-Menü "Organizations" einsehbar. | =====Rollen, Anmeldung und Abteilungen (Departments)===== |
| |
Die Stammdaten der Organisation können nur von der DFN-PCA geändert werden. | In SCM gibt es verschiedene Rollen und Möglichkeiten zur Anmeldung. Es können Abteilungen ("Departments") angelegt werden: |
| [[de:dfnpki:tcs:scmrollenundanmeldung|Rollen, Anmeldung, Abteilungen]] |
| |
| ===== Tipps und Tricks in SCM ===== |
| |
| [[de:dfnpki:tcs:scmtipstricks|Tipps und Tricks für SCM]] |
=====Admins, Rollen & Privilegien===== | |
| |
Im linken Seitenmenü können unter ☰->Settings->Admins weitere Accounts angelegt werden. | |
| |
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, modifizieren oder löschen, und eine Auswahl der Zertifikattypen SSL, Client und Code Signing erstellen. | |
| |
Der erste RAO-Account einer Einrichtung wird von der DFN-PCA angelegt. Weitere RAOs oder DRAOs können dann eigenständig angelegt und verwaltet werden. | |
| |
* Privilegien "Allow ... of peer admin" ermöglichen u.a. das Anlegen, Modifizieren oder Löschen von weiteren RAOs/DRAOs. Diese Privilegien können für DRAO-Accounts von einem RAO-Account aus selbst verwaltet werden. Für RAO-Accounts können diese Privilegien nicht selbst durch einen (anderen) RAO-Account gesetzt werden, sondern nur von der DFN-PCA nachträglich geändert werden. Zur Einbindung weiterer Personen mit RAO-Account, die neue Admins anlegen, ändern oder löschen dürfen, legen Sie bitte zuerst einen RAO-Account an, sofern kein bestehender RAO-Account geändert werden soll, und melden sich dann bitte per E-Mail bei ''dfnpca@dfn-cert.de''. | |
* Mit dem Privileg "DCV" (Domain Control Validation) kann die [[de:dfnpki:tcsfaq#domainvalidierung_domain_control_validation_dcv|Domainfreischaltung]] gesteuert werden. Dieses Privileg kann für DRAO-Accounts von einem RAO-Account aus selbst verwaltet werden. Für RAO-Accounts kann dieses Privileg nicht selbst durch einen (anderen) RAO-Account gesetzt werden, sondern nur von der DFN-PCA nachträglich geändert werden. Zur Einbindung weiterer Personen mit RAO-Account, die Domainfreischaltungen starten dürfen, legen Sie bitte zuerst einen RAO-Account an, sofern kein bestehender RAO-Account geändert werden soll, und melden sich dann bitte per E-Mail bei ''dfnpca@dfn-cert.de''. | |
* API-Only-User: Ein RAO/DRAO-Account kann auf "API-Only" eingeschränkt werden (Privileg "WS-API 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 only" über ☰->Settings->Admins-><Auswahl>->Edit unten im Karteireiter "Role & Privileges" angekreuzt werden. Dieses Privileg kann für DRAO-Accounts von einem RAO-Account aus selbst verwaltet werden. Für RAO-Accounts kann dieses Privileg nicht selbst durch einen (anderen) RAO-Account gesetzt werden, sondern nur von der DFN-PCA nachträglich geändert 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 und melden sich erst dann bitte per E-Mail bei ''dfnpca@dfn-cert.de''. 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. | |
| |
====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|mailto:dfnpca@dfn-cert.de]]. | |
* Ein von einem RAO neue angelegter IdP User in einem Department kann von einem zweiten RAO direkt freigeschaltet werden. | |
| |
| |
Ihr IdP muss mindestens ''schacHomeOrganization'', ''eduPersonPrincipalName'' und ''mail'' an Sectigo übertragen. Die übertragenen Attribute können Sie einsehen unter: https://cert-manager.com/customer/DFN/ssocheck/ | |
| |
| |
=====Departments===== | |
| |
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. | |
| |
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. | |
| |
**Wichtig:** Unter "Client Certificates" bitte im Regelfall unbedingt alle Punkte "Allow Key Recovery by..." herausnehmen! Es kommt sonst zu mysteriösen Fehlern bei der Zertifikatbeantragung. Für eine bewusste Entscheidung für Key Recovery siehe [[https://doku.tid.dfn.de/de:dfnpki:tcsfaq#schluesselhinterlegung_bei_nutzerzertifikaten|https://doku.tid.dfn.de/de:dfnpki:tcsfaq#schluesselhinterlegung_bei_nutzerzertifikaten]]. | |
| |
Im Anschluss können über ☰->Settings->Admins weitere Zugänge ("DRAOs") angelegt werden, die nur innerhalb der zugewiesenen Abteilung Zertifikate verwalten können. | |
| |
| |
=====Zugriff per AAI===== | =====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: | |
| |
* In der Verwaltungsoberfläche müssen unter ☰->Organizations-><Auswahl>->Edit->🖉 die Felder Secondary Organization Name und Academic code (SCHAC Home Organization) gesetzt sein. Welcher Wert als SCHAC Home Organization 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''. Der Academic code (SCHAC Home Organization) kann nicht (mehr) durch die RAOs selbst gesetzt werden. Bitte senden Sie uns den Wert, den der Identity-Provider Ihrer Einrichtung als SCHAC Home Organization (''schacHomeOrganization'') Attribut an die Service-Provider übermittelt per E-Mail an ''dfnpca@dfn-cert.de''. | |
* Ihr Identity-Provider muss in eduGAIN eingebunden sein | |
* Ihr Identity-Provider muss mindestens die Attribute ''mail'' und ''eduPersonPrincipleName'' 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 | |
| |
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> | |
| |
=====Domainvalidierung, Domain Control Validation (DCV)===== | |
| |
Um Zertifikate zu erhalten, müssen die entsprechenden Domains im linken Seitenmenü unter dem Punkt "Domains" eingetragen werden. Nach der Eintragung muss jede Domain über "Domain Control Validation" 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 in cert-manager verzichtet werden. Der FQDN wird dann automatisch im Rahmen des ACME-Protokoll validiert. | |
| |
Es 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 können Zertifikate zu beliebigen FQDN unterhalb der Hauptdomain erzeugt werden können. | |
| |
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]] | |
| |
Die Domainvalidierung muss bei Sectigo alle 365 Tage wiederholt werden. Das Ablaufdatum ist im cert-manager sichtbar. | |
| |
====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> | |
| |
Die Reihenfolge 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. | Viele Funktionen im cert-manager können auch nach einem Login über die DFN-AAI genutzt werden. Hierzu müssen Voraussetzungen erfüllt sein: [[de:dfnpki:tcs:zugriffperaai|Zugriff per AAI]] |
| |
===HTTP/HTTPS=== | =====Benachrichtigungen===== |
| |
Bei der HTTP-Methode muss auf dem Webserver eine von Sectigo vorgegebene Datei abgelegt werden. | Um Benachrichtigungen über Ereignisse wie den Ablauf von Zertifikaten oder der Gültigkeit von Domain-Valididierungen zu erhalten, können Benachrichtigungen konfiguriert werden: [[de:dfnpki:tcs:scm_notifications|Benachrichtigungen in SCM]] |
| |
**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. | =====Domains und IPv4-Adressen in Zertifikaten===== |
| |
Hinweise von Sectigo zu dieser Umstellung: https://sectigo.com/DCVChange | Um Zertifikate zu erhalten, müssen die entsprechenden Domains oder IPv4-Adressen **vorab** bei Sectigo im System eingetragen werden. |
| Eine detaillierte Beschreibung ist verfügbar unter: [[de:dfnpki:tcs:domains|Domains und IPv4-Adressen in Zertifikaten]] |
| |
| |
=====Zertifikate erstellen===== | =====Zertifikate erstellen===== |
| |
====Serverzertifikate==== | [[de:dfnpki:tcs:servercert|Serverzertifikate]] |
| |
===Direkt im cert-manager=== | [[de:dfnpki:tcs:servercert_acme|Serverzertifikate per ACME]] |
| |
Sie können als eingeloggter RAO oder DRAO direkt im cert-manager Serverzertifikate beantragen und ausstellen. | [[de:dfnpki:tcs:usercert|User-Zertifikate]] |
| |
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. | [[de:dfnpki:tcs:documentsigning|Document Signing]] |
| |
Wählen Sie im Regelfall das Zertifikatprofil OV Multi-Domain. Wählen Sie **nicht** EV Anchor, es sei denn, Sie wollen den speziellen EV-Prozess starten. | [[de:dfnpki:tcs:codesigning|Code Signing]] |
| |
===Über die AAI==== | [[de:dfnpki:tcs:restapi|REST API]] |
| |
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. | |
| |
Über ☰->Enrollment->Enrollment Forms und einen Klick auf den "Add"-Button muss ein Enrollment Endpoint vom Typ "SAML SSL self-enrollment form" angelegt werden. Die über diesen Enrollment Endpoint beantragbaren Zertifikatprofile müssen zugewiesen werden, typischer Weise "OV Multi-Domain" und ggf. weitere. | |
| |
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 Nutzenden eines IdP einzuschränken. Hiermit kann dann jeder Nutzenden in Ihrem IdP jedes Serverzertifikat erstellen. Wenn Sie hier "Automatically Approve Requests" aktivieren, dann **müssen** Sie die unten beschriebene "URI Extension" als //eine Art Passwort zur automatischen Zertifikatausstellung// sehen, die entsprechend komplex ausfallen sollte. | |
| |
Ist diese Checkbox nicht aktiviert, müssen die Anträge von einem RAO oder DRAO über ☰->Certificates-><Typ> Certificates-><Auswahl>->Approve Button genehmigt werden. | |
| |
Über die "URI Extension" wird eine einrichtungsspezifische URL angelegt, über die die Beantragung möglich ist. Diese URI Extension können Sie selbst z.B. als "sprechenden" oder sehr zufälligen Passwort-artigen URI-Teil wählen. Der endgültige Beantragungs-Link bildet sich nach dem Muster ''https://cert-manager.com/customer/DFN/idp/ssl/<URI-EXTENSION>/select'' also z.B. ''https://cert-manager.com/customer/DFN/idp/ssl/Uni-Musterstadt-Server-Zertifikat-Antrag-SAML/select'' oder ''https://cert-manager.com/customer/DFN/idp/ssl/WO4BkhxlFtNCN4toQxcXWB/select''. | |
| |
Über die optionalen "Hilfe"-Einstellungen können Sie auf eigene Info- bzw. Anleitungs-Web-Seiten Ihrer Einrichtung verweisen, auf denen Sie Ihre lokalen Prozesse zur Beantragung von Serverzertifikaten über TCS mittels DFN-AAI-Login (SAML) beschreiben. | |
| |
| |
===SSL Web Form=== | |
| |
Mit Web-Formularen können Nutzer ohne eigenen Login in cert-manager Zertifikate beantragen. Zur Nutzung eines Web-Formulars ist ein sogenannter "Access Code" notwendig. Jeder, der diesen Access Code kennt, kann Zertifikate beantragen. | |
| |
Access Codes werden von einem RAO unter ☰->Enrollment->Enrollment Forms-><Auswahl "SSL Web Form"> mit dem Button "Accounts" erstellt. | |
| |
**Bitte verwenden Sie nicht den Button Edit**. Mit diesem Button können Hilfetexte und -links gesetzt werden, die sich **global** auf alle anderen Einrichtungen im gesamten DFN-Mandanten auswirken. | |
| |
**Bei Accounts für SSL Web Forms setzen Sie bitte auf keinen Fall die Checkbox "Automatically Approve Requests"**. Genehmigen Sie eingehende Requests immer manuell nach Prüfung über out-of-band-Methoden (z.B. eine informelle E-Mail). | |
| |
Die URL ist für alle Web-Formulare aller Einrichtungen im DFN-Mandanten von TCS zur Beantragung von Serverzertifikaten identisch: https://cert-manager.com/customer/DFN/ssl | |
| |
Erst der Access Code sorgt für die Zuordnung eines Antrags zu Ihrer Einrichtung. | |
| |
===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=== | |
| |
Die Erstellung von Nutzerzertifikaten ist nach einiger Vorbereitung möglich. Zunächst muss ein entsprechende ''Enrollment Form'' und darin ein ''Enrollment Form Account'' angelegt werden: | |
| |
- Im SCM unter ☰->Enrollment->Enrollment Forms | |
- das Enrollment Form mit dem Namen ''DFN-wide Default Client Certificate Self-Enrollment Form'' auswählen; oder | |
- mit dem grünen "+"-Button ein weiteres eigenes Enrollment-Form vom Type ''Client certificate self-enrollment form'' anlegen und einen "sprechenden" Namen dafür vergeben, der auf Ihre Einrichtung hinweist. | |
- Falls Sie mit 1b ein neues Enrollment Form angelegt haben: Im nächsten Schritt im "Details"-Reiter eine URI-Extension setzen oder erzeugen lassen und im "Configuration"-Reiter einen Haken bei "Email Confirmation" und ggf. bei "Secret ID" setzen und das Popup-Fenster mittels "Save" schließen. | |
- Das Enrollment-Form (eigenes aus Schritt 2 oder ''DFN-wide Default Client Certificate Self-Enrollment Form'') auswählen und oben auf "Accounts" klicken. | |
- Im daraufhin geöffneten Popup-Fenster über mit dem grünen "+"-Button einen neuen Enrollment-Form-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, meist "GEANT Personal Certificate". | |
- Als "CSR Generation Method" den Wert "Browser" oder "Server" auswählen. Bisher war das implizit immer "Server", da die Schlüsselerzeugung durch den Browser ein neues Feature ist. Die CSR Generation Method "Browser" funktioniert mit den gängigen aktuellen Web-Browsern. | |
- "Allow empty PKCS12 Password" nicht aktivieren. | |
- Als "Authorization Method" den Wert "none" auswählen. | |
- Das Ganze mittels "Save"-button abspeichern. | |
| |
Bitte keine fremden ''Client certificate enrollment-forms'' löschen! | |
| |
Dann zum manuellen Auslösen der einzelnen Einladungs-Mails durch (D)RAOs unterhalb von ☰->Persons: | |
| |
- Mit dem grünen "+"-Button kann eine einzelne Person angelegt werden. Anschließend muss die Person mit der Checkbox vor dem Namen ausgewählt werden. Über den 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 (in den Schritten 4-11) den ''Enrollment Form Account'' angelegt haben und dann eben diesen angelegten "Account" auswählen. (Es werden die im Account ausgewählten Zertifikatprofile, die die Person später zur Auswahl zur Zertifikatsbeantragung vorgelegt bekommt, angezeigt.) | |
- Abschließend auf den "Send"-Button klicken, um die Einladungs-E-Mail zu versenden. | |
| |
Mit der Einladung kann direkt ein Zertifikat bezogen werden. Der private Schlüssel wird dabei je nach Konfiguration der "CSR Generation Method" im ''Enrollment Form Accounts'' vom "Browser" der beantragenden Person oder von Sectigo ("Server") erzeugt. Der für die "Person" gesetzte ''Common Name'' ist wird in das Zertifikat übernommen und ist nicht durch die Person selbst änderbar. Der ''Name'' der Person kann während der Zertifikatbeantragung geändert werden. | |
| |
Eine weitere Einschränkung der Beantragungsoptionen auf Laufzeit, Schlüssel-Typ, Schlüssellänge etc ist nicht möglich. | |
| |
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. | |
| |
Bitte beachten Sie die Identifizierungsvoraussetzungen, bevor Sie Personen anlegen: [[de:dfnpki:tcsfaq#identifizierung_und_dokumentation|Identifizierung und Dokumentation]]. | |
| |
Unter dem eigentlich naheliegenden Punkt ☰->Certificates->Client Certificates kann man ausschließlich bereits ausgegebene Zertifikate einsehen und gegebenenfalls sperren. | |
| |
| |
**Bitte richten Sie unter Ihren ''Enrollment Forms'' vom Typ ''Client certificate self-enrollment form'' keine Accounts mit der "Authorization method" ''Access Code'' ein.** 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. Der korrekte Weg für den Bezug von Nutzerzertifikaten in TCS führt über die AAI oder E-Mail-Einladungen aus ☰->Persons heraus. | |
| |
| |
===Schlüsselhinterlegung bei Nutzerzertifikaten=== | |
| |
Für den Antragsweg "E-Mail-Einladung" ist es möglich, Key Escrow zu konfigurieren. Bei der Einrichtung eines Departments kann ausgewählt werden, ob eine Schlüsselhinterlegung stattfinden soll. Wenn ja, muss vor dem Ausstellen von Nutzerzertifikaten von dem Department durch die Rolle DRAO ein Master Encryption Key erzeugt werden (Nutzen Sie hierzu ☰->Settings->Legacy Key Encryption). | |
| |
Die privaten Schlüssel der Nutzer werden dann an diesen Master Encryption Key verschlüsselt. | |
| |
Ein DRAO kann private Schlüssel von Nutzern wiederherstellen, indem der Master Encryption Key beim Wiederherstellungsprozess per Hand in ein entspr. Formular in cert-manager eingegeben wird. Zertifikate, deren Schlüssel so wiederhergestellt wurden, werden automatisch gesperrt. | |
| |
Achtung: Dies ist nur in diesem Antragsweg "E-Mail-Einladung" möglich, und nicht bei den Zertifikaten, die über die AAI oder einen der anderen Abläufe erstellt wurden. | |
| |
| |
===Ü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. | |
| |
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. | |
| |
Die Konfiguration erfordert 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]]. | |
* 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. | |
| |
**Achtung:** Unter ☰->Enrollment->Enrollment Forms gibt es die (theoretische) Option, einen individuellen ''Client Certificate SAML self-enrollment form'' Endpoint anzulegen. Dieser Weg ist nicht vorgesehen und führt nicht zum Erfolg. Hierüber ist keine Zertifikatausstellung möglich. (Fehlersymptom: "IdP is not configured properly for Client Certificate enroll.") Für die Beantragung von Nutzerzertifikaten per SAML ist **immer** der bereits vordefinierte und in eduGAIN eingebundene Enrollment EndPoint https://cert-manager.com/customer/DFN/idp/clientgeant zu verwenden. | |
| |
Achtung: Für Zertifikate, die auf diesem Wege ausgestellt werden, ist kein Key-Escrow möglich! | |
| |
===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. | |
| |
| |
===Client Certificate Web Form=== | |
| |
**Bitte richten Sie keine Accounts zur Nutzung von Web-Formularen für Nutzerzertifikate unter ☰->Enrollment->Enrollment Forms->Client Certificate Web Form ein**. 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. Der korrekte Weg für Nutzerzertifikate in TCS führt über die AAI oder E-Mail-Einladungen. | |
| |
| |
| |
=====Zertifikattypen===== | |
| |
====ECC oder RSA?==== | |
| |
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. | |
| |
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. Nicht verfügbar sind die Funktionalitäten aus den folgenden Profilen der DFN-PKI Global : ''Webserver mustStaple'', ''DomainController'' und ''Exchange Server'' | |
| |
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 Profil EV Anchor, es sei denn, Sie wollen den speziellen EV-Prozess starten. | |
| |
IP-Adressen können nicht in Serverzertifikate aus TCS aufgenommen werden. Die Antragswege über Webformulare ergeben Fehlermeldungen. Beim Einreichen eines Requests mit einer IP-Adresse im SubjectAlternativeName wird diese stillschweigend herausgefiltert. | |
| |
| |
====OV SSL oder OV Multi Domain?==== | |
| |
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. | |
| |
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 funktioniert zur Zeit noch nicht für die Verschlüsselung von VoIP-Anschlüssen im Rahmen von DFNFernsprechen, da die TCS-Wurzelzertifikate auf den SBCs nicht akzeptiert werden. Dort sind unverändert Zertifikate aus der DFN-PKI Global erforderlich. | |
https://www2.dfn.de/dienstleistungen/dfnfernsprechen/voip/verschluesselung | |
| |
| |
====Extended Validation Zertifikate (EV)==== | |
| |
EV-Zertifikate können nur erstellt werden, nachdem in cert-manager ein sog. EV Anchor angelegt wurde. Dies ist ein spezielles administratives Zertifikat, dessen Ausstellung von allen Prozeduren zur besonderen Prüfung nach EV-Standard begleitet wurde. | |
| |
* Bitte versuchen Sie auf keinen Fall, ein normales EV-Zertifikat vor der Erstellung eines EV Anchors zu beantragen. | |
| |
* Vor der Erstellung eines EV-Anchors müssen die EV-Informationen unter ☰->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?]] | |
Versuchen Sie auf keinen Fall mehrere EV Anchor zu erstellen. | |
| |
====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. | |
| |
Wenn für eine primäre E-Mail-Adresse erstmals ein Zertifikat beantragt wird, wird die Person mit den Angaben aus dem Antrag in die Liste eingetragen. | |
| |
Wenn für eine primäre E-Mail-Adresse weitere Zertifikate beantragt werden, werden die vorhandenen Personendaten in der Liste mit den Angaben aus den neuen Anträgen aktualisiert. | |
| |
Dabei gilt: | |
| |
* Sekundäre E-Mail-Adressen und der "commonName" können problemlos geändert werden. | |
| |
* Änderungen am "firstName", "middleName" oder "lastName" führen aber zur sofortigen **Sperrung** aller vorher für diese primäre E-Mail Adresse ausgestellten Zertifikate in allen Zertifikatprofilen (GEANT Personal, GEANT IGTF-MICS und GEANT IGTF-MICS-Robot Personal). Es erfolgt keine Rückfrage und es gibt keinen Hinweis an den Zertifikatinhaber! | |
| |
| |
===Beschränkung der Anzahl der Zertifikate pro Nutzer=== | |
| |
Zusätzlich kennt das System eine Beschränkung der Anzahl der gleichzeitig gültigen Nutzerzertifikate pro Person und Zertifikatprofil: | |
| |
Pro Person können maximal zwei Zertifikate je Zertifikatprofil GEANT Personal, GEANT IGTF-MICS und GEANT IGTF-MICS-Robot Personal erstellt werden. | |
| |
Wenn für ein Zertifikatprofil weitere Zertifikate beantragt werden, werden die jeweils ältesten Zertifikate mit diesem Zertifikatprofil automatisch **gesperrt**. Auch hier erfolgt keine Rückfrage und es gibt keinen Hinweis an den Zertifikatinhaber! | |
====Code Signing==== | |
| |
=== Code Signing über cert-manager === | |
| |
Die über die Oberfläche beziehbaren Code-Signing Zertifikate sind für die Signatur von Java JARs & MS Office Macros verwendbar. | |
| |
Die Zertifikatprofile ''Code Signing'' und ''GÉANT Code Signing'' unterscheiden sich in keinem Praxis-relevanten Aspekt. Im GÉANT-Profil wird als O=-Attribut der "Secondary Organization Name" verwendet (siehe ☰->Organizations-><Auswahl>->Edit->🖉). | |
| |
=== EV Code Signing === | |
| |
EV Code Signing-Zertifikate, denen beispielsweise in Microsoft SmartScreen sofort vertraut wird, müssen über einen separaten Antragsweg bestellt und zusätzlich bezahlt werden. | |
| |
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) | |
| |
====Document Signing==== | |
===Rechtliche Grundlagen=== | |
Erläuterungen zu dem rechtlichen Aspekt finden Sie unter: [[de:dfnpki:sigsie_faq|Rechtliche Grundlagen elektronischer Signaturen]] | |
===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. | |
| |
Eine sehr detaillierte Anleitung wird von der Universität Münster zur Verfügung gestellt: https://www.uni-muenster.de/WWUCA/de/howto-setup-acroread.html | |
| |
Diese Einstellungen müssen von jeder Person vorgenommen werden, die die Signaturen prüfen soll. | |
| |
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. | |
| |
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. | |
| |
Für den Bezug dieser Zertifikate gibt es einen separaten Antragsweg außerhalb von cert-manager. | |
| |
Die Zertifikate kosten ca. 130,- Euro für 3 Jahre. Der Betrag ist während des Antragsprozesses direkt per Kreditkarte 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. | |
| |
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"). | |
| |
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) | |
| |
===Qualifizierte Zertifikate=== | |
| |
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. | |
| |
Auch die qualifizierten Zertifikate müssen über einen separaten Antragsweg außerhalb von cert-manager bezogen werden. | |
| |
====Grid-Zertifikate (IGTF)==== | |
| |
* 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. | |
| |
* Für Serverzertifikate (Hostzertifikate), die im Grid-Umfeld verwendet werden sollen, verwenden Sie bitte das IGTF-Profil ''GÉANT IGTF Multi-Domain''. | |
| |
====Gruppenzertifikate==== | |
Die aus der DFN-PKI bekannten Gruppen- und Pseudonymzertifikate können | |
in TCS abgebildet werden, indem im SCM wie folgt vorgegangen wird: | |
| |
Zunächst die [[de:dfnpki:pkifaq#einldaung|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 vorbreitete ''Client certificate enrollment form'' auswählen | |
* Dann den darin vorbereiteten "Client certificate enrollment form"-''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. | |
| |
====CA- und Root-Zertifikate in TCS==== | ====CA- und Root-Zertifikate in TCS==== |
Die uns bekannten Root- und CA-Zertifikate in TCS sind dokumentiert unter: [[de:dfnpki:tcs_ca_certs|TCS CA-Zertifikate]] | Die uns bekannten Root- und CA-Zertifikate in TCS sind dokumentiert unter: [[de:dfnpki:tcs_ca_certs|TCS CA-Zertifikate]] |
| |
=====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 Advanced ==== | |
| |
Die Regeln der DFN-AAI Advanced (https://doku.tid.dfn.de/de:degrees_of_reliance) und die Regeln zur Identifizierung von Personen in TCS sind nicht deckungsgleich. | |
| |
Insbesondere lässt die DFN-AAI Advanced "etablierte Einschreibungs- und Einstellungsprozesse" zu. Ob die an Ihrer Einrichtung praktizierten Verfahren im Rahmen der DFN-AAI Advanced den oben genannten Regeln von GÉANT TCS genügen, kann darum nicht pauschal beantwortet werden, sondern muss von Ihnen bewertet werden. | |
| |
Vor einer gründlichen Prüfung der internen Prozesse sollten darum auf keinen Fall pauschal alle Personen in Ihrem IdP für den Zertifikatbezug freigeschaltet werden (Setzen des Attributs eduPersonEntitlement mit | |
Wert ''urn:mace:terena.org:tcs:personal-user'') | |
| |
=====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. | |
| |
=====ACME===== | |
====ACME Clients==== | |
Da das ACME-Protokoll sehr gut standardisiert ist, können neben den in den Beispielen gezeigten ''certbot'' auch andere Clients wie ''acme.sh'' oder ''win-acme'' verwendet werden. | |
| |
Einzige Voraussetzung: External Account Binding muss unterstützt werden (bei ''GetSSL'' beispielsweise mit Stand 09/2021 nur mit einem Patch). | |
====ACME-Accounts==== | |
| |
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. | |
| |
**Wichtig:** Der ACME-Endpoint ''https://acme.sectigo.com/v2/DV'' ist zur Zeit nicht nutzbar! Bitte nutzen Sie ''../v2/OV''. | |
| |
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''. | |
| |
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. | |
| |
====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==== | |
| |
Vorausgesetzt, dass die dem Account zugewiesene Domain validiert und delegiert ist, können direkt im Anschluss Zertifikate erzeugt werden: | |
| |
<code>certbot certonly --standalone --non-interactive --agree-tos --email <Email-Adresse> --server <Sectigo-Server> --eab-kid <Wert von eab-kid> --eab-hmac-key <Wert von eab-hmac-key> --domain <FQDN> </code> | |
| |
Es können für beliebig viele FQDNs, die innerhalb der dem Account zugewiesenen Domains liegen, Zertifikate erstellt werden. | |
| |
Da die ACME-Accounts in der Regel unlimitierte Fähigkeiten zum Ausstellen von Zertifikaten haben, ist sorgfältig abzuwägen ob die Account-Infomationen zwischen mehreren Servern geteilt werden sollten oder aber besser mit separaten ACME-Accounts gearbeitet werden soll. | |
| |
Ein Ansible-Gerüst zum zentralen Erstellen eines ACME-Accounts per REST-API und zum Bezug von Zertifikaten per ACME findet sich unter: https://github.com/francescm/acme-ansible-debian-sectigo | |
====ACME-Zertifikate sperren==== | |
| |
Per ACME ausgestellte Zertifikate können 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> | |
| |
Eine Sperrung per Cert-Manager ist auch möglich. Der unverständliche Informationsdialog kann ignoriert werden. | |
=====REST-API===== | |
| |
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 | |
| |
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 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 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: | |
| |
<code>curl 'https://cert-manager.com/api/ssl/v1/enroll' -i -X POST \ | |
-H "Content-Type: application/json;charset=utf-8" \ | |
-H "login: <account>" \ | |
-H "password: <passwort>" \ | |
-H "customerUri: DFN" \ | |
-d '{"orgId":<OrgId>,"subjAltNames":"<FQDN des Servers>","certType":<Nummer des Zertifikatprofils>,"numberServers":0,"serverType":-1,"term":365,"comments":"","externalRequester":"","customFields": [],"csr":"-----BEGIN CERTIFICATE REQUEST-----\nMIICYjCCAU...N818=\n-----END CERTIFICATE REQUEST-----"}'</code> | |
| |
Die <OrgId> (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: | |
| |
<code>curl 'https://cert-manager.com/api/ssl/v1/types' -i -X GET \ | |
-H "Content-Type: application/json;charset=utf-8" \ | |
-H "login: <account>" \ | |
-H "password: <passwort>" \ | |
-H "customerUri: DFN" \</code> | |
| |
Ausgestellte Zertifikate können mit folgendem Aufruf abgeholt werden: | |
| |
<code>curl 'https://cert-manager.com/api/ssl/v1/collect/<Antragsnummer>/<Format>' -i -X GET \ | |
-H "Content-Type: application/json;charset=utf-8" \ | |
-H "login: <account>" \ | |
-H "password: <passwort>" \ | |
-H "customerUri: DFN" \</code> | |
| |
<Antragsnummer> wurde bei einem vorherigen Aufruf von ...enroll als Rückgabewert zurückgeliefert. | |
| |
<Format> spezifiziert das Rückgabeformat, z.B. "pem", weitere mögliche Werte siehe https://sectigo.com/knowledge-base/detail/SCM-Sectigo-Certificate-Manager-REST-API/kA01N000000XDkE | |
| |
Für Nutzerzertifikate ist die Beantragung ähnlich aufgebaut. Die Aufrufe müssen an https://cert-manager.com/api/smime/v1/types, ....smime/v1/enroll und ....smime/v1/collect geschickt werden. Für weitere Details zu den Parametern ist die API-Dokumentation von Sectigo heranzuziehen. | |
=====CAA-Records===== | =====CAA-Records===== |
| |
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'': | Wenn Sie CAA-Records im DNS setzen möchten, um die Ausstellung von Zertifikaten auf bestimmte CAs einzuschränken: |
| |
<code> | |
muster-uni.de. IN CAA 0 issue "sectigo.com" | |
muster-uni.de. IN CAA 0 issue "pki.dfn.de" | |
</code> | |
| |
Der CAA-Record muss bereits zum Zeitpunkt der Domain-Freischaltung passen, nicht erst zum Zeitpunkt der konkreten Zertifikatausstellung. | |
| |
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: | |
| |
<code> | |
muster-uni.edu. IN CNAME muster-uni.de. | |
| |
muster-uni.de. IN CAA 0 issue "sectigo.com" | |
muster-uni.de. IN CAA 0 issue "pki.dfn.de" | |
</code> | |
| |
| [[de:dfnpki:tcs:caa|CAA]] |
| |
=====Zertifikate sperren (Revoke, Revocation)===== | =====Zertifikate sperren (Revoke, Revocation)===== |
| |
Zertifikate sollen hauptsächlich von einem RAO oder DRAO in https://cert-manager.com/customer/DFN gesperrt werden. | Zertifikate sollen üblicherweise 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. | 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. |
https://secure.sectigo.com/products/RevocationPortal | 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. | 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)===== | |
| |
====Tipps & Tricks==== | |
| |
===Fehlende Icons/Symbole=== | ======Audits====== |
| |
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". | Im Gegensatz zur DFN-PKI sind in GÉANT TCS keine regelmäßigen Audits der RA-Tätigkeit von Teilnehmern vorgesehen. |
| |
===Filtereinstellungen zurücksetzen === | Im [[https://wiki.geant.org/display/TCSNT/TCS+Repository|TCS Certification Practice Statement - Personal, eScience Personal and Document Signing Certificates]] wird in Kapitel 9.6.2 vereinbart: |
| |
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. | <code>The Subscriber agrees to provide on request full documentation to the Member and/or the GÉANT Association about the procedures used to populate and maintain the identity related information in its IdP. |
| </code> |
======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===== |
| |
Statusmeldungen und Wartungsankündigungen der Sectigo-Services sind sichtbar über: https://sectigo.status.io | Statusmeldungen und Wartungsankündigungen der Sectigo-Services sind sichtbar über: https://sectigo.status.io |
=====Support===== | =====Support===== |
| |
Wir helfen auch bei technischen Schwierigkeiten mit den TCS-Systemen gerne weiter, z.B. per Mail: ''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 Sectigo Support ist auch möglich. Das Support-Portal von Sectigo ist erreichbar unter: https://sectigo.com/support-ticket | 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." | 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 Kontaktaufnahme zum Sectigo Support mit uns zu sprechen. | 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]]. |
| |