Let's Encrypt: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
| (16 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
''' | '''Let's Encrypt''' ist eine kostenlose, automatisierte und offene [[Zertifizierungsstelle]] für [[X.509]]-basierte [[Transport Layer Security|TLS]]-[[Digitales Zertifikat|Zertifikate]]. Der Dienst wird von der gemeinnützigen Internet Security Research Group (ISRG) betrieben | ||
== | == Eigenschaften == | ||
; Zertifikatsarten | |||
* Ausstellung von Domain-Validation-(DV)-Zertifikaten für DNS-Namen (Einzelnamen, Subject-Alternative-Name-Zertifikate und Wildcard-Zertifikate) | |||
* OV- und EV-Zertifikate werden bewusst nicht angeboten, da deren Antragsprozesse nicht vollständig automatisierbar sind | |||
== Installation == | ; Gültigkeit | ||
* Standardgültigkeit der Zertifikate beträgt 90 Tage | |||
* Für den produktiven Betrieb ist eine automatisierte Erneuerung vorgesehen (z. B. über ACME-Clients. Details in [[#Nutzung|Nutzung]]) | |||
; Kosten | |||
* Ausstellung und Nutzung der Zertifikate sind kostenfrei. | |||
* Es wird weitgehend auf [[freie Software]] und offene Standards gesetzt | |||
; Transparenz | |||
* Ausgestellte Zertifikate werden in öffentlichen Logsystemen (z. B. Certificate Transparency) protokolliert | |||
* Die Betreibenden veröffentlichen regelmäßig Transparenz- und Sicherheitsberichte | |||
== Organisation == | |||
Let’s Encrypt ist ein von der Internet Security Research Group angebotener Dienst | |||
* Finanzierung erfolgt überwiegend durch Sponsoring großer Unternehmen aus Browser-, CDN- und Infrastrukturbereich sowie durch Spenden | |||
* Zu den wichtigen Unterstützenden gehören unter anderem die Electronic Frontier Foundation (EFF), die [[Mozilla|Mozilla Foundation]], Akamai, Google Chrome und [[Cisco Systems]] | |||
== Vertrauensmodell und Zertifikatskette == | |||
Let’s Encrypt betreibt eigene Root-Zertifikate (z. B. ''ISRG Root X1'') und stellt davon abgeleitete Zwischenzertifikate bereit. | |||
* Zur Sicherstellung der Kompatibilität mit älteren Clients wurden zeitweise zusätzlich von IdenTrust signierte Zwischenzertifikate eingesetzt | |||
* Die aktuell verwendeten Root- und Intermediate-Zertifikate sowie Details zur Schlüsselinfrastruktur sind in [[Let's Encrypt/Technik]] beschrieben | |||
== Technik == | |||
Let’s Encrypt verwendet das ACME-Protokoll (Automatic Certificate Management Environment) zur automatisierten Ausstellung und Erneuerung von Zertifikaten. | |||
* ACME-Clients führen die Authentifizierung der Domain und die Installation der Zertifikate auf dem Zielsystem aus | |||
* Unterstützte Validierungsmethoden (z. B. ''HTTP-01'', ''DNS-01'', ''TLS-ALPN-01'') sowie konkrete Anwendungsbeispiele werden in [[Let's Encrypt/Anwendungen]] beschrieben | |||
* Weitere technische Details zur Implementierung, zur CA-Software und zur Infrastruktur sind in [[Let's Encrypt/Technik]] zusammengefasst | |||
== Bedeutung == | |||
Let’s Encrypt hat die Verbreitung von HTTPS im [[World Wide Web]] wesentlich beschleunigt und die Hürden für den Einsatz von Transportverschlüsselung deutlich gesenkt | |||
* Das Projekt unterstützt Bestrebungen großer [[Webbrowser]]-Projekte, unverschlüsseltes [[Hypertext Transfer Protocol|HTTP]] als unsicher zu kennzeichnen | |||
* Für den gesellschaftlichen Nutzen erhielt Let’s Encrypt mehrere Auszeichnungen, darunter den FSF Award 2019 | |||
== Nutzung == | |||
=== Überblick === | |||
[[Let's Encrypt|Let’s Encrypt]] ermöglicht die automatisierte Ausstellung und Erneuerung von TLS-Zertifikaten über das ACME-Protokoll (RFC 8555) | |||
* Ein ACME-Client weist die Kontrolle über eine Domain nach und ruft ein Zertifikat ab | |||
* Zertifikate besitzen eine maximale Gültigkeit von 90 Tagen, daher sollte eine automatische Erneuerung konfiguriert werden | |||
=== ACME-Client-Implementierungen === | |||
Zur Nutzung von Let’s Encrypt muss eine ACME-Clientsoftware eingesetzt werden | |||
* Es stehen zahlreiche Clients von Drittanbietern zur Verfügung. | |||
:* Keine Überprüfung oder Zertifizierung dieser Clients durch Let’s Encrypt | |||
* Browserbasierte Clients werden nicht berücksichtigt, da sie manuelle Erneuerungen fördern | |||
==== Certbot ==== | |||
Für die meisten Szenarien wird Certbot empfohlen. | |||
* Unterstützt automatisiertes Ausstellen, Installieren und Erneuern von Zertifikaten | |||
* Bietet Auto-Konfiguration sowie Expertenmodus. | |||
* Umfangreiche Dokumentation und breite Betriebssystemunterstützung | |||
==== ACMEv1 / ACMEv2 ==== | |||
Alle unterstützten ACME-Clients verwenden '''ACMEv2 (RFC 8555)''' | |||
* ACMEv1 wurde am 1. Juni 2021 vollständig abgeschaltet | |||
=== Erste Schritte === | |||
Zur Aktivierung von HTTPS wird ein Zertifikat benötigt, das über ACME angefordert wird | |||
* Der Nachweis der Domainkontrolle erfolgt über einen ACME-Client oder über Integrationen beim Hosting-Provider | |||
* Entscheidend ist, '''ob Shell-Zugang verfügbar ist''' | |||
== | ==== Mit Shell-Zugang ==== | ||
Für Shell-Umgebungen wird Certbot empfohlen | |||
* Unterstützt automatische Abläufe ohne Ausfallzeit | |||
* Alternativ können weitere ACME-Clients eingesetzt werden | |||
Für Tests kann die Staging-Umgebung genutzt werden, um Rate Limits nicht auszulösen | |||
=== | ==== Ohne Shell-Zugriff ==== | ||
Optimal ist die Nutzung integrierter Let’s-Encrypt-Unterstützung des Hosting-Providers | |||
* Zertifikate werden automatisch angefordert und erneuert | |||
Falls keine Integration vorhanden ist, kann ein Zertifikat manuell erzeugt und anschließend beim Provider hochgeladen werden | |||
* Dieser Ansatz ist aufwendig und muss regelmäßig wiederholt werden. Gilt als Notlösung | |||
=== | === ACME-Challenge-Typen === | ||
Für die Domainvalidierung stehen mehrere Verfahren zur Verfügung. Auswahl und Einsatz hängen von Infrastruktur, DNS-Zugriff und Port-Verfügbarkeit ab | |||
{| class="wikitable options big" | {| class="wikitable options big" | ||
! Methode | |||
! Port | |||
! Vorteile | |||
! Nachteile | |||
|- | |- | ||
| HTTP-01 | |||
| Port 80 | |||
| | |||
* Einfach einzurichten | |||
* Kompatibel mit den meisten Webservern | |||
* Automatisierbar | |||
| | |||
* Erfordert offenen Port 80 | |||
* Probleme hinter CDN/Reverse-Proxy möglich | |||
* Nicht nutzbar für Wildcard-Zertifikate | |||
|- | |- | ||
| || | | DNS-01 | ||
| TXT-Record | |||
| | |||
* Ermöglicht Ausstellung von Wildcard-Zertifikaten | |||
* Unabhängig von Ports oder Webserver | |||
* Sehr flexibel bei komplexen Infrastrukturen | |||
| | |||
* Erfordert DNS-API oder manuellen Eingriff | |||
* DNS-Propagation kann Verzögerungen verursachen | |||
|- | |- | ||
| || | | TLS-ALPN-01 | ||
| Port 443 | |||
| | |||
* Keine Abhängigkeit von Port 80 | |||
* Funktioniert hinter bestimmten Proxies besser | |||
| | |||
* Benötigt direkte Kontrolle über TLS-Konfiguration | |||
* Nicht überall unterstützt | |||
|} | |} | ||
=== Funktionsweise von ACME === | |||
==== Architektur ==== | |||
Der ACME-Ablauf folgt festen Objekten und Schritten: | |||
* '''Account Key''' – kryptografische Identität des Clients | |||
* '''Order''' – Anforderung eines oder mehrerer Zertifikate | |||
* '''Authorization''' – Nachweis der Kontrolle für jede Domain | |||
* '''Challenge''' – konkrete Prüfaufgabe (HTTP-01, DNS-01, TLS-ALPN-01) | |||
* '''Finalization''' – Übermittlung des CSR | |||
* '''Certificate''' – Ausstellung des Zertifikats | |||
Diese Struktur entspricht dem ACME-Standard (RFC 8555) | |||
== | ==== Domain-Validierung ==== | ||
Der Client erzeugt ein Schlüsselpaar und fordert Validierungsaufgaben an. | |||
* Nach Bereitstellung der Challenge-Ressourcen prüft die Zertifizierungsstelle deren Erfüllung. | |||
* Bei Erfolg gilt der Account Key als autorisiert. | |||
* | |||
=== | ==== Zertifikatausstellung und Widerruf ==== | ||
Zur Ausstellung wird eine Zertifikatsanforderung (CSR) übermittelt | |||
* Nach erfolgreicher Prüfung wird ein Zertifikat zurückgegeben | |||
* Widerrufe erfolgen über signierte Widerrufsanfragen | |||
* Entsprechende Informationen werden über die üblichen Kanäle publiziert | |||
=== Rate Limits === | |||
Let’s Encrypt setzt verschiedene Beschränkungen ein, um Missbrauch zu verhindern. Für einen stabilen Betrieb sollte die automatisierte Erneuerung auf die Staging-Umgebung getestet werden. | |||
Limits: | |||
* Begrenzte Anzahl neuer Zertifikate pro registrierter Domain pro Woche. | |||
* Begrenzung fehlerhafter Validierungsversuche pro Stunde. | |||
* Begrenzte Anzahl neuer Orders pro Account innerhalb kurzer Zeiträume. | |||
Für Tests steht eine Staging-Umgebung mit deutlich höheren Limits zur Verfügung. | |||
; Staging-Umgebung | |||
Die Staging-Umgebung ist eine separate ACME-Testinfrastruktur mit hohen Limits und nicht vertrauenswürdigen Testzertifikaten. Sie dient zur sicheren Überprüfung von Validierung, Konfiguration und Automatisierung, ohne produktive Limits zu belasten. | |||
; Aktivierung der Staging-Umgebung | |||
Die Nutzung erfolgt über den Staging-ACME-Endpunkt oder entsprechende Client-Optionen: | |||
* Certbot: ''--staging'' | |||
= | * ACME-Endpoint: | ||
<syntaxhighlight lang="ini" copy line> | |||
https://acme-staging-v02.api.letsencrypt.org/directory | |||
* | </syntaxhighlight> | ||
* Certbot-Erneuerungstest: ''certbot renew --dry-run'' | |||
=== | === Beste Praxis === | ||
* Port 80 sollte für '''HTTP-01'''-Challenges und Weiterleitungen auf HTTPS offen bleiben. | |||
* | * Das Schließen von Port 80 reduziert das Sicherheitsrisiko kaum. | ||
* Falls Port 80 durch den Anbieter blockiert ist, können '''DNS-01''' oder '''TLS-ALPN-01''' eingesetzt werden. | |||
<noinclude> | |||
== Anhang == | |||
=== Siehe auch === | |||
<div style="column-count:2"> | |||
<categorytree hideroot=on mode="pages">Let's Encrypt</categorytree> | |||
</div> | |||
---- | |||
{{Special:PrefixIndex/{{BASEPAGENAME}}/}} | |||
<!-- | |||
=== Dokumentation === | |||
Platz für interne Hinweise oder zusätzliche Dokumentation. | |||
--> | |||
== Weblinks == | |||
# [https://letsencrypt.org/ Offizielle Website von Let’s Encrypt] | |||
# [https://cryptologie.net/article/274 Technische Einführung in Let’s Encrypt] | |||
[[Kategorie:Let's Encrypt]] | [[Kategorie:Let's Encrypt]] | ||
</noinclude> | |||
Aktuelle Version vom 18. Dezember 2025, 09:32 Uhr
Let's Encrypt ist eine kostenlose, automatisierte und offene Zertifizierungsstelle für X.509-basierte TLS-Zertifikate. Der Dienst wird von der gemeinnützigen Internet Security Research Group (ISRG) betrieben
Eigenschaften
- Zertifikatsarten
- Ausstellung von Domain-Validation-(DV)-Zertifikaten für DNS-Namen (Einzelnamen, Subject-Alternative-Name-Zertifikate und Wildcard-Zertifikate)
- OV- und EV-Zertifikate werden bewusst nicht angeboten, da deren Antragsprozesse nicht vollständig automatisierbar sind
- Gültigkeit
- Standardgültigkeit der Zertifikate beträgt 90 Tage
- Für den produktiven Betrieb ist eine automatisierte Erneuerung vorgesehen (z. B. über ACME-Clients. Details in Nutzung)
- Kosten
- Ausstellung und Nutzung der Zertifikate sind kostenfrei.
- Es wird weitgehend auf freie Software und offene Standards gesetzt
- Transparenz
- Ausgestellte Zertifikate werden in öffentlichen Logsystemen (z. B. Certificate Transparency) protokolliert
- Die Betreibenden veröffentlichen regelmäßig Transparenz- und Sicherheitsberichte
Organisation
Let’s Encrypt ist ein von der Internet Security Research Group angebotener Dienst
- Finanzierung erfolgt überwiegend durch Sponsoring großer Unternehmen aus Browser-, CDN- und Infrastrukturbereich sowie durch Spenden
- Zu den wichtigen Unterstützenden gehören unter anderem die Electronic Frontier Foundation (EFF), die Mozilla Foundation, Akamai, Google Chrome und Cisco Systems
Vertrauensmodell und Zertifikatskette
Let’s Encrypt betreibt eigene Root-Zertifikate (z. B. ISRG Root X1) und stellt davon abgeleitete Zwischenzertifikate bereit.
- Zur Sicherstellung der Kompatibilität mit älteren Clients wurden zeitweise zusätzlich von IdenTrust signierte Zwischenzertifikate eingesetzt
- Die aktuell verwendeten Root- und Intermediate-Zertifikate sowie Details zur Schlüsselinfrastruktur sind in Let's Encrypt/Technik beschrieben
Technik
Let’s Encrypt verwendet das ACME-Protokoll (Automatic Certificate Management Environment) zur automatisierten Ausstellung und Erneuerung von Zertifikaten.
- ACME-Clients führen die Authentifizierung der Domain und die Installation der Zertifikate auf dem Zielsystem aus
- Unterstützte Validierungsmethoden (z. B. HTTP-01, DNS-01, TLS-ALPN-01) sowie konkrete Anwendungsbeispiele werden in Let's Encrypt/Anwendungen beschrieben
- Weitere technische Details zur Implementierung, zur CA-Software und zur Infrastruktur sind in Let's Encrypt/Technik zusammengefasst
Bedeutung
Let’s Encrypt hat die Verbreitung von HTTPS im World Wide Web wesentlich beschleunigt und die Hürden für den Einsatz von Transportverschlüsselung deutlich gesenkt
- Das Projekt unterstützt Bestrebungen großer Webbrowser-Projekte, unverschlüsseltes HTTP als unsicher zu kennzeichnen
- Für den gesellschaftlichen Nutzen erhielt Let’s Encrypt mehrere Auszeichnungen, darunter den FSF Award 2019
Nutzung
Überblick
Let’s Encrypt ermöglicht die automatisierte Ausstellung und Erneuerung von TLS-Zertifikaten über das ACME-Protokoll (RFC 8555)
- Ein ACME-Client weist die Kontrolle über eine Domain nach und ruft ein Zertifikat ab
- Zertifikate besitzen eine maximale Gültigkeit von 90 Tagen, daher sollte eine automatische Erneuerung konfiguriert werden
ACME-Client-Implementierungen
Zur Nutzung von Let’s Encrypt muss eine ACME-Clientsoftware eingesetzt werden
- Es stehen zahlreiche Clients von Drittanbietern zur Verfügung.
- Keine Überprüfung oder Zertifizierung dieser Clients durch Let’s Encrypt
- Browserbasierte Clients werden nicht berücksichtigt, da sie manuelle Erneuerungen fördern
Certbot
Für die meisten Szenarien wird Certbot empfohlen.
- Unterstützt automatisiertes Ausstellen, Installieren und Erneuern von Zertifikaten
- Bietet Auto-Konfiguration sowie Expertenmodus.
- Umfangreiche Dokumentation und breite Betriebssystemunterstützung
ACMEv1 / ACMEv2
Alle unterstützten ACME-Clients verwenden ACMEv2 (RFC 8555)
- ACMEv1 wurde am 1. Juni 2021 vollständig abgeschaltet
Erste Schritte
Zur Aktivierung von HTTPS wird ein Zertifikat benötigt, das über ACME angefordert wird
- Der Nachweis der Domainkontrolle erfolgt über einen ACME-Client oder über Integrationen beim Hosting-Provider
- Entscheidend ist, ob Shell-Zugang verfügbar ist
Mit Shell-Zugang
Für Shell-Umgebungen wird Certbot empfohlen
- Unterstützt automatische Abläufe ohne Ausfallzeit
- Alternativ können weitere ACME-Clients eingesetzt werden
Für Tests kann die Staging-Umgebung genutzt werden, um Rate Limits nicht auszulösen
Ohne Shell-Zugriff
Optimal ist die Nutzung integrierter Let’s-Encrypt-Unterstützung des Hosting-Providers
- Zertifikate werden automatisch angefordert und erneuert
Falls keine Integration vorhanden ist, kann ein Zertifikat manuell erzeugt und anschließend beim Provider hochgeladen werden
- Dieser Ansatz ist aufwendig und muss regelmäßig wiederholt werden. Gilt als Notlösung
ACME-Challenge-Typen
Für die Domainvalidierung stehen mehrere Verfahren zur Verfügung. Auswahl und Einsatz hängen von Infrastruktur, DNS-Zugriff und Port-Verfügbarkeit ab
| Methode | Port | Vorteile | Nachteile |
|---|---|---|---|
| HTTP-01 | Port 80 |
|
|
| DNS-01 | TXT-Record |
|
|
| TLS-ALPN-01 | Port 443 |
|
|
Funktionsweise von ACME
Architektur
Der ACME-Ablauf folgt festen Objekten und Schritten:
- Account Key – kryptografische Identität des Clients
- Order – Anforderung eines oder mehrerer Zertifikate
- Authorization – Nachweis der Kontrolle für jede Domain
- Challenge – konkrete Prüfaufgabe (HTTP-01, DNS-01, TLS-ALPN-01)
- Finalization – Übermittlung des CSR
- Certificate – Ausstellung des Zertifikats
Diese Struktur entspricht dem ACME-Standard (RFC 8555)
Domain-Validierung
Der Client erzeugt ein Schlüsselpaar und fordert Validierungsaufgaben an.
- Nach Bereitstellung der Challenge-Ressourcen prüft die Zertifizierungsstelle deren Erfüllung.
- Bei Erfolg gilt der Account Key als autorisiert.
Zertifikatausstellung und Widerruf
Zur Ausstellung wird eine Zertifikatsanforderung (CSR) übermittelt
- Nach erfolgreicher Prüfung wird ein Zertifikat zurückgegeben
- Widerrufe erfolgen über signierte Widerrufsanfragen
- Entsprechende Informationen werden über die üblichen Kanäle publiziert
Rate Limits
Let’s Encrypt setzt verschiedene Beschränkungen ein, um Missbrauch zu verhindern. Für einen stabilen Betrieb sollte die automatisierte Erneuerung auf die Staging-Umgebung getestet werden.
Limits:
- Begrenzte Anzahl neuer Zertifikate pro registrierter Domain pro Woche.
- Begrenzung fehlerhafter Validierungsversuche pro Stunde.
- Begrenzte Anzahl neuer Orders pro Account innerhalb kurzer Zeiträume.
Für Tests steht eine Staging-Umgebung mit deutlich höheren Limits zur Verfügung.
- Staging-Umgebung
Die Staging-Umgebung ist eine separate ACME-Testinfrastruktur mit hohen Limits und nicht vertrauenswürdigen Testzertifikaten. Sie dient zur sicheren Überprüfung von Validierung, Konfiguration und Automatisierung, ohne produktive Limits zu belasten.
- Aktivierung der Staging-Umgebung
Die Nutzung erfolgt über den Staging-ACME-Endpunkt oder entsprechende Client-Optionen:
- Certbot: --staging
- ACME-Endpoint:
https://acme-staging-v02.api.letsencrypt.org/directory
- Certbot-Erneuerungstest: certbot renew --dry-run
Beste Praxis
- Port 80 sollte für HTTP-01-Challenges und Weiterleitungen auf HTTPS offen bleiben.
- Das Schließen von Port 80 reduziert das Sicherheitsrisiko kaum.
- Falls Port 80 durch den Anbieter blockiert ist, können DNS-01 oder TLS-ALPN-01 eingesetzt werden.
Anhang
Siehe auch
Weblinks