Let's Encrypt: Unterschied zwischen den Versionen
| (135 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
''' | '''Let's Encrypt''' - [[Zertifizierungsstelle]] für [[X.509]]-basierte [[Transport Layer Security|TLS]]-[[Digitales Zertifikat|Zertifikate]] | ||
= Beschreibung = | == Beschreibung == | ||
; Automatisierte Ausstellung und Erneuerung von TLS-Zertifikaten | |||
ACME-Protokoll ([[RFC/8555]]) | |||
* 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 | |||
; [[Zertifizierungsstelle]] für [[X.509]]-basierte [[Transport Layer Security|TLS]]-[[Digitales Zertifikat|Zertifikate]] | |||
Internet Security Research Group (ISRG) | |||
* offen | |||
* gemeinnützig | |||
* automatisiert | |||
* kostenlos | |||
; 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 | |||
= | === Zertifikate === | ||
== | ; Domain-Validation | ||
Domain-Validation-(DV)-Zertifikate | |||
* DNS-Namen | |||
* Einzelnamen | |||
* Subject-Alternative-Name-Zertifikate | |||
* Wildcard-Zertifikate | |||
; OV- und EV-Zertifikate | |||
Werden nicht angeboten | |||
* Antragsprozesse nicht vollständig automatisierbar | |||
; 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 | |||
; 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'' | |||
* stellt davon abgeleitete Zwischenzertifikate bereit | |||
; Kompatibilität mit älteren Clients | |||
* | * 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 | 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 | ||
* Weitere | * 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 | |||
== | == ACME == | ||
; Automatic Certificate Management Environment | |||
Funktionsweise von ACME | |||
=== | === Architektur === | ||
; ACME-Ablauf | |||
Objekte und Schritte | |||
{| class="wikitable options big" | |||
|- | |||
! Schritt !! Beschreibung | |||
|- | |||
| 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 | |||
=== | === 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 gnu" | |||
! 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 | |||
|} | |||
=== | === Rate Limits === | ||
Let’s Encrypt setzt v=erschiedene 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 | 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> | |||
== ACME-Clients == | |||
* | ; 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 | |||
== | === ACME Versionen === | ||
; 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 | |||
== Anhang == | |||
=== Siehe auch === | |||
<div style="column-count:2"> | |||
<categorytree hideroot=on mode="pages">Let's Encrypt</categorytree> | |||
</div> | |||
---- | |||
{{Special:PrefixIndex/{{BASEPAGENAME}}/}} | |||
---- | |||
* [[RFC/8555]] | |||
<!-- | |||
=== 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] | |||
= | |||
= | |||
[https:// | |||
[[Kategorie:Let's Encrypt]] | |||
</noinclude> | |||
Aktuelle Version vom 29. Dezember 2025, 09:59 Uhr
Let's Encrypt - Zertifizierungsstelle für X.509-basierte TLS-Zertifikate
Beschreibung
- Automatisierte Ausstellung und Erneuerung von TLS-Zertifikaten
ACME-Protokoll (RFC/8555)
- 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
- Zertifizierungsstelle für X.509-basierte TLS-Zertifikate
Internet Security Research Group (ISRG)
- offen
- gemeinnützig
- automatisiert
- kostenlos
- 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
Zertifikate
- Domain-Validation
Domain-Validation-(DV)-Zertifikate
- DNS-Namen
- Einzelnamen
- Subject-Alternative-Name-Zertifikate
- Wildcard-Zertifikate
- OV- und EV-Zertifikate
Werden nicht angeboten
- Antragsprozesse nicht vollständig automatisierbar
- 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
- 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
- stellt davon abgeleitete Zwischenzertifikate bereit
- Kompatibilität mit älteren Clients
- 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
ACME
- Automatic Certificate Management Environment
Funktionsweise von ACME
Architektur
- ACME-Ablauf
Objekte und Schritte
| Schritt | Beschreibung |
|---|---|
| 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
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 |
|
|
Rate Limits
Let’s Encrypt setzt v=erschiedene 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
ACME-Clients
- 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
ACME Versionen
- 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
Anhang
Siehe auch
Weblinks