Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:dfnpki:tcs:2020:servercert_acme [2025/06/05 13:31] – gelöscht - Externe Bearbeitung (Unbekanntes Datum) 127.0.0.1
+++ de:dfnpki:tcs:2020:servercert_acme [2025/06/05 13:31] (aktuell) – ↷ Links angepasst, weil Seiten im Wiki verschoben wurden Antonio Liu
@@ Zeile 1: / Zeile 1: @@
+=====ACME=====
+====ACME Clients====
+Zum Bezug von Zertifikaten per ACME stehen eine Fülle von clients zur Verfügung. Neben dem bekannten  ''certbot'' können auch andere Clients wie ''acme.sh'' oder ''win-acme'' verwendet werden.
+Einzige Voraussetzung: Es muss ein Mechanismus namens "External Account Binding" unterstützt werden (bei ''GetSSL'' beispielsweise mit Stand 09/2021 nur mit einem Patch).
+====ACME-Accounts====
+Zur Nutzung von ACME müssen im cert-manager.com spezielle ACME-Accounts angelegt werden. Hierzu muss unter ☰->Enrollment->ACME zu einem der ACME-Endpoints der Button Accounts betätigt werden. Dann per Button Add einen neuen Account anlegen.
+Nach dem Anlegen hat ein Account zunächst den Zustand ''pending''. Sobald der Account mit einem ACME-Client verwendet wurde, wechselt er in den Zustand ''valid''.
+====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. ''*.example.org'') zugeordnet werden dürfen. Die Zuordnung von solchen Stern-Domains hat im Kontext von ACME-Accounts keinen weiteren "Wildcard-Effekt".
+Die Zuordnung von Nicht-Stern-Domains (z.B. ''example.org'') genügt im Kontext von ACME-Accounts bereits vollständig aus, um sowohl Zertifikate für die eingetragene Domain selbst (in diesem Beispiel also ''example.org'') **als auch** für **alle** unterhalb von der explizit eingetragenen Domain möglichen FQDNs (auch unter Sub-Domains) (z.B. ''www.example.org'' und ''blog.it.example.org'') per ACME auszustellen. Siehe auch [[de:dfnpki:tcs:2020:servercert_acme#schutz_von_acme-accounts|Schutz von ACME-Accounts]].
+Eine häufige Fehlermeldung durch einen ACME-Client im Zusammenhang mit fälschlich zugewiesenen Stern-Domains im ACME-Kontext ist ''The client lacks sufficient authorization...''. Weitere Details dazu finden sich auch in der SCM-Knowledgebase unter https://sectigo.com/knowledge-base/detail/Sectigo-Certificate-Manager-SCM-ACME-error-The-client-lacks-sufficient-authorization/kA03l00000117Sy.
+====Schutz von ACME-Accounts====
+Die Daten eines ACME-Accounts (konkret die Werte ''eab-kid'' und ''eab-hmac-key'') sollten mindestens wie private Schlüssel für Serverzertifikate behandelt und geschützt werden. Dies gilt auch für die Daten in der Installation des ACME-Clients, z.B. das Verzeichnis ''/etc/letsencrypt''.
+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 ''example.org'' und ''www.example.org'' benötigen und einen entsprechenden ACME-Account mit diesen zugewiesenen Domainnamen  erstellen, erlauben Sie automatisch die Ausstellung von Zertifikaten auf weiteren beliebigen Sub-Domains wie ''internal.it.example.org''.
+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, geschützten "cerbot-Maschine" verwendet werden.
+====Ausstellen====
+Vorausgesetzt, dass die dem Account zugewiesene Domain validiert und delegiert ist, können direkt im Anschluss Zertifikate erzeugt werden:
+<code>certbot certonly --standalone --non-interactive --agree-tos --email <Email-Adresse> --server <Sectigo-Server> --eab-kid <Wert von eab-kid> --eab-hmac-key <Wert von eab-hmac-key> --domain <FQDN> </code>
+Es können für beliebig viele FQDNs, die innerhalb der dem Account zugewiesenen Domains liegen, Zertifikate erstellt werden.
+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://github.com/francescm/acme-ansible-debian-sectigo
+====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:
+<code>certbot revoke --cert-path <Pfad zum zu sperrenden Zertifikat> --server <Sectigo-Server></code>
+Eine Sperrung per Cert-Manager ist auch möglich. Der unverständliche Informationsdialog kann ignoriert werden.
+====ACME-Fehlermeldungen====
+===The identifiers are not all linked to the same preauthorized Subject organization name/address===
+Certbot meldet ''The identifiers are not all linked to the same preauthorized Subject organization name/address''. Geben Sie certbot explizit die Account-ID mit der Option ''--account ACCOUNT_ID'' mit oder räumen Sie im certbot-Verzeichnis ''/etc/letsencrypt/accounts/acme.sectigo.com'' auf und löschen Sie dort überflüssiges.