diff --git a/content/de/about.md b/content/de/about.md index 75e25fc67b..f8f6c074af 100644 --- a/content/de/about.md +++ b/content/de/about.md @@ -14,15 +14,15 @@ Let's Encrypt ist eine freie, automatisierte und offene Zertifizierungsstelle (C Wir geben Menschen die digitalen Zertifikate, die sie zur Aktivierung von HTTPS (SSL/TLS) auf ihrer Webseite benötigen, kostenlos und in der benutzerfreundlichsten Variante, die uns möglich ist. Wir machen das, um ein noch sicheres Web zu erstellen, das die Privatsphäre akzeptiert. -Lesen Sie über die Ereignisse des vergangenen Jahres durch Herunterladen des [Jahresberichts](https://abetterinternet.org/documents/2020-ISRG-Annual-Report.pdf). +Lesen Sie über die Ereignisse des vergangenen Jahres durch Herunterladen des [Jahresberichts](https://www.abetterinternet.org/annual-reports/). Die Schlüsselprinzipien hinter Let's Encrypt sind: -* Frei: Jeder, der einen Domainnamen besitzt, kann Let's Encrypt benutzen, um sichere Zertifikate kostenfrei zu erhalten. -* Automatisch: Die Software die auf dem Webserver läuft, kann auf einfache Website mit Let's Encrypt Zertifikate beziehen, zur Benutzung abgesichert werden und automatisch Zertifikate erneuern. -* Sicher: Let's Encrypt stellt eine Plattform für erweiterte TLS-Sicherheit zur Verfügung, sowohl auf der CA-Seite als auch beim Betreiber, um ihn bei der Absicherung seines Servers zu unterstützen. -* Transparent: Alle ausgestellten und widerrufenen Zertifikate werden öffentlich für jedermann zur Inspektion zur Verfügung gestellt. -* Offen: Das automatische Ausstellungs- und Erneuerungsprotokoll wird als offener Standard veröffentlicht, damit es andere adaptieren können. -* Kooperativ: Ähnlich wie die zugrundeliegenden Internetprotokolle selbst ist Let's Encrypt eine gemeinsame Anstrengung, die der Community zugute kommt und außerhalb der Kontrolle einer einzelnen Organisation liegt. +* **Frei:** Jeder, der einen Domainnamen besitzt, kann Let's Encrypt benutzen, um sichere Zertifikate kostenfrei zu erhalten. +* **Automatisch:** Die Software die auf dem Webserver läuft, kann auf einfache Website mit Let's Encrypt Zertifikate beziehen, zur Benutzung abgesichert werden und automatisch Zertifikate erneuern. +* **Sicher:** Let's Encrypt stellt eine Plattform für erweiterte TLS-Sicherheit zur Verfügung, sowohl auf der CA-Seite als auch beim Betreiber, um ihn bei der Absicherung seines Servers zu unterstützen. +* **Transparent:** Alle ausgestellten und widerrufenen Zertifikate werden öffentlich für jedermann zur Inspektion zur Verfügung gestellt. +* **Offen:** Das automatische Ausstellungs- und Erneuerungsprotokoll wird als offener Standard veröffentlicht, damit es andere adaptieren können. +* **Kooperativ:** Ähnlich wie die zugrundeliegenden Internetprotokolle selbst ist Let's Encrypt eine gemeinsame Anstrengung, die der Community zugute kommt und außerhalb der Kontrolle einer einzelnen Organisation liegt. Wir haben eine Seite mit detaillierteren Informationen, [wie Let's Encrypt-CA funktioniert](/how-it-works). diff --git a/content/de/contact.md b/content/de/contact.md index b9fa580917..eee6d9b168 100644 --- a/content/de/contact.md +++ b/content/de/contact.md @@ -3,7 +3,7 @@ title: Kontakt slug: contact description: Wie Sie uns erreichen top_graphic: 1 -lastmod: 2021-08-31 +lastmod: 2023-09-26 menu: main: weight: 90 @@ -20,15 +20,19 @@ Email: [press@letsencrypt.org](mailto:press@letsencrypt.org) Email: [sponsor@letsencrypt.org](mailto:sponsor@letsencrypt.org) -## Mailinglisten +## Abonnieren Sie unseren Newsletter -Um sich zu unserem Newsletter anzumelden, [klicken Sie hier.](https://mailchi.mp/letsencrypt.org/fjp6ha1gad) + + +## Privatsphäre + +E-Mail: [privacy@abetterinternet.org](mailto:privacy@abetterinternet.org) ## Sicherheit **Bitte schreiben Sie nicht an diese Adresse, es sei denn, Ihre Nachricht betrifft ein Sicherheitsproblem mit Let's Encrypt.** -Email: +E-Mail: - diff --git a/content/de/docs/godaddy.md b/content/de/docs/godaddy.md index bb3c4a4dc8..bdea60308e 100644 --- a/content/de/docs/godaddy.md +++ b/content/de/docs/godaddy.md @@ -8,10 +8,14 @@ show_lastmod: 1 --- -Wir haben eine Menge Anfragen bekommen, wie Let's Encrypt auf GoDaddy zu verwenden ist. Wenn Sie GoDaddy Shared Web Hosting verwenden, ist es momentan sehr schwierig, Let's Encrypt Zertifikate zu installieren, weswegen wir das momentan nicht empfehlen können. Begründet wird das damit, weil GoDaddy das [ACME Protocol](https://tools.ietf.org/html/rfc8555) zum automatischen Ausstellen und Erneuern von Zertifikaten nicht unterstützt. Stattdessen bietet GoDaddy ein automatisches Ausstellen und Erneuern für seine eigenen Zertifikate an, was eine [kostenpflichtiges Zusatzfunktion](https://www.godaddy.com/web-security/ssl-certificate) ist. +Wir haben eine Menge Anfragen bekommen, wie Let's Encrypt auf GoDaddy zu verwenden ist. Wenn Sie GoDaddy Shared Web Hosting verwenden, ist es momentan sehr schwierig, Let's Encrypt Zertifikate zu installieren, weswegen wir das momentan nicht empfehlen können. Begründet wird das damit, weil GoDaddy das [ACME Protocol][1] zum automatischen Ausstellen und Erneuern von Zertifikaten nicht unterstützt. Stattdessen bietet GoDaddy ein automatisches Ausstellen und Erneuern für seine eigenen Zertifikate an, was eine [kostenpflichtiges Zusatzfunktion][2] ist. Wir empfehlen, bei Hosting-Anbietern, die das ACME-Protokoll nicht direkt implementieren, die Option "Let's Encrypt" nicht zu verwenden, da Sie dadurch die Erneuerungen nicht vollständig automatisieren können. Wir sind der Meinung, dass automatische Verlängerungen ein sehr wichtiger Bestandteil bei der Verwendung von Zertifikaten sind. Durch die Verwendung von Software zur Automatisierung der Erneuerung ist es weniger wahrscheinlich, dass Ihr Zertifikat abläuft, ohne ersetzt zu werden. Wenn Ihr Zertifikat abläuft, ist dies für Ihre Benutzer sehr frustrierend, da sie nicht auf Ihre Website zugreifen können. Weil wir so stark an die automatisierte Erneuerung glauben, entwerfen wir unsere Zertifikate für die Verwendung mit ACME-Automatisierung. Ein Let's Encrypt-Zertifikat wird nach 60 Tagen automatisch erneuert und funktioniert nach 90 Tagen nicht mehr, wenn es nicht erneuert wird. -Wenn Sie immer ein Let’s Encrypt Zertifikat auf GoDaddy Shared Hosting verwenden möchten, lesen Sie die von GoDaddy [bereitgestellten Anweisungen](https://www.godaddy.com/help/install-a-lets-encrypt-certificate-on-your-cpanel-hosting-account-28023). Beachten Sie, dass diese Anweisungen zeitintensiv sind und Sie dies alle 60 Tage tun müssen (und nicht alle 90 Tage wie im Link beschrieben). +Wenn Sie immer ein Let’s Encrypt Zertifikat auf GoDaddy Shared Hosting verwenden möchten, lesen Sie die von GoDaddy [bereitgestellten Anweisungen][3]. Beachten Sie, dass diese Anweisungen zeitintensiv sind und Sie dies alle 60 Tage tun müssen (und nicht alle 90 Tage wie im Link beschrieben). + +[1]: https://tools.ietf.org/html/rfc8555 +[2]: https://www.godaddy.com/web-security/ssl-certificate +[3]: https://www.godaddy.com/help/install-a-lets-encrypt-certificate-on-your-cpanel-hosting-account-28023 diff --git a/content/de/docs/ipv6.md b/content/de/docs/ipv6.md index 78c339c931..e07223639a 100644 --- a/content/de/docs/ipv6.md +++ b/content/de/docs/ipv6.md @@ -1,4 +1,37 @@ --- +title: IPv6-Unterstützung slug: ipv6-support -untranslated: 1 +top_graphic: 1 +date: 2020-02-07 +lastmod: 2020-02-07 +show_lastmod: 1 --- + + +Let's Encrypt unterstützt IPv6 sowohl für den Zugriff auf die ACME-API mit einem ACME-Client als auch für die DNS-Lookups und HTTP-Requests, die wir beim Validieren der Domains durchführen. + +## Domain-Validierung + +Wenn Sie ausgehende Domain-Validierungsanfragen für eine Domain stellen, die sowohl IPv4 als auch IPv6 Adressen hat (z.B. sowohl `A` als auch `AAA` Einträge) wird Let's Encrypt immer die IPv6 Adressen für die erste Verbindung bevorzugen. Wenn die IPv6-Verbindung auf Netzwerkebene fehlschlägt (z.B wenn es eine Zeitüberschreitung gibt) und IPv4 Adressen verfügbar sind, dann versuchen wir die Anfrage mit einer der IPv4 Adressen erneut. + +## Ungültige IPv6-Adressen + +Oft ist Domain Inhabern nicht bewusst, dass ein `AAAA` Eintrag für ihre Domain existiert. Wenn die IPv6-Adresse im `AAAA` Eintrag falsch ist, wirkt sich dies auf den Domain-Validierungsprozess aus. + +Normalerweise wird die IPv6-Adresse ein anderer Server sein als die IPv4-Adresse, auf der der ACME-Client ausgeführt wird. Da der ACME-Client nur den IPv4 Server konfiguriert, um auf die Challenge zu reagieren, wird die Domain-Validierung fehlschlagen, wenn der IPv6 Server benutzt wird. + +In den meisten Fällen ist die richtige Fehlerbehebung die IPv6-Adresse zu aktualisieren, sodass sie auf den Server verweist, auf dem ACME-Client läuft, oder den `AAAA` Eintrag zu entfernen, wenn die Domain nicht für IPv6 gedacht ist. Es gibt keine Möglichkeit Let's Encrypt die IPv4 Adresse als Präferenz nutzen zu lassen, Sie müssen die Fehlkonfiguration beheben. + +## IPv6-zu-IPv4-Wiederholungsversuch Details + +Der IPv6 zu IPv4 Widerholungsversuch wird nur bei Verbindungs-Zeitüberschreitungen getätigt, nicht bei anderen Typen von Fehlern. + +Im obigen "Common Pitfalls"-Szenario wird beispielsweise ein erneuter Versuch nicht stattfinden, wenn ein Webserver auf die IPv6-Adresse hört, aber nicht bereit ist, auf die ACME-Aufforderung zu antworten. In diesem Fall gäbe es keine Zeitüberschreitung für den Zugriff auf die IPv6-Adresse, und die Abfrage schlägt ohne erneuten Versuch fehl, da eine falsche Antwort zurückgegeben wurde. + +Um unsere CA-Software einfach zu halten, führen wir bei der Validierung von "http-01" Challenges nur bei der ersten Anfrage einen IPv6 zu IPv4 Widerholungsversuch durch. Wenn Sie Umleitungen nutzen, werden diese keine Widerholungsversuche bekommen. + +Wenn zum Beispiel ein Domänenname einen `AAAA-Eintrag` hat, der immer ausläuft, und einen `A`-Eintrag mit einem Webserver, der von HTTP auf HTTPS umleitet, dann funktioniert der Fallback von IPv6 auf IPv4 nicht korrekt. Die erste Anfrage an die Domain wird ordnungsgemäß auf IPv4 zurückgreifen und eine Umleitung von HTTP zu HTTPS erhalten. Die nachfolgende Anfrage bevorzugt wieder die IPv6-Adresse, wird aber nach einer Zeitüberschreitung nicht auf IPv4 zurückgreifen. Sie können dieses Problem beheben, indem Sie entweder die IPv6-Fehlkonfiguration beheben oder die HTTP-zu-HTTPS-Umleitung für Anfragen an den ACME-HTTP-01-Challenge-Pfad entfernen. + +## Hilfe bekommen + +Wenn du Hilfe dabei benötigst, ein IPv6-bezogenes Problem zu lösen, besuche doch unser [Community-Forum](https://community.letsencrypt.org). diff --git a/content/de/docs/lencr-org.md b/content/de/docs/lencr-org.md index 2c015219e4..408272e304 100644 --- a/content/de/docs/lencr-org.md +++ b/content/de/docs/lencr-org.md @@ -2,17 +2,43 @@ title: lencr.org slug: lencr.org top_graphic: 1 -date: 2020-12-04 -lastmod: 2020-12-04 +date: 2021-11-30 +lastmod: 2022-09-30 show_lastmod: 1 --- -# Was ist lencr.org? +# Was ist `lencr.org`? -`lencr.org` ist eine Domain, die Let's Encrypt gehört. Wir verwenden sie zum Hosten von OCSP, CRLs und Aussteller-Zertifikaten: alle URLs, die in Zertifikaten angezeigt werden. +`lencr.org` ist ein Domänenname im Besitz von Let's Encrypt. Wir verwenden es, um Daten zu hosten, die in den von uns ausgestellten Zertifikaten referenziert werden. + +# Warum ruft mein Computer diese Daten ab? Ist es bösartig? + +Nein, die Daten auf `lencr.org` sind niemals bösartig. Wenn ein Gerät eine Verbindung zu `lencr.org` herstellt, liegt das daran, dass eine Client-Software auf diesem Gerät (z. B. ein Webbrowser oder eine App) eine Verbindung zu einer anderen Website hergestellt hat, ein Let's Encrypt-Zertifikat gesehen hat und versucht, dessen Gültigkeit zu überprüfen. Für viele Clients ist dies Routine. + +Wir können nicht sagen, ob die *andere Website*, zu der eine Verbindung besteht, bösartig ist. Wenn Sie Netzwerkaktivitäten untersuchen, die Ihnen ungewöhnlich erscheinen, dann sollten Sie sich auf die Verbindung konzentrieren, die kurz vor der Verbindung zu `lencr.org` begonnen hat. + +Das Muster der Verbindungen der Clients zu `lencr.org` könnte ungewöhnlich oder unregelmäßig aussehen. Es kann sein, dass die Clients diese Daten nie abrufen, nur Teilmengen davon abrufen oder einige Daten aus Effizienzgründen "zwischenspeichern", so dass sie nur manchmal darauf zugreifen (wenn sie sie zum ersten Mal benötigen und wenn die Daten möglicherweise abgelaufen sind). + +# Wofür genau sind diese Daten gedacht? + +Wenn eine Client-Software (z. B. ein Webbrowser oder eine Anwendung) eine Verbindung zu einer Website herstellt und diese Website ein Zertifikat vorlegt, sollte der Client überprüfen, ob das Zertifikat authentisch und gültig ist. Diese Daten helfen den Clients dabei in mehrfacher Hinsicht. + +* Unter `o.lencr.org` stellen wir Daten des Online Certificate Status Protocol (OCSP) zur Verfügung. Ein Client kann diese Daten verwenden, um festzustellen, ob ein einzelnes, noch nicht abgelaufenes Zertifikat, das wir ausgestellt haben, noch gültig ist oder widerrufen wurde. (Dies gilt nur für "End-Entity"- oder "Leaf"-Zertifikate, die wir aus einem unserer Zwischenzertifikate für Abonnenten ausgestellt haben.) + +* Unter `c.lencr.org` stellen wir Certificate Revocation Lists (CRLs) zur Verfügung, in denen alle nicht abgelaufenen Zertifikate aufgeführt sind, die wir ausgestellt und später widerrufen haben. + +* Unter `i.lencr.org` stellen wir Kopien unserer "Aussteller"-Zwischenzertifikate zur Verfügung, die entweder von einem unserer Stammzertifikate signiert oder von einer anderen Zertifizierungsstelle (CA) "cross-signed" sind. Ein Client kann diese Daten verwenden, um die "Vertrauenskette" von dem zu überprüfenden Endteilnehmerzertifikat über einen oder mehrere Zwischenschritte zu einem anerkannten und vertrauenswürdigen Stammzertifikat zu bestätigen. + +# Warum werden Verbindungen zu `o.lencr.org` über unsicheres HTTP hergestellt? + +OCSP-Antworten werden immer über HTTP übermittelt. Würden sie über HTTPS bereitgestellt, gäbe es ein Problem mit einer "Endlosschleife": Um das Zertifikat des OCSP-Servers zu überprüfen, müsste der Client OCSP verwenden. + +Die OCSP-Antwort selbst ist mit einem Zeitstempel versehen und kryptografisch signiert, so dass die Anti-Manipulationseigenschaften von TLS in diesem Fall nicht erforderlich sind. + +# Warum "`lencr.org`"? Wir haben längere URLs wie `http://ocsp.int-x3.letsencrypt.org/` verwendet. Aber als wir unsere [neuen Root- und Zwischenzertifikate][1] ausstellten, wollten wir sie so klein wie möglich machen. Jede HTTPS-Verbindung im Internet (Milliarden pro Tag) muss eine Kopie eines Zertifikats senden, daher ist jedes Byte wichtig. Wir haben `lencr.org` wegen der Ähnlichkeit mit unserem Namen gewählt: **L**et's **ENCR**ypt. Wir sprechen es ähnlich wie die fiktive Region von [Lancre][] in Terry Pratchetts _Discworld_-Romanen aus. [1]: https://letsencrypt.org/2020/09/17/new-root-and-intermediates.html -[Lancre]: https://discworld.fandom.com/wiki/Lancre +[Lancre]: https://wiki.lspace.org/Lancre diff --git a/content/de/docs/rate-limits.md b/content/de/docs/rate-limits.md index 2fba340dd3..b166b25c60 100644 --- a/content/de/docs/rate-limits.md +++ b/content/de/docs/rate-limits.md @@ -3,132 +3,48 @@ title: Rate Limits slug: rate-limits top_graphic: 1 date: 2018-01-04 -lastmod: 2019-06-04 +lastmod: 2021-10-05 show_lastmod: 1 --- -Let's Encrypt erstellt Rate Limits, um eine faire Benutzung durch so viele -Leute wie möglich sicherzustellen. Wir glauben, dass Rate Limits hoch genug -sind für die meisten Leute. Wir haben es auch so gestaltet, dass das -Erneuern eines Zertifikats niemals in ein Rate Limit läuft, sodass auch -grosse Organisationen eine grosse Anzahl an Zertifikaten ausstellen können, -ohne die Intervention von Let's Encrypt zu benötigen. - -Wenn Sie aktiv einen Let's Encrytpt Client entwickeln oder testen, bitte -benutzen Sie unsere [Staging Umgebung](/docs/staging-environment) anstatt -die Produktions API. -Wenn Sie an der Integration von Let's Encrypt als Provider arbeiten oder -einer grossen Webseite bitte [lesen Sie unseren Integration Guide](/docs/integration-guide). - -Das Hauptlimit ist **Zertifikate -pro registrierte Domain** (50 pro Woche). -Eine registrierte Domain ist, generell gesehen, der Teil der Domain, den Sie -von einem Domainregistrar gekauft haben. Zum Beispiel, im Namen `www.example.com`, -ist die registrierte Domain `example.com`. In `new.blog.example.co.uk`, -ist die registrierte Domain `example.co.uk`. Wir benutzen die -[Public Suffix List](https://publicsuffix.org), um die registrierte Domain zu -berechnen. - -Wenn Sie sehr viele Subdomains haben, möchten Sie vielleicht ein einfaches -Zertifikat kombinieren, bis zu einem Limit von 100 **Namen -per Zertifikat**. Kombiniert mit dem Limit darüber bedeutet das, Sie können -Zertifikate für bis zu 5000 einzigartige Subdomains pro Woche ausstellen. -Ein Zertifikat mit mehreren Namen wird oft SAN Zertifikat genannt, -oder manchmal UCC Zertifikat. Hinweis: Aus Gründen der Leistung und Zuverlässigkeit - sollten Sie nach Möglichkeit weniger Namen pro Zertifikat verwenden. - -Verlängerungen werden speziell behandelt: Sie werden nicht auf Ihr -**Zertifikat pro registrierter Domain**-Limit angerechnet, unterliegen jedoch einem -**Duplikat-Zertifikat**-Limit von 5 pro Woche. -Hinweis: Verlängerungen wurden bis März 2019 gegen Ihr **Zertifikat pro registrierter Domain**-Limit -angerechnet, [jetzt jedoch nicht mehr](https://community.letsencrypt.org/t/rate-limits-fixing-certs-per-name-rate-limit-order-of-operations-gotcha/88189). - -Zum Beispiel, Sie fordern die Ausstellung eines Zertifikates mit dem Namen -[`www.example.com`, `example.com`], und Sie stellen 4 weitere Anträge auf Zertifikate -die Woche. Wenn Sie den Hostnamen ändern durch Hinzufügen von [`blog.example.com`], -werden Sie wieder in der Lage sein, Ausstellungsanfragen zu senden. - -Bei der Erneuerungsbehandlung werden der öffentliche Schlüssel und die angeforderten -Erweiterungen ignoriert. Eine Zertifikatsausstellung kann auch dann als Erneuerung -betrachtet werden, wenn Sie einen neuen Schlüssel verwenden. - -**Sperren von Zertifikaten setzt das Rate Limit nicht zurück**, weil die -Resourcen zum Ausstellen dieser Zertifikate schon konsumiert sind. - -Es gibt ein **Fehlgeschlagene Validierung** -Limit von 5 Fehlern pro Account, pro Hostname, pro Stunde. Dieses Limit -ist höher auf unserer [Staging Umgebung](/docs/staging-environment), so können Sie diese Umgebung zur Fehlersuche bei Verbindungsproblemen -benutzen. - -Die "new-reg", "new-authz" und "new-cert" Endpunkte haben ein **Allgemeine Anfragen** Limit von 20 pro Sekunde. -Der "/directory" Endpunkt und das "/acme" Verzeichnis und Unterverzeichnisse -haben ein Allgemeines Anfragen Limit von 40 Anfragen pro Sekunde. - -Wir haben noch zwei andere Limits, in die Sie sehr unwahrscheinlich -laufen werden. - -Sie können maximal 10 **Konten pro IP-Adresse** -pro 3 Stunden erstellen. Sie können maximal 500 **Konten pro IP-Bereich** -mit einem IPv6 /48 pro 3 Stunden erstellen. -Es ist sehr selten, dass man in dieses Kontenlimit läuft und wir empfehlen, -dass grosse Integratoren ein Design von [ein Konto für viele Kunden](/docs/integration-guide) -verwenden. - -Sie können ein Maximum von 300 **Ausstehende -Autorisierungen** pro Konto haben. Das Erreichen dieses Rate Limits ist -selten und entsteht meistens bei der Entwicklung von ACME Clients. -Es bedeutet üblichrweise, dass Ihr Client Autorisierungsanfragen stellt, -diese aber nicht richtig verarbeiten kann. -Bitte benutzen Sie unsere [Staging Umgebung](/docs/staging-environment), -wenn Sie neue ACME Clients entwickeln. - -Benutzer der ACME v2 API können ein Maximum von 300 **Neue Aufträge** pro Konto pro 3 Stunden erstellen. +Let's Encrypt erstellt Rate Limits, um eine faire Benutzung durch so viele Leute wie möglich sicherzustellen. Wir glauben, dass Rate Limits für die meisten Leute hoch genug sind. Wir haben sie auch so gestaltet, dass das Erneuern eines Zertifikats niemals in ein Rate Limit läuft, sodass auch große Organisationen eine große Anzahl an Zertifikaten ausstellen können, ohne ein Eingreifen von Let's Encrypt zu benötigen. + +Wenn Sie aktiv einen Let's Encrytpt Client entwickeln oder testen, benutzen Sie bitte unsere [Staging-Umgebung](/docs/staging-environment) anstatt die Produktions-API. Wenn Sie an der Integration von Let's Encrypt als Provider oder einer großen Website arbeiten, [lesen Sie bitte unsere Integrationsanleitung](/docs/integration-guide). + +Das Hauptlimit ist **Zertifikate pro registrierter Domain** (50 pro Woche). Eine registrierte Domain ist, generell gesehen, der Teil der Domain, den Sie von einem Domainregistrar gekauft haben. Zum Beispiel ist im Namen `www.example.com` die registrierte Domain `example.com`. In `new.blog.example.co.uk` ist die registrierte Domain `example.co.uk`. Wir benutzen die [Public Suffix List](https://publicsuffix.org), um die registrierte Domain zu berechnen. Das Überschreiten des Limits der Zertifikate pro registrierter Domain wird mit der Fehlermeldung `too many certificates already issued` gemeldet, möglicherweise mit zusätzlichen Details. + +Sie können alle 3 Stunden maximal 300 **Neue Aufträge** pro Konto erstellen. Jedes Mal, wenn Sie ein Zertifikat von der Boulder CA anfordern, wird ein neuer Auftrag erstellt, das heißt, dass bei jeder Zertifikatsanforderung ein neuer Auftrag erstellt wird. Das Überschreiten des Limits für neue Aufträge wird mit der Fehlermeldung `too many new orders recently`. + +Es ist möglich mehrere hostnames in einem Zertifikat zu kombinieren. Es ist limitiert auf 100 **Namen pro Zertifikat**. Aus Sicht der Performance ist es besser, wenn möglich, weniger Namen pro Zertifikat zu verwenden. Ein Zertifikat mit mehreren Namen wird oft SAN Zertifikat oder auch UCC Zertifikat genannt. + +Aktualisierungen werden gesondert behandelt: sie zählen nicht in das **Zertifikate pro registrierte Domain** Limit, sondern in das [**Doppelte Zertifikate**]( /docs/duplicate-certificate-limit) Limit von 5 pro Woche. Überschreitet man das Doppelte Zertifikate Limit, dann erhält man die Fehlermeldung `too many certificates already issued for exact set of domains` (zu viele Zertifikate wurden beantragt für dasselbe Set an Domains). + +Ein Zertifikat wird als erneuert (oder als Duplikat) eines früheren Zertifikats angesehen, wenn es dasselbe Set von hostnames enthält, ungeachtet der Groß-/Kleinschreibung und der Reihenfolge. Wenn zum Beispiel ein neues Zertifikat für die Hostnamen [`www.example.com`, `example.com`] beantragt werden, kann man noch vier weitere Anträge für [`www.example.com`, `example.com`] in der Woche machen. Wenn das Set der Hostnamen geändert wurde durch Hinzufügen von [`blog.example.com`], ist es möglich ein zusätzliches Zertifikat zu beantragen. + +Bei der Erneuerung werden der öffentliche Schlüssel und die beantragten Erweiterungen ignoriert. Die Zertifikatausstellung kann als Erneuerung betrachtet werden, auch wenn Sie einen neuen Schlüssel verwenden. + +**Das Zurückziehen von Zertifikaten setzt die Ratenbeschränkungen nicht zurück**, da die für die Ausstellung dieser Zertifikate verwendeten Ressourcen bereits verbraucht wurden. + +Es gibt ein [**Failed Validation**](/docs/failed-validation-limit) Limit von 5 Fehlversuchen pro Konto, pro Hostname, pro Stunde. Diese Grenze ist in unserer [Staging-Umgebung](/docs/staging-environment) höher, so dass Sie diese Umgebung zum Debuggen von Konnektivitätsproblemen verwenden können. Das Überschreiten des Limits für fehlgeschlagene Validierungen wird mit der Fehlermeldung `zu viele fehlgeschlagene Autorisierungen in letzter Zeit` gemeldet. + +Die API-Endpunkte "new-nonce", "new-account", "new-order" und "revoke-cert" haben ein **Gesamtanfragen** Limit von 20 pro Sekunde. Der Endpunkt "/directory" und das Verzeichnis "/acme" & Unterverzeichnisse haben ein Limit von insgesamt 40 Anfragen pro Sekunde. + +Es gibt noch zwei weitere Einschränkungen, die Sie wahrscheinlich nicht treffen werden. + +Sie können maximal 10 [**Accounts pro IP-Adresse**](/docs/too-many-registrations-for-this-ip) innerhalb von 3 Stunden erstellen. Sie können maximal 500 **Accounts pro IP-Bereich** innerhalb eines IPv6 /48 pro 3 Stunden erstellen. Das Erreichen eines der beiden Kontoraten-Limits ist sehr selten, und wir empfehlen großen Integratoren, ein Design [zu bevorzugen, das ein Konto für viele Kunden verwendet](/docs/integration-guide). Das Überschreiten dieser Grenzen wird mit der Fehlermeldung `zu viele Registrierungen für diese IP` oder `zu viele Registrierungen für diesen IP-Bereich` gemeldet. + +Sie können maximal 300 **ausstehende Genehmigungen** in Ihrem Konto haben. Das Überschreiten dieser Ratengrenze ist selten und kommt am häufigsten bei der Entwicklung von ACME-Clients vor. In der Regel bedeutet dies, dass Ihr Client Berechtigungen erstellt, diese aber nicht einhält. Bitte verwenden Sie unsere [Staging-Umgebung](/docs/staging-environment), wenn Sie einen ACME-Client entwickeln. Das Überschreiten des Limits für ausstehende Berechtigungen wird mit der Fehlermeldung `zu viele derzeit ausstehende Berechtigungen` gemeldet. # Überschreibungen -Wenn Sie ein Rate Limit erreicht haben, gibt es keinen Weg, diesen temporär -zurückzusetzen. Sie müssen warten, bis das Rate Limit nach einer Woche -abgelaufen ist. Wie benutzen ein bewegliches Fenster. Wenn Sie 25 Zertifikate -am Montag ausstellen und 25 mehr am Freitag, so sind sie wieder ab Montag in -der Lage, neue Zertifikate auszustellen. Sie können eine Liste von -Zertifikaten ausgestellt für Ihre registrierte Domain erhalten von -[crt.sh](https://crt.sh), welches die öffentliche -[Certificate Transparency](https://www.certificate-transparency.org) -Logs benutzt. - -Wenn Sie ein grosser Hosting-Provider sind oder eine Organisation, die an -einer Let's Encrypt Integration arbeitet, haben wir ein -[Rate Limit Formular](https://isrg.formstack.com/forms/rate_limit_adjustment_request), welches zur -Anfrage nach höheren Limits benutzt werden kann. Die Bearbeitung der Anfrage -dauert ein paar Wochen, das heisst das Formular ist nicht zweckdienlich zum -Zurücksetzen eines bestehendes Rate Limits, in das Sie reingelaufen sind. - -Beachten Sie, dass die meisten Hosting-Provider keine Vergrösserung der -Rate Limits brauchen, weil es kein Limit an registrierten Domains und -eine Zertifikatsausstellung für diese gibt. Solange Ihre Kunden nicht mehr -als 5.000 Subdomains in einer registrierten Domain haben, brauchen Sie keine -Vergrösserung der Limits. Schauen Sie in unseren [Integration Guide](/docs/integration-guide) für mehr Anleitungen. +Wenn Sie ein Rate Limit erreicht haben, gibt es keinen Weg, diesen temporär zurückzusetzen. Sie müssen warten, bis das Rate Limit nach einer Woche abgelaufen ist. Wenn Sie 25 Zertifikate am Montag ausstellen und 25 mehr am Freitag, so sind sie wieder ab Montag in der Lage, neue Zertifikate auszustellen. Sie können eine Liste von Zertifikaten ausgestellt für Ihre registrierte Domain erhalten von [crt.sh](https://crt.sh), welches die öffentliche [Certificate Transparency](https://www.certificate-transparency.org) Logs benutzt. + +Wenn Sie ein grosser Hosting-Provider sind oder eine Organisation, die an einer Let's Encrypt Integration arbeitet, haben wir ein [Rate Limit Formular](https://isrg.formstack.com/forms/rate_limit_adjustment_request), welches zur Anfrage nach höheren Limits benutzt werden kann. Die Bearbeitung der Anfrage dauert ein paar Wochen, das heisst das Formular ist nicht zweckdienlich zum Zurücksetzen eines bestehendes Rate Limits, in das Sie reingelaufen sind. # Ausstehende Autorisierungen bereinigen -Wenn Sie eine grosse Anzahl von ausstehenden Autorisierungsanfragen haben -und dadurch in einen Rate Limit Fehler laufen, können Sie einen -Überprüfungsversuch für die Autorisierungsobjekte durch Absenden eines -JWS-Signierten POST absenden, wie in -[ACME spec](https://tools.ietf.org/html/rfc8555#section-7.5.1) -beschrieben. -Die ausstehenden Autorisierungsobjekte werden durch URLs in der Form -`https://acme-v02.api.letsencrypt.org/acme/authz/XYZ` dargestell und sollten in -Ihrem Client Log auftauchen. Beachten Sie, dass es keinen Unterschied macht, -ob die Validierung erfolgreich war oder nicht. Die Autorisierung wird immer -den Status ausserhalb von *pending* haben. Wenn Sie keine Logs mit relevanten -Autorisierungs-URLs haben, müssen Sie warten, bis das Rate Limit abgelaufen ist. -Wie oben beschrieben, ist es ein bewegliches Fenster, sodass es weniger als eine -Woche dauert, abhängig von ihrem Vorgehen bei der Ausstellung. - -Beachten Sie, dass eine hohe Anzahl von ausstehenden Autorisierungen das Ergebnis -eines fehlerhaften Clients ist. Wenn Sie regelmässig in dieses Rate Limit laufen, -sollten Sie Ihren Client Code nochmals überprüfen. +Wenn Sie eine große Anzahl ausstehender Autorisierungsobjekte haben und einen Ratenbegrenzungsfehler für ausstehende Autorisierungen erhalten, können Sie einen Validierungsversuch auslösen, indem Sie einen JWS-signierten POST an eine seiner challenges senden, wie in [ACME-Spezifikation](https://tools.ietf.org/html/rfc8555#section-7.5.1) beschrieben. Die ausstehenden Autorisierungsobjekte werden durch URLs im Format `https://acme-v02.api.letsencrypt.org/acme/authz/XYZ` dargestellt und sollten in Ihren Clientprotokollen angezeigt werden. Dabei ist es egal, ob die Validierung erfolgreich ist oder fehlschlägt. Bei beiden wird die Autorisierung aus dem Status „ausstehend“ genommen. Wenn Sie keine Protokolle mit den relevanten Autorisierungs-URLs haben, müssen Sie warten, bis die Ratenbegrenzung abgelaufen ist. Wie oben beschrieben, gibt es ein gleitendes Zeitfenster, sodass dies je nach Ausstellungsmuster weniger als eine Woche dauern kann. + +Beachten Sie, dass eine große Anzahl ausstehender Autorisierungen im Allgemeinen das Ergebnis eines fehlerhaften Clients ist. Wenn Sie dieses Ratenlimit häufig erreichen, sollten Sie Ihren Client-Code überprüfen. diff --git a/content/de/docs/revoking.md b/content/de/docs/revoking.md index d779fe46c5..023ff24351 100644 --- a/content/de/docs/revoking.md +++ b/content/de/docs/revoking.md @@ -1,51 +1,77 @@ --- -title: Zertifikate sperren +title: Widerruf von Zertifikaten slug: revoking top_graphic: 1 date: 2017-06-08 -lastmod: 2021-08-03 +lastmod: 2021-10-15 show_lastmod: 1 --- -Wenn ein zu einem Zertifikat dazugehöriger privater Schlüssel nicht länger sicher ist, sollten Sie das Zertifikat sperren. Das kann aus unterschiedlichen Gründen passieren. Zum Beispiel, Sie haben unglücklicherweise den privaten Schlüssel auf einer öffentlichen Webseite geteilt; Hacker haben Ihren privaten Schlüssel von Ihren Servern kopiert; oder Hacker haben temporär Kontrolle über Ihre Server oder Ihre DNS Konfiguration erhalten und benutzten das zum Validieren und Ausstellen eines Zertifikats, für den sie den privaten Schlüssel besitzen. +Wenn ein Zertifikat nicht mehr sicher zu verwenden ist, sollten Sie es widerrufen. Dafür kann es verschiedene Gründe geben. So könnten Sie beispielsweise den privaten Schlüssel versehentlich auf einer öffentlichen Website weitergeben; Hacker könnten den privaten Schlüssel von Ihren Servern kopieren; oder Hacker könnten vorübergehend die Kontrolle über Ihre Server oder Ihre DNS-Konfiguration übernehmen und diese zur Validierung und Ausstellung eines Zertifikats verwenden, für das sie den privaten Schlüssel besitzen. -Wenn Sie ein Let's Encrypt Zertifikat sperren, wird Let's Encrypt die Sperrinformationen durch das [Online Certificate Status Protocol (OCSP)](https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol) veröffentlichen und einige Browser werden OCSP überprüfen, ob sie einem Zertifikat vertrauen sollten. Beachten Sie, dass OCSP [einige grundlegende Probleme hat](https://www.imperialviolet.org/2011/03/18/revocation.html), sodass nicht alle Browser diese Überprüfung machen werden. Trotzdem, Sperren von Zertifikaten, die einen kompromitierten privaten Schlüssel haben, ist eine wichtige Praxis und ist erforderlich vom Let's Encrypt's [Subscriber Agreement](/repository). +Wenn Sie ein Let's Encrypt-Zertifikat widerrufen, veröffentlicht Let's Encrypt diese Widerrufsinformationen über das [Online Certificate Status Protocol (OCSP)](https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol), und einige Browser überprüfen OCSP, um festzustellen, ob sie einem Zertifikat vertrauen sollten. Beachten Sie, dass OCSP [einige grundsätzliche Probleme hat](https://www.imperialviolet.org/2011/03/18/revocation.html), so dass nicht alle Browser diese Prüfung durchführen. Dennoch ist der Widerruf von Zertifikaten, die kompromittierten privaten Schlüsseln zuzuordnen sind, eine wichtige Praxis und wird in der [Teilnehmervereinbarung](/repository) von Let's Encrypt gefordert. -Um ein Zertifikat mit Let's Encrypt zu sperren, werden Sie die [ACME API](https://github.com/letsencrypt/boulder/blob/master/docs/acme-divergences.md) benutzen, meist durch einen ACME Client wie [Certbot](https://certbot.eff.org/). Sie müssen gegenüber Let's Encrypt bestätigen, dass Sie die Berechtigung zum Sperren des Zertifikats haben. Es gibt drei Wege, das zu tun: +Um ein Zertifikat mit Let's Encrypt zu widerrufen, verwenden Sie die [ACME API](https://github.com/letsencrypt/boulder/blob/master/docs/acme-divergences.md), höchstwahrscheinlich über einen ACME Client wie [Certbot](https://certbot.eff.org/). Sie müssen Let's Encrypt gegenüber nachweisen, dass Sie berechtigt sind, das Zertifikat zu widerrufen. Es gibt drei Möglichkeiten, dies zu tun: über das Konto, das das Zertifikat ausgestellt hat, über ein anderes autorisiertes Konto oder über den privaten Schlüssel des Zertifikats. -# Vom Konto, dass das Zertifikat ausgestellt hat. +# Angabe einer Begründung -Wenn Sie ursprünglich das Zertifikat ausgestellt haben und weiterhin Kontrolle über das Konto, welches Sie benutzten, haben, können Sie Ihre Kontoanmeldeinformationen benutzen, welches das Zertifikat ausgestellt hat. Certbot wird das standardmässig machen. Beispiel: +Bei der Sperrung eines Zertifikats sollten Let's Encrypt-Abonnenten einen Grund angeben, der wie folgt lautet: + +* Kein Grund angegeben oder `unspecified` (RFC 5280 CRLReason #0) + - Wenn die nachstehenden Begründungen nicht auf den Antrag auf Widerruf zutreffen, darf der Teilnehmer keinen andere Begründung als "unspecified" angeben. +* `keyCompromise` (RFC 5280 CRLReason #1) + - Der Zertifikatsabonnent muss den Sperrgrund "keyCompromise" wählen, wenn er Grund zu der Annahme hat, dass der private Schlüssel seines Zertifikats kompromittiert wurde, z. B. wenn eine unbefugte Person Zugriff auf den privaten Schlüssel seines Zertifikats hatte. + - Wenn die Widerrufsanforderung mit dem privaten Schlüssel des Zertifikats und nicht mit dem privaten Schlüssel eines Abonnentenkontos signiert wird, ignoriert Let's Encrypt möglicherweise den Widerrufsgrund in der Anforderung und setzt den Grund auf "keyCompromise". +* `superseded` (RFC 5280 CRLReason #4) + - Der Zertifikatsabonnent sollte den Sperrgrund " superseded" wählen, wenn er ein neues Zertifikat beantragt, um sein bestehendes Zertifikat zu ersetzen. +* `cessationOfOperation` (RFC 5280 CRLReason #5) + - Der Zertifikatsabonnent sollte den Sperrgrund "cessationOfOperation" wählen, wenn er nicht mehr im Besitz aller Domainnamen des Zertifikats ist oder wenn er das Zertifikat nicht mehr verwenden wird, weil er seine Website einstellt. + - Wenn die Widerrufsanforderung von einem Abonnentenkonto stammt, das das betreffende Zertifikat nicht bestellt hat, aber die Kontrolle über alle Identifikatoren im Zertifikat nachweist, kann Let's Encrypt den Widerrufsgrund in der Anforderung ignorieren und den Grund auf "cessationOfOperation" setzen. + +Löschungsanträge, die einen anderen als den oben genannten Grund angeben, werden abgelehnt. + +# Von dem Account, der das Zertifikat ausgestellt hat + +Wenn Sie das Zertifikat ursprünglich ausgestellt haben und noch die Kontrolle über den Account haben, mit dem Sie es ausgestellt haben, können Sie es mit Ihren Account-Anmeldedaten widerrufen. Certbot wird dies standardmäßig versuchen. Beispiel: ```bash -certbot revoke --cert-path /etc/letsencrypt/archive/${YOUR_DOMAIN}/cert1.pem --reason keycompromise +certbot revoke --cert-path /etc/letsencrypt/archive/${YOUR_DOMAIN}/cert1.pem ``` -# Benutzen des privaten Schlüssels des Zertifikats +# Benutzung eines unterschiedlich autorisierten Kontos -Wenn Sie nicht das Zertifikat ausgestellt haben, aber noch eine Kopie des zugehörigen privaten Schlüssels haben, können Sie das Zertifikat unter Benutzung des privaten Schlüssels sperren, indem Sie den Sperrauftrag signieren. Zum Beispiel, wenn Sie sehen, dass der private Schlüssel unglücklicherweise veröffentlicht wurde, können Sie diese Methode zum Sperren des Zertifikats benutzen, wenn Sie nicht die Person sind, die das Zertifikat ursprünglich ausgestellt hat. +Wenn jemand ein Zertifikat ausgestellt hat, nachdem er Ihren Host oder Ihr DNS kompromittiert hat, müssen Sie dieses Zertifikat widerrufen, sobald Sie die Kontrolle wiedererlangt haben. Um das Zertifikat zu widerrufen, muss Let's Encrypt sicherstellen, dass Sie die Kontrolle über die Domänennamen in diesem Zertifikat haben (andernfalls könnten sich die Leute gegenseitig die Zertifikate widerrufen, ohne die Erlaubnis zu haben)! -Um diese Methode zu benutzen, müssen Sie zuerst das Zertifikat, welches gesperrt werden soll, herunterladen. Let's Encrypt speichert alle Logs zu Zertifikaten auf [Certificate Transparency](https://www.certificate-transparency.org/), so finden Sie es und können das Zertifikat von einem Logmonitor herunterladen, wie [crt.sh](https://crt.sh/). +Um dieses Steuerelement zu validieren, verwendet Let's Encrypt die gleichen Methoden wie bei der Validierung von Steuerelementen für die Ausgabe: Sie können einen [Wert in einen DNS-TXT-Eintrag](https://tools.ietf.org/html/rfc8555#section-8.4) oder eine [Datei auf einem HTTP-Server](https://tools.ietf.org/html/rfc8555#section-8.3) einfügen. In der Regel übernimmt ein ACME Client diese Aufgabe für Sie. Beachten Sie, dass die meisten ACME-Clients Validierung und Ausstellung kombinieren, so dass die einzige Möglichkeit, nach Validierungen zu fragen, darin besteht, die Ausstellung zu versuchen. Sie können dann das resultierende Zertifikat widerrufen, wenn Sie es nicht mehr benötigen, oder den privaten Schlüssel einfach vernichten. -Sie brauchen auch eine Kopie des privaten Schlüssels im PEM Format. Wenn Sie alles zusammen haben, können Sie das Zertifikat sperren: +Wenn Sie die Ausstellung eines Zertifikats vermeiden möchten, können Sie einen nicht existierenden Domänennamen in Ihre Befehlszeile einfügen, was dazu führt, dass die Ausstellung fehlschlägt, während die anderen, existierenden Domänennamen weiterhin überprüft werden. Beispiel: ```bash -certbot revoke --cert-path /PATH/TO/cert.pem --key-path /PATH/TO/key.pem --reason keycompromise +certbot certonly --manual --preferred-challenges=dns -d ${YOUR_DOMAIN} -d nonexistent.${YOUR_DOMAIN} ``` -# Benutzung eines unterschiedlich autorisierten Kontos +Und folgen Sie den Anweisungen. Wenn Sie lieber über HTTP als über DNS validieren möchten, ersetzen Sie das Flag `--preferred-challenges` durch `--preferred-challenges=http`. -Wenn irgendjemand ein Zertifikat ausgestellt hat, nachdem Ihr Server oder Ihr DNS kompromitiert wurde, möchten Sie das Zertifikat erneut sperren. Um die Richtigkeit der Sperrung sicherzustellen, brauch Let's Encrypt die Sicherheit, dass Sie die Kontrolle über Ihren Domainamen, in dem sich das Zertifikat befindet, haben (andererseits könnten Leute jede anderen Zertifikate ohne Erlaubnis sperren)! Zur Überprüfung dieser Kontrolle benutzt Let's Encrypt dieselben Methoden wie unter Validierung bei der Ausstellung. Sie können einen [Eintrag in DNS TXT ](https://tools.ietf.org/html/rfc8555#section-8.4) machen, eine [Datei auf Ihren HTTP Server](https://tools.ietf.org/html/rfc8555#section-8.3) ablegen oder bieten ein [spezielles TLS Zertifikat](https://tools.ietf.org/html/rfc8737#section-3). Im Allgemeinen wird ein ACME Client das alles für Sie erledigen. Beachten Sie, dass die meisten ACME CLients Validierung und Ausstellung kombinieren, der einzige Weg nach einer Validierung zu fragen, ist der Weg der Ausstellung. Sie können das Zertifikat im Ergebnis wieder sperren, wenn Sie es nicht möchten oder zerstören Sie einfach den privaten Schlüssel. Wenn Sie die Ausstellung eines Zertifikats im Allgemeinen verhindern möchten, können Sie eine nichtexistierende Domain auf der Kommandozeile verwenden, was dazu führt, dass die Ausstellung fehlschlägt bei gleichzeitiger Validierung der anderen existierenden Domainnamen. Um dies zu tun, führen: +Sobald Sie die Kontrolle über alle Domänennamen in dem zu widerrufenden Zertifikat validiert haben, können Sie das Zertifikat von [crt.sh](https://crt.sh/) herunterladen und das Zertifikat widerrufen, als ob Sie es ausgestellt hätten: ```bash -certbot certonly --manual --preferred-challenges=dns -d ${YOUR_DOMAIN} -d nonexistent.${YOUR_DOMAIN} +certbot revoke --cert-path /PATH/TO/downloaded-cert.pem ``` -Und folgen Sie den Anweisungen. Wenn Sie die Validierung über HTTP dem DNS bevorzugen, ersetzen Sie das `--preferred-challenges` Flag mit `--preferred-challenges=http`. +# Verwendung des privaten Schlüssels des Zertifikats + +Wenn Sie das Zertifikat ursprünglich nicht ausgestellt haben, aber über eine Kopie des zugehörigen privaten Schlüssels verfügen, können Sie es widerrufen, indem Sie diesen privaten Schlüssel zum Signieren des Widerrufsantrags verwenden. Wenn Sie z. B. feststellen, dass ein privater Schlüssel versehentlich veröffentlicht wurde, können Sie diese Methode verwenden, um Zertifikate zu widerrufen, die diesen privaten Schlüssel verwenden, auch wenn Sie nicht die Person sind, die diese Zertifikate ursprünglich erstellt hat. + +Um diese Methode zu verwenden, benötigen Sie zunächst eine Kopie des privaten Schlüssels im PEM-Format. + +Laden Sie dann das zu widerrufende Zertifikat herunter, falls Sie es noch nicht haben. Let's Encrypt protokolliert alle Zertifikate in [Certificate Transparency](https://www.certificate-transparency.org/)-Protokollen, so dass Sie Zertifikate über einen Protokollmonitor wie [crt.sh](https://crt.sh/) finden und herunterladen können. Die Suche nach einem passenden `SubjectPublicKeyInfo` (SPKI) Feld findet alle Zertifikate, die den privaten Schlüssel verwenden. Um den SPKI-Hash aus einem privaten Schlüssel zu extrahieren: +```bash +openssl pkey -outform DER -in /PATH/TO/privkey.pem -pubout | openssl sha256 +``` -Nur wenn Sie validierte Kontrolle über all die Domainnamen in dem Zertifikat, welches Sie sperren möchten, haben, können Sie das Zertifikat herunterladen von [crt.sh](https://crt.sh/), und fahren Sie mit dem Sperren des Zertifikats fort, als wenn Sie es ausgestellt haben: +Sobald Sie den privaten Schlüssel und das Zertifikat haben, können Sie das Zertifikat wie folgt widerrufen: ```bash -certbot revoke --cert-path /PATH/TO/downloaded-cert.pem --reason keycompromise +certbot revoke --cert-path /PATH/TO/cert.pem --key-path /PATH/TO/privkey.pem --reason keyCompromise ``` diff --git a/content/de/docs/too-many-registrations-for-this-ip.md b/content/de/docs/too-many-registrations-for-this-ip.md index 00bac712a8..5cd4632f09 100644 --- a/content/de/docs/too-many-registrations-for-this-ip.md +++ b/content/de/docs/too-many-registrations-for-this-ip.md @@ -1,9 +1,38 @@ --- -title: Registrations Per IP Limit +title: Registrierungen pro IP Limit slug: too-many-registrations-for-this-ip top_graphic: 1 lastmod: 2022-08-15 show_lastmod: false -untranslated: 1 --- + +# Beschreibung + +Abonnenten können alle 3 Stunden bis zu 10 Konten pro IP-Adresse registrieren. Sie sollten die folgende Fehlermeldung von Ihrem ACME-Client erhalten, wenn Sie das Limit für *Registrierungen pro IP* überschritten haben: + +``` +too many registrations for this IP: see https://letsencrypt.org/docs/too-many-registrations-for-this-ip/ +``` + +Die 'Registrierungen', auf die sich diese Fehlermeldung bezieht, sind Anfragen, die von Ihrer IP-Adresse gesendet werden, um ein neues Konto bei der Let's Encrypt API zu registrieren. Dieser Fehler zeigt an, dass in den letzten 3 Stunden bereits mindestens 10 Konten von dieser IP-Adresse aus registriert worden sind. + +# Häufige Ursachen + +Abonnenten, die das Limit für Registrierungen pro IP-Adresse erreichen, tun dies oft aufgrund einer Fehlkonfiguration in ihrer Umgebung. + +## Wiederholte Bereitstellungen + +Das Erreichen des Limits "Registrierungen pro IP" als einzelner Abonnent ist äußerst selten. Dies tritt höchstwahrscheinlich bei wiederholten Bereitstellungen Ihres Systems oder Ihrer Anwendung auf; entweder kann Ihr ACME-Client die Anmeldedaten Ihres Kontos nicht speichern und wiederverwenden oder das Dateisystem, in dem die Anmeldedaten gespeichert werden sollten, wird zwischen den Bereitstellungen zerstört (Container, virtuelle Maschinen, Cloud-Instanzen). Wenn Sie die Bereitstellung Ihres Systems oder Ihrer Anwendung testen, stellen Sie sicher, dass Sie Ihren ACME-Client für die Verwendung unserer Staging-Umgebung konfiguriert haben. Die Ratengrenzen für unsere Staging-Umgebung sind [deutlich höher](/docs/staging-environment/#rate-limits). + +## Zu viele Konten + +Hosting-Anbieter und andere große Integratoren stoßen in der Regel an die Grenze für Registrierungen pro IP, wenn sie versuchen, ein Konto pro Kunde anzufordern. Wir empfehlen, dass große Integratoren ein Design mit [einem Konto für viele Kunden](/docs/integration-guide/#one-account-or-many) bevorzugen. Stellen Sie beim Testen sicher, dass Sie Ihre ACME-Implementierung für die Verwendung unserer Testumgebung konfiguriert haben. Die Ratengrenzen für unsere Staging-Umgebung sind [deutlich höher](/docs/staging-environment/#rate-limits). + +# Anfordern von Hilfe + +Wenn Sie nicht sicher sind, wie Sie Ihren ACME-Client für die Verwendung unserer Staging-Umgebung konfigurieren sollen oder wenn Sie Hilfe bei der Fehlersuche benötigen, können Sie in [unserem Community-Forum Hilfe anfordern](https://community.letsencrypt.org/c/help/13). + +# Anforderung einer Überschreibung + +Überschreibungen sind für das Limit Registrierungen pro IP **nicht** möglich. diff --git a/content/de/donate.html b/content/de/donate.html index fa950008d9..c93e50867b 100644 --- a/content/de/donate.html +++ b/content/de/donate.html @@ -4,7 +4,7 @@ slug: donate top_graphic: 3 no_donate_footer: true -lastmod: 2019-09-18 +lastmod: 2023-08-08 menu: main: weight: 30 @@ -13,25 +13,97 @@