04.06.2022

5425

GMX über stunnel einrichten - Konfigurationsproblem?

Hallo,

ich habe ein Mailkonto bei GMX und bin durch die Abschaltung der älteren TLS-Versionen von Seiten von GMX betroffen, da ich auf meinem Arbeitsrechner weiterhin Mac OS X 10.8.5 nutze. Dadurch ist mir der Zugriff auf mein GMX-Postfach über Apple Mail (Version 6.6) nicht mehr möglich. Ein Update auf eine neuere Mac OS-Version würde einige für mich wichtige Software unbrauchbar machen, daher ist dies für mich momentan keine Option.

Ich habe hier eine Lösung gefunden und nach dieser Anleitung bereits stunnel installiert und konfiguriert: https://hilfe.udmedia.de/e-mail/e-mail-einstellungen/ich-nutze-eine-aelt ...

Leider funktioniert dies nicht reibungslos, da beim Aufrufen von stunnel folgende Meldung erscheint: [!] /usr/local/etc/stunnel/stunnel.conf:68: "checkHost = pop.gmx.net:110": Specified option name is not valid here

Ist hier etwas in der Konfigurationsdatei falsch eingestellt, oder gibt es spezifische Dinge, auf die ich beim Erstellen des Zertifikats achten muss? Ich denke, ich bin schon 90% des Wegs gegangen, und mir fehlt nur noch der letzte kleine Hinweis, damit ich alles wieder zum Laufen bekomme. Über eine Hilfestellung würde ich mich sehr freuen!

LG, Daniel

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 2987803951

Url: https://administrator.de/contentid/2987803951

Ausgedruckt am: 23.11.2024 um 10:11 Uhr

54 Kommentare

Neuester Kommentar

Moin,

Leider funktioniert dies nicht reibungslos, da beim Aufrufen von stunnel folgende Meldung erscheint: [!] /usr/local/etc/stunnel/stunnel.conf:68: "checkHost = pop.gmx.net:110": Specified option name is not valid here

Ich würde es mal mit Port 995 statt 110 probieren. Vgl. https://hilfe.gmx.net/pop-imap/pop3/serverdaten.html
Aber ihm scheint die komplette Zeile 68 in der stunnel.conf nicht zu gefallen.

Gruß

cykes

Danke für den Hinweis! Ich habe es gerade probiert, leider ist es tatsächlich so, dass stunnel die Zeile immer noch nicht gefällt.

[!] /usr/local/etc/stunnel/stunnel.conf:68: "checkHost = pop.gmx.net:995": Specified option name is not valid here

Ich habe übrigens die stunnel-Version 5.42 bei mir installiert. Wenn ich die Zeile komplett entferne oder auskommentiere, startet stunnel ohne Probleme, aber es gibt dann natürlich keine funktionierende Verbindung. Ich frage mich, was hier falsch ist. Unsichtbare Sonderzeichen in der Zeile kann ich als Fehlerquelle auch ausschließen, da ich die Zeile schon mehrmals komplett neu von Hand getippt habe.

Poste doch mal das komplette config File (die personalisierten Informationen kannst Du ja maskieren) und bitte in code-Tags einbetten.

P.S. ist zwar für Google und Windows aber vielleicht klappt es ja so: https://www.stunnel.org/config_windows.html
Auszug:

[gmail-pop3]
client = yes
accept = 127.0.0.1:110
connect = pop.gmail.com:995
verifyChain = yes
CAfile = ca-certs.pem
checkHost = pop.gmail.com
OCSPaia = yes

also in der connect Zeile pop.gmx.net:995 (host inkl. Port) und der checkHost nur pop.gmx.net.

[EDIT] Hier noch das Bespiel für unixoides OS: https://www.stunnel.org/config_unix.html

P.P.S. Gibt auch schon Version 5.6.4 von stunnel, vgl. https://www.stunnel.org/downloads.html

Zitat von @cykes:

Poste doch mal das komplette config File (die personalisierten Informationen kannst Du ja maskieren) und bitte in code-Tags einbetten.

Kein Problem, ich habe einfach die Beispieldatei genommen und entsprechend abgeändert. Persönliche Informationen gibt es eigentlich nicht, da diese ja vom Mailprogramm an den stunnel weitergegeben werden, also in Apple Mail eingetragen sind.

; Sample stunnel configuration file for Unix by Michal Trojnara 2002-2017
; Some options used here may be inadequate for your particular configuration
; This sample file does *not* represent stunnel.conf defaults
; Please consult the manual for detailed description of available options

; **************************************************************************
; * Global options                                                         *
; **************************************************************************

; It is recommended to drop root privileges if stunnel is started by root
;setuid = nobody
;setgid = nogroup

; PID file is created inside the chroot jail (if enabled)
;pid = /usr/local/var/run/stunnel.pid

; Debugging stuff (may be useful for troubleshooting)
;foreground = yes
;debug = info
;output = /usr/local/var/log/stunnel.log

; Enable FIPS 140-2 mode if needed for compliance
;fips = yes

; The pkcs11 engine allows for authentication with cryptographic
; keys isolated in a hardware or software token
; MODULE_PATH specifies the path to the pkcs11 module shared library,
; e.g. softhsm2.dll or opensc-pkcs11.so
; Each section using this feature also needs the "engineId = pkcs11" option  
;engine = pkcs11
;engineCtrl = MODULE_PATH:/usr/lib/softhsm/libsofthsm2.so
;engineCtrl = PIN:1234

; **************************************************************************
; * Service defaults may also be specified in individual service sections  *
; **************************************************************************

; Enable support for the insecure SSLv3 protocol
;options = -NO_SSLv3

; These options provide additional security at some performance degradation
;options = SINGLE_ECDH_USE
;options = SINGLE_DH_USE

; **************************************************************************
; * Include all configuration file fragments from the specified folder     *
; **************************************************************************

;include = /usr/local/etc/stunnel/conf.d

; **************************************************************************
; * Service definitions (remove all services for inetd mode)               *
; **************************************************************************

; ***************************************** Example TLS client mode services

; The following examples use /etc/ssl/certs, which is the common location
; of a hashed directory containing trusted CA certificates.  This is not
; a hardcoded path of the stunnel package, as it is not related to the
; stunnel configuration in /usr/local/etc/stunnel/.

[gmx-pop3]
client = yes
accept = 110
connect = pop.gmx.net:995
verify = 2
CAfile = /usr/local/etc/stunnel/stunnel.pem
checkHost = pop.gmx.net:995
protocol = pop3

[gmx-smtp]
client = yes
accept = 587
connect = mail.gmx.net:587
verify = 2
CAfile = /usr/local/etc/stunnel/stunnel.pem
checkHost = mail.gmx.net:587
protocol = smtp

; Encrypted HTTP proxy authenticated with a client certificate
; located in a cryptographic token
;[example-pkcs11]
;client = yes
;accept = 127.0.0.1:8080
;connect = example.com:8443
;engineId = pkcs11
;cert = pkcs11:token=MyToken;object=MyCert
;key = pkcs11:token=MyToken;object=MyKey

; ***************************************** Example TLS server mode services

;[pop3s]
;accept  = 995
;connect = 110
;cert = /usr/local/etc/stunnel/stunnel.pem

;[imaps]
;accept  = 993
;connect = 143
;cert = /usr/local/etc/stunnel/stunnel.pem

;[ssmtp]
;accept  = 465
;connect = 25
;cert = /usr/local/etc/stunnel/stunnel.pem

; TLS front-end to a web server
;[https]
;accept  = 443
;connect = 80
;cert = /usr/local/etc/stunnel/stunnel.pem
; "TIMEOUTclose = 0" is a workaround for a design flaw in Microsoft SChannel  
; Microsoft implementations do not use TLS close-notify alert and thus they
; are vulnerable to truncation attacks
;TIMEOUTclose = 0

; Remote shell protected with PSK-authenticated TLS
; Create "/usr/local/etc/stunnel/secrets.txt" containing IDENTITY:KEY pairs  
;[shell]
;accept = 1337
;exec = /bin/sh
;execArgs = sh -i
;ciphers = PSK
;PSKsecrets = /usr/local/etc/stunnel/secrets.txt

; Non-standard MySQL-over-TLS encapsulation connecting the Unix socket
;[mysql]
;cert = /usr/local/etc/stunnel/stunnel.pem
;accept = 3307
;connect = /run/mysqld/mysqld.sock

; vim:ft=dosini

Zitat von @cykes:

also in der connect Zeile pop.gmx.net:995 (host inkl. Port) und der checkHost nur pop.gmx.net.

Das geht leider auch nicht…

[!] /usr/local/etc/stunnel/stunnel.conf:68: "checkHost = pop.gmx.net": Specified option name is not valid here  

P.P.S. Gibt auch schon Version 5.6.4 von stunnel, vgl. https://www.stunnel.org/downloads.html

Die neueste Version, die noch unter meinem OS läuft ist leider 5.42, die neueren habe ich nicht kompilieren können. Vielleicht habe ich da aber auch etwas nicht richtig gemacht.

Irgendwie bist du bei einigen Themen der Vergangenheit verhaftet?

Dass Google Mail oder Outlook deine Mails bei GMX sendet und empfängt ist kein Weg für dich?

Das würde alle Probleme lösen und du kannst deine GMX Adresse behalten.

Zitat von @2423392070:

Irgendwie bist du bei einigen Themen der Vergangenheit verhaftet?

Dass Google Mail oder Outlook deine Mails bei GMX sendet und empfängt ist kein Weg für dich?

Das würde alle Probleme lösen und du kannst deine GMX Adresse behalten.

Hallo erstmal!

Ich denke, dass ich am besten selber über meine Situation und meine Softwareanforderungen bescheid weiß. Würden Hard- und Softwarehersteller andere Wege gehen, hätte ich auch bereits ein moderenes System installiert. Hier haben wir es mit einem komplexeren Setup zu tun, welches nicht einfach so ein OS-Update ermöglicht ohne massive negative Effekte oder sehr teure Hardwarenachkäufe mit sich ziehen würde.

Ich habe auch ein modernes OS auf einer anderen Partition installiert, möchte aber beim Arbeiten nicht immer unterbrechen und neu booten müssen nur um Zugriff auf GMX zu haben… Ich würde auch gerne bei Apple Mail bleiben, da mir dieses vom Interface besser gefällt, und die Lösung mit stunnel für mich eigentlich gut ist. Eigentlich sollte das ja auch funktionieren, oder nicht?

Eine Option wären es natürlich auch, bei GMX eine Weiterleitung auf eine andere Mailadresse einzurichten, aber dann kann ich nicht mehr direkt davon versenden. Webmail-Login ist mir zu umständlich. Andere Mailanbieter werden sicherlich früher oder später nachziehen, also muss ich eine Lösung für dieses TLS-Problem finden. Ein Arbeitskollege von mir ist auf Thunderbird umgestiegen, welches mir persönlich nicht wirklich gefällt, auch das wäre zur Not eine Lösung.

Es ging mir nicht um deine Marotten und Bedürfnisse. Ich bin lang genug dabei, dass ich sowas nur belächel.

Es ging mir darum, dass z. B. Googlemail und Outlook eine Technik kostenlos beinhalten, mit der man z. B. sein GMX behalten kann und die Genannten darüber senden und empfangen. Proxy- Prinzip.

So kannst Du alles behalten und musst dich nicht verändern.

Hallo,

Du könntest Dir einen kleinen Einplatinenrechner als IMAP-Server o.Ä. aufsetzen und den mit fetchmail betanken.

Oder alternativ ein richtiges E-Mail-Programm nutzen

Lange wird dein Dinosaurier übrigens eh' nicht mehr leben - irgendwann laufen ja auch die Stammzertifikate aus.

Gruß,
Jörg

Hi,

ich hab hierhergefunden weil ich ebenfalls über die TLS 1.0 und 1.1 Abschaltung bei GMX gestolpert bin. Ich hole Mails per pullution.net ab und leite sie an einen Exchange-Server weiter.

Ich hab das jetzt über stunnel gelöst bekommen und GMX wie folgt konfiguriert:

[gmx-pop3]
client = yes
accept = 127.0.0.1:110
connect = pop.gmx.net:995
verifyChain = yes
CAfile = ca-certs.pem
checkHost = pop.gmx.net
OCSPaia = yes

Vielleicht hilft es jemandem.

VG,
f0x

Zitat von @foxm2k:

Hi,

ich hab hierhergefunden weil ich ebenfalls über die TLS 1.0 und 1.1 Abschaltung bei GMX gestolpert bin. Ich hole Mails per pullution.net ab und leite sie an einen Exchange-Server weiter.

Ich hab das jetzt über stunnel gelöst bekommen und GMX wie folgt konfiguriert:

[gmx-pop3]
client = yes
accept = 127.0.0.1:110
connect = pop.gmx.net:995
verifyChain = yes
CAfile = ca-certs.pem
checkHost = pop.gmx.net
OCSPaia = yes

Vielleicht hilft es jemandem.

VG,
f0x

Vielen Dank für den lösungsorientierten Hinweis - gut zu wissen, dass jemand es hinbekommen hat mit GMX über stunnel!

Ich habe den Block von Dir einfach mal so kopiert, und es kommt immer noch der selbe Fehler bei mir:

[!] /usr/local/etc/stunnel/stunnel.conf:68: "checkHost = pop.gmx.net": Specified option name is not valid here  

Kann es sein, dass mein stunnel nicht richtig funktioniert? Oder dass meine Zertifikatsdatei nicht korrekt erstellt ist? Dürfte ich Dich fragen, wie Du die ca-certs.pem Datei erstellt hast? Ich glaube bei mir stimmt da nämlich etwas nicht mit.

Ich habe meine folgendermaßen erstellt:

openssl genrsa -out key.pem 2048  

openssl req -new -x509 -key key.pem -out cert.pem -days 1095
 
cat key.pem cert.pem >> /usr/local/etc/stunnel/stunnel.pem

Beim openssl-Befehl muss man ja einiges eingeben. Hängt davon evtl. ab ob das Ganze funktioniert oder nicht? Ich habe leider zu wenig Erfahrung mit Zertifikaten, um dies zu sagen.

Hallo,

das wurde unter Windows bei der Installation mit angelegt denk ich. Es wurden ein paar grundlegende Daten abgefragt (Länderkürzel "DE", Region, City, FQDN, Company Name). Danach gings mit o.g. Konfiguration out of the box.

Kommt der Fehler bei dir schon beim Laden der Konfiguration in stunnel oder erst wenn der Mail-client sich verbinden will?

Hallo,

dass stunnel für dein Betriebssystem nicht freigegeben ist hast Du gesehen?

Gruß,
Jörg

Zitat von @foxm2k:

Hallo,

das wurde unter Windows bei der Installation mit angelegt denk ich. Es wurden ein paar grundlegende Daten abgefragt (Länderkürzel "DE", Region, City, FQDN, Company Name). Danach gings mit o.g. Konfiguration out of the box.

Kommt der Fehler bei dir schon beim Laden der Konfiguration in stunnel oder erst wenn der Mail-client sich verbinden will?

Der Fehler kommt beim Laden der Konfiguration, so dass stunnel gar nicht richtig startet. Wenn ich die beanstandete Zeile in der Konfigurationsdatei entferne oder auskommentiere, dann startet stunnel, und Mail verbindet sich (sehe ich in meiner Firewall). Also läuft stunnel im Prinzip, aber stört sich aus irgendwelchen Gründen an dieser einen Zeile und startet nur ohne diese.

Beim Erstellen des Zertifikats nach der Anleitung von udmedia.de (siehe mein allererster Post in diesem Thread) habe ich auch all diese Daten angegeben und pop.gmx.net als Common Name:

Hinweis: Sie müssen nun einige Daten eingeben. Als Common Name geben Sie Ihren bei uns verwendeten Mailserver an (z.B. mail.ud01.udmedia.de oder mail.zeus01.de).

Ob das richtig ist, oder zu meinem Problem führt, weiß ich leider nicht… ich habe gestern auch noch einmal probiert, ein paar ältere stunnel-Versionen zu kompilieren, aber bei allen tritt der selbe Fehler auf, also bin ich wieder auf meine Version 5.42 hoch.

Ich habe noch ein Update:

Nach weiterem Lesen von Informationen zu dem Thema bin ich noch auf folgende Website gestoßen:

https://gehirn-mag.net/stunnel-noch-lange-nicht-ausgepopt/

Hier steht unter Anderem folgendes:

Besonders prekär ist es, wenn die Anwendung noch gegen openssl 0.9.x verlinkt ist. Damit geht maximal TLSv1.0.

Genau das war bei mir der Fall, aber ich konnte das Problem lösen, indem ich bei mir auf OpenSSL Version 1.0.1u upgedatet habe. Neuere Versionen ließen sich leider nicht ohne Fehler kompilieren.
Aber laut Wikipedia sollte mit dieser Version TLS 1.2 gehen, siehe hier:

https://en.wikipedia.org/wiki/OpenSSL#Major_version_releases

Nun habe ich auch stunnel nochmal neu kompiliert, und es scheint die neue OpenSSL-Version auch zu verwenden, siehe hier:

[ ] Clients allowed=125
[.] stunnel 5.42 on x86_64-apple-darwin12.6.0 platform
[.] Compiled/running with OpenSSL 1.0.1u  22 Sep 2016
[.] Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI
[ ] errno: (*__error())
[.] Reading configuration from file /usr/local/etc/stunnel/stunnel.conf
[.] UTF-8 byte order mark not detected
[.] FIPS mode disabled
[ ] Compression disabled
[ ] Snagged 64 random bytes from /Users/usa/.rnd
[ ] Wrote 1024 new random bytes to /Users/usa/.rnd
[ ] PRNG seeded successfully
[!] /usr/local/etc/stunnel/stunnel.conf:68: "checkHost = pop.gmx.net": Specified option name is not valid here  

Leider besteht das Problem mit der Zeile 68 immer noch. Aber immerhin ist wieder ein Stolperstein aus dem Weg geräumt!

Was mich in deiner Beschreibung gerade etwas gewundert hat ist, dass du bei den ersten Schritten (bei denen das Zertifikat angelegt wird) bereits den gmx Server angegeben hast. Das hab ich nicht. Die Angaben bei der Installation hab ich nur auf meine Installation bezogen, also meinen Domänen-Namen etc. eingegeben. Gmx Daten (Server Adresse) hab ich erst im Konfig File (siehe mein Auszug oben) angegeben.

Zitat von @foxm2k:

Was mich in deiner Beschreibung gerade etwas gewundert hat ist, dass du bei den ersten Schritten (bei denen das Zertifikat angelegt wird) bereits den gmx Server angegeben hast. Das hab ich nicht. Die Angaben bei der Installation hab ich nur auf meine Installation bezogen, also meinen Domänen-Namen etc. eingegeben. Gmx Daten (Server Adresse) hab ich erst im Konfig File (siehe mein Auszug oben) angegeben.

Ich bin ganz ehrlich, ich weiß wirklich nicht, wozu man dieses Zertifikat braucht bzw. erstellen muss. Das wurde eben leider auch bei der udmedia-Anleitung nicht genauer beschrieben. Da sie aber dort erwähnten, dass man den Mailserver als Common Name angeben soll, habe ich das mit dem GMX-Server ebenfalls gemacht.

Vielleicht ist das falsch und deswegen funktioniert es nicht. Jemand mit viel stunnel-Erfahrung könnte hier vielleicht wissen, ob diese Fehlermeldung im Zusammenhang mit einer fehlerhaften Zertifikatsdatei ist. Leider habe ich selber keine Erfahrungen mit stunnel, sonst hätte ich es wahrscheinlich schon längst selber zum Laufen bekommen.

Ich kann mich nur auf diesen Artikel von udmedia beziehen, und nach dem sollte es eigentlich so klappen mit meinem OS. Die Geschichte mit dem Zertifikat wird dort eben nur so am Rande erwähnt, und offenbar Vorwissen zu dem Thema vorausgesetzt.

Hi,

du hast aber in der Doku gesehen, dass die Option checkHost mindestens OpenSSL 1.0.2 erfordert?

checkHost = HOST
host of the peer certificate subject

Multiple checkHost options are allowed in a single service section. Certificates are accepted if no subject checks were specified, or the host name of the peer certificate matches any of the hosts specified with checkHost.

This option requires OpenSSL 1.0.2 or later.

www.stunnel.org/static/stunnel.html

Viele Grüße
Terminatorthree

Zitat von @Terminatorthree:

Hi,

du hast aber in der Doku gesehen, dass die Option checkHost mindestens OpenSSL 1.0.2 erfordert?

checkHost = HOST
host of the peer certificate subject

Multiple checkHost options are allowed in a single service section. Certificates are accepted if no subject checks were specified, or the host name of the peer certificate matches any of the hosts specified with checkHost.

This option requires OpenSSL 1.0.2 or later.

www.stunnel.org/static/stunnel.html

Viele Grüße
Terminatorthree

Wow, danke! Das habe ich echt nicht gesehen!

Jetzt stellt sich die Frage, ist CheckHost zwingend nötig, oder geht es auch ohne?
Sonst wird es knifflig, da ich OpenSSL 1.0.2 bisher nicht zum Laufen bekommen habe.

OK, hier ist ein Update:

Ich habe es geschafft, OpenSSL 1.0.2-beta1 zu installieren, die beta2 und beta3 gingen nicht mehr, weil es beim Kompilieren ein Problem mit 'mnemonic' gibt.

Dann wollte stunnel 5.42 nicht mehr, da die Anzahl der übergebenen Parameter für checkHost nicht mehr übereinstimmte mit der OpenSSL-Beta (wahrscheinlich wurde das mit den neueren Versionen geändert), und daher habe ich es mit stunnel 5.02 ersetzt, welches zeitgenössisch mit der Beta-1 von OpenSSL 1.0.2 ist. Das ging.

Das Problem besteht allerdings dennoch weiter:

[ ] Clients allowed=125
[.] stunnel 5.02 on x86_64-apple-darwin12.6.0 platform
[.] Compiled/running with OpenSSL 1.0.2-beta1 24 Feb 2014
[.] Threading:PTHREAD Sockets:SELECT,IPv6 SSL:ENGINE,OCSP,FIPS
[ ] errno: (*__error())
[.] Reading configuration from file /usr/local/etc/stunnel/stunnel.conf
[.] FIPS mode disabled
[ ] Compression disabled
[ ] Snagged 64 random bytes from /Users/usa/.rnd
[ ] Wrote 1024 new random bytes to /Users/usa/.rnd
[ ] PRNG seeded successfully
[!] Line 68: "checkHost = pop.gmx.net": Specified option name is not valid here  

Was könnte es jetzt noch sein?

Hallo,

Zitat von @DLippert:

Was könnte es jetzt noch sein?

Vielleicht hat er Probleme mit der darüberliegenden Zeile, weil da kein kompletter Pfad drin steht?!?

Ansonsten bietet es sich immer an, noch einmal eine Standard-Konfigurationsdatei zu schnappen und dort nur die Parameter zu ändern, die relevant ist.

Gerade bei dem alten Mac-Rechnern sollte man sich auch immer bewusst sein, dass es diverse Arten gibt, den Inhalt von Dateien zu codieren (z.B. ISO 8859-15, UTF-8 usw. usf.) und dass es mehrere Zeilenumbrüche (CR, LF, CR/LF usw.) gibt.

Apple kocht ja gerne mal sein eigenes Süppchen.

Ansonsten empfehle ich ernsthaft einen eigenen IMAP-Server oder ein aktuelles Betriebssystem: TLS 1.2 kann sogar schon mein WindowsXP und sooooo wertvoll kann die Hardware wirklich nicht sein, dass man sie in einem so langen Zeitraum nicht gewinnbringend abschreiben konnte. Zumal Dir sicher irgendwann eine Festplatte, ein Lüfter o.Ä. um die Ohren fliegt und es dann sowieso Essig ist mit deinem Museumsaufbau...

Gruß,
Jörg

So, ich bin wieder einen Schritt weiter gekommen. Ich hatte nicht die allerneuesten Command Line Tools installiert und habe diese nun geupdatet. Der Hinweis mit dem mnemonic hat mich nach etwas Suche darauf gebracht.

Nun habe ich ein neueres OpenSSL 1.02u kompilieren können, und wieder auf stunnel 5.42 updaten können. Der lästige bisher bestehende Fehler mit Zeile 68 ist nun dadurch auch behoben. Offenbar war die Beta nicht gut genug, es musste eine 'echte' 1.02 sein.

Nun gibt es aber gleich das nächste Problemchen, hoffentlich diesmal mit einer eindeutigen/einfacheren Lösung:

[ ] Clients allowed=125
[.] stunnel 5.42 on x86_64-apple-darwin12.6.0 platform
[.] Compiled/running with OpenSSL 1.0.2u  20 Dec 2019
[.] Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI
[ ] errno: (*__error())
[.] Reading configuration from file /usr/local/etc/stunnel/stunnel.conf
[.] UTF-8 byte order mark not detected
[.] FIPS mode disabled
[ ] Compression disabled
[ ] Snagged 64 random bytes from /Users/usa/.rnd
[ ] Wrote 1024 new random bytes to /Users/usa/.rnd
[ ] PRNG seeded successfully
[ ] Initializing service [gmx-pop3]
[ ] Ciphers: HIGH:!DH:!aNULL:!SSLv2
[ ] TLS options: 0x03000004 (+0x03000000, -0x00000000)
[ ] No certificate or private key specified
[.] Configuration successful
[ ] Listening file descriptor created (FD=8)
[ ] Option SO_REUSEADDR set on accept socket
[!] bind: Permission denied (13)
[!] Error binding service [gmx-pop3] to 127.0.0.1:110
[ ] Closing service [gmx-pop3]
[ ] Service [gmx-pop3] closed

Falls jemand weiß, was es hiermit auf sich hat, wäre ich sehr dankbar. Ich habe das Gefühl, dass ich jetzt schon 99% 'da' bin.

OK, das war jetzt einfacher als gedacht. Ports bis 1024 sind vom OS her nicht vom User aus freigegeben sondern nur vom Root. Ich habe einfach einen anderen Port genommen, in meinem Fall 12110, und es geht jetzt.

Ich kann stunnel nun starten und es läuft nun dauerhaft im Hintergrund. Wenn ich in Mail nun 127.0.0.1 als Servernamen und Port 12110 ohne SSL, mit einfacher Kennwort-Authentifizierung angebe, verbindet stunnel (sichtbar in meiner Firewall).

GMX schmeckt das aber noch nicht, denn es kommt die folgende Fehlermeldung zurück:

Der Server meldet den Fehler: Die Verbindung zum Server „127.0.0.1“ über den Port 12110 ist fehlgeschlagen (Fehler 54: Connection reset by peer).

Jetzt ist es wirklich nur noch ein ganz kleines Schrittchen.

Momentan sieht meine Config so aus:

[gmx-pop3]
client = yes
accept = 127.0.0.1:12110
connect = pop.gmx.net:995
verifyChain = yes
CAfile = /usr/local/etc/stunnel/stunnel.pem
checkHost = pop.gmx.net
protocol = pop3
OCSPaia = yes

[gmx-smtp]
client = yes
accept = 127.0.0.1:12025
connect = mail.gmx.net:587
verifyChain = yes
CAfile = /usr/local/etc/stunnel/stunnel.pem
checkHost = mail.gmx.net
protocol = smtp
OCSPaia = yes

Da foxm2k es ja so hinbekommen hat, kann es ja nun wirklich nur noch eine winzige Kleinigkeit sein.

Moin,

Zitat von @DLippert:
GMX schmeckt das aber noch nicht, denn es kommt die folgende Fehlermeldung zurück:

Der Server meldet den Fehler: Die Verbindung zum Server „127.0.0.1“ über den Port 12110 ist fehlgeschlagen (Fehler 54: Connection reset by peer).

Die Fehlermeldung besagt ja, dass der Tunnel-Eintrittspunkt nicht funktioniert/erreichbar ist.
Entweder wird der Port 12110 geblockt oder er ist gar nicht geöffnet worden, folglich kannst Du (bzw. AppleMail) Dich darüber nicht verbinden.

Gruß

cykes

Zitat von @cykes:

Moin,

Zitat von @DLippert:
GMX schmeckt das aber noch nicht, denn es kommt die folgende Fehlermeldung zurück:

Der Server meldet den Fehler: Die Verbindung zum Server „127.0.0.1“ über den Port 12110 ist fehlgeschlagen (Fehler 54: Connection reset by peer).

Danke für Dein Feedback! Ich habe mir das nochmal angeschaut, und probiert mit Apple Mail zu verbinden, ohne vorher stunnel zu öffnen. Dann kam folgende Meldung:

Der Server meldet den Fehler: Der Server „127.0.0.1“ hat eine Verbindung über den Port 12110 verweigert.

Wäre dies nicht der Hinweis, dass der Port nicht offen ist?

Nach dem Start von stunnel ändert sich Apple Mail's Fehler zu dem bekannten:

Der Server meldet den Fehler: Die Verbindung zum Server „127.0.0.1“ über den Port 12110 ist fehlgeschlagen (Fehler 54: Connection reset by peer).

Wenn ich stunnel in der Konfigurationsdatei auf 'foreground' stelle, sehe ich auch genauer, was dort unter der Haube passiert. Dort finde ich folgendes vor:

06.12 13:45:20 LOG5[2]: s_connect: connected 212.227.17.169:995
06.12 13:45:20 LOG5[2]: Service [gmx-pop3] connected remote server from 10.0.1.12:49786
06.12 13:45:30 LOG3[2]: Unexpected socket close (s_read)
06.12 13:45:30 LOG5[2]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket

Noch ein Update:

Ich habe in der Konfigurationsdatei die 'protocol'-Zeilen entfernt, damit es angeglichen an die funktionierende Lösung von foxm2k ist. Dies hat zur Folge, dass die Fehlermeldung sich geändert hat zu:

06.12 14:03:40 LOG5[4]: Service [gmx-pop3] accepted connection from 127.0.0.1:49982
06.12 14:03:40 LOG5[4]: s_connect: connected 212.227.17.185:995
06.12 14:03:40 LOG5[4]: Service [gmx-pop3] connected remote server from 10.0.1.12:49983
06.12 14:03:40 LOG4[4]: CERT: Pre-verification error: unable to get local issuer certificate
06.12 14:03:40 LOG4[4]: Rejected by CERT at depth=1: C=DE, O=T-Systems International GmbH, OU=T-Systems Trust Center, ST=Nordrhein Westfalen, postalCode=57250, L=Netphen, street=Untere Industriestr. 20, CN=TeleSec ServerPass Extended Validation Class 3 CA
06.12 14:03:40 LOG3[4]: SSL_connect: 14090086: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
06.12 14:03:40 LOG5[4]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket

Also stimmt jetzt etwas mit meinem lokalen Zertifikat nicht?

Zitat von @DLippert:

Noch ein Update:

Ich habe in der Konfigurationsdatei die 'protocol'-Zeilen entfernt, damit es angeglichen an die funktionierende Lösung von foxm2k ist.

Bei mir geht die Verbindung zu gmx tatsächlich nur wenn ich die Zeile

; protocol = pop3

auskommentiere.
Mit dieser Zeile geht es nicht und es kommt die gleiche Meldung wie bei dir.

2022.06.12 14:27:04 LOG3[28658]: Unexpected socket close (s_read)
2022.06.12 14:27:04 LOG5[28658]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket

Ich denke also du solltest den Eintrag draußen lassen und an deiner letzten Fehlermeldung weiterarbeiten.

Alles klar, vielen Dank für die Bestätigung meiner Vermutung!

Wenn ich das Zertifikat anlege, bekomme ich folgende Optionen zum Eintragen:

Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) :
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) :
Common Name (e.g. server FQDN or YOUR name) :
Email Address :

Ich habe dort jetzt mal probiert meine tatsächlichen lokalen Daten anzugeben, aber das Ergebnis ist immer noch das selbe: Das Zertifikat wird nicht akzeptiert.

Hallo,

hast Du dein E-Mail-Programm evtl. so eingestellt, dass es (immer noch) TLS 1.0 sendet?

Gruß,
Jörg

Zitat von @117471:

Hallo,

hast Du dein E-Mail-Programm evtl. so eingestellt, dass es (immer noch) TLS 1.0 sendet?

Gruß,
Jörg

Hallo,

das ist in der Tat ein wertvoller Input, daran hatte ich noch gar nicht gedacht! Ich glaube, bei Apple's Mail-Programm gibt es gar keine Einstellung für TLS. Man kann nur SSL aktivieren oder deaktivieren, was den Standardport zwischen 110 und 995 wechselt.

Bei der Authentifizierung gibt es 6 verschiedene Optionen:

· Extern (TLS-Clientzertifikat)
· Kerberos Version 5 (GSSAPI)
· NTLM
· MD5 Challenge-Response
· Authentifizierter POP (APOP)
· Kennwort

Ich hatte dort bisher immer 'Kennwort' gewählt. Ob hier etwas davon das TLS deaktiviert, weiß ich leider nicht.

In jedem Fall könnte ich aber zwei stunnel-Durchgänge verwenden, einen um das 'veraltete TLS' in 'kein TLS' umzuwandeln, und dann einen um das 'kein TLS' in 'aktuelles TLS' umzuwandeln. Ich werde mich da auf jeden Fall mal reinlesen und schauen, ob das mit einer einzelnen stunnel-Instanz mit zwei konfigurierten Diensten in Kette geht.

Gruß,
Daniel

Servus Daniel.

Zitat von @DLippert:
In jedem Fall könnte ich aber zwei stunnel-Durchgänge verwenden, einen um das 'veraltete TLS' in 'kein TLS' umzuwandeln, und dann einen um das 'kein TLS' in 'aktuelles TLS' umzuwandeln. Ich werde mich da auf jeden Fall mal reinlesen und schauen, ob das mit einer einzelnen stunnel-Instanz mit zwei konfigurierten Diensten in Kette geht.

TLS eingehend > auf TLS weitergeleitet mit stunnel geht, habe ich hier mal schnell testweise mit GMX zusammengebaut (für IMAP und SMTP), Host war hier ein Archlinux mit installiertem stunnel.

# proxy imap to gmx
[gmx-imap]
client = yes
accept = 127.0.0.1:55993
connect = imap.gmx.net:993
verifyChain = yes
CApath = /etc/ssl/certs
checkHost = imap.gmx.net
OCSPaia = yes

 # proxy smtp to gmx
[gmx-smtp]
client = yes
accept = 127.0.0.1:55587
protocol = smtp
connect = mail.gmx.net:587
verifyChain = yes
CApath = /etc/ssl/certs
checkHost = mail.gmx.net
OCSPaia = yes

# local imap tls listener (only needed if local connection should also be encrypted)
[imap_listener]
accept = 993
protocol = imap
cert = /etc/stunnel/stunnel.pem
CAfile = /etc/stunnel/stunnel.pem
connect = 127.0.0.1:55993

# local smtp tls listener (only needed if local connection should also be encrypted)
[smtp_listener]
accept = 587
protocol = smtp
cert = /etc/stunnel/stunnel.pem
CAfile = /etc/stunnel/stunnel.pem
connect = 127.0.0.1:55587

Selbstsigniertes Zertifikat kannst du dir schnell so bauen (FQDN des Hosts anpassen)

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -nodes -sha256 -days 365 -subj "/C=DE/CN=host.demo.tld" -addext "subjectAltName = host.demo.tld" -addext "extendedKeyUsage = serverAuth,clientAuth" -addext "keyUsage = critical,keyEncipherment,dataEncipherment"  
cat key.pem cert.pem >/etc/stunnel/stunnel.pem

Auf dem dann beim neu Einrichten entweder das Zertifikat akzeptieren und es im Schlüsselbund auf vertrauenswürdig setzen, oder es manuell dort hinterlegen und als vertrauenswürdig markieren.

Klappte hier im Test mit einem alten Apple-Mail aus einer VM heraus einwandfrei. Bei Bedarf kannst du auf dem Host noch die lokal akzeptierten TLS-Ciphers in der stunnel.conf anpassen, die sind ja je nach Host und OpenSSL Version auf unterschiedlichem Stand.

Grüße Uwe

Hallo,

denkbar wäre auch noch, dass der Applemüll Autodiscover nutzt und den lokalen stunnel „heimlich“ umgeht.

Gruß,
Jörg

Zitat von @117471:
denkbar wäre auch noch, dass der Applemüll Autodiscover nutzt und den lokalen stunnel „heimlich“ umgeht.

Die zu nutzenden Server kann ich problemlos manuell im Profil angeben, ein Fallback fand hier nicht statt wenn ich den stunnel explizit angegeben habe.

Zitat von @colinardo:

Servus Daniel.

TLS eingehend > auf TLS weitergeleitet mit stunnel geht, habe ich hier mal schnell testweise mit GMX zusammengebaut (für IMAP und SMTP), Host war hier ein Archlinux mit installiertem stunnel.

Auf dem dann beim neu Einrichten entweder das Zertifikat akzeptieren und es im Schlüsselbund auf vertrauenswürdig setzen, oder es manuell dort hinterlegen und als vertrauenswürdig markieren.

Klappte hier im Test mit einem alten Apple-Mail aus einer VM heraus einwandfrei. Bei Bedarf kannst du auf dem Host noch die lokal akzeptierten TLS-Ciphers in der stunnel.conf anpassen, die sind ja je nach Host und OpenSSL Version auf unterschiedlichem Stand.

Servus Uwe und vielen Dank für Deinen detaillierten Bericht, ich weiß es wirklich sehr zu schätzen, dass Du Dir die Zeit genommen hast! Ich werde das ganz genau studieren und versuchen bei mir auch so einzurichten. Ich glaube mit dem Zertifikat oder den Zugriffsrechten bei mir stimmt momentan etwas nicht, ich werde es mal genauso einrichten wie Du es beschrieben hast.

Vielleicht liegt das daran, dass es nicht im Schlüsselbund hinterlegt war. Der Fehler war auf jeden Fall lokal bei mir, da es ja um einen 'Pre-verification error' ging, also die eigentliche Überprüfung noch gar nicht stattgefunden hat , und 'unable to get local issuer certificate' deutet auch auf ein lokales Problem auf meiner Seite hin.

Dass der stunnel umgangen wird, halte ich für ausgeschlossen, da der stunnel bei mir ja im Vordergrund-Modus läuft und alles im Terminal mitloggt. Wenn Mail dann versucht zu verbinden, wird dies dann auch prompt angezeigt mit den entsprechenden Zertifikatsproblemen.

Ich werde mich da jetzt mal dran machen und hoffe, dass ich es ebenso wie Du hinbekomme - nochmals vielen Dank für die ausführliche Anleitung!

LG, Daniel

OK, nochmal ich

Leider scheint meine OpenSSL-Version 1.0.2u nicht das -addext zu schmecken. Ist das eine Funktion einer neueren Version?

Mir ist auch aufgefallen, dass Du drei verschiedene Zertifikat-basierte Parameter in stunnel angibst:

CApath = /etc/ssl/certs

sowie

cert = /etc/stunnel/stunnel.pem
CAfile = /etc/stunnel/stunnel.pem

Kann ich das mit dem /etc/ssl/certs-Verzeichnis einfach so übernehmen? Ich habe nachgeschaut, und leider gibt es dieses ssl-Verzeichnis in meinem etc-Ordner gar nicht.

Ich habe noch einmal nachgeschaut, und das bisher von mir erstellte/verwendete Zertifikat mit der folgenden Methode ist bereits im Schlüsselbund hinterlegt und als vertrauenswürdig markiert:

openssl genrsa -out key.pem 2048  

openssl req -new -x509 -key key.pem -out cert.pem -days 1095
 
cat key.pem cert.pem >> /usr/local/etc/stunnel/stunnel.pem

Dennoch gibt es die Fehlermeldung, dass das Zertifikat nicht gelesen werden kann:

06.12 14:03:40 LOG5[4]: Service [gmx-pop3] accepted connection from 127.0.0.1:49982
06.12 14:03:40 LOG5[4]: s_connect: connected 212.227.17.185:995
06.12 14:03:40 LOG5[4]: Service [gmx-pop3] connected remote server from 10.0.1.12:49983
06.12 14:03:40 LOG4[4]: CERT: Pre-verification error: unable to get local issuer certificate
06.12 14:03:40 LOG4[4]: Rejected by CERT at depth=1: C=DE, O=T-Systems International GmbH, OU=T-Systems Trust Center, ST=Nordrhein Westfalen, postalCode=57250, L=Netphen, street=Untere Industriestr. 20, CN=TeleSec ServerPass Extended Validation Class 3 CA
06.12 14:03:40 LOG3[4]: SSL_connect: 14090086: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
06.12 14:03:40 LOG5[4]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket

Dazu kommt noch, dass stunnel beim Starten folgende Meldung ausgibt:

2022.06.16 22:36:09 LOG4[ui]: Insecure file permissions on /usr/local/etc/stunnel/stunnel.pem

Die Datei hat den Eigentümer root (0) und die Gruppe admin (80) und die Zugriffsrechte -rw-r--r-- (644).

Hallo,

naja - welche Anforderungen an die Zugriffsrechte bestehen sollte ja in der stunnel Anleitung stehen.

Offenbar hast Du im Moment zuviel erlaubt und stunnel erachtet das als unsicher.

Gruß,
Jörg

Zitat von @117471:

Hallo,

naja - welche Anforderungen an die Zugriffsrechte bestehen sollte ja in der stunnel Anleitung stehen.

Offenbar hast Du im Moment zuviel erlaubt und stunnel erachtet das als unsicher.

Gruß,
Jörg

Hallo,

ich habe die Zugriffsrechte der Zertifikats-Datei nun auf -rw-r----- (640) geändert und stunnel beschwert sich nun auch nicht mehr, aber die Zertifikatsdatei bekommt immer noch den Pre-Verification Error.

Immerhin wieder ein potenzielles Problem behoben.

Gruß,
Daniel

2022.06.12 14:03:40 LOG4[4]: Rejected by CERT at depth=1: C=DE, O=T-Systems International GmbH, OU=T-Systems Trust Center, ST=Nordrhein Westfalen, postalCode=57250, L=Netphen, street=Untere Industriestr. 20, CN=TeleSec ServerPass Extended Validation Class 3 CA

Die Meldung hat nichts mit deinem Zertifikat zu tun sondern besagt das dem Remote Zertifikat bei GMX nicht vertraut wird.
Bei der Telesec CA gab es in der Zwischenzeit mal ein revoke der Symantec Certs, und das hat dein alter MAC nicht mitbekommen, also seine CA-Roots nicht aktualisiert und deswegen misstraut er der CA. Kopiere dir also das aktuelle Root der Telesec CA in deinen Zertifikatsspeicher und schon sollte dem GMX Server wieder vertraut werden.
https://corporate-pki.telekom.de/downloads.html

Zitat von @colinardo:

Vielen Dank für den Hinweis, da wäre ich niemals drauf gekommen!

Ich habe alle Zertifikate dort heruntergeladen, und die .crt-Dateien alle mit der Schlüsselbundverwaltung geöffnet und sowohl bei System als auch Anmeldung hinterlegt. Dennoch gibt es nach wie vor folgende Fehlermeldung von stunnel:

06.18 11:45:03 LOG4[1]: CERT: Pre-verification error: unable to get local issuer certificate
06.18 11:45:03 LOG4[1]: Rejected by CERT at depth=1: C=DE, O=T-Systems International GmbH, OU=T-Systems Trust Center, ST=Nordrhein Westfalen, postalCode=57250, L=Netphen, street=Untere Industriestr. 20, CN=TeleSec ServerPass Extended Validation Class 3 CA
06.18 11:45:03 LOG3[1]: SSL_connect: 14090086: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
06.18 11:45:03 LOG5[1]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
06.18 11:45:03 LOG3: readsocket (s_read): Connection reset by peer (54)
06.18 11:45:03 LOG5: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket

Habe ich da noch etwas übersehen? Hier steht ja 'TeleSec ServerPass Extended Validation Class 3 CA', aber auf der Website gab es nur Class 1 und Class 2-Zertifikate herunterzuladen.

Gäbe es vielleicht eine Möglichkeit, die fehlenden Zertifikate von einem neueren MacOS zu kopieren? Ich habe Zugriff auf mehrere Macs mit neueren Betriebssystemen, auch mein Arbeitsrechner hat ein Triple-Boot mit zwei verschiedenen MacOS-Versionen und Windows.

Du brauchst das Root und das Intermediate Cert
https://de.ssl-tools.net/subjects/31e4c31bde81d32ad0d8ecacd40c3da4e71aeb ...
https://de.ssl-tools.net/subjects/7d9136a73aadb30e5548e30c7915c9479f234a ...
Und die müssen zwingend in die Trusted CAs des Schlüsselrings. Bzw. je nach Host auch als Files im angegebenen Pfad für stunnel abgelegt sein.

Gäbe es vielleicht eine Möglichkeit, die fehlenden Zertifikate von einem neueren MacOS zu kopieren?

Kann man auch machen
https://apple.stackexchange.com/questions/422332/how-do-i-update-my-root ...

Zitat von @colinardo:

Du brauchst das Root und das Intermediate Cert
https://de.ssl-tools.net/subjects/31e4c31bde81d32ad0d8ecacd40c3da4e71aeb ...
https://de.ssl-tools.net/subjects/7d9136a73aadb30e5548e30c7915c9479f234a ...
Und die müssen zwingend in die Trusted CAs des Schlüsselrings. Bzw. je nach Host auch als Files im angegebenen Pfad für stunnel abgelegt sein.

Gäbe es vielleicht eine Möglichkeit, die fehlenden Zertifikate von einem neueren MacOS zu kopieren?

Kann man auch machen
https://apple.stackexchange.com/questions/422332/how-do-i-update-my-root ...

Danke für den neuen Link!

Ich habe auch dieses Zertifikat jetzt hinzugefügt und dieses und alle 16 von der Telekom-Seite im Schlüsselbund als "Immer vertrauen" eingerichtet. Ich habe auch den fehlenden Ordner /etc/ssl/certs angelegt und die Datei dort hinterlegt. In der stunnel-Konfiguration habe ich dann den CApath überall angegeben. Dennoch kommt immer noch die exakt selber Fehlermeldung.

Ich schaue mir mal an, ob ich die Root-Zertifikate aus einer neueren MacOS-Version extrahieren kann.

Hallo,

verwendet der root-User von deinem System denn das „Schlüsselbund“ des „normalen" Benutzers?

Gruß,
Jörg

Zitat von @117471:
verwendet der root-User von deinem System denn das „Schlüsselbund“ des „normalen" Benutzers?

CA Zertifikate gehören auf dem MAC in den SYSTEM-Abschnitt, dem vertrauen alle User.

Aber auf einem MAC muss man wohl statt meinem oben genannten CApath aber auch in den oberen beiden Instanzen ersetzen durch

CAfile = /path/to/ca-certs.pem

Stunnel nutzt wohl vermutlich auf dem MAC nicht den Schlüsselbund dann müssen die CA-Certs in das File.
Also das Global-Root und optional das Intermediate concatenated in ein file kopieren.

Ich habe gerade nach der Anleitung auf stackexchange.com die Zertifikate importiert.

Im Bereich "System" der Schlüsselbundverwaltung sind jetzt unter Anderem die folgenden Zertifikate installiert:

T-TeleSec GlobalRoot Class 2 (verfällt 2033)
T-TeleSec GlobalRoot Class 3 (verfällt 2033)
TeleSec ServerPass Extended Validation Class 3 CA (verfällt 2024)

Ich habe auch alle 3 PEM-Dateien von ssl-tools.net im /etc/ssl/certs-Ordner abgelegt, aber die Fehlermeldung bei stunnel sobald ich mit Mail verbinde, bleibt nach wie vor gleich.

Muss ich die Datei an stunnel.pem anhängen, damit stunnel das Zertifikat annimmt?

Zitat von @DLippert:
Muss ich die Datei an stunnel.pem anhängen, damit stunnel das Zertifikat annimmt?

Nein, s. Ergänzung oben. Die gehören in ein separates CA File und in den obigen Instanzen die sich zu GMX verbinden mittels CAfile direktive hinterlegt

Zitat von @colinardo:

Zitat von @117471:
verwendet der root-User von deinem System denn das „Schlüsselbund“ des „normalen" Benutzers?

CAfile = /path/to/ca-certs.pem

Stunnel nutzt wohl vermutlich auf dem MAC nicht den Schlüsselbund dann müssen die CA-Certs in das File.
Also das Global-Root und optional das Intermediate concatenated in ein file kopieren.

Also kann ich als Basis dafür ja eigentlich die exportierten Root-Zertifikate aus dem neueren Mac OS nehmen, oder?

Zitat von @DLippert:
Also kann ich als Basis dafür ja eigentlich die exportierten Root-Zertifikate aus dem neueren Mac OS nehmen, oder?

Geht auch, klar.

OK, jetzt hat's funktioniert! Ich habe die exportierte Datei als stunnel.pem umbenannt und dort abgelegt und die Zeile geändert:

CAfile = /usr/local/etc/stunnel/stunnel.pem

Nun wird das Zertifikat schonmal akzeptiert, und es gibt nur noch die letzte Hürde auszubügeln:

06.18 12:49:03 LOG5[5]: Service [gmx-pop3-out] connected remote server from 10.0.1.12:49544
06.18 12:49:03 LOG5[5]: OCSP: Connecting the AIA responder "http://ocsp.telesec.de/ocspr"  
06.18 12:49:03 LOG5[5]: s_connect: connected 217.170.186.111:80
06.18 12:49:03 LOG5[5]: OCSP: Certificate accepted
06.18 12:49:03 LOG5[5]: OCSP: Connecting the AIA responder "http://ocsp.serverpass.telesec.de/ocspr"  
06.18 12:49:03 LOG5[5]: s_connect: connected 217.170.186.111:80
06.18 12:49:04 LOG5[5]: OCSP: Certificate accepted
06.18 12:49:04 LOG5[5]: Certificate accepted at depth=0: businessCategory=Private Organization, serialNumber=HRB 7666, jurisdictionL=Montabaur, jurisdictionST=Rheinland-Pfalz, jurisdictionC=DE, C=DE, ST=Rheinland-Pfalz, L=Montabaur, O=1&1 Mail & Media GmbH, CN=mail.gmx.net
06.18 12:49:04 LOG3[4]: Client does not want TLS
06.18 12:49:04 LOG5[4]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
06.18 12:49:04 LOG3[5]: readsocket: Connection reset by peer (54)
06.18 12:49:04 LOG5[5]: Connection reset: 0 byte(s) sent to TLS, 58 byte(s) sent to socket

Ich glaube, Du hast das schon mal erwähnt, wie man das genau konfigurieren muss, ich werde das nochmal genauestens studieren und schauen, wo der Fehler bei mir liegt!

Zitat von @DLippert:
2022.06.18 12:49:04 LOG3[4]: Client does not want TLS

Apple Mail muss nun auf den lokalen TLS-Port und SSL umgestellt werden. (Am besten Profil neu einrichten)

Jep, es geht! Ich hatte nur den zweifachen stunnel noch drin. Einfach von Mail direkt auf GMX ging es nun und ich habe meine Mails wieder empfangen können! Jetzt richte ich noch rasch das SMTP auch ein, und dann bin ich eigentlich wunschlos glücklich - vielen lieben Dank für Deine Unterstützung, ich weiß das wirklich sehr zu schätzen!

Ich werde, sobald ich alles fertig habe, eine Schritt-für-Schritt Anleitung hier hinterlegen, falls jemand anderes das selbe Problem hat, um diese Lösung so verständlich wie möglich weiterzugeben.

👍, so muss das sein.
Immer gerne und schönes Wochenende!

Grüße Uwe

GMX-Mail via Apple Mail (v6.6) unter Mac OS X 10.8.5 'Mountain Lion' einrichten - Die Anleitung

Schritt 1: Command Line Tools aktualisieren

Mithilfe eines Developer-Accounts (gratis mit einer Apple ID erstellbar) kann man bei Apple
die neueste Version der Entwicklertools für Mac OS X Mountain Lion herunterladen.

https://developer.apple.com/xcode/resources/

Dort geht man unten auf "Additional Downloads" und loggt sich mit seiner Apple ID ein.
Nun sucht man am besten direkt nach den 'Command Line Tools (OS X Mountain Lion) for Xcode - April 2014'
Diese müssen als erstes heruntergeladen und installiert werden.

Mithilfe einer Terminal-Sitzung kann man schnell mit dem Befehl 'clang -v' die Versionsnummern überprüfen:

clang -v
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin12.6.0
Thread model: posix

Sollte dies die Ausgabe sein, ist soweit alles korrekt installiert.

Schritt 2: OpenSSL 1.02u installieren

Hier kommt man zum Download der passenden Version:

https://www.openssl.org/source/old/1.0.2/

Hier am besten die neueste 1.0.2u downloaden. Die dazugehörige SHA256-Datei auch downloaden.

Terminal öffnen und damit in den Ordner mit den beiden Downloads navigieren.

Folgende Befehle zur Überprüfung ausführen:

openssl dgst -sha256 openssl-1.0.2u.tar.gz

more openssl-1.0.2u.tar.gz.sha256

Wenn die angezeigten Prüfsummen nicht übereinstimmen, sollte man die Dateien erneut herunterladen.
Sind die Prüfsummen identisch, geht es weiter mit:

tar -xzvf openssl-1.0.2u.tar.gz

cd openssl-1.0.2u

./configure darwin64-x86_64-cc

make

make test

sudo make install

Hier muss man sein Administrator-Kennwort vom Mac eingeben.
Nach diesem Vorgang hat man erfolgreich OpenSSL 1.02u installiert.

Schritt 3: stunnel 5.42 installieren

Hier kommt man zum Download der passenden Version:

http://ftp.vim.org/networking/stunnel/archive/5.x/

Hier die Version 5.42 und die dazugehörige SHA256-Datei downloaden.

Terminal öffnen und damit erneut in den Ordner mit den beiden Downloads navigieren.

Folgende Befehle zur Überprüfung ausführen:

openssl dgst -sha256 stunnel-5.42.tar.gz

more stunnel-5.42.tar.gz.sha256

Wenn die angezeigten Prüfsummen nicht übereinstimmen, sollte man die Dateien erneut herunterladen.
Sind die Prüfsummen identisch, dann geht es hier weiter:

cd stunnel-5.42

./configure && make && make check && sudo make install

Auch hier ist wieder die Eingabe des Administrator-Kennworts vom Mac erforderlich.
Nun ist auch stunnel 5.42 erfolgreich installiert und einsatzbereit.

Schritt 4: Root-Zertifikate aktualisieren

Damit stunnel anstandslos funktioniert, braucht es eine Zertifikatsdatei mit gültigen aktuellen Root-Zertifikaten.
Um diese zu erhalten gibt es verschiedene Wege.

Die einfachste ist es, einen neueren Mac zur Hand zu haben, auf dem ein Mac OS X ab 10.13 oder neuer läuft.
Falls dies der Fall ist, kann man hier im Ordner Dienstprogramme die Schlüsselbundverwaltung öffnen,
und dort links im Fenster bei Schlüsselbunde auf 'System-Roots' klicken, und darunter bei der Kategorie auf 'Zertifikate'.

Nun sieht man eine Liste aller Zertifikate, die in 'System-Roots' enthalten sind. Diese markiert man jetzt alle
und wählt im Menü 'Ablage' die Funktion 'Objekte exportieren…' aus.

Die so gesicherte Datei kann man dann in 'stunnel.pem' umbenennen. Diese Datei kopiert man dann auf den Mac mit dem OS X 10.8.5,
und zwar in den Ordner '/usr/local/etc/stunnel'. Dort wird sie später für die Konfiguration von stunnel benötigt.

Sollte man keinen neueren Mac zur Hand haben, kann man die nötigen Zertifikate für den GMX-Mailserver auch manuell herunterladen
und dann per 'cat'-Befehl zu einer Datei zusammenhängen, welche man dann ebenfalls stunnel.pem nennt und an den angegebenen Ort legt.
Downloadmöglichkeiten für diese Zertifikate finden sich hier:

https://de.ssl-tools.net/subjects/31e4c31bde81d32ad0d8ecacd40c3da4e71aeb ...
https://de.ssl-tools.net/subjects/7d9136a73aadb30e5548e30c7915c9479f234a ...
https://corporate-pki.telekom.de/downloads.html

Erwähnenswert ist noch, dass die Zugriffsrechte der Datei in '/usr/local/etc/stunnel/stunnel.pem' auf -rw-r----- (640)
gesetzt werden, damit stunnel sich nicht beschwert, dass diese Datei unsicher sei.

Schritt 5: stunnel konfigurieren

Dies ist ein Beispiel, welches bei mir wunderbar funktioniert, man kann also diese Zeilen direkt in eine Datei kopieren
und diese als 'stunnel.conf' in /usr/local/etc/stunnel/ abspeichern.

sslVersion = all
ciphers = ALL

[gmx-pop3-out]
client = yes
accept = 127.0.0.1:12110
connect = pop.gmx.net:995
verifyChain = yes
CAfile = /usr/local/etc/stunnel/stunnel.pem
checkHost = pop.gmx.net
OCSPaia = yes

[gmx-smtp-out]
client = yes
accept = 127.0.0.1:12025
connect = mail.gmx.net:465
verifyChain = yes
CAfile = /usr/local/etc/stunnel/stunnel.pem
checkHost = mail.gmx.net
OCSPaia = yes

Zum Überprüfen kann man eine Terminal-Sitzung öffnen und dort einfach nur 'stunnel' eingeben, welches dann starten sollte,
ohne eine Meldung auszugeben. Gibt es eine Fehlermeldung, ist es nicht korrekt konfiguriert.

Über die Aktivitätsanzeige (in Dienstprogramme) kann man nun den Prozess 'stunnel' sehen, wenn man danach sucht.
In diesem Fall hat alles bisher funktioniert. Falls nicht, bitte noch einmal die Konfigurationsdate prüfen,
ob alle Zeilen korrekt eingetragen sind und die Date am richtigen Ort liegt.

Schritt 6: Apple Mail konfigurieren

In Apples Mail muss man nun noch ein paar Änderungen der Konfiguration vornehmen, falls man bisher GMX dort empfangen hat.
Wichtig ist, dass man sowohl beim POP-Server als auch beim SMTP-Server die IP 127.0.0.1 eingibt, also localhost,
damit die Verbindung zu stunnel geleitet wird, bevor sie dann von dort aus zum GMX-Server weitergeleitet wird.

Nun deaktiviert man SSL und gibt für POP den Port 12110 und als Authentifizierung die Methode 'Kennwort' ein.
Beim SMTP-Server gibt man den Port 12025 ein, ebenfalls ohne SSL mit 'Kennwort' als Authentifizierungsmehode.

Nach dem Sichern der Änderungen für diesen Account sollte Mail sich wieder wie gehabt verbinden können und alle Mails empfangen und senden können.

Schritt 7: stunnel beim Systemstart ausführen

Damit stunnel nun dauerhaft läuft, ist es ratsam, die Software bei jedem Systemstart automatisch auszuführen,
so dass sie ständig die 'Brücke' zum GMX-Server hält. Hierfür gibt es unterschiedliche Wege.

Am einfachsten ist es, in Systemeinstellungen bei Nutzer und Gruppen das Programm aus /usr/local/bin/stunnel
bei den Anmeldeobjekten zu hinterlegen. Dann startet nach dem Booten eine Terminal-Sitzung und diese startet
dann automatisch den stunnel. Leider schließt sich das Fenster nicht wieder, was etwas unschön ist.

Eine sauberere Methode wäre es, im Ordner /Library/LaunchDaemons eine Datei anzulegen mit folgendem Inhalt:

<?xml version="1.0" encoding="UTF-8"?>  
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">  
<plist version="1.0">  
<dict>
	<key>Label</key>
	<string>com.deinname.startstunnel</string>
	<key>ProgramArguments</key>
	<array>
		<string>/usr/local/bin/stunnel</string>
	</array>
	<key>ServiceIPC</key>
	<false/>
	<key>OnDemand</key>
	<false/>
	<key>RunAtLoad</key>
	<true/>
</dict>
</plist>

Einfach bei 'deinname' einen Namen eingeben, und die Datei dann genauso nennen, also z.B. com.deinname.startstunnel.plist
Wichtig ist dann noch, dass die Datei als User root und als Gruppe wheel gehört und die Zugriffsrechte -rw-r--r-- (644) hat.

Wenn man das alles korrekt gemacht hat, startet stunnel unsichtbar bei jedem Systemstart, überprüfbar durch die Aktivitätsanzeige.

Viel Spaß weiterhin mit diesem Weg, GMX zu nutzen!

Vielen Dank auch an colinardo, foxm2k, cykes und altmetaller aus diesem Forum! Ohne eure Hilfe hätte ich diese Lösung nicht gefunden und hätte diese Anleitung nicht schreiben können.

LG, Daniel

gelöst Frage Internet E-Mail

Mehr von DLippert

GMX-Mail via Apple Mail (v6.6) unter Mac OS X 10.8.5 "Mountain Lion" einrichten - So geht esDLippert

Heiß diskutiert