SSL-Zertifikate¶

enconf verwaltet SSL-Zertifikate automatisch über Let's Encrypt und unterstützt zusätzlich den Upload eigener Zertifikate.

Übersicht¶

Die SSL-Verwaltung zeigt alle konfigurierten SSL-Zertifikate mit ihrem Status.

Spalte	Beschreibung
Domain	Domain des Zertifikats
Typ	Let's Encrypt oder Custom
Gültig bis	Ablaufdatum
Status	Gültig, Bald ablaufend, Abgelaufen

Let's Encrypt (Automatisch)¶

Zertifikat anfordern¶

Let's Encrypt-Zertifikate werden in den meisten Fällen automatisch beim Erstellen einer Website oder Domain ausgestellt.

Manuelle Anforderung:

Navigieren Sie zur Domain-Verwaltung
Wählen Sie die gewünschte Domain
Klicken Sie auf SSL aktivieren

Voraussetzungen:

Die Domain muss per A- oder AAAA-Record auf den Server zeigen
Port 80 muss für die ACME-HTTP-Challenge erreichbar sein
Die Domain muss öffentlich auflösbar sein

Automatische DNS-Prüfung

Vor der SSL-Aktivierung prüft das Panel automatisch über einen externen DNS-Resolver (Cloudflare 1.1.1.1), ob der A-Record der Domain auf die IP des Servers zeigt. Stimmt die IP nicht überein, wird die Aktivierung mit einer klaren Fehlermeldung abgelehnt. Dies verhindert fehlgeschlagene Let's Encrypt Challenges.

Alle Domains auf einmal absichern¶

Nach einer Migration (der Import überträgt bewusst keine Zertifikate) sind alle Websites zunächst ohne SSL. Über den Button „Alle absichern" auf der SSL-Seite stellt das Panel für jede aktive Website-Domain ohne Zertifikat ein Let's-Encrypt-Zertifikat aus:

Läuft im Hintergrund mit Fortschrittsanzeige und Ergebnis pro Domain
Ergebnis je Domain: ausgestellt · übersprungen (DNS zeigt noch nicht auf diesen Server — später erneut möglich) · fehlgeschlagen
Nutzt dieselbe DNS-Vorprüfung wie die Einzel-Aktivierung, sodass keine Let's-Encrypt-Limits durch Domains verbrannt werden, die noch nicht hierher zeigen

So bringen Sie nach einem Import mit einem Klick alle Domains auf HTTPS, ohne jede einzeln zu aktivieren.

Automatische Verlängerung¶

Der Certbot-Timer prüft regelmäßig alle Zertifikate
Zertifikate werden automatisch 30 Tage vor Ablauf erneuert
Nach der Erneuerung wird Nginx automatisch neu geladen

Let's Encrypt Limits

Let's Encrypt erlaubt maximal 50 Zertifikate pro registrierter Domain pro Woche. Bei vielen Subdomains empfiehlt sich ein Wildcard-Zertifikat.

Fehlerbehebung¶

Problem	Lösung
DNS zeigt nicht auf Server	A/AAAA-Record korrigieren
Port 80 blockiert	Firewall-Regel prüfen
Rate-Limit erreicht	1 Stunde warten, dann erneut versuchen
Domain nicht auflösbar	DNS-Konfiguration prüfen
DNS zeigt auf falsche IP	A-Record auf eine öffentliche IP dieses Servers zeigen lassen — bei einem Server mit mehreren IPs wird jede davon akzeptiert (geprüft über externen DNS 1.1.1.1)

SSL-Reparatur¶

Unter Einstellungen → Reparatur → RepairSSL gleicht das Panel den gewünschten TLS-Zustand aus der Datenbank mit den tatsächlich auf dem Server vorhandenen Zertifikaten ab und heilt Abweichungen.

Was RepairSSL erkennt und behebt:

Fehlendes Zertifikat — eine Domain ist im Panel als SSL-aktiv markiert, aber es liegt kein Zertifikat (mehr) auf der Platte (z. B. nach einem versehentlichen Widerruf) → wird neu ausgestellt.
Abgelaufenes Zertifikat → wird neu ausgestellt.
SAN-Drift — das Zertifikat deckt nicht alle Domains/Aliase der Site ab (z. B. eine nachträglich hinzugefügte www.-Domain) → wird erweitert.
Redundante Alias-Zertifikate — ein Alias hat ein eigenes Zertifikat, obwohl er bereits vom Haupt-Zertifikat der Site abgedeckt ist → wird als Ein-Klick-„Entfernen" angeboten (nie automatisch gelöscht).
Marker und gespeicherte Wahl — ein eigenes Zertifikat wird über eine Markierung neben den Dateien ausgeliefert, die Wahl steht zusätzlich in der Datenbank. RepairSSL gleicht beides ab: Steht „eigenes Zertifikat“ in der Datenbank und fehlt die Markierung, wird sie (nach derselben Prüfung wie bei einer Installation) gesetzt; steht „Let's Encrypt“ und die Markierung ist noch da, wird sie entfernt — aber nur, wenn eine Let's-Encrypt-Linie existiert, an die zurückgegeben werden kann. Sonst wird nur gemeldet.
Entscheidung nötig — Let's-Encrypt-Linie und eigenes Zertifikat liegen vor, ohne dass eine Wahl gespeichert ist → nur gemeldet, nie geändert (siehe oben).

Vorschau zuerst: Der Dry-Run zeigt pro Domain, was passieren würde, ohne etwas auszustellen. Beim Anwenden rendert RepairSSL zuerst den Vhost neu (damit alle Namen im server_name stehen), stellt dann die betroffenen Zertifikate neu aus — und überschreibt dabei einen zuvor gesetzten ACME-Backoff, damit eine Domain, deren Ursache gerade behoben wurde, sofort wieder ausgestellt werden kann.

Nur erreichbare Namen

Namen, die nicht (mehr) per DNS auf den Server zeigen, werden aus der Neuausstellung ausgelassen — so bringt nicht eine einzige fehlende DNS-Angabe die gesamte Zertifikatsanfrage zu Fall.

Selbstheilung beim Start¶

Fehlt ein Zertifikat, auf das ein Nginx-Vhost noch verweist (z. B. nach einem Widerruf), würde nginx -t serverweit fehlschlagen und Nginx nach einem Reboot nicht mehr starten. Der Agent heilt das beim Start automatisch: Der betroffene server-Block wird auf das immer vorhandene Snakeoil-Zertifikat zurückgesetzt, damit Nginx sicher hochkommt — das echte Zertifikat wird anschließend über RepairSSL oder den normalen SSL-Ablauf wiederhergestellt.

Nicht bediente Namen (HTTPS-Catch-all)¶

Fragt ein Besucher einen Namen an, den kein Vhost des Servers bedient (z. B. eine nicht angelegte oder bereits gelöschte Domain, die per DNS noch hierher zeigt), antwortet ein HTTPS-Catch-all mit dem neutralen, selbstsignierten Zertifikat des Betriebssystems und einem 404 — nie mit dem Zertifikat eines Kunden, das sonst den Namen und die Existenz dieses Kunden verraten würde. Der Catch-all deckt seit 2.10.5 auch HTTP/3 (QUIC, UDP 443) ab: Dort galt die Standardvorgabe nur für TCP, sodass nginx auf UDP auf den ersten QUIC-Vhost der Konfiguration zurückfiel und dessen (fremdes) Zertifikat auslieferte. Der Agent schreibt die Variante mit QUIC zuerst und lässt nginx -t entscheiden; ein nginx ohne HTTP/3-Modul behält den reinen TCP-Catch-all.

Domain-Aliase und Subdomains¶

Wenn ein Domain-Alias oder eine Subdomain angelegt wird, geschieht automatisch:

DNS-Zone wird erstellt mit A-Records auf die Server-IP
Domain-Eintrag wird im Panel angelegt (sichtbar in der Domain- und SSL-Verwaltung)
Nginx-Vhost wird aktualisiert — der Alias erscheint im server_name

SSL für Aliase aktivieren¶

Beim Aktivieren von SSL für eine Domain werden automatisch alle Domain-Aliase der zugehörigen Site als SANs (Subject Alternative Names) in das Zertifikat aufgenommen. Das bedeutet:

Ein Zertifikat deckt die Hauptdomain + alle Aliase ab
Alle Domains teilen denselben Nginx server-Block und dasselbe Zertifikat
Bei neuen Aliase wird das Zertifikat automatisch erweitert (certbot --expand)

Sie müssen SSL also nur für die Hauptdomain aktivieren — die Aliase werden automatisch abgedeckt.

Wildcard-Zertifikate zählen als Deckung

Ob ein Zertifikat einen Namen abdeckt, wird einheitlich nach den TLS-Regeln entschieden: Ein Wildcard (*.beispiel.de) deckt genau ein Label (www.beispiel.de, shop.beispiel.de), nicht die Hauptdomain beispiel.de und nicht zwei Label (a.b.beispiel.de). Ein vorhandenes Wildcard-Zertifikat wird deshalb für einen Alias oder Namen darunter gefunden (statt dass dieser das Platzhalter-Zertifikat bekommt), und eine Neuausstellung wird übersprungen, wenn das Wildcard alle Namen schon abdeckt. Die 30-Tage-Grenze der Erneuerung entscheidet weiterhin allein.

DNS muss korrekt sein

Für alle Domains im Zertifikat (Hauptdomain + Aliase) muss der A-Record auf die Server-IP zeigen. Andernfalls schlägt die Let's Encrypt Challenge fehl.

Wildcard-Zertifikate (*.domain.de)¶

Wildcard-Zertifikate decken alle Subdomains einer Domain ab (z. B. *.beispiel.de). Sie werden über die DNS-01-Challenge von Let's Encrypt ausgestellt.

Voraussetzungen¶

Die Domain muss die Nameserver des Panels verwenden, damit der _acme-challenge TXT-Record automatisch gesetzt werden kann
Kunden mit externem DNS können stattdessen Let's Encrypt (HTTP-01) oder ein eigenes Zertifikat nutzen

Wildcard-Zertifikat anfordern¶

Navigieren Sie zu SSL-Zertifikate
Klicken Sie auf SSL aktivieren bei der gewünschten Domain
Wählen Sie Wildcard (*.domain)
Klicken Sie auf Aktivieren

Der Vorgang dauert 1–3 Minuten, da DNS-Propagation abgewartet werden muss.

ACME-DNS Konfiguration¶

Modus	Beschreibung
Automatisch	Verwendet den PowerDNS-Server, der die DNS-Zone im Panel verwaltet
Externer PowerDNS	Verwendet eine externe PowerDNS-Instanz (API-URL + API-Key erforderlich)

Konfiguration unter Einstellungen → Panel-Einstellungen → ACME-DNS:

Einstellung	Beschreibung
DNS-Modus	Automatisch oder Externer PowerDNS
PowerDNS API-URL	URL der externen PowerDNS-API (z. B. `http://ns1.example.com:8081`)
PowerDNS API-Key	API-Schlüssel für die Authentifizierung

Automatische Erneuerung¶

Wildcard-Zertifikate werden wie reguläre Zertifikate automatisch 30 Tage vor Ablauf erneuert — ebenfalls über DNS-01-Challenge.

Externe PowerDNS-Instanzen

Wenn Sie einen externen PowerDNS-Server verwenden, stellen Sie sicher, dass die API-URL vom Panel-Server aus erreichbar ist und der API-Key die Berechtigung hat, TXT-Records in der Zone zu erstellen und zu löschen.

Eigene Zertifikate (Custom SSL)¶

Für Domains, die kein Let's Encrypt verwenden können oder sollen:

Zertifikat installieren¶

Öffnen Sie SSL aktivieren für die Domain und wählen Sie als Zertifikat-Typ Eigenes Zertifikat
Fügen Sie die Inhalte im PEM-Format in die Felder ein:

Feld	Pflicht	Beschreibung
Zertifikat (PEM)	Ja	Das SSL-Zertifikat
Private Key (PEM)	Ja	Der zugehörige private Schlüssel
Intermediate Chain (optional)	Nein	Intermediäre Zertifikate, werden dem Zertifikat angehängt

Klicken Sie auf Aktivieren

Ein eigenes Zertifikat lässt sich nur für die Hauptdomain einer Website (oder eine Domain ohne Website) installieren, nicht für einen einzelnen Alias oder eine Subdomain.

Was vor der Installation geprüft wird¶

Bevor etwas auf den Server geschrieben wird, prüft der Agent:

Zertifikat und Schlüssel sind gültiges PEM (maximal 64 KB je Feld) und gehören zusammen
Der Schlüssel ist stark genug: RSA ab 2048 Bit, bei EC ab 256 Bit (Ed25519 wird ebenfalls akzeptiert)
Das Zertifikat gilt für die Domain — Wildcard-Zertifikate werden dabei richtig behandelt (*.beispiel.de deckt www.beispiel.de, nicht beispiel.de)
Das Zertifikat ist jetzt gültig (nicht abgelaufen, nicht erst in der Zukunft gültig)

Ein Verstoß bricht die Installation mit einer konkreten Meldung ab. Ein passwortgeschützter Schlüssel wird nicht akzeptiert — entfernen Sie die Passphrase vorher.

Alles oder nichts

Die Dateien werden atomar geschrieben (Schlüssel nur für root lesbar), danach wird die Webserver-Konfiguration neu gerendert. Lehnt Nginx die Konfiguration ab, nimmt der Agent die Installation zurück und stellt das bisherige Zertifikat wieder her — Sie sehen die Fehlermeldung, aber keinen halb installierten Zustand. Der private Schlüssel wird weder geloggt noch in der Datenbank gespeichert noch in einer Antwort zurückgegeben.

Zertifikat ersetzen¶

Installieren Sie einfach ein neues Zertifikat für dieselbe Domain — das bisherige wird erst entfernt, wenn das neue erfolgreich ausgeliefert wird.

Ihr eigenes Zertifikat bleibt¶

Ein installiertes eigenes Zertifikat wird nie stillschweigend gegen Let's Encrypt getauscht. Der Agent merkt sich Ihre Wahl und liefert das eigene Zertifikat aus, solange es gültig ist. Konkret lassen diese Abläufe es in Ruhe:

Neuausstellung (löst jeder neue Alias und jede neue Subdomain aus), die automatische Erneuerung, RepairSSL und der Site-Doctor: Sie überspringen die Domain mit dem Grund „eigenes Zertifikat“. Der Doctor bietet bei ablaufendem eigenem Zertifikat keine Reparatur „neu ausstellen“ an — hier hilft nur, ein neues Zertifikat zu installieren.
Let's Encrypt aktivieren ersetzt das eigene Zertifikat nur nach ausdrücklicher Bestätigung im Dialog (der Aufruf verlangt replace_custom=true; ohne Bestätigung antwortet das Panel mit einem Konflikt und ändert nichts).
FTP nutzt ein eigenes Zertifikat nicht — für FTP-TLS wird nie das Kundenzertifikat gewählt.

Fällt das eigene Zertifikat aus (abgelaufen, Schlüsselpaar defekt, Datei ausgetauscht, noch nicht gültig), liefert der Server wieder das Let's-Encrypt-Zertifikat aus, falls eines vorhanden ist, statt Besuchern ein totes Zertifikat zu zeigen. Ohne Let's-Encrypt-Zertifikat bleibt das eigene stehen.

Aliase und Subdomains

Ein eigenes Zertifikat wird nicht erweitert. Legen Sie einen Alias oder eine Subdomain an, deren Name das Zertifikat nicht abdeckt, warnt das Panel: Besucher sehen eine Zertifikatswarnung, bis Sie ein Zertifikat hochladen, das den Namen enthält.

Anzeige und Entscheidung nötig¶

Die Zertifikatsliste zeigt je Name genau das Zertifikat, das ausgeliefert wird — ist ein eigenes aktiv, steht dort dieses und nicht die Let's-Encrypt-Linie dahinter.

Bei Bestandsdomains kann sowohl eine Let's-Encrypt-Linie als auch ein eigenes Zertifikat auf der Platte liegen, ohne dass je eine Wahl gespeichert wurde. Das Panel rät dann nicht: Es ändert nichts, meldet die Domain mit den Ablaufdaten beider Zertifikate im RepairSSL-Bericht als „Entscheidung nötig“ und zeigt auf dem Admin-Dashboard einen Zähler „Entscheidung nötig“. Entscheiden Sie, indem Sie das gewünschte Zertifikat aktivieren (eigenes installieren bzw. Let's Encrypt aktivieren).

Panel-SSL¶

Das SSL-Zertifikat für das Panel selbst wird über Einstellungen > Server konfiguriert:

Optionen¶

Modus	Beschreibung
Let's Encrypt	Automatisches Zertifikat für die Panel-URL
Custom	Eigenes Zertifikat hochladen
Self-Signed	Selbstsigniertes Zertifikat (nur für Tests)

Panel-SSL konfigurieren¶

Navigieren Sie zu Einstellungen > Server
Wählen Sie den Panel SSL-Modus
Bei Custom: Laden Sie Zertifikat und Schlüssel hoch
Klicken Sie auf Speichern

SSL-Validierungsmethode (für nicht öffentlich erreichbare Server)¶

Standardmäßig validiert das Panel-Zertifikat über HTTP-01 — Let's Encrypt muss den Server über Port 80 aus dem Internet erreichen. Für interne oder per Firewall abgeschottete Server, die von außen nicht erreichbar sind, schlägt HTTP-01 zwangsläufig fehl (der „Zertifikat ausstellen"-Button scheint dann nichts zu tun). Für diese Fälle bietet enconf DNS-01-Validierung über einen DNS-Provider an — das Zertifikat wird dann über einen DNS-Eintrag statt über HTTP validiert.

Konfiguration unter Einstellungen → Panel → Panel-SSL-Validierung:

Methode	Beschreibung
HTTP (Standard)	HTTP-01 über Port 80 — Server muss aus dem Internet erreichbar sein
DNS (Cloudflare)	DNS-01 über die Cloudflare-API — nutzt automatisch den Cloudflare-API-Token aus Einstellungen → DNS
DNS (Hetzner)	DNS-01 über die Hetzner-DNS-API — Hetzner-DNS-API-Token eingeben
DNS (RFC2136 / dynamisch)	DNS-01 über dynamische DNS-Updates (TSIG) — funktioniert mit dem enconf-eigenen PowerDNS und jedem BIND/PowerDNS/Knot-Server, der dynamische Updates erlaubt

Für RFC2136 werden zusätzlich die TSIG-Zugangsdaten benötigt:

Feld	Beschreibung
DNS-Server	Hostname oder IP des DNS-Servers, der dynamische Updates annimmt
Port	Standard `53`
TSIG-Schlüsselname	Name des TSIG-Schlüssels (mit abschließendem Punkt, z. B. `acme-key.`)
TSIG-Secret	Base64-kodiertes TSIG-Secret
TSIG-Algorithmus	z. B. `HMAC-SHA256` (auch SHA512/384/224/SHA1/MD5)

Zertifikat ausstellen:

Einstellungen → Panel → Panel-SSL-Validierung — Provider wählen und Zugangsdaten eingeben
Speichern
Auf Panel-Zertifikat jetzt ausstellen klicken

Nur der Ausstellen-Button erzwingt die Erstausstellung

Auf einem internen Server, dessen erster HTTP-Versuch fehlgeschlagen ist, existiert noch keine Erneuerungs-Konfiguration — die reguläre „Erneuern"-Funktion kann daher kein Erst-Zertifikat anlegen. Der Button „Panel-Zertifikat jetzt ausstellen" löst eine frische Ausstellung mit der gewählten Validierungsmethode aus.

Automatische Erneuerung & Sicherheit

Die Zugangsdaten werden in einer nur für root lesbaren Datei gespeichert, sodass certbot renew das Zertifikat später automatisch über dieselbe DNS-Methode erneuert — ohne erneuten manuellen Eingriff. Das für die Validierung benötigte DNS-Plugin (Cloudflare/Hetzner/RFC2136) wird bei Bedarf automatisch installiert. Die HTTP-Validierung für öffentlich erreichbare Server bleibt unverändert der Standard.

Mail-SSL¶

Für die verschlüsselte E-Mail-Kommunikation (IMAP/SMTP):

Navigieren Sie zu Einstellungen > Server
Konfigurieren Sie den Mail SSL-Modus
Optionen wie bei Panel-SSL

Separate Zertifikate

Es wird empfohlen, separate Zertifikate für Panel und Mail-Server zu verwenden, damit der Mail-Hostname (z. B. mail.beispiel.de) korrekt im Zertifikat enthalten ist.

Dedizierter Mail-Server

Auch ein dedizierter Mail-Server (Rolle Mail-Gateway oder Mail-Speicher, ohne Nginx) bekommt ein Let's-Encrypt-Zertifikat für seinen Hostnamen. Certbot gehört dafür zu beiden Mail-Rollen; ohne Nginx läuft die Ausstellung per --standalone. Auf Servern mit Nginx bleibt es bei der Challenge über den Webserver. Bisher blieb der Mail-Hostname dort beim selbstsignierten Zertifikat — genau dem, das Mail-Clients zu sehen bekamen.

Mail-SNI (Server Name Indication)¶

enconf unterstützt Mail-SNI — individuelle TLS-Zertifikate pro Domain für Postfix (SMTP) und Dovecot (IMAP/POP3). Damit können Kunden ihre eigene Domain (z. B. mail.kunde.de) anstelle des zentralen Mail-Hostnamens verwenden, ohne Zertifikatswarnungen zu erhalten.

Funktionsweise¶

Wenn SSL für eine Domain aktiviert wird, werden die Zertifikate automatisch auch für die Mail-Dienste konfiguriert:

SSL aktivieren — Beim Aktivieren von SSL für eine Domain wird das Zertifikat automatisch an Postfix und Dovecot übergeben
SNI-Mapping — Postfix und Dovecot wählen das passende Zertifikat anhand des vom Client angeforderten Hostnamens
Automatische Aktualisierung — Bei Zertifikatserneuerung (Let's Encrypt) werden die Mail-Dienste automatisch aktualisiert

Kompatibilität¶

Mail-SNI funktioniert mit beiden Mail-Architekturen:

Architektur	Beschreibung
Zentral	Mail-Gateway-Server verwaltet alle Zertifikate
Dezentral	Jeder Server verwaltet seine eigenen Mail-Zertifikate

Kein manueller Eingriff nötig

Die SNI-Konfiguration erfolgt vollautomatisch beim Aktivieren von SSL für eine Domain. Es sind keine zusätzlichen Schritte erforderlich.

Zertifikat-Überwachung¶

Das System überwacht automatisch alle SSL-Zertifikate:

30 Tage vor Ablauf: Automatische Erneuerung bei Let's Encrypt
14 Tage vor Ablauf: Benachrichtigung an den Kunden. Für eigene Zertifikate gilt ein eigenes Ereignis (Eigenes SSL-Zertifikat läuft ab, ssl_expiring_custom), dessen Text zum Hochladen eines neuen Zertifikats auffordert — es wird ja nicht automatisch erneuert. Für Let's Encrypt bleibt es beim Ereignis „SSL-Zertifikat läuft ab“. Beide lassen sich unter Benachrichtigungen anpassen.
Abgelaufen: Warnung im Dashboard und auf der Systemseite

TLS-Health bewertet das ausgelieferte Zertifikat¶

Der TLS-Health-Bericht verbindet sich mit den Diensten (HTTPS, SMTPS, IMAPS, Panel) und bewertet das Zertifikat, das tatsächlich ausgeliefert wird — nicht nur den Eintrag im Zertifikatsregister. Das ist wichtig, weil z. B. Postfix nach einer Erneuerung noch das alte Zertifikat ausliefern kann, während das Register schon das neue zeigt. Ein abgelaufenes ausgeliefertes Zertifikat erscheint jetzt auch bei SMTPS und IMAPS als abgelaufen; der Ablauf wird vor dem Namen geprüft. Der Namensvergleich versteht Wildcard-Zertifikate, ein Wildcard auf www.beispiel.de ist also kein Fehlalarm mehr.