Zertifikate im eigenen Netz: ACME, Let's Encrypt und eine eigene CA

Wer im Homelab oder im kleinen Firmennetz mehr als zwei oder drei Dienste betreibt, landet irgendwann bei derselben Frage: Wie bekommt jede Weboberfläche ein gültiges HTTPS-Zertifikat, ohne dass die Verwaltung zur Daueraufgabe wird? Dieser Artikel ordnet die Begriffe, beschreibt den Standardablauf von ACME, vergleicht drei Werkzeuge und zeigt die typischen Fehler in der Praxis.

Wofuer TLS ueberhaupt

TLS verschluesselt die Verbindung zwischen Browser und Dienst und stellt sicher, dass die Antworten unverändert beim Empfänger ankommen. Fehlt es, passiert im LAN genau das Gleiche wie im offenen Internet, nur mit kürzerer Wegstrecke:

• Mitlauschen: Ohne Verschlüsselung liest jedes Gerät im selben Netz die Zugangsdaten im Klartext mit. Ein ungeswitchtes WLAN oder ein kompromittierter Switch genügen.
• Veränderte Antworten: Ein Angreifer oder ein fehlgeleitetes Proxy kann Inhalte und Antworten unterwegs abändern, ohne dass es auffällt.
• Browser-Warnungen: Chromium und Firefox zeigen bei fehlendem oder falschem Zertifikat eine Vollbild-Warnung. Nutzer klicken sie weg oder brechen ab — beides kostet Vertrauen.
• Nicht erreichbare WebSchnittstellen: Viele moderne Dienste erzwingen HTTPS und schalten sonst ihre Weboberfläche oder ihre API gar nicht frei. Ohne Zertifikat bleibt der Zugriff dauerhaft gestört.

Kurz: TLS ist heute keine Kür, sondern die Grundvoraussetzung dafür, dass Dienste überhaupt nutzbar sind.

Oeffentliche CA gegen eigene CA

Bei einer öffentlichen CA wie Let's Encrypt prüft eine anerkannte Stelle die Domain und stellt ein Zertifikat aus. Der Vorteil: Das Zertifikat gilt auf jedem Endgerät sofort, weil die Root-Zertifikate bereits im Betriebssystem und in jedem Browser ausgeliefert werden.

Bei einer eigenen CA betreibst du die Vertrauenswurzel selbst. Das Problem verschiebt sich damit vom Ausstellen zum Verteilen: Jedes Endgerät muss die Root der eigenen CA importiert haben, sonst bleibt die Warnung. Das gelingt bei fünf verwalteten Rechnern mit einem Skript, ist bei fremden Gästen aber mühsam.

| Kriterium | Oeffentliche CA | Eigene CA |

|---|---|---|

| Vertrauensverwaltung | auf jedem Gerät bereits vorhanden | Root muss auf jedes Gerät importiert werden |

| Einrichtungsaufwand | gering, ACME automatisiert | hoch: CA aufsetzen, Root verteilen, ggf. CRL betreiben |

| Verteilung | keine | pro Gerät, per Skript oder MDM |

| Wildcard | möglich, meist per DNS-01 | beliebig viele Namen frei wählbar |

| Geeignet ab | Internet-Dienste, fremde Besucher | viele interne Namen, Offline-Netze, keine oeffentliche Domain |

Eine eigene CA ist die richtige Wahl, sobald die Dienste nur nach innen zeigen, ein öffentlicher Name fehlt oder das Netz nicht dauerhaft am Internet haengt. Fuer Dienste, die von aussen erreichbar sein muessen, bleibt die oeffentliche CA der einfachere Weg.

Der ACME-Ablauf in drei Schritten

ACME automatisiert die Ausstellung in drei Schritten. Danach uebernimmt ein Renewal-Hook das Ausrollen des erneuerten Zertifikats.

  (1) Schluesselpaar          (2) Challenge               (3) Ausstellung
  +--------------+            +-------------+             +---------------+
  | Account-Key  |  ------->  | HTTP-01     |  ------->   | CA prueft die |
  | Domain-Key   |            | DNS-01      |             | Challenge und |
  | (privat)     |            | TLS-ALPN-01 |             | signiert das  |
  +--------------+            +-------------+             | Zertifikat    |
                                                          +-------+-------+
                                                                  |
                                                                  v
                                                        +-------------------+
                                                        | Renewal-Hook      |
                                                        | Dienst neu laden  |
                                                        +-------------------+

1. Schluesselpaar: Der Client erzeugt einen Account-Schluessel und ein Domain-Schluesselpaar. Der private Schluessel bleibt lokal.

2. Challenge: Der Client meldet der CA einen Nachweis, dass er die Domain kontrolliert — als Datei auf Port 80, als DNS-Eintrag oder ueber ein Sonderzertifikat.

3. Ausstellung: Die CA prueft den Nachweis, signiert das Zertifikat und liefert es aus. Der Renewal-Hook schiebt das Ergebnis an den Webserver und laedt den Dienst neu.

Die Challenge-Typen

| Typ | Voraussetzung | Port | Hinterlegung bei 80/443 | Wann noetig |

|---|---|---|---|---|

| HTTP-01 | Webserver auf Port 80 erreichbar | 80 | Datei unter /.well-known/acme-challenge/ | Einzeldomin(s) mit offenem Port 80 |

| DNS-01 | Kontrolle ueber DNS | kein Port noetig | TXT-Eintrag _acme-challenge | Wildcard, Port 80 gesperrt, viele IPs |

| TLS-ALPN-01 | Nur-Port-443-Betrieb | 443 | TLS-Sonderzertifikat waehrend der Pruefung | Wenn nur 443 erreichbar ist |

DNS-01 ist der einzige Typ, mit dem sich Wildcard-Zertifikate ausstellen lassen. Ist Port 80 gesperrt, scheidet HTTP-01 aus. Betreibt eine Domain viele IP-Adressen hinter einem Loadbalancer, ist DNS-01 ebenfalls der robusteste Weg.

Toolvergleich: Certbot, acme.sh und Caddy

| Tool | Renew-Mechanismus | Konfigurationsaufwand | Timer oder Haken |

|---|---|---|---|

| Certbot | eigener Timer (systemd) oder Cron | mittel, pro Dienst Konfig anpassen | Renew-Run per systemd-Timer |

| acme.sh | eigener Cron-Eintrag | gering, Shell-Skript | Cron-Eintrag |

| Caddy | im Server eingebaut | sehr gering, Zertifikat in der Config | automatische Erneuerung, Haken im Server |

Certbot und acme.sh loesen die Erneuerung ueber einen externen Zeitplan, meist als systemd-Timer oder Cron. Caddy bringt ACME in den Webserver ein und erneuert im Hintergrund.

Wichtig ist ein Punkt, der leicht uebersehen wird: Der Haken laeuft nach der Erneuerung und muss den Dienst neu laden. Schlaegt der Reload fehl — etwa weil der Dienst anders heisst oder die Berechtigung fehlt — liegt das neue Zertifikat auf der Platte, der Dienst liefert aber weiter das alte aus. Nach spaetestens 90 Tagen steht der Nutzer vor einer Ablaufwarnung.

Betrieb: Fristen, Renew-Fenster und Monitoring

Let's Encrypt stellt Zertifikate mit 90 Tagen Laufzeit aus. Empfohlen wird die Erneuerung bei 30 Tagen Restlaufzeit. Der Rechenweg: 90 − 30 = 60 Tage Nutzung, 30 Tage Puffer als Ausfallreserve. Bleibt die Erneuerung einmal aus, kann sie noch im Fenster nachgeholt werden.

Monitoring sollte das Ablaufdatum als Warnschwelle kennen, nicht nur den Port. Eine sinnvolle Staffelung:

• Warnung bei weniger als 21 Tagen Restlaufzeit.
• Kritisch bei weniger als 7 Tagen.
• Alarm, wenn der Renewal-Dienst seit ueber 24 Stunden nicht erfolgreich war.

Faellt der Renewal-Dienst aus, laeuft das vorhandene Zertifikat weiter, bis es ablaeuft. Danach liefern alle abhaengigen Dienste eine Browser-Warnung aus. Eine Alarmierung auf den Dienst selbst ist deshalb genauso wichtig wie die Warnung auf das Ablaufdatum.

Stolperfallen mit Loesung

• Fehlendes Intermediate in der Kette: Der Browser meldet ein unvollstaendiges Zertifikat. Loesung: die vollstaendige Kette (fullchain) ausliefern, nicht nur das Leaf-Zertifikat.
• Falsche Reihenfolge der Kette: Das Intermediate muss direkt hinter dem Leaf stehen. Loesung: Reihenfolge Leaf, Intermediate, Root einhalten.
• Falsch gesetzte SAN-Namen ohne Wildcard: Ein Name fehlt im SAN, die Verbindung bricht. Loesung: jeden benoetigten Namen explizit ins SAN schreiben oder auf Wildcard umstellen.
• Domain-Umbrella mit Intermediate ohne Root: Der Client findet die Wurzel nicht. Loesung: die Kette bis zur vertrauten Root vervollstaendigen.
• CRL gegen OCSP: Manche Clients, etwa schannel unter Windows, erzwingen eine Sperrpruefung per CRL. Loesung: eine CRL bereitstellen, wenn OCSP nicht genuegt.
• Falsche Schreibweise der SAN: DNS:*.intern.example.de und intern.example.de sind verschiedene Eintraege. Loesung: Wildcard und Apex jeweils als eigenen SAN-Eintrag fuehren.

Praxisbeispiel fuer ein Homelab mit rund 10 internen Diensten

Ein Homelab betreibt zehn Dienste unter einer Wildcard-Domain. Die oeffentlich erreichbaren Dienste laufen mit einem Let's-Encrypt-Wildcard ueber DNS-01, die rein internen ueber die eigene CA.

                 Internet
                    |
              +-----v------+
              |  Reverse-  |
              |  Proxy     |  <-- Let's Encrypt Wildcard (*.example.de)
              +--+------+--+
                 |      |
     +-----------+      +-------------+
     |                                |
+----v----+   +----------------+   +--v---------+
| oeffentl.|   | interne       |   | interne    |
| Dienste  |   | Dienste       |   | Dienste    |
| (LE-Cert)|   | (eigene CA)   |   | (eigene CA)|
+---------+   +----------------+   +------------+
  Wiki          NAS               Monitoring
  Cloud         Router            Passwort-Tresor
  Mail          Backup            Git

Mit oeffentlichem Zertifikat laufen Dienste, die auch von aussen oder von Familienmitgliedern genutzt werden. Ueber die interne CA laufen reine Verwaltungsdienste. Als Ausnahme werden Endgeraete, die keine eigene Root importieren koennen — etwa ein Fernseher oder ein Drucker — entweder mit einem oeffentlichen Zertifikat versorgt oder bewusst ueber HTTP im getrennten VLAN betrieben.

Fazit

Die Wahl haengt am Profil, nicht an der Technik:

• Privat: Eine oeffentliche CA (Let's Encrypt) mit HTTP-01 oder DNS-01 deckt fast alles ab. Der Aufwand bleibt minimal.
• Familie: Wildcard ueber DNS-01 fuer die gemeinsam genutzten Dienste, ergaenzt um eine kleine interne CA fuer reine Verwaltungsdienste.
• Kleine Firma: Eine eigene CA mit sauber verteilter Root lohnt sich, sobald viele interne Namen und mehrere Endgeraete verwaltet werden. Fuer nach aussen sichtbare Dienste bleibt die oeffentliche CA erste Wahl.

In allen Faellen gehoert Monitoring mit Alarmierung auf Ablaufdatum und Renewal-Dienst dazu. Ohne das ist jede Automatisierung nur eine Frage der Zeit bis zur naechsten abgelaufenen Kette.

FAQ

Wie lange laufen Let's-Encrypt-Zertifikate?

Seit 2024 mit 90 Tagen Laufzeit. Die Erneuerung ist bei 30 Tagen Restlaufzeit vorgesehen, also nach 60 Tagen Nutzung.

Wann brauche ich zwingend DNS-01?

Immer dann, wenn ein Wildcard-Zertifikat benoetigt wird, Port 80 gesperrt ist oder eine Domain viele IP-Adressen umfasst.

Kann ich eine eigene CA fuer oeffentlich erreichbare Dienste nutzen?

Technisch ja, praktisch nein: Fremde Browser vertrauen der eigenen Root nicht. Fuer Dienste mit externen Besuchern ist eine oeffentliche CA noetig.

Warum liefert mein Dienst trotz Erneuerung ein altes Zertifikat aus?

Weil der Renewal-Hook zwar das Zertifikat ersetzt, den Dienst aber nicht neu geladen hat. Der Dienst muss nach der Erneuerung neu gestartet oder neu geladen werden.

Was passiert, wenn der Renewal-Dienst ausfaellt?

Das vorhandene Zertifikat laeuft bis zum Ablaufdatum weiter. Danach zeigen alle abhaengigen Dienste eine Browser-Warnung. Deshalb ist eine Alarmierung auf den Dienst genauso wichtig wie auf das Ablaufdatum.

Interne Verlinkungen

• caddy-reverse-proxy-https — Ankertext: "Reverse Proxy mit automatischem HTTPS einrichten"
• sso-selbst-gehostet — Ankertext: "Single Sign-on im eigenen Netz betreiben"
• monitoring-ohne-cloud — Ankertext: "Monitoring ohne Cloud-Anbindung aufbauen"
• fernzugriff-heimserver-tailscale-wireguard — Ankertext: "Sicherer Fernzugriff per Tailscale oder WireGuard"

Hinweis: Dieser Artikel ist redaktioneller Inhalt und enthält keine Affiliate- oder Partner-Links. Alle Angaben entsprechen dem Stand 2026 und können sich ändern.