Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
de:dfnpki:tcsfaq [2021/09/13 15:55] – [Was ist TCS?] Reimer Karlsen-Masur | de:dfnpki:tcsfaq [2024/04/15 16:13] (aktuell) – [E-Mail-Verteilerliste dfnpki-d] Reimer Karlsen-Masur | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
- | Auf dieser Seite stellen wir den Teilnehmern | + | **Diese FAQ richtet sich primär an die Teilnehmerservices an den an der DFN-PKI |
- | + | ||
- | =====Was ist TCS?===== | + | |
- | + | ||
- | TCS (Trusted Certificate Service) ist ein PKI-Angebot, | + | |
- | + | ||
- | Überblick über den Dienst bei GÉANT: [[https:// | + | |
- | + | ||
- | Der DFN-Verein führt das Angebot zur Zeit bei allen Teilnehmern der DFN-PKI ein. | + | |
=====Wie erhalten Einrichtungen einen Zugang? | =====Wie erhalten Einrichtungen einen Zugang? | ||
- | Zur Zeit geht der DFN-Verein auf alle bisherigen Teilnehmer der DFN-PKI zu, um ihnen einen Zugang zu TCS zu ermöglichen. | + | Ein Zugang zu TCS kann über den Kontakt [[pki@dfn.de|pki@dfn.de]] beauftragt werden. |
- | Das initiale Setup erfolgt dann in direkter Absprache mit dfnpca@dfn-cert.de. | + | Das initiale Setup erfolgt dann in direkter Absprache mit [[dfnpca@dfn-cert.de|dfnpca@dfn-cert.de]]. |
====Gibt es eine Testumgebung für TCS REST API und die Webseiten? | ====Gibt es eine Testumgebung für TCS REST API und die Webseiten? | ||
Zeile 21: | Zeile 13: | ||
=====Erste Schritte===== | =====Erste Schritte===== | ||
- | Überblick über erste Schritte nach Erhalt eines Zugangs: | + | Überblick über erste Schritte nach Erhalt eines Zugangs: |
=====Dokumentation===== | =====Dokumentation===== | ||
Zeile 27: | Zeile 19: | ||
Bei GÉANT gibt es eine Zusammenstellung von FAQs: [[https:// | Bei GÉANT gibt es eine Zusammenstellung von FAQs: [[https:// | ||
- | Die Dokumentation von Sectigo zur Administrations-Oberfläche und zu ACME ist zu finden unter https://support.sectigo.com/ | + | Die Dokumentation von Sectigo zur Administrations-Oberfläche und zu ACME ist zu finden unter https:// |
- | Die REST-API ist dokumentiert unter https://support.sectigo.com/ | + | Die REST-API ist dokumentiert unter https:// |
+ | |||
+ | Sectigo unterhält einen Youtube-Kanal mit vielen Tutorials: https:// | ||
=====Datenschutz===== | =====Datenschutz===== | ||
- | Eine Bewertung von GÈANT zu Fragen des Datenschutzes | + | Hinweise zum Datenschutz |
+ | [[de:dfnpki:tcs: | ||
=====Funktionsüberblick===== | =====Funktionsüberblick===== | ||
- | Anwender haben Zugriff über die Administrations-Oberfläche unter https:// | + | Anwender haben Zugriff über die Administrations-Oberfläche, genannt " |
- | 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 | + | Dort gibt es, wie in der Java RA-Oberfläche der DFN-PKI, einen direkten Überblick über offene Anträge und ausgestellte Zertifikate und eine Verwaltung von Domains. Es gibt eine Verwaltung von weiteren Administratoren und Abteilungen. Im cert-manager ist die sofortige Ausstellung von neuen Server- und Client-Zertifikaten |
TCS bietet zusätzlich: | TCS bietet zusätzlich: | ||
- | * Web-Formulare zum Beantragen von Zertifikaten für nicht in cert-manager.com eingeloggte Benutzer | + | * 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: | + | * Eine REST-API |
+ | |||
+ | Es gibt **keine** Testumgebung. | ||
- | Es gibt **keine** Testumgebung, | ||
- | =====Organisationsvalidierung===== | ||
- | Der Anbieter muss die Existenz | + | =====Rollen, |
- | Die Stammdaten der Organisation | + | In SCM gibt es verschiedene Rollen und Möglichkeiten zur Anmeldung. Es können |
+ | [[de: | ||
- | =====Rollen===== | + | ===== Tipps und Tricks in SCM ===== |
- | Es wird zwischen verschiedenen Rollen unterschieden, | + | [[de: |
- | * 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, | ||
- | Der erste RAO einer Einrichtung wird von der DFN-PCA angelegt. Weitere RAOs oder DRAOs können dann eigenständig angelegt und verwaltet werden. | + | =====Zugriff per AAI===== |
- | * Privilegien "Allow ... of peer admin" ermöglichen u.a. das Anlegen oder modifizieren von weiteren RAOs/DRAOs. Diese Privilegien können nicht selbst gesetzt werden, sondern nur von der DFN-PCA nachträglich geändert werden. | + | Viele Funktionen |
- | * API-Only-User: | + | |
- | =====Departments===== | + | =====Benachrichtigungen===== |
- | Zur weiteren Strukturierung | + | Um Benachrichtigungen über Ereignisse wie den Ablauf von Zertifikaten oder der Gültigkeit von Domain-Valididierungen zu erhalten, können Benachrichtigungen konfiguriert werden: [[de: |
- | **Wichtig: | + | =====Domains und IPv4-Adressen in Zertifikaten===== |
- | Es können dann DRAOs angelegt werden, die nur innerhalb der zugewiesenen Abteilung Zertifikate verwalten können. | + | Um Zertifikate zu erhalten, müssen |
+ | Eine detaillierte Beschreibung ist verfügbar unter: [[de: | ||
- | =====Domainvalidierung, | ||
- | Um Zertifikate | + | =====Zertifikate |
- | Wichtig: Nach dem Eintragen und der Validierung müssen die Domains an eine Organization " | + | [[de:dfnpki: |
- | Domainvalidierungen können über Settings-> | + | [[de: |
- | Nach derzeitigem Kenntnisstand muss zunächst die Hauptdomain eingetragen und validiert werden, z.B. '' | + | [[de: |
- | Wenn Sie CAA-Records verwenden, so müssen diese bereits zum Zeitpunkt der Domainvalidierung passen, und nicht erst zum Zeitpunkt der Ausstellung von Zertifikaten, | + | [[de: |
- | ====Validierungsmethoden==== | + | [[de: |
- | ===E-Mail=== | + | [[de: |
- | Domains können wie in der DFN-PKI über die Standardadressen '' | ||
- | 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. | + | ====CA- und Root-Zertifikate |
- | ===DNS bzw. CNAME=== | + | Die uns bekannten Root- und CA-Zertifikate in TCS sind dokumentiert unter: [[de: |
- | Bei der CNAME-Methode muss im DNS ein von Sectigo vorgegebener CNAME für die Domain hinterlegt werden. Beispiel: | ||
- | < | ||
- | _230283408052380233432bdcad080132.example.org. | ||
- | </ | ||
- | ===HTTP/ | ||
- | Bei der HTTP-Methode muss auf dem Webserver eine von Sectigo vorgegebene Datei abgelegt werden. | + | =====CAA-Records===== |
- | **Achtung: | + | Wenn Sie CAA-Records im DNS setzen möchten, |
- | Hinweise von Sectigo zu dieser Umstellung: https:// | + | |
- | =====Zertifikattypen===== | + | |
- | ====ECC oder RSA?==== | + | [[de: |
- | Bei Serverzertifikaten ist die Wahl des Algorithmus nicht so relevant. | + | =====Zertifikate sperren (Revoke, Revocation)===== |
- | Bei Nutzerzertifikaten ist zu beachten, dass Zertifikate | + | Zertifikate |
- | ====Serverzertifikate==== | + | Die [[de: |
- | Die Serverzertifikate ("OV Multi-Domain" | + | |
+ | Unter der folgenden URL steht ein Sperrinterface bereit, in dem Sperranträge gestellt werden können: | ||
+ | https:// | ||
- | ====OV SSL oder OV Multi Domain?==== | + | Hier sind allerdings weitere Authentifizierungsschritte erforderlich, |
- | 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, | ||
- | Im Zertifikatprofil OV SSL wird automatisch jedem Zertifikat ein zweiter, in den meisten Fällen sicherlich unerwünschter Alternativer Name " | ||
- | Beispiel: Antrag enthält " | + | ======Audits====== |
+ | Im Gegensatz zur DFN-PKI sind in GÉANT TCS keine regelmäßigen Audits der RA-Tätigkeit von Teilnehmern vorgesehen. | ||
- | 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. Mehr sind (innerhalb der Grenzen der CSR-Größe) sicherlich auch noch möglich. | + | Im [[https:// |
- | ====Extended Validation Zertifikate (EV)==== | + | <code>The Subscriber agrees to provide on request full documentation to the Member |
- | + | ||
- | EV-Zertifikate können nur erstellt werden, nachdem in cert-manager ein sog. EV Anchor angelegt wurde. Dies ist ein spezielles administratives Zertifikat, dessen Ausstellung von allen Prozeduren zur besonderen Prüfung nach EV-Standard begleitet wurde. | + | |
- | + | ||
- | * Bitte versuchen Sie auf keinen Fall, ein normales EV-Zertifikat vor der Erstellung eines EV Anchors zu beantragen. | + | |
- | + | ||
- | * Vor der Erstellung eines EV-Anchors müssen die EV-Informationen unter Settings-> | + | |
- | + | ||
- | Die Anleitung im GÈANT FAQ ist zu finden unter: [[https:// | + | |
- | Versuchen Sie auf keinen Fall mehrere EV Anchor zu erstellen. | + | |
- | + | ||
- | ====Nutzerzertifikate==== | + | |
- | + | ||
- | Nutzerzertifikate (" | + | |
- | + | ||
- | ====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 " | + | |
- | + | ||
- | * Änderungen am " | + | |
- | + | ||
- | + | ||
- | ===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 '' | + | |
- | + | ||
- | === EV Code Signing === | + | |
- | + | ||
- | EV Code Signing-Zertifikate, | + | |
- | + | ||
- | Die Beantragung erfolgt außerhalb des Cert-Managers. Eine Anleitung findet sich unter [[https:// | + | |
- | + | ||
- | ====Document Signing==== | + | |
- | ===Tauglichkeit normaler Nutzerzertifikate=== | + | |
- | Document Signing, z.B. in Adobe, ist mit den normalen Nutzerzertifikaten zwar 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. Bei Adobe muss beispielsweise sowohl die Windows Integration der vertrauenswürdigen Zertifikate eingestellt werden, als auch die CA-Zertifikate "GEANT Personal CA 4" und "GEANT eScience Personal CA4" explizit als vertrauenswürdig markiert werden: | + | |
- | + | ||
- | * Einstellungen-> | + | |
- | * Einstellungen-> | + | |
- | + | ||
- | Diese Einstellungen müssen von jeder Person vorgenommen werden, die die Signaturen prüfen soll. | + | |
- | + | ||
- | ===" | + | |
- | Für spezielle Document Signing Zertifikate, | + | |
- | + | ||
- | Die Zertifikate kosten ca. 130,- Euro für 3 Jahre. Der Betrag ist während des Antragsprozesses direkt per Kreditkarte zu begleichen. Neben diesem Betrag entstehen zusätzliche, | + | |
- | + | ||
- | 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 " | + | |
- | + | ||
- | Die Beantragung führen Sie bitte wie in der Dokumentation von GÉANT dargestellt durch: [[https:// | + | |
- | ====Grid-Zertifikate (IGTF)==== | + | |
- | + | ||
- | * Für Nutzerzertifikate, | + | |
- | * **Wichtig: | + | |
- | + | ||
- | * Für Serverzertifikate (Hostzertifikate), | + | |
- | + | ||
- | =====Identifizierung und Dokumentation===== | + | |
- | ====Welche Anforderungen bestehen an die Identifizierung und Dokumentation für persönliche Zertifikate (client certificates, | + | |
- | + | ||
- | Die Anforderungen an die Identifizierung und die Dokumentation für Nutzerzertifikate sind im TCS Certification Practice Statement - Personal, eScience Personal | + | |
- | + | ||
- | Die dort für "TCS eScience Personal" | + | |
- | + | ||
- | Die wichtigsten Punkte: | + | |
- | + | ||
- | * Vor der Ausstellung eines Zertifikats soll eine persönliche | + | |
- | * Alternativ ist auch eine Video-Identifizierung oder eine Identifizierung über einen Notar möglich. | + | |
- | * Alternativ genügt auch eine bestehende andauernde Beziehung zum Zertifikatnehmer, | + | |
- | + | ||
- | Im Unterschied zur DFN-PKI " | + | |
- | + | ||
- | Die Dokumentation der Identifizierung muss nicht über die Verfahren hinausgehen, | + | |
- | sind. Die Einrichtung muss mit ihrer Dokumentation in der Lage sein, den Namen im Zertifikat auf eine konkrete Person zurückzuführen. | + | |
- | + | ||
- | ====Unterschiede | + | |
- | + | ||
- | Formal unterscheiden sich die Anforderungen an die Ausstellung von Nutzerzertifikaten für die Zertifikatprofile " | + | |
- | + | ||
- | 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:// | + | |
- | + | ||
- | Insbesondere lässt die DFN-AAI Advanced " | + | |
- | + | ||
- | 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 '' | + | |
- | + | ||
- | ====Welche Anforderung bestehen bei Serverzertifikaten (SSL OV)?==== | + | |
- | + | ||
- | Die Anforderungen an die Identifizierung und die Dokumentation für Serverzertifikate sind im TCS Certification Practice Statement - Server, eScience Server | + | |
- | + | ||
- | [[https:// | + | |
- | + | ||
- | =====Beantragen von Zertifikaten ohne Login im cert-manager: | + | |
- | + | ||
- | Mit Web-Formularen können Nutzer ohne eigenen Login in cert-manager Zertifikate beantragen. Zur Nutzung eines Web-Formulars ist ein sogenannter " | + | |
- | + | ||
- | Access Codes werden von einem RAO unter Settings-> | + | |
- | + | ||
- | + | ||
- | **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, | + | |
- | + | ||
- | **Bei Accounts für SSL Web Forms setzen Sie bitte auf keinen Fall die Checkbox " | + | |
- | + | ||
- | Die URL ist für alle Web-Formulare aller Einrichtungen im DFN-Mandanten von TCS identisch: https:// | + | |
- | + | ||
- | Erst der Access Code sorgt für die Zuordnung eines Antrags zu Ihrer Einrichtung. | + | |
- | + | ||
- | =====Wie können Zertifikate mit mehreren Servernamen erstellt werden? | + | |
- | + | ||
- | Zertifikate mit mehreren Servernamen (FQDN) können mit einem der " | + | |
- | + | ||
- | =====Was ist ein " | + | |
- | + | ||
- | Ein External Requester wird optional bei den Antragsformularen für Serverzertifikate abgefragt. Hier kann schlicht eine zusätzliche Mailadresse angegeben werden, die Benachrichtigungen zum Zertifikat erhält. | + | |
- | + | ||
- | =====Wie können Wildcard-Zertifikate erzeugt werden? | + | |
- | + | ||
- | Im Profil " | + | |
- | + | ||
- | =====Anmeldung an cert-manager===== | + | |
- | ====Mit Nutzername/ | + | |
- | Anmeldung mit Nutzername/ | + | |
- | ====Mit Zertifikat==== | + | |
- | Unter Admins-> | + | |
- | + | ||
- | **Achtung: | + | |
- | + | ||
- | Besonders tückische Falle: Die automatische Sperrung, wenn bereits zwei Nutzerzertifikate existieren, siehe [[https:// | + | |
- | ====SAML für Login in cert-manager.com==== | + | |
- | + | ||
- | Über den Button "Sign in with our Institution" | + | |
- | + | ||
- | Hierbei gibt es zwei verschiedene Wege: | + | |
- | - Bei einem per Admins, Button " | + | |
- | - Mit dem Weg Admins, Button "Add IdP User", kann ein Account ohne Passwort angelegt werde, der sich nur über den IdP einloggen kann. Zur Zeit müssen diese Accounts noch von der DFN-PCA manuell freigeschaltet werden. Ohne Freischaltung ist kein Login möglich. | + | |
- | + | ||
- | =====SAML für das Beantragen von Zertifikaten===== | + | |
- | + | ||
- | ====Tests==== | + | |
- | Unter https:// | + | |
- | + | ||
- | Die DFN-AAI stellt in der //DFN-AAI Testföderation// | + | |
- | + | ||
- | ====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 " | + | |
- | * Definition eines Attributes " | + | |
- | * Aufstellen einer SP-spezifischen AttributeFilterPolicy | + | |
- | * Mappen des Attributes singlemail auf mail | + | |
- | + | ||
- | Definition des Attributs: | + | |
- | < | + | |
- | <!-- attribute-filter.xml --> | + | |
- | <!-- Definition des zusätzlichen Attributes --> | + | |
- | < | + | |
- | < | + | |
- | </ | + | |
</ | </ | ||
- | 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 '' | + | =====Statusmeldungen und Wartungsankündigungen===== |
- | < | + | Statusmeldungen und Wartungsankündigungen der Sectigo-Services sind sichtbar über: https://sectigo.status.io |
- | <!-- attribute-filter.xml --> | + | |
- | < | + | |
- | < | + | |
- | < | + | |
- | < | + | Die Meldungen können dort auch als E-Mail und RSS-Feed (https://status.io/ |
- | < | + | |
- | </AttributeRule> | + | |
- | < | + | |
- | < | + | |
- | </AttributeRule> | + | |
- | </ | + | =====Support===== |
- | </ | + | |
- | Je nach eingesetzter IdP Version müssen an geeigneter Stelle noch die OID + Beschreibungen gesetzt werden: | + | Wir helfen auch bei technischen Schwierigkeiten mit den TCS-Systemen gerne weiter: [[dfnpca@dfn-cert.de|dfnpca@dfn-cert.de]] |
- | < | + | |
- | <bean parent=" | + | |
- | < | + | |
- | <props merge=" | + | |
- | <prop key=" | + | |
- | <prop key=" | + | |
- | <prop key=" | + | |
- | <prop key=" | + | |
- | <prop key=" | + | |
- | <prop key=" | + | |
- | <prop key=" | + | |
- | <prop key=" | + | |
- | <prop key=" | + | |
- | <prop key=" | + | |
- | <prop key=" | + | |
- | <prop key=" | + | |
- | <prop key=" | + | |
- | <prop key=" | + | |
- | <prop key=" | + | |
- | </ | + | |
- | </ | + | |
- | </ | + | |
- | </ | + | |
+ | Ein direkter Kontakt mit dem englischsprachigen Sectigo Support ist auch möglich. Das Support-Portal von Sectigo ist erreichbar unter: https:// | ||
+ | Bitte unbedingt den folgenden Hinweis einfügen: "We are a DFN member of the GEANT TCS service, using the SCM instance https:// | ||
- | ====Serverzertifikate==== | + | Es ist zu empfehlen, vor einer direkten Kontaktaufnahme zum Sectigo Support mit uns zu sprechen. |
- | Über diesen Weg können direkt per AAI-Login Serverzertifikate beantragt werden. | + | ===Support-Tickets für die Validierung (DCV) von IP-Adressen=== |
+ | Sofern Sie ein Ticket für den speziellen [[de: | ||
- | Der IdP muss in eduGAIN eingebunden sein. Über Settings-> | + | ===Support-Tickets für Anträge von Code-Signing-Zertifikate=== |
+ | Sofern Sie ein Ticket für die Bearbeitung von [[de: | ||
- | Mit der Checkbox " | + | Die Order Number ist zwingend anzugeben. Sie ist im SCM unter ☰→Certificates→Code Signing einsehbar. |
- | Ist diese Checkbox nicht aktiviert, müssen die Anträge von einem RAO oder DRAO über Certificates->Approve freigeschaltet werden. | + | =====E-Mail-Verteilerliste dfnpki-d===== |
- | Über die "URI Extension" | + | Auf [[https://listserv.dfn.de]] ist die E-Mail-Verteilerliste dfnpki-d@listserv.dfn.de eingerichtet. Diese unmoderierte Liste soll den Austausch **unter den Teilnehmern an der DFN-PKI** befördern und die Diskussion von Problemen und die Verbreitung von Lösungsvorschlägen ermöglichen. |
- | Über die optionalen " | + | Eine Anmeldung ist **für DFN-PKI-Teilnehmer** möglich unter [[https:// |
- | ====Nutzerzertifikate==== | + | |
- | Über diesen Weg können Nutzer direkt per AAI-Login Nutzerzertifikate beziehen. Die Zertifikate werden automatisch ohne weiteren Genehmigungsschritt ausgestellt. | ||
- | |||
- | In der Verwaltungsoberfläche müssen unter Settings-> | ||
- | |||
- | Der IdP muss in eduGAIN eingebunden sein und alle Attribute wie in folgender Beschreibung von GÈANT freigeben: [[https:// | ||
- | |||
- | |||
- | Insbesondere muss ein eduPersonEntitlement '' | ||
- | |||
- | Bitte beachten Sie die Identifizierungsvoraussetzungen, | ||
- | |||
- | |||
- | Wenn diese Voraussetzungen gegeben sind, können über https:// | ||
- | |||
- | Die Zertifikate werden automatisiert, | ||
- | |||
- | Achtung: Unter Settings-> | ||
- | |||
- | Achtung: Für Zertifikate, | ||
- | =====ACME===== | ||
- | ====ACME-Accounts==== | ||
- | |||
- | Zur Nutzung von ACME müssen im cert-manager.com spezielle ACME-Accounts angelegt werden. Hierzu muss unter Settings-> | ||
- | |||
- | Achtung: Zustände von ACME-Accounts sind anscheinend nicht notwendigerweise komplett synchron zu Hintergrundsystemen bei Sectigo. Im Test konnte bspw. ein ACME-Account nicht direkt, sondern erst nach einer Wartezeit über Nacht gelöscht werden. | ||
- | |||
- | ====Ausstellen==== | ||
- | |||
- | Vorausgesetzt, | ||
- | |||
- | < | ||
- | |||
- | Es können für beliebig viele FQDNs, die innerhalb der dem Account zugewiesenen Domains liegen, Zertifikate erstellt werden. | ||
- | |||
- | Der ACME-Account ist anschließend auf dem System, auf dem die o.g. Zeile aufgerufen wurde, mit einem dort abgelegten Account-Key verknüpft und kann nicht ohne weiteres auf anderen Systemen durch einfache erneute Eingabe von eab-kid und eab-hmac-key verwendet werden. | ||
- | |||
- | Um einen ACME-Account auf mehreren Systemen zu verwenden, muss die Account-Information des ACME-Clients kopiert werden. Für certbot liegen die Account-Informationen in / | ||
- | |||
- | 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:// | ||
- | ====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: | ||
- | |||
- | < | ||
- | |||
- | =====REST-API===== | ||
- | |||
- | Die Systeme von Sectigo können per REST-API angesprochen werden. Eine Dokumentation hierzu finden Sie unter: https:// | ||
- | |||
- | Die REST-API kann nur dann zum Enrollment verwendet werden, wenn unter Settings-> | ||
- | |||
- | Es ist ein Login/ | ||
- | |||
- | Tipp: Man kann einen Account in seiner Rolle so einschränken, | ||
- | |||
- | Beispiel für die Beantragung von Serverzertifikaten: | ||
- | |||
- | < | ||
- | -H " | ||
- | -H " | ||
- | -H " | ||
- | -H " | ||
- | -d ' | ||
- | |||
- | Die < | ||
- | |||
- | Die <Nummer des Zertifikatprofils> | ||
- | |||
- | < | ||
- | -H " | ||
- | -H " | ||
- | -H " | ||
- | -H " | ||
- | |||
- | Ausgestellte Zertifikate können mit folgendem Aufruf abgeholt werden: | ||
- | |||
- | < | ||
- | -H " | ||
- | -H " | ||
- | -H " | ||
- | -H " | ||
- | |||
- | < | ||
- | |||
- | < | ||
- | |||
- | Für Nutzerzertifikate ist die Beantragung ähnlich aufgebaut. Die Aufrufe müssen an https:// | ||
- | |||
- | =====Antragsweg " | ||
- | |||
- | Für den (nicht empfehlenswerten) Antragsweg " | ||
- | |||
- | Die geheimen Schlüssel der Nutzer werden dann an diesen Master Encryption Key verschlüsselt. | ||
- | |||
- | Ein RAO oder DAO kann geheime Schlüssel von Nutzern wiederherstellen, | ||
- | |||
- | Achtung: Dies betrifft nur den Antragsweg " | ||
- | |||
- | =====CAA-Records===== | ||
- | |||
- | Wenn Sie CAA-Records setzen möchten, um die Ausstellung von Zertifikaten auf bestimmte CAs einzuschränken, | ||
- | |||
- | < | ||
- | |||
- | |||
- | Der CAA-Record muss bereits zum Zeitpunkt der Domain-Freischaltung passen, nicht erst zum Zeitpunkt der konkreten Zertifikatausstellung. | ||
- | |||
- | =====Sperrinterface===== | ||
- | |||
- | Zertifikate sollen hauptsächlich von einem RAO oder DRAO in https:// | ||
- | |||
- | Die Sperrmechanismen von ACME (z.B. mit certbot revoke) stehen für per ACME ausgestellte Zertifikate ebenfalls zur Verfügung. | ||
- | |||
- | Unter der folgenden URL steht ein Sperrinterface bereit, in dem Sperranträge gestellt werden können: | ||
- | https:// | ||
- | |||
- | Hier sind allerdings weitere Authentifizierungsschritte erforderlich, | ||
- | |||
- | |||
- | ======Audits====== | ||
- | |||
- | Im Gegensatz zur DFN-PKI sind in GÉANT TCS keine regelmäßigen Audits der RA-Tätigkeit von Teilnehmern vorgesehen. | ||
- | |||
- | =====Status und Support===== | ||
- | |||
- | Wir helfen gerne per dfnpca@dfn-cert.de | ||
- | |||
- | Ein direkter Kontakt mit dem Sectigo Support ist auch möglich, es ist aber zu empfehlen, zunächst mit uns zu sprechen. Das Support-Portal von Sectigo ist erreichbar unter: https:// | ||
- | |||
- | Bitte unbedingt den folgenden Hinweis einfügen: "We are a DFN member of the GEANT TCS service, using the SCM instance https:// | ||
- | Statusmeldungen der Sectigo-Services sind sichtbar über: https:// |