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 [2022/09/30 16:44] – [Nutzerzertifikate] Juergen Brauckmann | de:dfnpki:tcsfaq [2024/01/26 16:32] – Juergen Brauckmann | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
- | Auf dieser Seite stellen wir den Teilnehmern an der DFN-PKI eine FAQ-Seite zur Einführung in TCS zur Verfügung. Diese Seite wird permanent mit den Fragen der Anwender weiter entwickelt. | ||
- | |||
**Diese FAQ richtet sich primär an die Teilnehmerservices an den an der DFN-PKI teilnehmenden Einrichtungen. Nicht alle hier beschriebenen Funktionen werden von allen Einrichtungen gleichermaßen umgesetzt. Falls Sie sich für den Bezug eines Zertifikats interessieren, | **Diese FAQ richtet sich primär an die Teilnehmerservices an den an der DFN-PKI teilnehmenden Einrichtungen. Nicht alle hier beschriebenen Funktionen werden von allen Einrichtungen gleichermaßen umgesetzt. Falls Sie sich für den Bezug eines Zertifikats interessieren, | ||
- | |||
- | =====Was ist TCS?===== | ||
- | |||
- | TCS (Trusted Certificate Service) ist ein PKI-Angebot, | ||
- | |||
- | Der DFN-Verein führt das Angebot zur Zeit für alle Teilnehmer der DFN-PKI ein. TCS wird die bisherige DFN-PKI " | ||
=====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 [[mailto: |
- | Das initiale Setup erfolgt dann in direkter Absprache mit '' | + | Das initiale Setup erfolgt dann in direkter Absprache mit [[mailto:dfnpca@dfn-cert.de|dfnpca@dfn-cert.de]]. |
====Gibt es eine Testumgebung für TCS REST API und die Webseiten? | ====Gibt es eine Testumgebung für TCS REST API und die Webseiten? | ||
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 30: | Zeile 22: | ||
Die REST-API ist dokumentiert unter https:// | Die REST-API ist dokumentiert unter https:// | ||
- | |||
Sectigo unterhält einen Youtube-Kanal mit vielen Tutorials: 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:datenschutz|Datenschutz]] | |
- | Die Bewertung von GÉANT wurde von der Forschungsstelle Recht im DFN überprüft. Das Ergebnis der Prüfung ist hier verfügbar: [[https:// | + | |
=====Funktionsüberblick===== | =====Funktionsüberblick===== | ||
Zeile 43: | Zeile 34: | ||
Anwender haben Zugriff über die Administrations-Oberfläche, | Anwender haben Zugriff über die Administrations-Oberfläche, | ||
- | 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: | ||
+ | ===== Tipps und Tricks in SCM ===== | ||
+ | [[de: | ||
- | =====Admins, | ||
- | |||
- | Im linken Seitenmenü können unter ☰-> | ||
- | |||
- | Es wird zwischen verschiedenen Rollen unterschieden, | ||
- | |||
- | * RAO und DRAO sind Registration Authority Officer auf Organisations- oder Department-(Abteilungs)-Ebene. Je nach den diesen Accounts bei der Einrichtung zugewiesenen Rechten können RAO/DRAO weitere RAOs/DRAOs anlegen, modifizieren oder löschen, und eine Auswahl der Zertifikattypen SSL, Client und Code Signing erstellen. | ||
- | |||
- | Der erste RAO-Account einer Einrichtung wird von der DFN-PCA angelegt. Weitere RAOs oder DRAOs können dann eigenständig angelegt und verwaltet werden. | ||
- | |||
- | * Privilegien "Allow ... of peer admin" ermöglichen u.a. das Anlegen, Modifizieren oder Löschen von weiteren RAOs/DRAOs. | ||
- | * Mit dem Privileg " | ||
- | * API-Only-User: | ||
- | * E-Mail-Adressen von SCM-Admin-Accounts dürfen keine großen Buchstaben (A-Z) enthalten. Kleinschreibung (a-z) wird akzeptiert. | ||
- | |||
- | Die meisten Privilegien können für DRAO-Accounts mit einem RAO-Account selbst verwaltet werden. Für RAO-Accounts können die Privilegien nicht selbst gesetzt werden, sondern nur von der DFN-PCA nachträglich geändert werden. Melden Sie sich zum Umsetzen von Privilegien bitte per E-Mail bei '' | ||
- | |||
- | ====Passworte==== | ||
- | |||
- | Vorsicht bei der Vergabe von Passworten: Zeichen außerhalb von 7-bit ASCII können zwar beim Setzen des Passwortes genutzt werden, das Einloggen schlägt aber fehl. D.h., Standard-Sonderzeichen wie ''# | ||
- | |||
- | ====Anmeldung mit Zertifikat==== | ||
- | Unter ☰-> | ||
- | |||
- | **Achtung: | ||
- | |||
- | Besonders tückische Falle: Die automatische Sperrung, wenn bereits zwei Nutzerzertifikate existieren, siehe [[https:// | ||
- | ====Anmeldung mit SAML==== | ||
- | |||
- | Über den Button "Sign in with your Institution" | ||
- | |||
- | Weitere Voraussetzungen finden Sie unter [[de: | ||
- | |||
- | Um einen Account für das Einloggen vorzubereiten, | ||
- | - Bei einem per ☰-> | ||
- | - Mit dem Weg ☰-> | ||
- | * Ein neu angelegter IdP User in der Organisation muss von der DFN-PCA freigeschaltet werden. Beauftragen Sie die Freischaltung bitte einfach per E-Mail an [[mailto: | ||
- | * Ein von einem RAO neue angelegter IdP User in einem Department kann von einem zweiten RAO direkt freigeschaltet werden. | ||
- | |||
- | |||
- | Ihr IdP muss mindestens '' | ||
- | |||
- | |||
- | =====Departments===== | ||
- | |||
- | Zur weiteren Strukturierung der Organisation können RAOs Abteilungen anlegen. Hierzu im linken Seiten-Menü " | ||
- | |||
- | Bitte beim Eintragen des Secondary Organization Names darauf achten, dass dessen Länge unter 64 Zeichen bleibt. Es wird sonst zu mysteriösen Fehlern bei der Zertifikatbeantragung kommen. | ||
- | |||
- | **Wichtig: | ||
- | |||
- | Im Anschluss können über ☰-> | ||
- | |||
- | Entgegen der Intuition unterliegen DRAOs keiner besonderen Beschränkung in der Domain-Verwaltung. | ||
=====Zugriff per AAI===== | =====Zugriff per AAI===== | ||
- | ====Voraussetzungen==== | ||
- | Viele Funktionen im cert-manager können auch nach einem Login über die DFN-AAI genutzt werden. Hierzu müssen die folgenden Voraussetzungen erfüllt sein: | ||
- | |||
- | * In der Verwaltungsoberfläche müssen unter ☰-> | ||
- | * Wenn kein Academic code (SCHAC Home Organization) gesetzt ist, senden Sie bitte den entspr. Wert per E-Mail an '' | ||
- | * Welcher Wert zu setzen ist, können Sie evtl. schon der Ausgabe von https:// | ||
- | * Ihr Identity-Provider muss in eduGAIN eingebunden sein | ||
- | * Ihr Identity-Provider muss mindestens die Attribute '' | ||
- | * Für eine AttributeFilterPolicy für Ihren Identity-Provider, | ||
- | |||
- | Die Konfiguration erfordert in der Regel die Mithilfe Ihrer AAI-Administration, | ||
- | ====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-resolver.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 '' | ||
- | |||
- | < | ||
- | <!-- attribute-filter.xml --> | ||
- | < | ||
- | < | ||
- | < | ||
- | |||
- | < | ||
- | < | ||
- | </ | ||
- | < | ||
- | < | ||
- | </ | ||
- | |||
- | </ | ||
- | </ | ||
- | |||
- | Je nach eingesetzter IdP Version müssen an geeigneter Stelle noch die OID + Beschreibungen gesetzt werden: | ||
- | < | ||
- | <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=" | ||
- | </ | ||
- | </ | ||
- | </ | ||
- | </ | ||
- | |||
- | =====Domainvalidierung, | ||
- | |||
- | Um Zertifikate zu erhalten, müssen die entsprechenden Domains im linken Seitenmenü unter dem Punkt " | ||
- | |||
- | **Ausnahme: | ||
- | |||
- | Es muss zunächst die Hauptdomain eingetragen und validiert werden, z.B. '' | ||
- | |||
- | Wenn Sie CAA-Records verwenden, so müssen diese bereits zum Zeitpunkt der Domainvalidierung passen, und nicht erst zum Zeitpunkt der Ausstellung von Zertifikaten, | ||
- | |||
- | Die Domainvalidierung muss bei Sectigo alle 365 Tage wiederholt werden. Das Ablaufdatum ist im cert-manager sichtbar. | ||
- | |||
- | ====Validierungsmethoden==== | ||
- | |||
- | ===E-Mail=== | ||
- | |||
- | Domains können wie in der DFN-PKI über die Standardadressen '' | ||
- | |||
- | Die E-Mail-Adresse aus dem SOA-Record im DNS steht **nicht** zur Verfügung. Wenn in der zu validierenden Domain kein Mail-Empfang möglich ist, muss eine der anderen Validierungsmethoden verwendet werden. | ||
- | |||
- | ===DNS bzw. CNAME=== | ||
- | |||
- | Bei der CNAME-Methode muss im DNS ein von Sectigo vorgegebener CNAME für die Domain hinterlegt werden. Beispiel: | ||
- | < | ||
- | _230283408052380233432bdcad080132.example.org. | ||
- | </ | ||
- | |||
- | Die Reihenfolge der Schritte im DCV-Ablauf mittels CNAME ist entscheidend: | ||
- | |||
- | Nach dem " | ||
- | |||
- | Nach erfolgter Validierung kann der CNAME wieder entfernt werden. Es ist davon auszugehen, dass bei einer Revalidierung (alle 365 Tage) ein anderer CNAME gesetzt werden muss. | ||
- | |||
- | ===HTTP/ | ||
- | |||
- | Bei der HTTP-Methode muss auf dem Webserver eine von Sectigo vorgegebene Datei abgelegt werden. | ||
- | |||
- | **Achtung: | ||
- | |||
- | Hinweise von Sectigo zu dieser Umstellung: https:// | ||
- | |||
- | ====Domains und Departments==== | ||
- | |||
- | Department-Administratoren (DRAOs) unterliegen keiner besonderen Beschränkung in der Domain-Verwaltung. Sie können neue Domains eintragen und abhängig vom Recht '' | ||
- | |||
- | Ist eine von einem DRAO eingetragene Domain bereits Ihrer Organisation | ||
- | zugewiesen und gibt es eine gültige Domain Control Validation, steht die | ||
- | Domain quasi sofort im Department zur Ausstellung von Zertifikaten zur Verfügung. Das gleiche gilt für im Department eingetragen Sub-Domains von bereits der Organisation zugewiesenen Parent-Domains. | ||
- | |||
- | Wenn Sie Domains in eingerichteten Departments kontrollieren wollen, | ||
+ | Viele Funktionen im cert-manager können auch nach einem Login über die DFN-AAI genutzt werden. Hierzu müssen Voraussetzungen erfüllt sein: [[de: | ||
- | ====Umlaut-Domains, | + | =====Benachrichtigungen===== |
- | Umlaut-Domains | + | Um Benachrichtigungen über Ereignisse wie den Ablauf von Zertifikaten oder der Gültigkeit von Domain-Valididierungen zu erhalten, |
- | ====IP-Adressen in Zertifikaten==== | + | =====Domains und IPv4-Adressen in Zertifikaten===== |
- | Um eine IP-Adresse in Zertifikate | + | Um Zertifikate zu erhalten, müssen |
- | - IP-Adresse wie eine Domain unter ☰-> | + | Eine detaillierte Beschreibung ist verfügbar unter: |
- | - Bestätigung der Domain-Delegation abwarten. | + | |
- | - DCV für die IP-Adresse mit der Methode '' | + | |
- | - Den [[de: | + | |
- | Der Weg über den Support ist auch bei jeder turnusmäßigen, | ||
- | Es können nur einzelne IP-Adressen eingetragen werden, keine Adressbereiche. | ||
=====Zertifikate erstellen===== | =====Zertifikate erstellen===== | ||
- | ====Serverzertifikate==== | + | [[de: |
- | ===Direkt im cert-manager=== | + | [[de: |
- | Sie können als eingeloggter RAO oder DRAO direkt im cert-manager Serverzertifikate beantragen und ausstellen. | + | [[de: |
- | Wählen Sie hierzu unter ☰-> | + | [[de: |
- | Wählen Sie im Regelfall das Zertifikatprofil OV Multi-Domain. Wählen Sie **nicht** EV Anchor, es sei denn, Sie wollen den speziellen EV-Prozess starten. | + | [[de: |
- | ===Über die AAI==== | + | [[de: |
- | Wenn Ihre Einrichtung in die DFN-AAI eingebunden ist und Ihr IdP die Voraussetzungen erfüllt (siehe | ||
- | |||
- | Über ☰-> | ||
- | |||
- | Mit der Checkbox " | ||
- | |||
- | Ist diese Checkbox nicht aktiviert, müssen die Anträge von einem RAO oder DRAO über ☰-> | ||
- | |||
- | Über die "URI Extension" | ||
- | |||
- | Über die optionalen " | ||
- | |||
- | |||
- | ===SSL Web Form=== | ||
- | |||
- | Mit Web-Formularen können Nutzer ohne eigenen Login in cert-manager Zertifikate beantragen. Zur Nutzung eines Web-Formulars ist ein sogenannter " | ||
- | |||
- | Access Codes werden von einem RAO unter ☰-> | ||
- | |||
- | **Bitte verwenden Sie nicht den Button Edit**. Mit diesem Button können Hilfetexte und -links gesetzt werden, die sich **global** auf alle anderen Einrichtungen im gesamten DFN-Mandanten auswirken. | ||
- | |||
- | **Bei Accounts für SSL Web Forms setzen Sie bitte auf keinen Fall die Checkbox " | ||
- | |||
- | Die URL ist für alle Web-Formulare aller Einrichtungen im DFN-Mandanten von TCS zur Beantragung von Serverzertifikaten identisch: https:// | ||
- | |||
- | Erst der Access Code sorgt für die Zuordnung eines Antrags zu Ihrer Einrichtung. | ||
- | |||
- | ===ACME=== | ||
- | |||
- | Es stehen Endpunkte für das ACME-Protokoll zur Verfügung, mit denen mit Standard-Clients automatisiert Serverzertifikate bezogen werden können. Hinweise hierzu unter [[de: | ||
- | |||
- | |||
- | ===REST-API für Serverzertifikate=== | ||
- | |||
- | Über das REST API können mit selbst erstellter Software oder Skripten Serverzertifikate erstellt werden. Hinweise hierzu unter [[de: | ||
- | |||
- | |||
- | |||
- | |||
- | ====Nutzerzertifikate==== | ||
- | |||
- | ===E-Mail-Einladung=== | ||
- | |||
- | Die Erstellung von Nutzerzertifikaten ist nach einiger Vorbereitung möglich. Insbesondere muss ein '' | ||
- | |||
- | - Im SCM unter ☰-> | ||
- | - das Enrollment Form mit dem Namen '' | ||
- | - oben auf " | ||
- | - Im daraufhin geöffneten Popup-Fenster über mit dem grünen " | ||
- | - Einen sprechenden Namen für den Account vergeben, der auf Ihre Einrichtung hindeutet. | ||
- | - Als " | ||
- | - Bei den Zertifikatprofilen über das kleine " | ||
- | - meist "GEANT Personal Certificate", | ||
- | - alternativ "GEANT Personal Certificate RSA 3 year" oder "...1 year" mit Limitierung auf 4096 Bit RSA mit 3 bzw. 1 Jahr Laufzeit. | ||
- | - Als "CSR Generation Method" | ||
- | - " | ||
- | - " | ||
- | - "Allow empty PKCS12 Password" | ||
- | - Als " | ||
- | - Das Ganze mittels " | ||
- | |||
- | Bitte keine fremden '' | ||
- | |||
- | Bitte keine neuen, eigenen '' | ||
- | |||
- | Dann zum manuellen Auslösen der einzelnen Einladungs-Mails durch (D)RAOs unterhalb von ☰-> | ||
- | |||
- | - Mit dem grünen " | ||
- | - Der gesetzte '' | ||
- | - **Achtung: | ||
- | - Anschließend muss die Person mit der Checkbox vor dem Namen ausgewählt werden. Über den Button " | ||
- | - Dabei genau den " | ||
- | - Abschließend auf den " | ||
- | |||
- | Mit der Einladung kann direkt ein Zertifikat bezogen werden. | ||
- | |||
- | |||
- | Mit dem Upload-Symbol neben dem " | ||
- | |||
- | Bitte beachten Sie die Identifizierungsvoraussetzungen, | ||
- | |||
- | Unter dem Punkt ☰-> | ||
- | |||
- | |||
- | ===Schlüsselhinterlegung bei Nutzerzertifikaten=== | ||
- | |||
- | Für den Antragsweg " | ||
- | |||
- | **Wir empfehlen dringend, auf diese Möglichkeit zu verzichten. Der Key Escrow Mechanismus funktioniert nur mit einer eingeschränkten Auswahl an Antragswegen, | ||
- | |||
- | Bei der Einrichtung eines Departments kann ausgewählt werden, ob eine Schlüsselhinterlegung stattfinden soll. Wenn ja, muss vor dem Ausstellen von Nutzerzertifikaten von dem Department durch die Rolle DRAO ein Master Encryption Key erzeugt werden (Nutzen Sie hierzu ☰-> | ||
- | |||
- | Die privaten Schlüssel der Nutzer werden dann an diesen Master Encryption Key verschlüsselt. | ||
- | |||
- | Ein DRAO kann private Schlüssel von Nutzern wiederherstellen, | ||
- | |||
- | Achtung: Dies ist nur in diesem Antragsweg " | ||
- | |||
- | |||
- | ===Über die AAI=== | ||
- | |||
- | Unter der URL https:// | ||
- | |||
- | Für die Schlüsselerzeugung im AAI-Workflow gibt es in dem angebotenen Formular eine Wahlmöglichkeit: | ||
- | * Entweder wird der private Schlüssel von Sectigo erzeugt | ||
- | * oder aber vom Beantragenden vorab zusammen mit einem CSR generiert. Der erstellte CSR kann dann im Formular zur Zertifikaterstellung hochgeladen werden. | ||
- | |||
- | Die Konfiguration erfordert zwingend die Mithilfe Ihrer AAI-Administration, | ||
- | |||
- | Die folgenden Voraussetzungen müssen erfüllt sein: | ||
- | * Grundkonfiguration siehe [[de: | ||
- | * Ihr Identity-Provider muss alle Attribute wie in folgender Beschreibung von GÉANT freigeben: [[https:// | ||
- | * Ein Konfigurationsbeispiel für Ihren Identity-Provider finden Sie unter: [[de: | ||
- | * Insbesondere muss ein eduPersonEntitlement '' | ||
- | * Alternativer '' | ||
- | - In '' | ||
- | - Attribut '' | ||
- | - In ''/ | ||
- | |||
- | **Achtung: | ||
- | |||
- | Achtung: Für Zertifikate, | ||
- | |||
- | ===REST-API für Nutzerzertifikate=== | ||
- | |||
- | Über das REST API können mit selbst erstellter Software oder Skripten Nutzerzertifikate erstellt werden. Hinweise hierzu unter [[de: | ||
- | |||
- | Die Schlüsselerzeugung findet stets auf Seiten des Clients und nicht bei Sectigo statt. | ||
- | |||
- | |||
- | ===Client Certificate Web Form=== | ||
- | |||
- | **Bitte richten Sie keine Accounts zur Nutzung von Web-Formularen für Nutzerzertifikate unter ☰-> | ||
- | |||
- | |||
- | |||
- | =====Zertifikattypen===== | ||
- | |||
- | ====ECC oder RSA?==== | ||
- | |||
- | Bei Serverzertifikaten ist der Algorithmus entsprechend den Fähigkeiten der Server-Software zu wählen. In den meisten Fällen wird heutzutage ECC genutzt werden können. | ||
- | |||
- | Bei Nutzerzertifikaten ist zu beachten, dass Zertifikate mit den ECC-Schlüsseltypen P-384 und P-256 nur für Signatur und Authentisierung, | ||
- | |||
- | ====Profile für Serverzertifikate==== | ||
- | Die Serverzertifikate aus TCS enthalten sowohl den Zertifikatzweck '' | ||
- | |||
- | Dies gilt für alle Profile | ||
- | |||
- | Wählen Sie auf keinen Fall das Profil EV Anchor, es sei denn, Sie wollen den speziellen EV-Prozess starten. | ||
- | |||
- | IP-Adressen können nicht in Serverzertifikate aus TCS aufgenommen werden. Die Antragswege über Webformulare ergeben Fehlermeldungen. Beim Einreichen eines Requests mit einer IP-Adresse im SubjectAlternativeName wird diese stillschweigend herausgefiltert. | ||
- | |||
- | |||
- | ====OV SSL oder OV Multi Domain?==== | ||
- | |||
- | Wir empfehlen in jedem Fall OV Multi Domain zu verwenden. Im Zertifikatprofil OV Multi Domain sind mehrere Servernamen im Alternative Name möglich, z.B. '' | ||
- | |||
- | Im Zertifikatprofil OV SSL wird automatisch jedem Zertifikat ein zweiter, in den meisten Fällen sicherlich unerwünschter Alternativer Name '' | ||
- | |||
- | Beispiel: Antrag enthält '' | ||
- | |||
- | |||
- | Es gibt eine Größenbeschränkung des CSR auf 32k. Es gibt Dokumentationsfundstücke bei Sectigo, die ein Limit der Anzahl der alternativen Namen auf 250 beschreiben. Diese Dokumentation ist nicht korrekt, in der Praxis konnten wir auch schon 400 alternative Namen aufnehmen. Die Größe für akzeptierte CSR liegt irgendwo zwischen 15000 und 19000 Byte. | ||
- | |||
- | ====Wildcard-Zertifikate==== | ||
- | |||
- | Voraussetzung für ein Wildcard-Zertifikat ist eine im cert-manager eingetragene Domain, die mit den Methoden EMAIL oder CNAME validiert wurde. Für Domains, die per HTTP/HTTPS validiert wurden, können keine Wildcard-Zertifikate ausgestellt werden. | ||
- | |||
- | Für Wildcard-Zertifikate wählen Sie günstigerweise immer das Profil "OV Multi Domain" | ||
- | |||
- | Im Profil " | ||
- | |||
- | ====VoIP-Zertifikate für DFNFernsprechen==== | ||
- | |||
- | GÉANT TCS funktioniert zur Zeit noch nicht für die Verschlüsselung von VoIP-Anschlüssen im Rahmen von DFNFernsprechen, | ||
- | https:// | ||
- | |||
- | |||
- | ====Extended Validation Zertifikate (EV)==== | ||
- | |||
- | EV-Zertifikate können nur erstellt werden, nachdem in cert-manager ein sog. EV Anchor angelegt wurde. Dies ist ein spezielles administratives Zertifikat, dessen Ausstellung von allen Prozeduren zur besonderen Prüfung nach EV-Standard begleitet wurde. | ||
- | |||
- | * Bitte versuchen Sie auf keinen Fall, ein normales EV-Zertifikat vor der Erstellung eines EV Anchors zu beantragen. | ||
- | |||
- | * Vor der Erstellung eines EV-Anchors müssen die EV-Informationen unter ☰-> | ||
- | |||
- | Die Anleitung im GÉANT FAQ ist zu finden unter: [[https:// | ||
- | Versuchen Sie auf keinen Fall mehrere EV Anchor zu erstellen. | ||
- | |||
- | ====Automatische Sperrung von Nutzerzertifikaten==== | ||
- | ===Sperrung bei Datenänderung=== | ||
- | Sectigo führt eine Liste aller Personen, die ein Zertifikat erhalten haben. Personen werden anhand ihrer primären E-Mail-Adresse identifiziert. Dieselbe natürliche Person kann also verschiedene primäre E-Mail-Adressen verwenden und gilt dann für Sectigo als verschiedene Personen. | ||
- | |||
- | Wenn für eine primäre E-Mail-Adresse erstmals ein Zertifikat beantragt wird, wird die Person mit den Angaben aus dem Antrag in die Liste eingetragen. | ||
- | |||
- | Wenn für eine primäre E-Mail-Adresse weitere Zertifikate beantragt werden, werden die vorhandenen Personendaten in der Liste mit den Angaben aus den neuen Anträgen aktualisiert. | ||
- | |||
- | Dabei gilt: | ||
- | |||
- | * Sekundäre E-Mail-Adressen und der " | ||
- | |||
- | * Ä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==== | ||
- | ===Rechtliche Grundlagen=== | ||
- | Erläuterungen zu dem rechtlichen Aspekt finden Sie unter: [[de: | ||
- | ===Tauglichkeit normaler Nutzerzertifikate=== | ||
- | Document Signing, z.B. in Adobe, ist mit den normalen Nutzerzertifikaten zwar technisch möglich, es müssen aber recht hohe Hürden überwunden werden. Insbesondere sind bei den Prüfern der Signaturen spezielle Einstellungen zu treffen, um die Vertrauenswürdigkeit der Signaturen darzustellen. | ||
- | |||
- | Eine sehr detaillierte Anleitung wird von der Universität Münster zur Verfügung gestellt: https:// | ||
- | |||
- | Diese Einstellungen müssen von jeder Person vorgenommen werden, die die Signaturen prüfen soll. | ||
- | |||
- | Zur rechtlichen Bewertung der auf diese Art erzeugten Signaturen (" | ||
- | |||
- | ===Document Signing Zertifikate=== | ||
- | Im Rahmen von TCS können von Sectigo kostenpflichtige, | ||
- | |||
- | Den Ansprüchen von qualifizierten Signaturen genügen die mit diesen Zertifikaten erzeugten Signaturen aus formalen Gründen nicht. Zur weiteren rechtlichen Bewertung (" | ||
- | |||
- | Für den Bezug dieser Zertifikate gibt es einen separaten Antragsweg außerhalb von cert-manager. | ||
- | |||
- | Die Zertifikate kosten ca. 130,- Euro für 3 Jahre. Der Betrag ist während des Antragsprozesses direkt per Kreditkarte oder PayPal zu begleichen. Neben diesem Betrag entstehen zusätzliche, | ||
- | |||
- | 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=< | ||
- | |||
- | Die Beantragung führen Sie bitte wie in der Dokumentation von GÉANT dargestellt durch: [[https:// | ||
- | |||
- | ===Qualifizierte Zertifikate=== | ||
- | |||
- | Sectigo hat auch ein Angebot für qualifizierte Zertifikate, | ||
- | |||
- | Auch die qualifizierten Zertifikate müssen über einen separaten Antragsweg außerhalb von cert-manager bezogen werden. | ||
- | |||
- | ====Grid-Zertifikate (IGTF)==== | ||
- | |||
- | * Für Nutzerzertifikate, | ||
- | * **Wichtig: | ||
- | |||
- | * Für Serverzertifikate (Hostzertifikate), | ||
- | |||
- | ====Gruppenzertifikate==== | ||
- | Die aus der DFN-PKI bekannten Gruppen- und Pseudonymzertifikate können | ||
- | in TCS abgebildet werden, indem im SCM wie folgt vorgegangen wird: | ||
- | |||
- | Zunächst die [[de: | ||
- | |||
- | * ☰-> | ||
- | * Daten im ersten Dialog ausfüllen und mit OK bestätigen: | ||
- | - '' | ||
- | - E-Mail-Adresse auf die Gruppen-Mail-Adresse | ||
- | * Im nächsten großen Dialog Feld '' | ||
- | * Den Button " | ||
- | * Den neuen Eintrag auswählen, Button " | ||
- | * Im neuen Dialog Reiter " | ||
- | * Dort hinter " | ||
- | * Als Enrollment Form auswählen: '' | ||
- | * Dann den im Schritt [[de: | ||
- | * An die eingetragene E-Mail-Adresse wird nun eine Einladungs-Mail geschickt, und das Zertifikat kann von der für die Gruppe verantwortlichen Person erstellt werden. | ||
====CA- und Root-Zertifikate in TCS==== | ====CA- und Root-Zertifikate in TCS==== | ||
Zeile 563: | Zeile 89: | ||
Die uns bekannten Root- und CA-Zertifikate in TCS sind dokumentiert unter: [[de: | Die uns bekannten Root- und CA-Zertifikate in TCS sind dokumentiert unter: [[de: | ||
- | =====Identifizierung und Dokumentation===== | ||
- | Die Anforderungen an die Identifizierung und die Dokumentation für persönliche Zertifikate (client certificates, | ||
- | Die dort für "TCS eScience Personal" | + | =====CAA-Records===== |
- | Die wichtigsten Punkte: | + | Wenn Sie CAA-Records im DNS setzen möchten, um die Ausstellung von Zertifikaten auf bestimmte CAs einzuschränken: |
- | * Vor der Ausstellung eines Zertifikats soll eine persönliche | + | [[de: |
- | * 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 " | + | =====Zertifikate sperren (Revoke, Revocation)===== |
- | Die Dokumentation der Identifizierung muss nicht über die Verfahren hinausgehen, | + | Zertifikate sollen üblicherweise von einem RAO oder DRAO in https:// |
- | sind. Die Einrichtung muss mit ihrer Dokumentation | + | |
- | ====Unterschiede GÉANT Personal und GÉANT IGTF==== | + | Die [[de: |
- | Formal unterscheiden sich die Anforderungen an die Ausstellung von Nutzerzertifikaten für die Zertifikatprofile " | + | Unter der folgenden URL steht ein Sperrinterface bereit, in dem Sperranträge gestellt werden können: |
+ | https:// | ||
- | 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. | + | 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. |
- | ==== Vergleich mit DFN-AAI Advanced ==== | ||
- | Die Regeln der DFN-AAI Advanced (https:// | ||
- | Insbesondere lässt die DFN-AAI Advanced " | + | ======Audits====== |
- | Vor einer gründlichen Prüfung der internen Prozesse sollten darum auf keinen Fall pauschal alle Personen | + | Im Gegensatz zur DFN-PKI sind in GÉANT TCS keine regelmäßigen Audits der RA-Tätigkeit von Teilnehmern vorgesehen. |
- | Wert '' | + | |
- | =====Was ist ein " | + | Im [[https:// |
- | Ein External Requester wird optional bei den Antragsformularen für Serverzertifikate abgefragt. Hier kann schlicht eine zusätzliche Mailadresse angegeben werden, die Benachrichtigungen zum Zertifikat erhält. | + | < |
- | + | ||
- | =====ACME===== | + | |
- | ====ACME Clients==== | + | |
- | Da das ACME-Protokoll sehr gut standardisiert ist, können neben den in den Beispielen gezeigten '' | + | |
- | + | ||
- | Einzige Voraussetzung: | + | |
- | ====ACME-Accounts==== | + | |
- | + | ||
- | Zur Nutzung von ACME müssen im cert-manager.com spezielle ACME-Accounts angelegt werden. Hierzu muss unter ☰-> | + | |
- | + | ||
- | **Wichtig: | + | |
- | + | ||
- | Nach dem Anlegen hat ein Account zunächst den Zustand '' | + | |
- | + | ||
- | Zustände von ACME-Accounts sind anscheinend nicht notwendigerweise komplett synchron zu Hintergrundsystemen bei Sectigo. Im Test konnte bspw. ein ACME-Account nicht direkt, sondern erst nach einer Wartezeit über Nacht gelöscht werden. | + | |
- | + | ||
- | ====Domains in ACME-Accounts==== | + | |
- | + | ||
- | Einem ACME-Account müssen vor dessen Nutzung bereits delegierte Domains zugeordnet werden. Die Domains müssen nicht notwendigerweise bereits validiert sein. | + | |
- | + | ||
- | * Für nicht validierte Domains muss im Laufe der Zertifikatausstellung eine ACME-Challenge beantwortet werden (automatisch durch den ACME-Client). Im Standard-Fall ist dafür eine Inbound-Verbindung von Sectigo zu einem Webserver auf dem zu zertifizierenden Domainnnamen erforderlich. | + | |
- | + | ||
- | * Für bereits validierte Domains ist keine ACME-Challenge und damit keine Inbound-Verbindung erforderlich. | + | |
- | + | ||
- | Es ist zu beachten, dass einem ACME-Account **keine** Stern-Domains (z.B. '' | + | |
- | + | ||
- | Die Zuordnung von Nicht-Stern-Domains (z.B. '' | + | |
- | + | ||
- | Eine häufige Fehlermeldung durch einen ACME-Client im Zusammenhang mit fälschlich zugewiesenen Stern-Domains im ACME-Kontext ist '' | + | |
- | + | ||
- | ====Schutz von ACME-Accounts==== | + | |
- | + | ||
- | Die Daten eines ACME-Accounts (konkret die Werte '' | + | |
- | + | ||
- | Je nach Domains, die dem ACME-Account zugewiesen wurden, hat eine Komprimittierung des Accounts oder der Installationsdaten sogar deutlich größere Auswirkungen. Denn: In ACME-Accounts können für alle zugewiesenen einfachen Domainnamen beliebige Zertifikate unter weiteren Sub-Domains ausgestellt werden. | + | |
- | + | ||
- | Beispiel: Wenn Sie für Ihren Haupt-Webserver Zertifikate für '' | + | |
- | + | ||
- | Dieser ACME-Account ist dann je nach Risikoanalyse nicht unbedingt dafür geeignet, in einer ausgelagerten Hosting-Umgebung betrieben zu werden, und sollte eher auf einer spezialisierten, | + | |
- | + | ||
- | ====Ausstellen==== | + | |
- | + | ||
- | Vorausgesetzt, | + | |
- | + | ||
- | < | + | |
- | + | ||
- | Es können für beliebig viele FQDNs, die innerhalb der dem Account zugewiesenen Domains liegen, Zertifikate erstellt werden. | + | |
- | + | ||
- | Da die ACME-Accounts | + | |
- | + | ||
- | 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 per ACME-Client (z.B. certbot) gesperrt werden. certbot benötigt Zugriff auf die Account-Informationen von der initialen Ausstellung des Zertifikats. Wenn diese Voraussetzung gegeben ist, kann folgendermaßen gesperrt werden: | + | |
- | + | ||
- | < | + | |
- | + | ||
- | Eine Sperrung per Cert-Manager ist auch möglich. Der unverständliche Informationsdialog kann ignoriert werden. | + | |
- | =====REST-API===== | + | |
- | + | ||
- | Die Systeme von Sectigo können per REST-API angesprochen werden. Eine Dokumentation hierzu finden Sie unter: https:// | + | |
- | + | ||
- | Das REST-API kann nur dann zum Enrollment verwendet werden, wenn unter ☰-> | + | |
- | + | ||
- | Es ist ein Login/ | + | |
- | Anfangspasswort bereits geändert wurde. Die in der Dokumentation angegebene Client-Authentifizierung per Zertifikat für das REST-API ist noch nicht getestet. | + | |
- | + | ||
- | Tipp: Man kann einen Account in seiner Rolle so einschränken, | + | |
- | + | ||
- | 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:// | + | |
- | =====CAA-Records===== | + | |
- | + | ||
- | Wenn Sie CAA-Records im DNS setzen möchten, um die Ausstellung von Zertifikaten auf bestimmte CAs einzuschränken, | + | |
- | + | ||
- | < | + | |
- | muster-uni.de. | + | |
- | muster-uni.de. | + | |
</ | </ | ||
- | Der CAA-Record muss bereits zum Zeitpunkt der Domain-Freischaltung passen, nicht erst zum Zeitpunkt der konkreten Zertifikatausstellung. | + | =====Statusmeldungen und Wartungsankündigungen===== |
- | Ist für eine betrachtete Domain (Alias-Domain) ein CNAME im DNS definiert, so müssen die CAA-Records für den CNAME die Ausstellung von Zertifikaten durch TCS erlauben: | + | Statusmeldungen und Wartungsankündigungen der Sectigo-Services sind sichtbar über: https:// |
- | < | + | Die Meldungen können dort auch als E-Mail und RSS-Feed (https:// |
- | muster-uni.edu. | + | |
- | muster-uni.de. | + | =====Support===== |
- | muster-uni.de. | + | |
- | </ | + | |
+ | Wir helfen auch bei technischen Schwierigkeiten mit den TCS-Systemen gerne weiter: [[mailto: | ||
- | =====Zertifikate sperren (Revoke, Revocation)===== | + | Ein direkter Kontakt mit dem englischsprachigen Sectigo Support ist auch möglich. Das Support-Portal von Sectigo ist erreichbar unter: https:// |
- | Zertifikate sollen hauptsächlich von einem RAO oder DRAO in https:// | + | Bitte unbedingt den folgenden Hinweis einfügen: "We are a DFN member of the GEANT TCS service, using the SCM instance |
- | Die [[de: | + | Es ist zu empfehlen, vor einer direkten Kontaktaufnahme zum Sectigo Support |
- | Unter der folgenden URL steht ein Sperrinterface bereit, in dem Sperranträge gestellt werden können: | + | ===Support-Tickets für die Validierung (DCV) von IP-Adressen=== |
- | https://secure.sectigo.com/products/RevocationPortal | + | Sofern Sie ein Ticket für den speziellen [[de:dfnpki:tcs: |
- | Hier sind allerdings weitere Authentifizierungsschritte erforderlich, | + | ===Support-Tickets für Anträge von Code-Signing-Zertifikate=== |
+ | Sofern Sie ein Ticket für die Bearbeitung von [[de: | ||
- | =====Sectigo Certificate Manager (SCM)===== | + | Die Order Number ist zwingend anzugeben. Sie ist im SCM unter ☰→Certificates→Code Signing einsehbar. |
- | ====Tipps & Tricks==== | + | =====E-Mail-Verteilerliste dfnpki-d===== |
- | ===Fehlende Icons/Symbole=== | + | Auf [[https:// |
- | Werden im SCM an einigen Stellen Alternativtexte oder Platzhalter anstatt Icons oder Symbole angezeigt, so kann das daran liegen, dass der verwendete Browser (z.B. Firefox) so konfiguriert | + | Eine Anmeldung |
- | ===Filtereinstellungen zurücksetzen === | ||
- | |||
- | In den unterschiedlichen Übersichtslisten des SCMs können verschiedene Ansichtsfilter gesetzt werden, die auch über Login-Sessions hinweg persistent bleiben. Hat man aus Versehen einen Filter gesetzt, der zu Zeitüberschreitungsfehlern oder gar internen Server-Fehlern führt und daher nicht mehr über die normale Filterkonfiguration zurücksetzbar ist, so können über die Profil-Verwaltung des eigenen Accounts unter "My Profile" | ||
- | |||
- | ======Audits====== | ||
- | |||
- | Im Gegensatz zur DFN-PKI sind in GÉANT TCS keine regelmäßigen Audits der RA-Tätigkeit von Teilnehmern vorgesehen. | ||
- | |||
- | =====Status von TCS===== | ||
- | |||
- | Statusmeldungen und Wartungsankündigungen der Sectigo-Services sind sichtbar über: https:// | ||
- | |||
- | Die Meldungen können dort auch als E-Mail und RSS-Feed (https:// | ||
- | |||
- | =====Support===== | ||
- | |||
- | Wir helfen auch bei technischen Schwierigkeiten mit den TCS-Systemen gerne weiter, z.B. per Mail: '' | ||
- | |||
- | Ein direkter Kontakt mit dem 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:// | ||
- | Es ist zu empfehlen, vor einer Kontaktaufnahme zum Sectigo Support mit uns zu sprechen. |