Let's Encrypt/Technik: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
Zeile 1: | Zeile 1: | ||
== | == Beschreibung == | ||
Let’s Encrypt besitzt ein [[RSA|RSA]]-Stammzertifikat, das in einem [[Hardware-Sicherheitsmodul]] verwahrt und nicht direkt verwendet wird | Let’s Encrypt besitzt ein [[RSA|RSA]]-Stammzertifikat, das in einem [[Hardware-Sicherheitsmodul]] verwahrt und nicht direkt verwendet wird | ||
* Es soll im dritten Quartal 2019 durch ein [[Elliptic Curve DSA|ECDSA]]-Stammzertifikat ergänzt werden | * Es soll im dritten Quartal 2019 durch ein [[Elliptic Curve DSA|ECDSA]]-Stammzertifikat ergänzt werden | ||
Zeile 8: | Zeile 8: | ||
* Seit Ende Juli 2018 ist das Stammzertifikat von Let's Encrypt in allen wichtigen Root-Programmen vertreten | * Seit Ende Juli 2018 ist das Stammzertifikat von Let's Encrypt in allen wichtigen Root-Programmen vertreten | ||
== Protokoll == | |||
Zur Automatisierung der Zertifizierung nutzt Let’s Encrypt das [[Challenge-Response-Authentifizierung|Challenge-Response-Verfahren]] [[Automatic Certificate Management Environment]] (ACME) | Zur Automatisierung der Zertifizierung nutzt Let’s Encrypt das [[Challenge-Response-Authentifizierung|Challenge-Response-Verfahren]] [[Automatic Certificate Management Environment]] (ACME) | ||
* Dabei werden verschiedene Anfragen entweder an Unterseiten am Webserver oder direkt [[Domain Name System|DNS]]-Anfragen an die zu zertifizierende Domain gestellt | * Dabei werden verschiedene Anfragen entweder an Unterseiten am Webserver oder direkt [[Domain Name System|DNS]]-Anfragen an die zu zertifizierende Domain gestellt | ||
Zeile 27: | Zeile 27: | ||
* Das Protokoll wurde im März 2019 von der [[Internet Engineering Task Force]] als [[Request for Comments]] im Status eines vorgeschlagenen [[Internetstandard]]s veröffentlicht | * Das Protokoll wurde im März 2019 von der [[Internet Engineering Task Force]] als [[Request for Comments]] im Status eines vorgeschlagenen [[Internetstandard]]s veröffentlicht | ||
== Server-Implementierung == | |||
[[Datei:Letsencrypt screenshot 2 domain choice.png|mini|Domainauswahldialog]] | [[Datei:Letsencrypt screenshot 2 domain choice.png|mini|Domainauswahldialog]] | ||
Die Zertifizierungsstelle besteht im Wesentlichen aus einer in [[Go (Programmiersprache)|Go]] geschriebenen Software namens Boulder, die die Server-Seite des ACME-Protokolls implementiert | Die Zertifizierungsstelle besteht im Wesentlichen aus einer in [[Go (Programmiersprache)|Go]] geschriebenen Software namens Boulder, die die Server-Seite des ACME-Protokolls implementiert |
Aktuelle Version vom 14. Dezember 2024, 10:11 Uhr
Beschreibung
Let’s Encrypt besitzt ein RSA-Stammzertifikat, das in einem Hardware-Sicherheitsmodul verwahrt und nicht direkt verwendet wird
- Es soll im dritten Quartal 2019 durch ein ECDSA-Stammzertifikat ergänzt werden
- Damit werden mehrere Zwischenzertifikate signiert, welche durch die Zertifizierungsstelle IdenTrust gegengezeichnet werden
- Eines davon dient dann zur Signierung der ausgestellten Zertifikate, die anderen als Ersatz bei Problemen mit dem ersten
- Durch die IdenTrust-Signatur können die ausgestellten Zertifikate in gebräuchlichen Webbrowsern über die vorinstallierten Stammzertifizierungsstellen geprüft werden
- So werden Let’s-Encrypt-Zertifikate auf Client-Seite von Anfang an in der Regel ohne weiteres akzeptiert
- Seit Ende Juli 2018 ist das Stammzertifikat von Let's Encrypt in allen wichtigen Root-Programmen vertreten
Protokoll
Zur Automatisierung der Zertifizierung nutzt Let’s Encrypt das Challenge-Response-Verfahren Automatic Certificate Management Environment (ACME)
- Dabei werden verschiedene Anfragen entweder an Unterseiten am Webserver oder direkt DNS-Anfragen an die zu zertifizierende Domain gestellt
- In beiden Fällen wird ein vorher von Let’s Encrypt erstellter Token entweder auf einer speziellen Unterseite am Web-Server oder als TXT Resource Record im DNS der betreffenden Domain öffentlich abgelegt und von Let’s-Encrypt-Servern in Folge abgefragt
- Anhand der Antwort mit den Token wird sichergestellt, dass der Antragsteller den Web-Server oder direkt den Nameserver und die damit verknüpfte Domain kontrolliert ()
Auf dem Server-System müssen diese Anfragen korrekt beantwortet werden
- Dazu bietet das Protokoll verschiedene Möglichkeiten
- Bei einer wird dazu von der ACME-Client-Software ein besonders konfigurierter TLS-Server eingerichtet, der mittels Server Name Indication auf besondere Anfragen der Zertifizierungsstelle antwortet (Domain-Validierung mittels Server Name Indication, DVSNI)
- Dieses Verfahren wird allerdings nur für eine erste Zertifikatsausstellung für eine Domain akzeptiert (sogenanntes „trust on first use“, TOFU – Vertrauen bei erster Benutzung)
- Danach kommt die alternative Validierung über ein bestehendes Zertifikat zum Einsatz
- Bei Verlust der Kontrolle über ein bereits ausgestelltes Zertifikat muss daher ein Zertifikat von einem Drittanbieter erworben werden, um wieder ein Let’s-Encrypt-Zertifikat zu erhalten
Die Validierungsverfahren werden mehrmals über verschiedene Netzwerkpfade durchgeführt
- Zur Erschwerung von DNS-Spoofing ist die Prüfung von DNS-Einträgen von mehreren geographisch verteilten Standpunkten aus vorgesehen
Bei ACME-Interaktionen werden JSON-Dokumente über HTTPS-Verbindungen ausgetauscht
- Das Protokoll wurde im März 2019 von der Internet Engineering Task Force als Request for Comments im Status eines vorgeschlagenen Internetstandards veröffentlicht
Server-Implementierung
Die Zertifizierungsstelle besteht im Wesentlichen aus einer in Go geschriebenen Software namens Boulder, die die Server-Seite des ACME-Protokolls implementiert
- Sie wird als freie Software auch in Quelltextform unter den Bedingungen von Version 2 der Mozilla Public License (MPL) verbreitet
- Sie stellt eine REST-Programmierschnittstelle zur Verfügung, auf die TLS-verschlüsselt zugegriffen werden kann
Für verschiedene Linux-Distributionen existieren Pakete, welche die Cert-Updates automatisch durchführen, so für Debian das package Certbot
Clients
Durch den offenen Standard ACME sind mittlerweile über 40 unterschiedliche Clients entwickelt worden
Im Rahmen des Projekts wurde eine Apache-lizenzierte Nach der Installation und Zustimmung zu einem Benutzervertrag genügt die Ausführung des reinen Befehls, um ein gültiges Zertifikat installiert zu bekommen
- Es können aber auch zusätzliche Funktionen wie OCSP stapling oder HTTP Strict Transport Security (HSTS) eingestellt werden
- Die automatische Einrichtung funktioniert zunächst allerdings nur mit Apache und nginx
- Der Client kann aus den Paketquellen diverser Linux-Distributionen installiert werden, beispielsweise aus den Debian-Paketquellen
Daneben gibt es mit acmetool einen in Go geschriebenen mit vor-kompilierten, statischen Programmdateien Client
- Die Seite Get HTTPS for free! ist ein HTTP/2-kompatibler Webserver, der vollautomatisch ein Zertifikat erzeugt und Inhalte per HTTPS ausliefert
- Ein weiterer weit verbreiteter Client ist acme-tiny, ein in Python geschriebener Client, er ist weniger als 200 Zeilen lang und soll somit von jedem Nutzer vor der Verwendung selbst gelesen werden