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/09/07 08:03] – [Ausstellen] Juergen Brauckmann | de:dfnpki:tcsfaq [2024/04/15 16:11] – [Wie erhalten Einrichtungen einen Zugang?] 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 in einer Pilotphase ein. | + | |
- | + | ||
- | =====Was bedeutet Pilotphase? | + | |
- | + | ||
- | 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. | + | |
- | + | ||
- | Hierdurch kann leider noch nicht jeder Einrichtung, | + | |
- | + | ||
- | Wenn genügend Erfahrungen vorliegen, wird das Angebot | + | |
=====Wie erhalten Einrichtungen einen Zugang? | =====Wie erhalten Einrichtungen einen Zugang? | ||
- | Nach Abschluss der Pilotphase (voraussichtlich Sommer 2021) wird der DFN-Verein auf alle Teilnehmer der DFN-PKI zukommen, um ihnen einen Zugang zu TCS zu ermöglichen. | + | Ein Zugang zu TCS kann über den Kontakt [[pki@dfn.de|mailto: |
- | 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 29: | 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 35: | 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: |
- | Die Validierung von Domains per E-Mail-Challenge funktioniert bei TCS in einem wichtigen Detail anders: Während in der DFN-PKI die E-Mail-Adresse aus dem SOA-Record im DNS zusätzlich zu den Standardadressen '' | + | [[de:dfnpki: |
- | =====Zertifikattypen===== | + | [[de: |
- | ====ECC oder RSA?==== | ||
- | Bei Serverzertifikaten ist die Wahl des Algorithmus nicht so relevant. | + | ====CA- und Root-Zertifikate in TCS==== |
- | Bei Nutzerzertifikaten ist zu beachten, dass Zertifikate mit den ECC-Schlüsseltypen P-384 und P-256 nur für Signatur und Authentisierung, | + | Die uns bekannten Root- und CA-Zertifikate in TCS sind dokumentiert unter: [[de: |
- | ====Serverzertifikate==== | ||
- | Die Serverzertifikate ("OV Multi-Domain" | ||
- | ====OV SSL oder OV Multi Domain?==== | + | =====CAA-Records===== |
- | Wir empfehlen in jedem Fall OV Multi Domain zu verwenden. Im Zertifikatprofil OV Multi Domain sind mehrere Servernamen | + | Wenn Sie CAA-Records |
- | Im Zertifikatprofil OV SSL wird automatisch jedem Zertifikat ein zweiter, in den meisten Fällen sicherlich unerwünschter Alternativer Name " | + | [[de: |
- | Beispiel: Antrag enthält fachbereich1.example.org | + | =====Zertifikate sperren (Revoke, Revocation)===== |
+ | Zertifikate sollen üblicherweise von einem RAO oder DRAO in https:// | ||
- | 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. | + | Die [[de: |
- | ====Extended Validation Zertifikate (EV)==== | + | Unter der folgenden URL steht ein Sperrinterface bereit, in dem Sperranträge gestellt werden können: |
+ | https:// | ||
- | 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. | + | 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. |
- | * 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:// | + | ======Audits====== |
- | Versuchen Sie auf keinen Fall mehrere EV Anchor zu erstellen. | + | |
- | ====Nutzerzertifikate==== | + | Im Gegensatz zur DFN-PKI sind in GÉANT TCS keine regelmäßigen Audits der RA-Tätigkeit von Teilnehmern vorgesehen. |
- | Nutzerzertifikate (" | + | Im [[https:// |
- | ====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. | + | =====Statusmeldungen und Wartungsankündigungen===== |
- | 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. | + | Statusmeldungen und Wartungsankündigungen |
- | Dabei gilt: | + | Die Meldungen können dort auch als E-Mail und RSS-Feed (https:// |
- | * Sekundäre E-Mail-Adressen und der " | + | =====Support===== |
- | * Änderungen am " | + | 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:// | ||
- | ===Beschränkung der Anzahl der Zertifikate pro Nutzer=== | + | Bitte unbedingt den folgenden Hinweis einfügen: "We are a DFN member of the GEANT TCS service, using the SCM instance https:// |
- | Zusätzlich kennt das System eine Beschränkung der Anzahl der gleichzeitig gültigen Nutzerzertifikate pro Person und Zertifikatprofil: | + | Es ist zu empfehlen, vor einer direkten Kontaktaufnahme zum Sectigo Support mit uns zu sprechen. |
- | Pro Person können maximal zwei Zertifikate je Zertifikatprofil GEANT Personal, GEANT IGTF-MICS und GEANT IGTF-MICS-Robot Personal erstellt werden. | + | ===Support-Tickets für die Validierung (DCV) von IP-Adressen=== |
+ | Sofern Sie ein Ticket für den speziellen [[de: | ||
- | 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! | + | ===Support-Tickets für Anträge von Code-Signing-Zertifikate=== |
- | ====Code Signing==== | + | Sofern Sie ein Ticket für die Bearbeitung von [[de: |
- | === Code Signing | + | Die Order Number ist zwingend anzugeben. Sie ist im SCM unter ☰→Certificates→Code Signing |
- | Die über die Oberfläche beziehbaren Code-Signing Zertifikate sind für die Signatur von Java JARs & MS Office Macros verwendbar. | + | =====E-Mail-Verteilerliste dfnpki-d===== |
- | Die Zertifikatprofile '' | + | Auf [[https:// |
- | === EV Code Signing === | + | Eine Anmeldung ist **für DFN-PKI-Teilnehmer** möglich unter [[https:// |
- | EV Code Signing-Zertifikate, | ||
- | |||
- | Es müssen PDF-Formulare ausgefüllt und an den Sectigo-Support gesandt werden. Unter anderem muss die Organisation noch einmal validiert werden, auch wenn sie innerhalb von cert-manager bereits geprüft ist. | ||
- | ====Document Signing==== | ||
- | ===Tauglichkeit normaler Nutzerzertifikate=== | ||
- | Document Signing, z.B. in Adobe, ist mit den normalen Nutzerzertifikaten prinzipiell möglich. Allerdings sind gegebenenfalls 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 eine Kopie eines Ausweisdokumentes verlangt. | ||
- | |||
- | Bisherige Erfahrungen zeigen, dass Sectigo bei den bestätigenden Notariaten/ | ||
- | |||
- | Der DN der ausgestellten Zertifikate enthält je nach gewähltem Zertifikattyp entweder CN=< | ||
- | |||
- | Das Zertifikat wird von Sectigo auf Crypto-Token erstellt und versandt. | ||
- | |||
- | Die Dokumentation bei GÉANT: [[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 and Document Signing Certificates festgehalten: | ||
- | |||
- | 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 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 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 and Code Signing Certificates festgehalten: | ||
- | |||
- | [[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// | ||
- | |||
- | ====Serverzertifikate==== | ||
- | |||
- | Ü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-> | ||
- | |||
- | Über die "URI Extension" | ||
- | |||
- | Über die optionalen " | ||
- | ====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:// |