KeyHelp: SSL-Zertifikate mit Let's Encrypt und eigener CA einrichten und überwachen

Ein abgelaufenes Zertifikat legt nicht nur die Webseite lahm: Mailprogramme verweigern IMAP und SMTP, FTP-Clients brechen ab, und das Panel zeigt eine Browserwarnung. KeyHelp nimmt Ihnen vieles ab, Let's Encrypt für Domains und Serverdienste ist eingebaut und erneuert sich selbst. Trotzdem gibt es drei Stellen, an denen Zertifikate in KeyHelp verwaltet werden, und eine Warnfunktion, die ab Werk ins Leere laufen kann. Diese Anleitung richtet sich an Administratoren kleiner Hosting-Server, Agenturen und KMU, die KeyHelp nach unserer Anleitung KeyHelp installieren und absichern betreiben. Sie zeigt Let's Encrypt, eigene Zertifikate einer Zertifizierungsstelle, die Absicherung der Serverdienste und die Überwachung, mit den echten Bezeichnungen der Oberfläche von KeyHelp 26.1.

Voraussetzungen

• KeyHelp mit Admin-Zugang, getestet mit 26.1.1 (Build 3698) auf Debian 12.
• Für Let's Encrypt: Die Domain muss im öffentlichen DNS auf die Server-IP zeigen und Port 80 muss von außen erreichbar sein (KeyHelp legt die Prüfdatei unter /.well-known/acme-challenge/ ab und ruft sie per HTTP auf). Für die Serverdienste muss laut KeyHelp-Wissensdatenbank der Hostname des Servers auf die Server-IP auflösen.
• Für eigene Zertifikate: Zertifikat, privater Schlüssel und das Zwischenzertifikat (CA-Zertifikat) Ihrer Zertifizierungsstelle im PEM-Format.
• Root per SSH für die Prüfbefehle mit openssl und curl.

Schritt 1: Die drei Orte für Zertifikate kennen

KeyHelp verteilt die Zertifikatsverwaltung auf drei Seiten:

Ort in KeyHelp	Wozu
„Domains“ → Domain bearbeiten → Reiter „Sicherheit“	Zertifikat einer Domain wählen: „Kein Zertifikat“, „Let's-Encrypt-Zertifikat“ oder „Zertifikat auswählen“, dazu HTTPS-Weiterleitung und HSTS
„SSL/TLS-Zertifikate“ im Hauptmenü	Eigene Zertifikate anlegen und Serverdienste absichern
„Konfiguration“ → „SSL/TLS-Zertifikate“	Benachrichtigungen, Vorwarnzeit, Let's-Encrypt-Umgebung

Wichtig: Let's-Encrypt-Zertifikate tauchen in der Übersicht „SSL/TLS-Zertifikate“ nicht auf. Die Seite sagt das selbst: „Zertifikate der Let's-Encrypt-Zertifizierungsstelle […] werden in dieser Übersicht nicht aufgeführt.“ Nach der Installation steht dort nur das selbstsignierte Zertifikat „default“ für den Hostnamen, im Test zehn Jahre gültig.

Verifizieren: Das Zertifikat, das ein Dienst gerade ausliefert, zeigt openssl. Direkt nach der Installation im Test:

echo | openssl s_client -connect 127.0.0.1:443 -servername IHR-HOSTNAME 2>/dev/null | openssl x509 -noout -issuer -enddate

issuer=C = DE, ST = Thuringia, L = Erfurt, O = KeyHelp, OU = KeyHelp Control Panel, CN = kh.example.com, ...
notAfter=Sep 28 07:43:30 2036 GMT

Schritt 2: Let's Encrypt für eine Domain aktivieren

Öffnen Sie „Domains“, bearbeiten Sie die Domain und wählen Sie im Reiter „Sicherheit“ unter „SSL/TLS Zertifikat“ die Option „Let's-Encrypt-Zertifikat“. KeyHelp beschreibt sie so: „Administrative Aufgaben, wie die Beantragung oder Erneuerung eines Zertifikats, sind durch das Control Panel vollständig automatisiert.“ Lassen Sie „Sichere Verbindung erzwingen“ aktiviert; dann leitet der Server HTTP mit Code 301 auf HTTPS um. Für mehrere Subdomains hilft „Sicherheitseinstellungen auf alle Subdomains übertragen“, eine einmalige Operation.

KeyHelp prüft vor der Anfrage bei Let's Encrypt, ob die Domain lokal auflösbar ist (Option „Lokale Prüfungen der Domain-Namen-Auflösung durchführen“ unter „Konfiguration“ → „SSL/TLS-Zertifikate“, ab Werk an). Das schützt vor den Ratenbegrenzungen von Let's Encrypt bei vielen Fehlversuchen.

In unserer Testumgebung ohne öffentliche Domain ließ sich die Ausstellung nicht durchführen; das Protokoll zeigt aber genau, wie KeyHelp vorgeht und woran es scheitert:

INFO | Apache: request lets encrypt cert
INFO | Using certificate authority: "https://acme-v02.api.letsencrypt.org/" (PRODUCTION).
INFO | Token stored at: /home/keyhelp/www/.well-known/acme-challenge/local-check-...
INFO | Curl: Could not resolve host: www.testkunde.example (...)
ERROR | Apache: a Let's Encrypt error occurred: Local resolving checks failed for domain "www.testkunde.example". Please ensure that your domain is locally resolvable!

Solange kein Zertifikat da ist, leitet der HTTPS-vHost der Domain mit Code 302 auf HTTP zurück.

Verifizieren: Nach erfolgreicher Ausstellung liefert die Domain ein Zertifikat von Let's Encrypt:

grep -i "lets encrypt" /var/log/keyhelp/cronjob/master.log | tail -5
echo | openssl s_client -connect IHRE-DOMAIN:443 -servername IHRE-DOMAIN 2>/dev/null | openssl x509 -noout -issuer -enddate

Schritt 3: Ein eigenes Zertifikat anlegen

Für Zertifikate einer kommerziellen Zertifizierungsstelle (etwa mit Organisationsprüfung) öffnen Sie „SSL/TLS-Zertifikate“ → „SSL/TLS-Zertifikat hinzufügen“. Neben „Zertifikatsname“ und „Besitzer“ (System oder ein Kunde) wählen Sie unter „Aktion wählen“ eine von drei Möglichkeiten:

• „Generiere CSR“: KeyHelp erzeugt Schlüssel (2048 oder 4096 Bit) und Zertifikatsanforderung aus Land, Bundesland, Stadt, Organisation, Domain, „Alternative Domainnamen“ und E-Mail. Laut Formular sollten Sie dabei Sonderzeichen und Umlaute vermeiden.
• „Generiere selbstsigniertes Zertifikat“ mit wählbarem Gültigkeitszeitraum, nur für interne Zwecke.
• „Ein vorhandenes Zertifikat hochladen“: privater Schlüssel, Zertifikat und „CA-Zertifikat“ als Text oder Datei.

Den CSR-Weg haben wir vollständig durchgespielt: KeyHelp meldete „Die Zertifikatsanforderung (CSR) wurde erfolgreich erstellt. Um ein gültiges Zertifikat zu erhalten, reichen Sie dieses CSR bei einer Zertifizierungsstelle ein“. Den CSR finden Sie beim Bearbeiten des Zertifikats unter „Zertifikatskomponenten“. Das signierte Zertifikat tragen Sie anschließend dort unter „Zertifikatskomponenten aktualisieren“ in die Felder „Zertifikat“ und „CA-Zertifikat“ ein. Die Übersicht zeigt danach Aussteller und „Gültig bis“.

Ein hochgeladenes Zertifikat weisen Sie der Domain im Reiter „Sicherheit“ über „Zertifikat auswählen“ zu. KeyHelp schreibt es nach /etc/ssl/keyhelp/pem/ und trägt es samt Zwischenzertifikat in den vHost ein:

SSLCertificateFile /etc/ssl/keyhelp/pem/testkunde.example_6abe14e14d591.pem
SSLCertificateChainFile /etc/ssl/keyhelp/files/testkunde.example_6abe14e14d591-ca.crt

Verifizieren: Prüfen Sie Zertifikat und Kette mit dem CA-Zertifikat Ihrer Zertifizierungsstelle. Im Test mit unserer Test-CA:

echo | openssl s_client -connect 127.0.0.1:443 -servername IHRE-DOMAIN -CAfile ca.crt 2>/dev/null | grep -E "^subject=|^issuer=|Verify return code"

subject=CN = testkunde.example
issuer=CN = K3 Test-CA
Verify return code: 0 (ok)

Die Änderung wirkte im Test erst nach rund einer Minute, wenn die Wartungsaufgabe „Aufgaben abarbeiten“ gelaufen war.

Schritt 4: Panel, Mail- und FTP-Server absichern

Mailprogramme prüfen das Zertifikat des Mailservers streng. Öffnen Sie „SSL/TLS-Zertifikate“ und dort den Bereich „Serverdienste absichern“. Für „Control Panel“, „E-Mail-Server“ und „FTP-Server“ wählen Sie „Let's-Encrypt-Zertifikat“ (auf den Hostnamen ausgestellt) oder ein eigenes Zertifikat; für die „Webmail-Subdomain“ bietet KeyHelp nur eigene Zertifikate an.

Direkt nach der Installation versucht KeyHelp schon selbst, ein Let's-Encrypt-Zertifikat für den Hostnamen zu holen. In unserem Test mit einer Beispieldomain lehnte Let's Encrypt ab, das Panel blieb beim selbstsignierten Zertifikat:

ERROR | auto-request of lets encrypt certificate for server services failed: Failed to receive order details.
Details: Error creating new order :: Cannot issue for "kh.example.com": The ACME server refuses to issue a certificate for this domain name, because it is forbidden by policy

Prüfen Sie diese Zeile in /var/log/keyhelp/cronjob/master.log nach jeder Installation. Mit eigenem Zertifikat wechselten im Test nach einer Minute alle Dienste gleichzeitig.

Verifizieren: Prüfen Sie jeden Port einzeln, auch STARTTLS:

for p in 443 993 995 465; do echo | openssl s_client -connect IHR-HOSTNAME:$p 2>/dev/null | openssl x509 -noout -enddate; done
echo | openssl s_client -connect IHR-HOSTNAME:587 -starttls smtp 2>/dev/null | openssl x509 -noout -enddate
echo | openssl s_client -connect IHR-HOSTNAME:21 -starttls ftp 2>/dev/null | openssl x509 -noout -enddate

Im Test zeigten alle sechs Ports dasselbe Zertifikat mit notAfter=Oct 6 08:09:59 2026 GMT, ebenso Port 25.

Schritt 5: HSTS bewusst einschalten

Im Reiter „Sicherheit“ der Domain aktivieren Sie „HTTP Strict Transport Security (HSTS)“ mit einer Dauer („max-age“), optional mit „includeSubdomains“ und „preload“. KeyHelp warnt: Wer später auf HTTP zurückschaltet, sperrt Besucher unter Umständen aus. Beginnen Sie deshalb mit einem Tag und erhöhen Sie erst, wenn die Erneuerung zuverlässig läuft. Ab Werk steht das Feld auf 180 Tage.

Verifizieren: Im Test mit einem Tag lieferte der Server:

HTTP/2 200
strict-transport-security: max-age=86400

Schritt 6: Ablaufwarnungen einrichten und testen

Unter „Konfiguration“ → „SSL/TLS-Zertifikate“ legen Sie fest, wer gewarnt wird („Administrator-Konten“ oder „Zertifikatsbesitzer“, ab Werk der Besitzer) und wie viele Tage vorher („Zertifikatsablaufmitteilung“, 1 bis 30 Tage, ab Werk 14). Die Warnung umfasst laut Oberfläche Probleme bei der Erneuerung von Let's-Encrypt-Zertifikaten und den Ablauf benutzter Zertifikate. Die Prüfung erledigt die Wartungsaufgabe „SSL/TLS-Zertifikate warten“ unter „Wartungsintervalle“, ab Werk einmal täglich zwischen 0 und 1 Uhr. Dort können Sie sie für einen Test auch sofort starten.

Der Stolperstein aus dem Test: Die Warnung geht an die E-Mail-Adresse im Profil des Administrators. Der Installer trägt dort root@HOSTNAME ein. Die erste Warnung kam deshalb nie an:

status=bounced (user unknown. Command output: lda(root@kh.example.com): Error: net_connect_unix(/run/dovecot/stats-writer) failed: Permission denied )

Tragen Sie unter „Profil“ eine Adresse ein, die Sie wirklich lesen, und stellen Sie die Empfänger auf „Administrator-Konten“, wenn Kunden mit eigenen Zertifikaten nicht selbst reagieren.

Verifizieren: Laden Sie testweise ein Zertifikat mit kurzer Laufzeit hoch, starten Sie „SSL/TLS-Zertifikate warten“ und lesen Sie das Protokoll:

tail -20 /var/log/keyhelp/cronjob/ssl-maintenance.log

INFO | certificate name is "server-5-tage"
INFO | certificate is valid until 2026-10-06 08:09:59 (4 days left)
INFO | added message to notification stack

Die Mail hatte den Betreff „SSL/TLS-Zertifikatsprobleme auf Server kh.example.com“ und nannte Zertifikatsname, Ablaufdatum und Resttage.

Typische Fehler

Let's Encrypt schlägt mit „Local resolving checks failed“ fehl

Der Server selbst kann die Domain nicht auflösen. Prüfen Sie mit dig +short IHRE-DOMAIN auf dem Server, ob die öffentliche IP kommt.

Panel bleibt nach der Installation selbstsigniert

Der automatische Versuch nach der Installation ist gescheitert, meist weil der Hostname noch nicht im DNS stand. Prüfen Sie master.log und wählen Sie unter „Serverdienste absichern“ erneut „Let's-Encrypt-Zertifikat“.

Änderung am Zertifikat wirkt nicht

Die Konfiguration schreibt KeyHelp über die Aufgabe „Aufgaben abarbeiten“ im Minutentakt. Warten Sie eine Minute.

Testumgebung statt echter Zertifikate

Unter „Konfiguration“ → „SSL/TLS-Zertifikate“ steht „Umgebung“ auf „Produktiv-Umgebung“. Die „Staging-Umgebung“ erzeugt laut KeyHelp ungültige Zertifikate; nach einem Wechsel kann es nötig sein, /etc/ssl/keyhelp/letsencrypt/ zu löschen und die Wartung neu auszulösen.

Häufige Fragen

Kann ich Zertifikate per Skript überwachen?

Ja. Die REST-API liefert unter /api/v2/certificates je Zertifikat Name, Domains, Aussteller und valid_till, im Test etwa "valid_till": "2026-10-06T08:09:59+0000". Ob dort auch Let's-Encrypt-Zertifikate erscheinen, konnten wir ohne ausgestelltes Zertifikat nicht prüfen.

Wie lange vor Ablauf erneuert KeyHelp Let's Encrypt?

Das haben wir nicht testen können, und Keyweb nennt dafür keinen Wert. Verlassen Sie sich auf die Ablaufwarnung.

Gilt das Panel-Zertifikat auch für Webmail?

Nein, die „Webmail-Subdomain“ wählen Sie separat und nur aus eigenen Zertifikaten.

Testumfang

Wir haben in KeyHelp 26.1.1 auf Debian 12 eigene Zertifikate einer Test-CA hochgeladen, einen CSR erzeugt und signiert, Domain sowie Panel, Mail und FTP abgesichert, HSTS gesetzt und eine Ablaufwarnung ausgelöst. Auffällig war die Warnung an root@, die nicht zustellbar war. Let's Encrypt ließ sich ohne öffentliche Domain nicht ausstellen; diesen Teil beschreiben wir aus Protokoll und Oberfläche. Prüfen Sie die erste Ausstellung auf Ihrem Server mit openssl.

Fazit

Let's Encrypt in KeyHelp ist mit einem Klick erledigt, wenn DNS stimmt. Die eigentliche Arbeit liegt danach: Panel und Mailserver absichern, die Empfängeradresse für Warnungen korrigieren und einmal mit einem kurzlebigen Zertifikat prüfen, dass die Warnung wirklich ankommt. Wer zusätzlich von außen überwacht, ist auf der sicheren Seite, etwa mit einem Uptime-Monitor mit SSL-Tracking. Hintergründe zu Let's Encrypt ohne Panel finden Sie in unserer Anleitung zu Let's Encrypt mit certbot.

Weiterführende Anleitungen und Quellen

• KeyHelp installieren und absichern: das kostenlose Hosting-Panel für eigene Server
• KeyHelp: Rspamd-Spamfilter einrichten und einstellen
• KeyHelp-Wissensdatenbank: Zertifikate für Serverdienste festlegen
• Keyweb: KeyHelp 26.1
• Let's Encrypt: Ratenbegrenzungen