Dieser Beitrag ist als Antwort auf die Frage „Wozu braucht man eigentlich ein teures TLS-Zertifikat, wenn es mit Let’s Encrypt doch kostenlos geht?” entstanden. Da ich das Zertifikat für diese Seite erst letzte Woche einem externen Zertifikatsdienst zu Let’s Encrypt gewechselt habe, versuche ich, diese Frage vernünftig zu beantworten.
Was ist Let’s Encrypt?
Let’s Encrypt ist eine gemeinnützige Zertifizierungsstelle (CA – Certificate Authority), die im Jahre 2014 von der Internet Security Research Group (ISRG) gegründet wurde. Let’s Encrypt gibt jedem Webseitenbetreiber / Domaininhaber die Möglichkeit, ein kostenloses TLS-Zertifikat vollautomatisch zu erhalten.
Wie funktioniert die Ausstellung technisch?
Der Ablauf lässt sich grob in wenigen Schritten erklären.
Das wichtigste Element des Systems ist das sogenannte ACME-Protokoll (Automatic Certificate Management Environment). Das ACME-Protokoll funktioniert nicht allein, sondern benötigt einen ACME-Client. Dies kann beispielsweise Certbot oder acme.sh sein.
1. Im ersten Schritt findet eine „Kontaktaufnahme“ statt. Der ACME-Client registriert (Account-Registrierung) sich bei der Let’s Encrypt API mit einem zuvor erstellten kryptografischen Schlüsselpaar (also einem privaten und einem öffentlichen Schlüssel). Der private Schlüssel bleibt auf unserem Server, während der öffentliche Schlüssel bei der Account-Registrierung an Let’s Encrypt übermittelt wird. Dieser wird bei Let’s Encrypt gespeichert, damit unsere Anfragen verifiziert werden können.
2. Der nächste Schritt ist eine sogenannte Challenge, mit der der „Besitznachweis der Webserver“ der Domain durchgeführt wird. Am häufigsten wird die HTTP-01-Challenge. Dabei muss der Server eine bestimmte Datei unter einer genau definierten URL bereitstellen. Die Datei wird vom ACME-Client auf unserem Server erzeugt. Let’s Encrypt ruft diese URL auf und prüft, ob der erwartete Inhalt dabei ist.
Als Alternative zur HTTP-01-Challenge gibt es die DNS-01-Challenge. Dabei wird ein spezieller TXT-Eintrag in der DNS-Zone der Domain gesetzt. Anschließend überprüft Let’s Encrypt, ob dieser Eintrag korrekt vorhanden ist.
Diese Methode ist zwingend erforderlich, wenn Wildcard-Zertifikate, beispielsweise für *.kreyman.de, ausgestellt werden sollen. Da eine Wildcard alle Subdomains abdeckt, muss der Besitz der gesamten DNS-Zone nachgewiesen werden.
3. Wenn die Challenge erfolgreich bestanden wurde, erstellt der ACME-Client einen Certificate Signing Request (CSR), der die den öffentlichen Schlüssel sowie die gewünschten Subject Alternative Names (SAN) enthält. Dieser CSR wird an Let’s Encrypt übermittelt. Let’s Encrypt signiert den enthaltenen öffentlichen Schlüssel mit seinem CA-Schlüssel und stellt das fertige Zertifikat (X.509) aus. Anschließend installiert der ACME-Client das Zertifikat automatisch auf dem Server.
4. Erneuerung: Aktuell sind Let’s Encrypt-Zertifikate 90 Tage gültig. Der ACME-Client wird in der Regel täglich automatisch ausgeführt (z. B. per Cronjob). Dabei prüft er, ob das Zertifikat innerhalb der nächsten 30 Tage abläuft (dies ist der Standardwert vieler ACME-Clients). Wenn dies der Fall ist, initiiert er eine Neuausstellung.
Validierungsstufen
Genau hier liegt der Kern der ganzen Diskussion. Es gibt drei Stufen der Zertifikatsvalidierung.
Domain Validation (DV)
Bei einem DV-Zertifikat wird lediglich geprüft, ob der Antragsteller die technische Kontrolle über die betreffende Domain besitzt. Eine Überprüfung der dahinterstehenden Person oder Organisation findet hingegen nicht statt. Wer sich dahinter verbirgt, ob eine Firma bzw. Organisation existiert und ob der Seitenbetreiber vertrauenswürdig ist, ist für die CA nicht relevant.
Im Zertifikat sind lediglich die Domainnamen (CN, Subject Alternative Names) enthalten. Angaben zur Organisation, zum Land oder zur Adresse werden bei DV-Zertifikaten nicht aufgenommen. Wichtig, dass dieser Umstand nicht nur für Let’s Encrypt gilt, sondern für alle DV-Zertifikate, unabhängig davon, ob sie kostenlos oder kostenpflichtig ausgestellt werden.
Extended Validation (EV)
Bei einem EV-Zertifikat wird die antragstellende Organisation in einem umfassenden manuellen Verfahren geprüft. Dabei werden unter anderem die rechtliche Existenz des Unternehmens und die Vertretungsberechtigung der antragstellenden Person überprüft.
Organization Validation (OV)
Bei einem OV-Zertifikat prüft die Zertifizierungsstelle zusätzlich, ob das antragstellende Unternehmen real existiert und rechtlich registriert ist. Dies erfolgt beispielsweise durch Handelsregisterabgleich, Telefonverifizierung und weitere Dokumentationsnachweise. Im Zertifikat sind der Firmenname, das Land sowie weitere Organisationsangaben hinterlegt. z.B. www.bundesregierung.de oder www.nato.int
Das eigentliche Sicherheitsproblem: Phishing
Das häufigste Sicherheitsrisiko im Zusammenhang mit DV-Zertifikaten ist nicht die Verschlüsselung selbst, sondern Phishing. So kann ein typisches Szenario aussehen: Ein Angreifer registriert eine täuschend ähnliche Domain. Statt www.deinlieblingsshop.de könnte das www.deinlieblingsshop.info sein.
Der Angreifer kopiert das Erscheinungsbild der Originalseite und beantragt für seine Domain ein Let’s Encrypt-Zertifikat. Der Browser zeigt somit das bekannte Schloss-Symbol an. Dadurch könnte ein unachtsamer Besucher glauben, sich auf der echten Website zu befinden.
Homograph-Angriffe (IDN-Angriffe)
Glücklicherweise gehören die erfolgreichsten Zeiten dieser Angriffsmethode weitgehend der Vergangenheit an. Hier wird eine Domain registriert, die optisch identisch aussieht, technisch jedoch andere Zeichen verwendet. Beispiel:
- www.kreyman.de
- www.kreymаn.de
Auf den ersten Blick sehen beide Adressen gleich aus. In der zweiten Variante wird kein lateinisches „a“, sondern ein kyrillisches „а“ verwendet. Solche Domainnamen können registriert und mit einem Zertifikat versehen werden. Im modernen Browser erscheint die manipulierte Adresse dann beispielsweise als (Punycode): www.xn--kreymn-7nf.de
Braucht z.B. kreyman.de ein bezahltes Zertifikat?
Ein klares Nein, und zwar aus folgenden konkreten Gründen:
Wenn ein Besucher kreyman.de öffnet, liest er einen Artikel zu einem IT-Thema und verlässt die Seite wieder. Das war es. Es werden keine Passwörter eingegeben, keine Kreditkartendaten übertragen und keine persönlichen Informationen gespeichert. Der einzige Datenstrom seitens des Providers ist der Blogbeitrag, der im Browser dargestellt wird.
Und was macht ein Zertifikat dabei?
Ein Zertifikat verschlüsselt die Verbindung zwischen Browser und Webserver. Damit kann niemand mitlesen, welchen Artikel gerade gelesen wird. Das ist bei einem öffentlichen Blog zwar nett, aber nicht kritisch. Es gibt schlicht nichts Wertvolles zu stehlen.
Was würde ein bezahltes DV-Zertifikat zusätzlich bringen?
Nichts, was die Seitenbesucher jemals bemerken würden. Das Schloss-Symbol im Browser sieht identisch aus. Im Zertifikat stünde nur „kreyman.de”, kein Organisationsname, keine Adresse, kein Unterschied zu einem kostenlosen Let’s-Encrypt-Zertifikat.
Wann würde sich ein teureres Zertifikat wirklich lohnen?
In der Theorie nur, wenn eine Seite einen Mitgliederbereich mit Login, einen Shop oder ein Kontaktformular mit sensiblen Daten hat. Dann wäre zumindest ein EV-Zertifikat eine Überlegung wert.
Wenn Sie meinen, dass kommerzielle Seiten standardmäßig ein teures EV-Zertifikat verwenden, dann irren Sie sich. Auch große Unternehmen (z. B. Zalando) sind in den letzten Jahren zu Let’s Encrypt gewechselt, da die Verschlüsselungsqualität technisch absolut identisch ist. Die Browser haben den EV-Grünbalken abgeschafft, sodass kein Unterschied mehr sichtbar ist.
Auch die offiziellen Seiten fühlen sich nicht mehr verpflichtet, OV-Zertifikate zu verwenden. (z. B. www.whitehouse.gov nutzt Let’s Encrypt.)
Was bedeutet „Garantie“?
Die sogenannte Garantie oder Warranty ist vermutlich das am häufigsten missverstandene Thema bei SSL-Zertifikaten. Sechsstellige Beträge wie „1 000 000 SSL Certificate Warranty“ suggerieren vielen ein Versprechen wie dieses: „Wenn meine Website gehackt wird und meine Kunden dadurch Geld verlieren, zahlt die Zertifizierungsstelle den Schaden.“ Das ist jedoch nicht der Fall: Warranty ist keine Cyberversicherung.
3. Warranty „Sectigo warrants to you that Sectigo has exercised reasonable care in following the validation process…“
Quelle: Sectigo Relying Party Agreement
Eine solche Garantie greift ausschließlich, wenn die Zertifizierungsstelle bei der Ausstellung des Zertifikats grob fahrlässig gehandelt hat, beispielsweise indem sie einem Unternehmen ein Zertifikat ausgestellt hat, das die erforderliche Identitätsprüfung eigentlich nicht bestanden hätte oder gar nicht erst hätte bestehen dürfen.
Gegen die alltäglichen Bedrohungen im Internet, wie etwa Server-Hacks, Datenlecks, Phishing oder Fehlkonfigurationen, ist diese Garantie faktisch bedeutungslos.
Reduzierung der Laufzeit von TLS-Zertifikaten
Bevor wir zum Thema „Reduzierung der Gültigkeitszeiten von TLS-Zertifikaten“ übergehen, lohnt es sich, einen Blick auf die Herkunft solcher Entscheidungen zu werfen.
Viele grundlegende Regeln, die öffentlich vertrauenswürdige Zertifikate betreffen, etwa maximale Laufzeiten oder verpflichtende Inhalte, werden im CA/Browser-Forum definiert.
Das CA/B-Forum ist ein freiwilliger Zusammenschluss mehrerer Interessengruppen. Die zwei zentralen Gruppen sind:
- Certificate Authorities (CAs) – darunter DigiCert, Sectigo, Let’s Encrypt, Entrust und andere Zertifizierungsstellen.
- Certificate Consumers. Das sind vor allem Browser-Hersteller. Dazu gehören Google (Chrome), Mozilla (Firefox), Apple (Safari), Microsoft (Edge) und andere.
De facto liegt die entscheidende Durchsetzungsmacht jedoch bei den Browserherstellern. Sie legen fest, welche CAs in ihren Trust Stores enthalten sind und unter welchen Bedingungen deren Zertifikate akzeptiert werden.
Selbst wenn eine Regel im CA/B-Forum beschlossen wird, kann ein Browseranbieter strengere Vorgaben durchsetzen. So hat beispielsweise Apple einseitig entschieden, dass Safari ab dem 1. September 2020 keine Zertifikate mehr akzeptieren wird, die länger als 398 Tage (13 Monate Laufzeit) gültig sind.
47-Tage-Zertifikate
Im März 2025 hat das CA/Browser-Forum einen Beschluss gefasst, der wahrscheinlich viele überrascht hat. Auf Initiative von Apple wurde beschlossen, die maximale Gültigkeitsdauer öffentlich vertrauenswürdiger TLS-Zertifikate schrittweise von aktuell 398 Tagen auf 47 Tage zu verringern. Die verkürzte Zertifikatslaufzeit ist jedoch nur ein Teil der Änderung. Gleichzeitig wurde auch die sogenannte „Data Reuse Period” deutlich reduziert.
Offizielle Entscheidung: Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods
Die maximale Gültigkeitsdauer eines TLS-Zertifikats
| Datum | Gültigkeitsdauer | |
| 1. September 2020 | 398 Tage | |
| 15. März 2026 | 200 Tage | |
| 15. März 2027 | 100 Tage | |
| 15. März 2029 | 47 Tage | |
Die „Data Reuse Period“ definiert den Zeitraum, in dem eine Zertifizierungsstelle bereits durchgeführte Domain-Validierungen wiederverwenden darf. Nach Ablauf dieses Zeitraums muss die CA die Domain erneut prüfen, bevor sie ein weiteres Zertifikat ausstellen darf.
Die maximale Nutzungsdauer von Domainvalidierung-Informationen
| Zertifikat ausgestellt am oder nach | Maximum data reuse period | |
| 15. März 2026 | 200 Tage | |
| 15. März 2027 | 100 Tage | |
| 15. März 2029 | 10 Tage | |
Fazit
Aufgrund der bewerteten Informationen würde ich vorsichtig behaupten, dass die Let’s-Encrypt-Zertifikate die technischen Anforderungen in den meisten Fällen vollständig abdecken, sodass die teuren Zertifikate kaum notwendig sind.
Angesichts der kommenden Reduzierung der Zertifikatslaufzeiten auf 47 Tage wäre die Verwendung eines Let’s-Encrypt-ähnlichen Verfahrens nicht nur sinnvoll, sondern notwendig. Die manuelle Verwaltung von Zertifikaten wird zunehmend unrealistisch.
Die regulatorischen Anforderungen erzwingen die Erstellung von Zertifikaten in einem stark automatisierten, API-basierten und ACME-kompatiblen Prozess.