Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision | ||
de:dfnpki:tcsfaq [2021/06/03 11:23] – [Welche Anforderungen bestehen an die Identifizierung und Dokumentation für persönliche Zertifikate (client certificates, Nutzerzertifikate)?] Juergen Brauckmann | de:dfnpki:tcsfaq [2024/01/12 17:22] – [Wie erhalten Einrichtungen einen Zugang?] Juergen Brauckmann | ||
---|---|---|---|
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?===== | =====Was ist TCS?===== | ||
- | TCS (Trust Certificate Service) ist ein PKI-Angebot, | + | TCS (Trusted |
- | Überblick über den Dienst bei GÉANT: https://www.geant.org/ | + | Der DFN-Verein führt das Angebot zur Zeit für alle Teilnehmer der DFN-PKI ein. TCS wird die bisherige DFN-PKI " |
- | Der DFN-Verein führt das Angebot zur Zeit in einer Pilotphase ein. | + | =====Wie erhalten Einrichtungen einen Zugang? |
- | =====Was bedeutet Pilotphase? | + | Ein Zugang zu TCS kann über den Kontakt [[mailto: |
- | In der Pilotphase werden die Prozesse zum Ausrollen des Angebots an alle Teilnehmer der DFN-PKI | + | Das initiale Setup erfolgt dann in direkter Absprache |
- | Hierdurch kann leider noch nicht jeder Einrichtung, | + | ====Gibt es eine Testumgebung für TCS REST API und die Webseiten? |
- | Wenn genügend Erfahrungen vorliegen, wird das Angebot an alle Teilnehmer der DFN-PKI ausgerollt. Nach derzeitigem Stand wird dies im Sommer 2021 der Fall sein. | + | Der TCS-Anbieter Sectigo stellt keine Testumgebung zur Verfügung. |
- | =====Wie erhalten Einrichtungen einen Zugang?===== | + | =====Erste Schritte===== |
- | Nach Abschluss der Pilotphase (voraussichtlich Sommer 2021) wird der DFN-Verein auf alle Teilnehmer der DFN-PKI zukommen, um einen Zugang zu TCS zu geben. | + | Überblick über erste Schritte nach Erhalt eines Zugangs: [[de: |
- | Voraussetzung ist der Abschluss einer Dienstvereinbarung. Das initiale Setup erfolgt dann in direkter Absprache mit dfnpca@dfn-cert.de. | + | =====Dokumentation===== |
- | =====Dokumentation===== | + | Bei GÉANT gibt es eine Zusammenstellung von FAQs: [[https:// |
- | 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 möglich. | Dort gibt es, wie in der Java RA-Oberfläche der DFN-PKI, einen direkten Überblick über offene Anträge und ausgestellte Zertifikate und eine Verwaltung von Domains. Es gibt eine Verwaltung von weiteren Administratoren und Abteilungen. Im cert-manager ist die sofortige Ausstellung von neuen Server- und Nutzerzertifikaten möglich. | ||
Zeile 43: | Zeile 45: | ||
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 |
- | 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 können dort auch als E-Mail und RSS-Feed (https:// |
- | 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==== | + | =====Support===== |
- | Formal unterscheiden sich die Anforderungen an die Ausstellung von Nutzerzertifikaten für die Zertifikatprofile " | + | Wir helfen auch bei technischen Schwierigkeiten mit den TCS-Systemen gerne weiter: [[mailto: |
- | 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. | + | Ein direkter Kontakt mit dem englischsprachigen Sectigo Support ist auch möglich. Das Support-Portal von Sectigo ist erreichbar unter: https:// |
- | ==== Vergleich mit DFN-AAI Advanced ==== | + | Bitte unbedingt den folgenden Hinweis einfügen: "We are a DFN member of the GEANT TCS service, using the SCM instance https:// |
- | Die Regeln der DFN-AAI Advanced und die Regeln zur Identifizierung von Personen in TCS sind **nicht** deckungsgleich. | + | Es ist zu empfehlen, vor einer direkten Kontaktaufnahme zum Sectigo Support mit uns zu sprechen. |
- | Insbesondere lässt die DFN-AAI Advanced " | + | ===Support-Tickets für die Validierung (DCV) von IP-Adressen=== |
+ | Sofern Sie ein Ticket für den speziellen [[de: | ||
- | 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 | + | =====E-Mail-Verteilerliste |
- | Wert urn: | + | |
- | ====Welche Anforderung bestehen bei Serverzertifikaten (SSL OV)?==== | + | Auf [[https:// |
- | 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: | + | Eine Anmeldung |
- | + | ||
- | 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 | + | |
- | + | ||
- | Access Codes werden von einem RAO unter Settings-> | + | |
- | + | ||
- | + | ||
- | **Bitte richten Sie keine Accounts zur Nutzung von Web-Formularen | + | |
- | + | ||
- | **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 | + | |
- | + | ||
- | 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 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: https:// | + | |
- | + | ||
- | + | ||
- | 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 Nutzername/ | + | |
- | + | ||
- | Tipp: Man kann einen Nutzer in seiner Rolle so einschränken, | + | |
- | + | ||
- | Beispiel für die Beantragung von Serverzertifikaten: | + | |
- | + | ||
- | < | + | |
- | -H " | + | |
- | -H " | + | |
- | -H " | + | |
- | -H " | + | |
- | | + | |
- | + | ||
- | 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, | + | |
- | + | ||
- | < | + | |
- | + | ||
- | + | ||
- | Der CAA-Record muss bereits zum Zeitpunkt der Domain-Freischaltung passen, nicht erst zum Zeitpunkt der konkreten Zertifikatausstellung. | + | |
- | =====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:// |