Zum Hauptinhalt springen
S-EDV news
← Alle Anleitungen
📘 Anleitung Linux 01.10.2026 · 11 min Lesezeit

KeyHelp: TLS-Versionen und Cipher-Suites für Web, Mail und FTP festlegen

So legen Sie in KeyHelp Mindestversion und Cipher-Suites für Apache, Dovecot, Postfix und ProFTPD fest und weisen mit openssl s_client auf jedem Port nach, was angenommen und was abgelehnt wird.

Geprüft am 01.10.2026 · für KeyHelp 26.1.1

WerbelinksMit * markierte Links sind Werbelinks: Bei einem Kauf erhalten wir eine Provision, der Preis bleibt gleich. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Mehr dazu

Illustration eines Hosting-Panels mit der Überschrift KeyHelp TLS festlegen und den Karten Web, Mail, FTP

Welche TLS-Versionen und Cipher-Suites Ihr Server anbietet, entscheidet, welche Clients noch eine verschlüsselte Verbindung aufbauen. KeyHelp legt beides zentral für Webserver, Mailserver und FTP-Server fest. Diese Anleitung zeigt die Seite „TLS-Version & -Ciphers“, was sie in die vier Dienste einträgt und wie Sie die Wirkung mit openssl s_client je Port nachweisen. Zertifikate behandelt die Anleitung SSL-Zertifikate in KeyHelp einrichten und überwachen. Getestet haben wir mit KeyHelp 26.1.1 auf Debian 12 mit OpenSSL 3.0.

Voraussetzungen

  • Ein KeyHelp-Server mit Administrator-Zugang. Getestet mit KeyHelp 26.1.1 (Build 3698) auf Debian 12.15, Apache 2.4, Postfix 3.7, Dovecot 2.3, ProFTPD 1.3.8 und OpenSSL 3.0.
  • SSH-Zugang als root, um Konfiguration und Wirkung zu prüfen. Die Einstellung selbst setzen Sie im Panel.
  • Ein Wartungsfenster: Beim Übernehmen startet KeyHelp Dienste neu, im Test belegt für Apache, Dovecot und ProFTPD. Ob laufende Verbindungen dabei abbrechen, haben wir nicht geprüft.

Schritt 1: Grundzustand ansehen

Öffnen Sie im Administrator-Bereich „Konfiguration“ und dort „TLS-Version & -Ciphers“. Ab Werk ist „Standardkonfiguration“ gewählt. Die Felder darunter sind ausgegraut, keine Version ist markiert, das Cipher-Feld zeigt acht Suites mit ECDHE oder DHE und AES-GCM bzw. ChaCha20. Die gültige Mindestversion, TLS 1.2, zeigen erst die Konfigurationsdateien. Der Hinweistext sagt, dass KeyHelp diese Werte bei Panel-Updates an aktuelle Standards anpassen kann.

KeyHelp-Seite TLS-Version und Ciphers mit gewählter Standardkonfiguration, ausgegrauten TLS-Versionen und acht Standard-Cipher-Suites
Grundzustand: Standardkonfiguration, die Felder sind nur zur Anzeige.

In der VM finden Sie diese Werte in vier Dateien. Apache:

grep -rn -i "SSLProtocol\|SSLCipherSuite\|SSLHonorCipherOrder" /etc/apache2/
/etc/apache2/mods-available/ssl.conf:30:    SSLProtocol                         all -SSLv3 -TLSv1 -TLSv1.1 
/etc/apache2/mods-available/ssl.conf:32:    SSLHonorCipherOrder                 off

Dovecot (IMAP, POP3), Postfix (SMTP) und ProFTPD:

grep -rn "^ssl_min_protocol\|^ssl_prefer" /etc/dovecot/
postconf smtpd_tls_protocols smtpd_tls_mandatory_ciphers tls_high_cipherlist
grep -rn "TLSProtocol" /etc/proftpd/
/etc/dovecot/conf.keyhelp.d/10-ssl.conf:17:ssl_min_protocol = TLSv1.2
/etc/dovecot/conf.keyhelp.d/10-ssl.conf:20:ssl_prefer_server_ciphers = no
smtpd_tls_protocols = !SSLv2 !SSLv3 !TLSv1 !TLSv1.1
smtpd_tls_mandatory_ciphers = high
tls_high_cipherlist = aNULL:-aNULL:HIGH:@STRENGTH
/etc/proftpd/tls.conf:5:    TLSProtocol                 ALL -SSLv3 -TLSv1 -TLSv1.1 

SSLHonorCipherOrder off und ssl_prefer_server_ciphers = no bedeuten laut Apache- und Dovecot-Dokumentation: Es gilt die Reihenfolge des Clients. Bei Apache und Dovecot zählt also vor allem, welche Suites in Ihrer Liste stehen, nicht deren Reihenfolge.

Verifizieren: Alle vier Ausgaben zeigen TLS 1.2 als Untergrenze.

Schritt 2: Ein Prüfskript für alle Ports

Das kleine Skript unten versucht für jede TLS-Version einen Handshake gegen HTTPS (443), IMAPS (993), SMTPS (465), Submission mit STARTTLS (587) und FTP mit explizitem TLS (21, AUTH TLS). Die Option -cipher "DEFAULT:@SECLEVEL=0" erlaubt dem Testclient auch alte Verfahren, damit eine Ablehnung wirklich vom Server kommt und nicht vom eigenen OpenSSL. Legen Sie es als /root/tlstest.sh an, ersetzen Sie server.example.de durch den Hostnamen Ihres Servers und machen Sie es mit chmod +x ausführbar. Alle Tests laufen vom Server selbst gegen 127.0.0.1, nicht von außen:

#!/bin/bash
# tlstest.sh: je Dienst und Protokollversion einen Handshake versuchen
t(){
  r=$(echo Q | timeout 8 openssl s_client -connect 127.0.0.1:$1 $2 $3 -cipher "DEFAULT:@SECLEVEL=0" 2>&1)
  p=$(echo "$r" | grep -m1 -E "^ +Protocol +:" | awk '{print $NF}')
  c=$(echo "$r" | grep -m1 -E "^ +Cipher +:" | awk '{print $NF}')
  n=$(echo "$r" | grep -m1 "^New, " | grep -v "(NONE)")
  # TLS 1.3: Session-Block kommt oft erst nach Q, dann die Zeile "New, ..." auswerten
  [ -z "$p" ] && [ -n "$n" ] && p=$(echo "$n" | cut -d" " -f2 | tr -d ,) && c=$(echo "$n" | awk '{print $NF}')
  if [ -n "$c" ] && [ "$c" != "0000" ] && [ "$c" != "(NONE)" ]; then
    echo "$4 $3: OK $p $c"
  else
    echo "$4 $3: abgelehnt ($(echo "$r" | grep -m1 -oE 'alert [a-z ]+[a-z]|unexpected eof while reading|wrong version number' | head -1))"
  fi
}
for v in ${VERS:--tls1 -tls1_1 -tls1_2 -tls1_3}; do
  t 443 "-servername server.example.de" $v "HTTPS 443"
  t 993 "" $v "IMAPS 993"
  t 465 "" $v "SMTPS 465"
  t 587 "-starttls smtp" $v "SMTP 587 STARTTLS"
  t 21 "-starttls ftp" $v "FTP 21 AUTH TLS"
done

Im Grundzustand lautete das Ergebnis (gekürzt; dieser Lauf stammt von einer früheren Skriptfassung mit „, Cipher is“ in der Ausgabe):

HTTPS 443 -tls1: abgelehnt (alert protocol version)
IMAPS 993 -tls1: abgelehnt (unexpected eof while reading)
FTP 21 AUTH TLS -tls1_1: abgelehnt (alert protocol version)
HTTPS 443 -tls1_2: OK TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
IMAPS 993 -tls1_2: OK TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
FTP 21 AUTH TLS -tls1_2: OK TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
HTTPS 443 -tls1_3: OK TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
FTP 21 AUTH TLS -tls1_3: OK TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384

Dovecot bricht alte Versionen ohne TLS-Alert ab, deshalb meldet der Client dort „unexpected eof while reading“. Im Dovecot-Log steht der Grund:

SSL_accept() failed: error:0A000102:SSL routines::unsupported protocol

Verifizieren: TLS 1.0 und 1.1 werden auf allen fünf Ports abgelehnt, TLS 1.2 und 1.3 funktionieren.

Schritt 3: Benutzerdefinierte Konfiguration setzen

Wählen Sie „Benutzerdefinierte Konfiguration“. Jetzt sind „Minimale TLS-Protokoll-Version“ und das Feld „TLS-Ciphers“ bearbeitbar. Markieren Sie eine Mindestversion und tragen Sie die Suites in OpenSSL-Schreibweise ein, eine pro Zeile. Im Test haben wir die Standardliste ohne die beiden DHE-Suites verwendet:

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
Benutzerdefinierte TLS-Konfiguration in KeyHelp mit TLS 1.2 als Mindestversion und sechs ECDHE-Cipher-Suites im Feld TLS-Ciphers
Eigene Konfiguration: Mindestversion TLS 1.2 und sechs ECDHE-Suites.

Nach „Speichern“ meldet das Panel „Die Einstellungen wurden aktualisiert. Die Änderungen werden in wenigen Augenblicken wirksam.“ Die Umsetzung erfolgt also nicht sofort beim Klick. Im Test waren die Dateien bei der nächsten Prüfung, gut eine Minute nach dem Speichern, bereits geändert. KeyHelp verbindet die Zeilen mit Doppelpunkten und schreibt sie in alle vier Dienste:

grep -n "SSLCipherSuite" /etc/apache2/mods-available/ssl.conf
postconf tls_medium_cipherlist
31:    SSLCipherSuite                      ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
tls_medium_cipherlist = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305

Bei Dovecot landet die Liste in ssl_cipher_list, bei ProFTPD in TLSCipherSuite. Dovecot, Apache und ProFTPD wurden im Test dabei neu gestartet.

Verifizieren: Erzwingen Sie im Test eine Suite, die nicht mehr in der Liste steht:

echo Q | openssl s_client -connect 127.0.0.1:443 -tls1_2 -cipher DHE-RSA-AES256-GCM-SHA384 2>&1 | grep -E "alert|Cipher *:"
40573A30D57F0000:error:0A000410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1602:SSL alert number 40
    Cipher    : 0000

Apache lehnt DHE nun ab. Auch Dovecot auf Port 993 kam mit dieser Suite nicht zustande (Cipher : 0000).

Schritt 4: Die Postfix-Besonderheit kennen

Für Postfix setzt KeyHelp die Cipher-Liste nur in tls_medium_cipherlist. Diese Liste gilt für smtpd_tls_ciphers = medium, also für opportunistisches TLS auf Port 25. Auf 465 und 587 erzwingt KeyHelp Verschlüsselung, dort gilt smtpd_tls_mandatory_ciphers = high mit der OpenSSL-Liste HIGH. Der Test mit drei Suites je Port:

Port 25 ECDHE-RSA-AES256-GCM-SHA384: ECDHE-RSA-AES256-GCM-SHA384
Port 25 DHE-RSA-AES256-GCM-SHA384: 0000
Port 25 AES256-SHA256: 0000
Port 465 DHE-RSA-AES256-GCM-SHA384: DHE-RSA-AES256-GCM-SHA384
Port 465 AES256-SHA256: AES256-SHA256
Port 587 DHE-RSA-AES256-GCM-SHA384: DHE-RSA-AES256-GCM-SHA384
Port 587 AES256-SHA256: AES256-SHA256

Auf den Ports für Ihre Mailprogramme nimmt Postfix also weiterhin Suites an, die Sie aus der Liste entfernt haben, darunter AES256-SHA256 ohne Forward Secrecy. Im Panel gibt es dafür kein Feld. Wenn Sie das ändern wollen, geht das nur außerhalb von KeyHelp, und ob KeyHelp eigene Änderungen an main.cf später überschreibt, haben wir nicht getestet.

Verifizieren: Prüfen Sie nach jeder Änderung Port 25 und Port 465 mit einer gestrichenen Suite.

Schritt 5: TLS 1.3 als Mindestversion

Das Panel beschreibt „TLS 1.3“ als Option für Dienste mit Clients, die TLS 1.3 unterstützen und keine Abwärtskompatibilität benötigen. KeyHelp schreibt dann in Apache und ProFTPD -TLSv1.2 zusätzlich in die Ausschlussliste und in Dovecot ssl_min_protocol = TLSv1.3:

30:    SSLProtocol                         all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2 
17:ssl_min_protocol = TLSv1.3
smtpd_tls_protocols = !SSLv2 !SSLv3 !TLSv1 !TLSv1.1 !TLSv1.2
smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3 !TLSv1 !TLSv1.1 !TLSv1.2

Das Prüfskript bestätigt die Wirkung auf allen Ports:

HTTPS 443 -tls1_2: abgelehnt (alert protocol version)
IMAPS 993 -tls1_2: abgelehnt (unexpected eof while reading)
SMTPS 465 -tls1_2: abgelehnt (alert protocol version)
SMTP 587 STARTTLS -tls1_2: abgelehnt (alert protocol version)
FTP 21 AUTH TLS -tls1_2: abgelehnt (alert protocol version)
HTTPS 443 -tls1_3: OK TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
SMTP 587 STARTTLS -tls1_3: OK TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384

Wichtig: smtpd_tls_protocols gilt auch für Port 25, über den andere Mailserver Ihnen Mails zustellen. Ein Test auf Port 25 mit TLS 1.2, danach ein Blick ins Postfix-Log:

echo Q | openssl s_client -connect 127.0.0.1:25 -starttls smtp -tls1_2 2>&1 | grep -E "^New,|alert"
journalctl -u postfix@- --since "-1min" --no-pager | grep -i "SSL_accept\|TLS"
40079600A07F0000:error:0A00042E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:../ssl/record/rec_layer_s3.c:1602:SSL alert number 70
postfix/smtpd[5726]: warning: TLS library problem: error:0A000102:SSL routines::unsupported protocol:../ssl/statem/statem_srvr.c:1664:
postfix/smtpd[5726]: lost connection after STARTTLS from localhost[127.0.0.1]

Ein Client mit nur TLS 1.2 verlor im Test die Verbindung nach STARTTLS. Ob ein Absender danach unverschlüsselt zustellt, haben wir nicht getestet. Auf TLS 1.3 wirkte die Cipher-Liste im Test nicht: Der Handshake verwendete in jedem Test TLS_AES_256_GCM_SHA384, auch mit der verkürzten Liste.

Verifizieren: Das Prüfskript meldet für -tls1_2 auf allen fünf Ports „abgelehnt“ und für -tls1_3 „OK“.

Schritt 6: Zurück zur Standardkonfiguration

Wählen Sie „Standardkonfiguration“ und speichern Sie. Bei der nächsten Prüfung standen im Test wieder die Werte aus Schritt 1 in allen vier Diensten. Die ausgegrauten Felder zeigten danach weiterhin eigene Werte aus einem früheren Durchgang, maßgeblich war aber nur die Option unter „Konfigurationstyp wählen“.

Verifizieren: Das Prüfskript liefert dasselbe Ergebnis wie in Schritt 2:

HTTPS 443 -tls1_1: abgelehnt (alert protocol version)
FTP 21 AUTH TLS -tls1_2: OK TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256

Typische Fehler

„Ungültige Angabe im Feld TLS-Ciphers.“ Diese Meldung erschien, als wir die OpenSSL-Kurzschreibweise HIGH:!aNULL eingetragen haben. Einzelne Suite-Namen, je Zeile einer, nahm das Panel an.

Rote Fehlermeldung in KeyHelp: Ungültige Angabe im Feld TLS-Ciphers über der Auswahl des Konfigurationstyps
Kurzschreibweisen wie HIGH:!aNULL lehnt das Panel ab.

„Ungültige Angabe im Feld Minimale TLS-Protokoll-Version.“ Diese Meldung erschien, als wir „Benutzerdefinierte Konfiguration“ ohne markierte Version gespeichert haben. In der Ausgangsansicht (erste Abbildung) ist keine Version markiert.

Tippfehler im Suite-Namen werden nicht erkannt. Eine erfundene Zeile FOOBAR-CIPHER neben einer gültigen Suite speicherte das Panel ohne Meldung und schrieb sie so in alle Dienste:

31:    SSLCipherSuite                      FOOBAR-CIPHER:ECDHE-RSA-AES256-GCM-SHA384

Die Dienste liefen weiter, Verbindungen mit der gültigen Suite funktionierten. Bot ein Client nur eine Suite an, die nicht in der Liste stand, endete der TLS-1.2-Handshake mit „no shared cipher“, so im Dovecot-Log. Achten Sie deshalb auf exakt geschriebene Suite-Namen und vergleichen Sie nach dem Speichern die Zeile in ssl.conf mit Ihrer Eingabe.

TLS 1 als Minimum: Web, IMAP und FTP lehnten TLS 1.0 trotzdem ab. Mit „TLS 1“ und einer Liste, die eine CBC-Suite enthält, schreibt KeyHelp SSLProtocol all -SSLv3. Trotzdem scheiterten Web, IMAP und FTP mit TLS 1.0:

HTTPS 443 -tls1: abgelehnt (alert internal error)
IMAPS 993 -tls1: abgelehnt (unexpected eof while reading)
SMTPS 465 -tls1: OK TLSv1 ECDHE-RSA-AES256-SHA
FTP 21 AUTH TLS -tls1: abgelehnt (alert internal error)

Dovecot und ProFTPD nennen im Log denselben Grund, hier ProFTPD:

  (1) error:0A000076:SSL routines::no suitable signature algorithm

Die genaue Ursache in OpenSSL haben wir nicht untersucht. Mit TLS 1.1 war das Ergebnis gleich. Nur Postfix auf 465 und 587 nahm TLS 1.0 und 1.1 an, Port 25 haben wir in diesem Fall nicht geprüft.

Häufige Fragen

Welche Einstellung empfiehlt sich für die meisten Server?

Das Panel nennt TLS 1.2 „empfohlen für fast alle Systeme“, und genau das setzt die Standardkonfiguration. Im Test nahmen damit alle fünf Ports TLS 1.2 und 1.3 an und lehnten 1.0 und 1.1 ab. Die Postfix-Besonderheit aus Schritt 4 gilt auch hier.

Gilt die Einstellung auch für das Panel selbst?

Unser Test auf Port 443 mit dem Server-Hostnamen zeigte die gesetzte Mindestversion. Kunden-Domains haben wir nicht einzeln geprüft.

Wird POP3S auf Port 995 ebenfalls umgestellt?

Unter /etc/dovecot/ fanden wir nur eine Einstellung ssl_min_protocol, ohne eigene Werte je Protokoll. Getestet haben wir aber nur IMAPS auf Port 993.

Wann werden Änderungen wirksam?

Laut Panel „in wenigen Augenblicken“. Im Test waren die Dateien gut eine Minute nach dem Speichern umgestellt. Prüfen Sie vor dem Testen die Dateien.

Testumfang

Wir haben auf KeyHelp 26.1.1 Standardkonfiguration, TLS 1.3, TLS 1 und eigene Cipher-Listen gesetzt und jede Variante mit openssl s_client vom Server selbst (127.0.0.1) auf den Ports 443, 993, 465, 587 und 21 geprüft, Port 25 für die Cipher-Liste und für TLS 1.3. Auffällig: Auf 465 und 587 ignoriert Postfix die eigene Cipher-Liste. Nicht geprüft haben wir die Einstellung „TLS 1.1“, POP3S, Tests von außen, echte Altgeräte und Zustellversuche fremder Mailserver.

Fazit

Die Seite „TLS-Version & -Ciphers“ steuert vier Dienste zentral. Wer DHE-Suites streichen oder TLS 1.3 erzwingen will, sollte zwei Dinge wissen: Die Liste schützt die Postfix-Ports 465 und 587 nicht, und TLS 1.3 als Minimum gilt auch für Mails anderer Server auf Port 25.

Weiterführende Anleitungen und Quellen

KeyHelpTLSCipher-SuitesPostfixDovecotProFTPDApache