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/06/10 14:55] – Sperrinterface Juergen Brauckmann | de:dfnpki:tcsfaq [2024/04/15 16:13] (aktuell) – [E-Mail-Verteilerliste dfnpki-d] Reimer Karlsen-Masur | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
- | Auf dieser Seite stellen wir den Teilnehmern | + | **Diese FAQ richtet sich primär an die Teilnehmerservices an den an der DFN-PKI |
- | =====Was ist TCS?===== | + | =====Wie erhalten Einrichtungen einen Zugang?===== |
- | TCS (Trusted Certificate Service) ist ein PKI-Angebot, | + | Ein Zugang zu TCS kann über den Kontakt [[pki@dfn.de|pki@dfn.de]] beauftragt |
- | Überblick über den Dienst bei GÉANT: https://www.geant.org/ | + | Das initiale Setup erfolgt dann in direkter Absprache mit [[dfnpca@dfn-cert.de|dfnpca@dfn-cert.de]]. |
- | Der DFN-Verein führt das Angebot zur Zeit in einer Pilotphase ein. | + | ====Gibt es eine Testumgebung für TCS REST API und die Webseiten? |
- | =====Was bedeutet Pilotphase? | + | Der TCS-Anbieter Sectigo stellt keine Testumgebung zur Verfügung. |
- | In der Pilotphase werden die Prozesse zum Ausrollen des Angebots an alle Teilnehmer der DFN-PKI mit einem eingeschränkten Nutzerkreis erprobt. Die Erprobung ist nicht nur in Bezug auf die internen Prozesse der DFN-PCA zur Versorgung der Teilnehmer notwendig, sondern auch zur Einschätzung der Abläufe und Vorgehensweisen des TCS-Anbieters insbesondere im Bereich der Organisationsvalidierung. | + | =====Erste Schritte===== |
- | Hierdurch kann leider noch nicht jeder Einrichtung, | + | Überblick über erste Schritte nach Erhalt eines Zugangs: [[de: |
- | Wenn genügend Erfahrungen vorliegen, wird das Angebot an alle Teilnehmer der DFN-PKI ausgerollt. Nach derzeitigem Stand wird dies im Sommer 2021 der Fall sein. | + | =====Dokumentation===== |
- | =====Wie erhalten Einrichtungen einen Zugang? | + | Bei GÉANT gibt es eine Zusammenstellung von FAQs: [[https:// |
- | + | ||
- | Nach Abschluss der Pilotphase (voraussichtlich Sommer 2021) wird der DFN-Verein auf alle Teilnehmer der DFN-PKI zukommen, um einen Zugang zu TCS zu geben. | + | |
- | + | ||
- | Voraussetzung ist der Abschluss einer Dienstvereinbarung. Das initiale Setup erfolgt dann in direkter Absprache mit dfnpca@dfn-cert.de. | + | |
- | + | ||
- | =====Dokumentation===== | + | |
- | Bei GÉANT gibt es eine Zusammenstellung | + | Die Dokumentation |
- | Die Dokumentation von Sectigo zur Administrations-Oberfläche und zu ACME ist zu finden | + | Die REST-API ist dokumentiert |
- | Die REST-API ist dokumentiert unter https://support.sectigo.com/Com_KnowledgeDetailPage? | + | Sectigo unterhält einen Youtube-Kanal mit vielen Tutorials: |
=====Datenschutz===== | =====Datenschutz===== | ||
- | Eine Bewertung von GÈANT zu Fragen zu Datenschutz und DSGVO liegt vor: https:// | + | Hinweise zum Datenschutz und der vertraglichen Konstruktion: |
+ | [[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. | ||
- | =====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. example.org. Nach erfolgreicher Validierung kann dann ein Sternchen-Eintrag *.example.org erzeugt werden. Nur mit dem Sternchen-Eintrag scheinen | + | [[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: |
- | =====Zertifikattypen===== | + | |
- | ====Welchen Zertifikattyp für welchen Zweck/ | + | |
- | * Die Serverzertifikate ("OV Multi-Domain" | + | [[de:dfnpki: |
- | * Die Nutzerzertifikate (" | + | |
- | * Die Code-Signing | + | |
- | ====OV SSL oder OV Multi Domain?==== | + | [[de: |
- | Wir empfehlen in jedem Fall OV Multi Domain zu verwenden. Im Zertifikatprofil OV Multi Domain sind mehrere Servernamen möglich, z.B. fachbereich1.example.org, | ||
- | Im Zertifikatprofil OV SSL wird automatisch jedem Zertifikat ein zweiter, | + | ====CA- und Root-Zertifikate |
- | Beispiel: Antrag enthält fachbereich1.example.org => Das ausgestellte Zertifikat enthält die Namen fachbereich1.example.org | + | Die uns bekannten Root- und CA-Zertifikate in TCS sind dokumentiert unter: [[de: |
- | ====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. | + | =====CAA-Records===== |
- | * Vor der Erstellung eines EV-Anchors müssen | + | Wenn Sie CAA-Records im DNS setzen möchten, um die Ausstellung |
- | Die Anleitung im GÈANT FAQ ist zu finden unter: https:// | + | [[de:dfnpki:tcs:caa|CAA]] |
- | Versuchen Sie auf keinen Fall mehrere EV Anchor zu erstellen. | + | |
- | ====Document Signing==== | + | =====Zertifikate sperren (Revoke, Revocation)===== |
- | Für spezielle Document Signing | + | Zertifikate |
- | https:// | + | Die [[de:dfnpki: |
- | ====Grid-Zertifikate (IGTF)==== | + | Unter der folgenden URL steht ein Sperrinterface bereit, in dem Sperranträge gestellt werden können: |
+ | https:// | ||
- | * Für Nutzerzertifikate, die um Grid-Umfeld verwendet werden sollen, verwenden Sie bitte eines der IGTF-Profile. | + | Hier sind allerdings weitere Authentifizierungsschritte erforderlich, wie beispielsweise |
- | * **Wichtig: | + | |
- | * Die Serverzertifikate aus den Standard-Profilen (z.B. "OV Multi Domain" | ||
- | =====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 and Document Signing Certificates festgehalten: | + | ======Audits====== |
- | Die dort für "TCS eScience Personal" | + | Im Gegensatz zur DFN-PKI sind in GÉANT |
- | Die in dem Dokumente genannten Anforderungen für "MICS/Birch" sind für die Nutzerzertifikate im Profil " | + | Im [[https://wiki.geant.org/display/TCSNT/TCS+Repository|TCS Certification Practice Statement - Personal, eScience Personal and Document Signing Certificates]] wird in Kapitel 9.6.2 vereinbart: |
- | Die wichtigsten Punkte: | + | < |
+ | </ | ||
- | * Vor der Ausstellung eines Zertifikats soll eine persönliche | + | =====Statusmeldungen |
- | * 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 " | + | Statusmeldungen |
- | Die Dokumentation der Identifizierung muss nicht über die Verfahren hinausgehen, | + | Die Meldungen |
- | 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 " | + | |
- | + | ||
- | 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 müssen. | + | |
- | + | ||
- | ==== Vergleich mit DFN-AAI Advanced ==== | + | |
- | + | ||
- | Die Regeln der DFN-AAI Advanced und die Regeln zur Identifizierung von Personen in TCS sind **nicht** deckungsgleich. | + | |
- | + | ||
- | 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 urn: | + | |
- | + | ||
- | ====Welche Anforderung bestehen bei Serverzertifikaten (SSL OV)?==== | + | |
- | + | ||
- | Die Anforderungen an die Identifizierung und die Dokumentation für Serverzertifikate sind im TCS Certification Practice Statement - Server, eScience Server and Code Signing Certificates festgehalten: | + | |
- | + | ||
- | https:// | + | |
- | + | ||
- | =====Beantragen von Zertifikaten ohne Login im cert-manager: | + | |
- | + | ||
- | Mit Web-Formularen | + | |
- | + | ||
- | 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 " | + | |
- | + | ||
- | =====SAML===== | + | |
- | + | ||
- | Ein Einrichtungs-eigener IdP aus der DFN-AAI kann für drei verschiedene Zwecke an das TCS-System angebunden werden. | + | |
- | + | ||
- | Unter https:// | + | |
- | + | ||
- | ====SAML für Login in cert-manager.com==== | + | |
- | + | ||
- | Mit diesem Weg können sich RAOs oder DRAOs in cert-manager.com einloggen. Eine Beschreibung der Voraussetzungen ist zu finden unter: https:// | + | |
- | + | ||
- | Hierbei gibt es zwei verschiedene Wege: | + | |
- | - Bei einem per Admins, Button " | + | |
- | | + | |
- | + | ||
- | ====SAML für die Beantragung von Serverzertifikaten==== | + | |
- | + | ||
- | Über diesen Weg können direkt per AAI-Login Serverzertifikate beantragt werden. | + | |
- | + | ||
- | Der IdP muss in eduGain eingebunden sein. Über Settings-> | + | |
- | + | ||
- | Mit der Checkbox " | + | |
- | + | ||
- | Ist diese Checkbox nicht aktiviert, müssen die Anträge von einem RAO oder DRAO über Certificates-> | + | |
- | + | ||
- | ====SAML für die Beantragung von Nutzerzertifikaten==== | + | |
- | + | ||
- | Über diesen Weg können Nutzer direkt per AAI-Login Nutzerzertifikate beziehen. Die Zertifikate werden automatisch ohne weiteren Genehmigungsschritt ausgestellt. | + | |
- | + | ||
- | In der Verwaltungsoberfläche müssen unter Settings-> | + | |
- | + | ||
- | Der IdP muss in eduGain eingebunden sein und alle Attribute wie in folgender Beschreibung von GÈANT freigeben: | + | |
- | + | ||
- | + | ||
- | Insbesondere muss ein eduPersonEntitlement urn: | + | |
- | + | ||
- | 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, | + | |
- | + | ||
- | < | + | |
- | + | ||
- | 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 / | + | |
- | + | ||
- | 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 entweder 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:// | + | |
- | + | ||
- | =====Schlüsselerzeugung und -hinterlegung bei Nutzerzertifikaten===== | + | |
- | + | ||
- | Die Schüsselerzeugung bei Nutzerzertifikaten (" | + | |
- | + | ||
- | 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 ist beim Antragsweg " | + | |
- | + | ||
- | =====CAA-Records===== | + | |
- | Wenn Sie CAA-Records setzen möchten, um die Ausstellung von Zertifikaten auf bestimmte CAs einzuschränken, | + | =====Support===== |
- | < | + | Wir helfen auch bei technischen Schwierigkeiten mit den TCS-Systemen gerne weiter: [[dfnpca@dfn-cert.de|dfnpca@dfn-cert.de]] |
+ | Ein direkter Kontakt mit dem englischsprachigen Sectigo Support ist auch möglich. Das Support-Portal von Sectigo ist erreichbar unter: https:// | ||
- | Der CAA-Record muss bereits zum Zeitpunkt der Domain-Freischaltung passen, nicht erst zum Zeitpunkt der konkreten Zertifikatausstellung. | + | Bitte unbedingt den folgenden Hinweis einfügen: "We are a DFN member of the GEANT TCS service, using the SCM instance https:// |
- | =====Sperrinterface===== | + | Es ist zu empfehlen, vor einer direkten Kontaktaufnahme zum Sectigo Support mit uns zu sprechen. |
- | Zertifikate sollen hauptsächlich | + | ===Support-Tickets für die Validierung (DCV) von IP-Adressen=== |
+ | Sofern Sie ein Ticket für den speziellen [[de:dfnpki: | ||
- | Die Sperrmechanismen von ACME (z.B. mit certbot revoke) stehen | + | ===Support-Tickets |
+ | Sofern Sie ein Ticket für die Bearbeitung von [[de: | ||
- | Unter der folgenden URL steht ein Sperrinterface bereit, in dem Sperranträge gestellt werden können | + | Die Order Number ist zwingend anzugeben. Sie ist im SCM unter ☰→Certificates→Code Signing einsehbar. |
- | https:// | + | |
- | Hier sind allerdings weitere Authentifizierungsschritte erforderlich, | + | =====E-Mail-Verteilerliste dfnpki-d===== |
- | =====Status | + | Auf [[https:// |
- | Wir helfen gerne per dfnpca@dfn-cert.de | + | Eine Anmeldung ist **für DFN-PKI-Teilnehmer** möglich unter [[https:// |
- | 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:// | ||
- | Statusmeldungen der Sectigo-Services sind sichtbar über: https:// |