[Frage] Gibt es in freetz ein Paket, das http zu https macht?

rspring

Mitglied
Mitglied seit
17 Nov 2006
Beiträge
204
Punkte für Reaktionen
2
Punkte
18
Ich habe ein dummes IOT-Gerät, das nur http kann. Es soll zu einem Service im Internet eine Anfrage senden. Die API akzeptiert aber nur https. Bietet freetz ein Paket, mit dem ich das umsetzen kann.
(Konkret: Ein ESP8266 mit tasmota misst meinen Solarstrom und soll ihn an pvoutput.org senden.)
 
Das könnte mit nem Proxy funktionieren. Ist squid noch Bestandteil? Allerdings werden da wohl erweiterte Konfigurationen und ggf. rewrite Regeln erforderlich. Ob man das auf einer Fritzbox abgebildet bekommt, weiß ich nicht.
 
Für stunnel habe ich diese config geschrieben:
[pvoutput.org https] client = yes accept = 8843 connect = pvoutput.org:443 CAfile = /tmp/flash/stunnel/certs.pem cert = /tmp/flash/stunnel/key.pem key = /tmp/flash/stunnel/key.pem
und nach Anleitung key & Zertifikat in der Web-GUI eingetragen, bekomme aber diesen Fehler:

[!] error queue: NA:0: error:140DC009:lib(20):func(220):reason(9)
[!] SSL_CTX_use_certificate_chain_file: NA:0: error:0909006C:lib(9):func(144):reason(108)
[!] Service [pvoutput.org https]: Failed to initialize TLS context
[!] Configuration failed

Was mache ich falsch?
 
Erstens würde ich noch einen SNI-Header hinzufügen lassen (Parameter SNI im Client-Mode) und zweitens wäre es schon hilfreich, den Inhalt der in der Konfiguration angegebenen Dateien zu kennen.

Für einen "anonymous client" (der sich also nicht gegenüber dem Server bei pvoutput.org mit seinem eigenen Zertifikat ausweisen soll/muß - und davon steht hier nirgendwo etwas) macht das irgendwie keinen Sinn, wenn man die Parameter cert und key angibt.

Auf der "client side" (also da, wo das accept() wartet), gibt es gar kein TLS, also auch keine Notwendigkeit für Zertifikat und/oder Private-Key und auf der TLS-Seite (da, wo stunnel dann die Verbindung zum Server aufnimmt) bräuchte man das auch nur, wenn man mittels "client certificates" eine Authentifizierung vornehmen wollte.

Ist das (mittlerweile) tatsächlich so bei pvoutput.org? Ich dachte ja immer, deren API erfordert einen speziellen HTTP-Header mit einem Key für die Authentifizierung: https://pvoutput.org/help/api_specification.html#getting-started

Insgesamt aber immer noch zu wenig Information, um jenseits von "Raten" irgendwelche sinnvollen Vorschläge zu machen.

Sollte sich das Ganze dann doch nur als falscher Gebrauch von Parametern herausstellen [BTW ... man KANN sich die Fehlermeldungen (das sind oben die "Zahlen" 140DC009 und 0909006C) auch mit einem openssl errstr <error-code> in eine (etwas) aussagekräftigere Nachricht "übersetzen" lassen.], wäre es (falls das vom Server vorgelegte Zertifikat geprüft werden soll) noch wichtig zu verifizieren, daß auch LE-Zertifikate korrekt bis zur passenden Root-CA verfolgt werden können:
Rich (BBCode):
vidar:~ $ echo | openssl s_client -connect pvoutput.org:443 -showcerts | openssl x509 -noout -text
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = pvoutput.org
verify return:1
DONE
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:82:e2:19:f1:c5:79:64:b5:2f:90:40:26:70:6f:af:66:12
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Let's Encrypt, CN = R3
        Validity
            Not Before: Apr  4 13:10:48 2022 GMT
            Not After : Jul  3 13:10:47 2022 GMT
        Subject: CN = pvoutput.org
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:d1:cc:75:0b:b6:5d:aa:3f:fc:fd:23:2e:7b:f8:
                    ae:43:52:6b:dc:7c:94:0d:a8:eb:82:6c:3c:28:33:
                    63:f7:a2:b3:96:c9:cb:a3:6f:4e:f1:8f:c7:28:bb:
                    52:a6:ec:e9:fa:9a:a8:54:35:9f:4a:f4:45:fe:2a:
                    da:0d:80:cc:3c:20:ba:1c:2c:94:aa:96:03:65:c1:
                    3a:a6:96:98:cf:fc:23:3f:c0:87:9a:1e:b5:40:40:
                    70:8a:d8:69:c6:07:27:b1:e6:b9:02:60:6e:5f:0a:
                    88:d1:be:32:e3:79:a1:f0:99:aa:8b:93:af:b7:cc:
                    10:b0:47:16:ba:59:a3:36:f6:ac:08:66:52:e8:d9:
                    34:f8:fb:87:cc:3d:05:29:df:b2:dc:7a:e8:e9:0a:
                    88:e0:cb:f4:4a:b9:f7:78:b4:e0:f8:d8:84:32:73:
                    9d:72:d7:aa:ac:a3:f1:25:f6:57:b8:3c:dc:8b:1c:
                    5f:c3:7e:75:30:b6:88:06:67:8e:ec:8b:2a:e8:24:
                    41:05:86:fe:cf:c7:5e:e0:78:51:8a:8f:b1:e2:b9:
                    52:15:55:82:9c:b3:2d:58:72:e3:ed:a3:4e:a0:66:
                    53:fe:41:78:45:dc:ca:4c:65:ca:e3:40:8a:ac:d5:
                    e0:bf:ea:9c:ab:5b:81:24:15:c4:12:41:9d:fa:eb:
                    80:09
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                04:4A:A8:34:1A:9C:94:14:C1:E6:E2:EF:95:83:21:BC:59:58:7E:6F
            X509v3 Authority Key Identifier:
                keyid:14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C2:C6

            Authority Information Access:
                OCSP - URI:http://r3.o.lencr.org
                CA Issuers - URI:http://r3.i.lencr.org/

            X509v3 Subject Alternative Name:
                DNS:pvoutput.org, DNS:www.pvoutput.org
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.44947.1.1.1
                  CPS: http://cps.letsencrypt.org

            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 29:79:BE:F0:9E:39:39:21:F0:56:73:9F:63:A5:77:E5:
                                BE:57:7D:9C:60:0A:F8:F9:4D:5D:26:5C:25:5D:C7:84
                    Timestamp : Apr  4 14:10:48.646 2022 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:46:02:21:00:8B:04:0E:9A:B3:51:13:69:81:52:CC:
                                D2:05:46:83:4D:26:D4:03:FD:E1:D4:68:D2:A5:CE:21:
                                22:E2:33:E2:D5:02:21:00:89:F2:FA:02:97:8E:02:F1:
                                85:1E:A4:38:07:F6:65:11:6B:AE:B9:30:1D:91:6A:62:
                                F2:7A:F9:AB:55:3C:1B:13
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 41:C8:CA:B1:DF:22:46:4A:10:C6:A1:3A:09:42:87:5E:
                                4E:31:8B:1B:03:EB:EB:4B:C7:68:F0:90:62:96:06:F6
                    Timestamp : Apr  4 14:10:49.185 2022 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:72:27:4D:16:6E:CE:AF:F6:E8:3D:2A:8D:
                                E7:E8:A6:20:5D:B5:03:E7:9E:DC:55:59:C0:B8:E8:F7:
                                B7:D3:FD:DC:02:20:78:D4:9D:EF:6A:B8:71:12:11:57:
                                1E:47:57:06:E9:AC:32:BD:18:C1:15:59:5D:64:73:3B:
                                C3:A5:E0:D1:2E:02
    Signature Algorithm: sha256WithRSAEncryption
         a2:d9:5f:88:d6:e1:a7:29:5f:27:b7:4b:df:23:0b:b2:83:dd:
         4b:5d:3f:d1:cd:0b:67:98:3c:8e:ed:79:72:39:69:09:64:af:
         52:47:03:60:ee:25:11:b7:f9:df:80:c2:82:f6:a4:b2:f0:77:
         78:63:02:19:f1:7d:27:39:23:e0:50:77:55:a3:3f:ef:dd:3a:
         8d:e7:4c:3f:34:bb:9e:64:cd:8f:69:68:86:a3:2f:f1:5d:78:
         56:d0:9f:f5:9d:fa:69:d4:bd:2c:04:23:55:5f:d8:6d:d0:63:
         1e:f7:86:90:4a:72:25:c1:b8:31:f4:51:cc:13:5c:20:f2:72:
         f4:3c:a1:c0:c9:fd:08:87:a6:45:49:d3:0f:4e:06:c9:0c:84:
         0d:23:5b:b0:67:cb:d7:ad:37:57:58:43:d0:51:37:7a:ae:19:
         e6:3c:47:a7:e7:19:ca:76:90:1f:91:53:3e:68:02:f7:66:19:
         7a:6e:18:e2:e7:f9:12:b3:28:5e:8b:7b:8f:92:03:5e:47:af:
         2a:fc:bd:1a:70:57:ca:a8:1f:a0:98:65:1b:c2:2c:7e:90:19:
         d1:d8:64:63:b4:ca:f2:d6:9c:e1:a5:92:78:e4:78:09:db:d8:
         35:d2:f1:85:a3:05:36:93:6d:8d:d9:b8:98:fe:69:4b:77:78:
         05:4a:c7:9f
vidar:~ $
 
Danke @PeterPawn für deine ausführliche Antwort. Sie übersteigt leider bei weitem mein Wissen zu Protokollen etc. Ich kann nur sagen, daß ich z.B. mit
curl https://pvoutput.org/service/r2/addoutput.jsp?key=Your-API-Key&sid=Your-System-Id&d=20100830&g=12000
mein Konto ansprechen kann. Ich dachte nun, mit stunnel kann ich diese Anfrage an
senden und stunnel macht daraus eine korrekte https-Anfrage. Was sonst wo in irgend einem header stehen muß weiß ich nicht. Das stunnel setup habe ich nach der o. g. stunnel-Hilfe aufgesetzt in der Annahme, daß das den Fall meint.
 
Was soll denn
nach der o. g. stunnel-Hilfe
genau sein?

Das Beispiel in Freetz zeigt ja deutlich "client = no" in der Konfiguration.

Ansonsten gibt es bei stunnel auch genug zu lesen ... DAS ist dann auch wieder über die kurze Freetz-Seite zu finden: https://www.stunnel.org/howto.html (Do I need a valid certificate?)

EDIT:
Ich habe es gerade mal selbst mit stunnel probiert (halt auf einem Server und nicht auf einer FRITZ!Box) ... einfach "client = yes", "accept" und "connect" richtig eingesetzt und (ggf. noch ein "verifyChain = no", zumindest für den Anfang und die "grundsätzliche" Konfiguration - das Prüfen der Chain kann man immer noch aktivieren, wenn der Rest erst mal funktioniert) und schon sollte das "aus dem Stand" funktionieren. "CAfile" wird erst benötigt, wenn man WIRKLICH Zertifikate bis zum Ursprung validieren will.
 
rspring, soweit ich Dich verstehe, möchtest Du eine unverschlüsselte Server-Verbindung in eine verschlüsselte Client-Verbindung wandeln. In dem Fall machst Du ein client = yes und ein accept = Port. Und dann noch ein connect =. Genau wie Du es gemacht hast. Die aktuellen Versionen von Stunnel senden dann auch automatisch den SNI.

Was Du nicht brauchst, sind die PEM-Dateien, weil Du lokal keinen verschlüsselte Server-Verbindung hast. Warum Du jetzt so einen Fehler bekommst … Schluck. Kannst Du die Verbosity ein wenig höher drehen, also debug = info vor dem Kontext?
 
Auch mit
[pvoutput.org https]
client = yes
accept = 8843
connect = pvoutput.org:443
verifyChain = no
kommt der Fehler
[!] SSL_CTX_use_certificate_chain_file: NA:0: error:140AB18F:lib(20):func(171):reason(399)
[!] Service [pvoutput.org https]: Failed to initialize TLS context
[!] Configuration failed

Und lt. stunnel.org MUSS ein Zertifikat da sein ob es genutzt wird oder nicht:
"

Do I need a valid certificate?​

Stunnel does need a pem file, regardless whether or not the data is used.
"
Ich habe eigentlich die denkbar trivialste Anwendung und bekomme es nicht hin. Schade.
 
Du siehst aber schon, daß das jetzt ein anderer Fehler ist?

Was sagt Dir denn "das Internet", wenn Du mit der dazugehörenden Fehlermeldung (wie Du an deren Text kommst, habe ich oben gezeigt) nach Leidensgenossen suchst?

Ich würde ja immer noch gerne die INHALTE von Dateien sehen wollen (private Schlüssel MÜSSEN nicht sein, sind aber - wenn man sie mit einem Kennwort versehen hat - i.d.R. auch nicht problematisch), denn es bleibt unklar, warum hier überhaupt ein eigener Schlüssel benutzt werden sollte, dessen Länge offensichtlich nicht ausreicht.



Wobei das eigentlich auch nur eine Einstellung in der benutzten SSL-Library sein kann - aber auch das ist nur geraten, denn es fehlen praktisch ALLE Angaben zu den verwendeten Programmen, das geht beim Modell der FRITZ!Box los, zieht sich über die Freetz(-NG?)-Version bis zur verwendeten Konfigurationsdatei für den Freetz-Build (wo man sich das NOTFALLS noch selbst ansehen könnte, auch wenn sich eigentlich das "Vorzeigen" dieser Angaben durch den Fragesteller von selbst verstehen sollte) und auch stunnel kann ein entsprechendes Protokoll erstellen. In der Konfigurationsdatei kann man dann auch noch festlegen, ob das ins Syslog oder in eine Datei geschrieben werden soll.

Stunnel does need a pem file, regardless whether or not the data is used.
Das steht da tatsächlich, ist aber ein Widerspruch zu hier: https://www.stunnel.org/static/stunnel.html

cert = CERT_FILE
certificate chain file name

The parameter specifies the file containing certificates used by stunnel to authenticate itself against the remote client or server. The file should contain the whole certificate chain starting from the actual server/client certificate, and ending with the self-signed root CA certificate. The file must be either in PEM or P12 format.

A certificate chain is required in server mode, and optional in client mode.

This parameter is also used as the certificate identifier when a hardware engine is enabled.
Die weiter oben noch "gezeigten" Parameter cert, key und CAfile haben (im Moment jedenfalls, wo erst mal das Prinzip funktionieren soll und erst später das LE-Zertifikat von pvoutput.org geprüft werden soll) KEINEN Platz in der entsprechenden Service-Konfiguration, wo stunnel nur als Client aktiv werden soll.

Mit dieser Datei (das ist das "Standard-File", was eigentlich vom stunnel installiert werden sollte) klappt das jedenfalls ... auch ohne die Angabe irgendeines eigenen Schlüssels und/oder Zertifikats:
Rich (BBCode):
peh@vidar:~> sudo cat /etc/stunnel/stunnel.conf
[sudo] password for root:
# Sample stunnel configuration file for Unix by Michal Trojnara 1998-2022
# 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 = stunnel
setgid = nogroup

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

# Debugging stuff (may be useful for troubleshooting)
#foreground = yes
#debug = info
debug = 7
output = /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 = /etc/stunnel/conf.d

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

# ***************************************** Example TLS client mode services

[pvoutput.org]
client = yes
accept = 8088
connect = pvoutput.org:443
verifyChain = no

# 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 /etc/stunnel/.

#[gmail-pop3]
#client = yes
#accept = 127.0.0.1:110
#connect = pop.gmail.com:995
#verifyChain = yes
#CApath = /etc/ssl/certs
#checkHost = pop.gmail.com
#OCSPaia = yes

#[gmail-imap]
#client = yes
#accept = 127.0.0.1:143
#connect = imap.gmail.com:993
#verifyChain = yes
#CApath = /etc/ssl/certs
#checkHost = imap.gmail.com
#OCSPaia = yes

#[gmail-smtp]
#client = yes
#accept = 127.0.0.1:25
#connect = smtp.gmail.com:465
#verifyChain = yes
#CApath = /etc/ssl/certs
#checkHost = smtp.gmail.com
#OCSPaia = yes

# 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 = /etc/stunnel/stunnel.pem

#[imaps]
#accept  = 993
#connect = 143
#cert = /etc/stunnel/stunnel.pem

# Either only expose this service to trusted networks, or require
# authentication when relaying emails originated from loopback.
# Otherwise the following configuration creates an open relay.
#[ssmtp]
#accept  = 465
#connect = 25
#cert = /etc/stunnel/stunnel.pem

# TLS front-end to a web server
#[https]
#accept  = 443
#connect = 80
#cert = /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 "/etc/stunnel/secrets.txt" containing IDENTITY:KEY pairs
#[shell]
#accept = 1337
#exec = /bin/sh
#execArgs = sh -i
#PSKsecrets = /etc/stunnel/secrets.txt

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

# vim:ft=dosini
peh@vidar:~>
Wenn da bei Dir irgendwie versucht wird, einen Key bzw. ein Zertifikat zu finden, zu öffnen und zu verwenden (darauf deutet die Fehlermeldung hin), dann kann das eigentlich nur daran liegen, daß da noch IRGENDWO ein Parameter gesetzt ist, der zum Zugriffsversuch auf diese Datei animiert. EDIT: Die Einstellungen für setuid und setgid solltest Du erst einmal AUCH NICHT verwenden (bringt im FRITZ!OS ohnehin fast nichts an zusätzlicher Sicherheit, weil praktisch alle Prozesse als root laufen).

Zeig doch mal die VOLLSTÄNDIGE Konfigurationsdatei ...

Ich kann jedenfalls auch im "ausführlichen Protokoll" (mit der o.a. Konfiguration, nur noch das foreground = yes "einkommentiert") keinen Zugriff auf irgendeine Datei erkennen (die bräuchte es eben nur für den "server mode" bei client = no):
Rich (BBCode):
vidar:/tmp # strace -o stunnel.strace -ff stunnel /etc/stunnel/stunnel.conf
2022.04.27 14:14:20 LOG6[ui]: Initializing inetd mode configuration
2022.04.27 14:14:20 LOG7[ui]: Clients allowed=500
2022.04.27 14:14:20 LOG5[ui]: stunnel 5.63 on x86_64-suse-linux-gnu platform
2022.04.27 14:14:20 LOG5[ui]: Compiled/running with OpenSSL 1.1.1n  15 Mar 2022
2022.04.27 14:14:20 LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,OCSP,PSK,SNI Auth:LIBWRAP
2022.04.27 14:14:20 LOG7[ui]: errno: (*__errno_location ())
2022.04.27 14:14:20 LOG6[ui]: Initializing inetd mode configuration
2022.04.27 14:14:20 LOG5[ui]: Reading configuration from file /etc/stunnel/stunnel.conf
2022.04.27 14:14:20 LOG5[ui]: UTF-8 byte order mark detected
2022.04.27 14:14:20 LOG7[ui]: "/etc/stunnel/conf.d/." is not a file
2022.04.27 14:14:20 LOG7[ui]: "/etc/stunnel/conf.d/.." is not a file
2022.04.27 14:14:20 LOG5[ui]: FIPS mode disabled
2022.04.27 14:14:20 LOG6[ui]: Compression enabled: 0 methods
2022.04.27 14:14:20 LOG7[ui]: No PRNG seeding was required
2022.04.27 14:14:20 LOG6[ui]: Initializing service [pvoutput.org]
2022.04.27 14:14:20 LOG6[ui]: OpenSSL security level is used: 2
2022.04.27 14:14:20 LOG7[ui]: Ciphers: HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK
2022.04.27 14:14:20 LOG7[ui]: TLSv1.3 ciphersuites: TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256
2022.04.27 14:14:20 LOG7[ui]: TLS options: 0x2100004 (+0x0, -0x0)
2022.04.27 14:14:20 LOG6[ui]: Session resumption enabled
2022.04.27 14:14:20 LOG7[ui]: No certificate or private key specified
2022.04.27 14:14:20 LOG4[ui]: Service [pvoutput.org] needs authentication to prevent MITM attacks
2022.04.27 14:14:20 LOG6[ui]: DH initialization skipped: client section
2022.04.27 14:14:20 LOG7[ui]: ECDH initialization
2022.04.27 14:14:20 LOG7[ui]: ECDH initialized with curves X25519:P-256:X448:P-521:P-384
2022.04.27 14:14:20 LOG5[ui]: Configuration successful
2022.04.27 14:14:20 LOG7[ui]: Deallocating deployed section defaults
2022.04.27 14:14:20 LOG7[ui]: Binding service [pvoutput.org]
2022.04.27 14:14:20 LOG7[ui]: Listening file descriptor created (FD=9)
2022.04.27 14:14:20 LOG7[ui]: Setting accept socket options (FD=9)
2022.04.27 14:14:20 LOG7[ui]: Option SO_REUSEADDR set on accept socket
2022.04.27 14:14:20 LOG6[ui]: Service [pvoutput.org] (FD=9) bound to 0.0.0.0:8088
2022.04.27 14:14:20 LOG7[ui]: Listening file descriptor created (FD=10)
2022.04.27 14:14:20 LOG7[ui]: Setting accept socket options (FD=10)
2022.04.27 14:14:20 LOG7[ui]: Option SO_REUSEADDR set on accept socket
2022.04.27 14:14:20 LOG5[ui]: Binding service [pvoutput.org] to :::8088: Address already in use (98)
2022.04.27 14:14:20 LOG7[ui]: No pid file being created
2022.04.27 14:14:20 LOG7[cron]: Cron thread initialized
2022.04.27 14:14:20 LOG6[cron]: Executing cron jobs
2022.04.27 14:14:20 LOG6[cron]: Cron jobs completed in 0 seconds
2022.04.27 14:14:20 LOG7[cron]: Waiting 86400 seconds
2022.04.27 14:14:24 LOG7[ui]: Found 1 ready file descriptor(s)
2022.04.27 14:14:24 LOG7[ui]: FD=4 events=0x2001 revents=0x0
2022.04.27 14:14:24 LOG7[ui]: FD=9 events=0x2001 revents=0x1
2022.04.27 14:14:24 LOG7[ui]: Service [pvoutput.org] accepted (FD=3) from 127.0.0.1:46888
2022.04.27 14:14:24 LOG7[0]: Service [pvoutput.org] started
2022.04.27 14:14:24 LOG7[0]: Setting local socket options (FD=3)
2022.04.27 14:14:24 LOG7[0]: Option TCP_NODELAY set on local socket
2022.04.27 14:14:24 LOG5[0]: Service [pvoutput.org] accepted connection from 127.0.0.1:46888
2022.04.27 14:14:24 LOG6[0]: s_connect: connecting 45.56.66.169:443
2022.04.27 14:14:24 LOG7[0]: s_connect: s_poll_wait 45.56.66.169:443: waiting 10 seconds
2022.04.27 14:14:24 LOG7[0]: FD=6 events=0x2001 revents=0x0
2022.04.27 14:14:24 LOG7[0]: FD=11 events=0x2005 revents=0x0
2022.04.27 14:14:24 LOG5[0]: s_connect: connected 45.56.66.169:443
2022.04.27 14:14:24 LOG5[0]: Service [pvoutput.org] connected remote server from 192.168.131.2:37582
2022.04.27 14:14:24 LOG7[0]: Setting remote socket options (FD=11)
2022.04.27 14:14:24 LOG7[0]: Option TCP_NODELAY set on remote socket
2022.04.27 14:14:24 LOG7[0]: Remote descriptor (FD=11) initialized
2022.04.27 14:14:24 LOG6[0]: SNI: sending servername: pvoutput.org
2022.04.27 14:14:24 LOG6[0]: Peer certificate not required
2022.04.27 14:14:24 LOG7[0]: TLS state (connect): before SSL initialization
2022.04.27 14:14:24 LOG7[0]: Initializing application specific data for session authenticated
2022.04.27 14:14:24 LOG7[0]: TLS state (connect): SSLv3/TLS write client hello
2022.04.27 14:14:24 LOG7[0]: TLS state (connect): SSLv3/TLS write client hello
2022.04.27 14:14:24 LOG7[0]: TLS state (connect): SSLv3/TLS read server hello
2022.04.27 14:14:24 LOG6[0]: Certificate verification disabled
2022.04.27 14:14:24 LOG6[0]: Certificate verification disabled
2022.04.27 14:14:24 LOG7[0]: TLS state (connect): SSLv3/TLS read server certificate
2022.04.27 14:14:24 LOG7[0]: TLS state (connect): SSLv3/TLS read server key exchange
2022.04.27 14:14:24 LOG6[0]: Client certificate not requested
2022.04.27 14:14:24 LOG7[0]: TLS state (connect): SSLv3/TLS read server done
2022.04.27 14:14:24 LOG7[0]: TLS state (connect): SSLv3/TLS write client key exchange
2022.04.27 14:14:24 LOG7[0]: TLS state (connect): SSLv3/TLS write change cipher spec
2022.04.27 14:14:24 LOG7[0]: TLS state (connect): SSLv3/TLS write finished
2022.04.27 14:14:24 LOG7[0]: TLS state (connect): SSLv3/TLS write finished
2022.04.27 14:14:24 LOG7[0]: TLS state (connect): SSLv3/TLS read server session ticket
2022.04.27 14:14:24 LOG7[0]: TLS state (connect): SSLv3/TLS read change cipher spec
2022.04.27 14:14:24 LOG7[0]: TLS state (connect): SSLv3/TLS read finished
2022.04.27 14:14:24 LOG7[0]: New session callback
2022.04.27 14:14:24 LOG7[0]: Peer certificate was cached (3684 bytes)
2022.04.27 14:14:24 LOG6[0]: Session id: 986AB872E3F0F186764707FF75850C9EB955048246868191039FB58D9A9B0287
2022.04.27 14:14:24 LOG7[0]:      1 client connect(s) requested
2022.04.27 14:14:24 LOG7[0]:      1 client connect(s) succeeded
2022.04.27 14:14:24 LOG7[0]:      0 client renegotiation(s) requested
2022.04.27 14:14:24 LOG7[0]:      0 session reuse(s)
2022.04.27 14:14:24 LOG6[0]: TLS connected: new session negotiated
2022.04.27 14:14:24 LOG6[0]: TLSv1.2 ciphersuite: ECDHE-RSA-AES256-GCM-SHA384 (256-bit encryption)
2022.04.27 14:14:24 LOG6[0]: Peer temporary key: ECDH, P-256, 256 bits
2022.04.27 14:14:24 LOG7[0]: Compression: null, expansion: null
2022.04.27 14:14:24 LOG6[0]: Read socket closed (readsocket)
2022.04.27 14:14:24 LOG7[0]: Sending close_notify alert
2022.04.27 14:14:24 LOG7[0]: TLS alert (write): warning: close notify
2022.04.27 14:14:24 LOG6[0]: SSL_shutdown successfully sent close_notify alert
2022.04.27 14:14:24 LOG7[0]: TLS alert (read): warning: close notify
2022.04.27 14:14:24 LOG6[0]: TLS closed (SSL_read)
2022.04.27 14:14:24 LOG7[0]: Sent socket write shutdown
2022.04.27 14:14:24 LOG5[0]: Connection closed: 129 byte(s) sent to TLS, 4043 byte(s) sent to socket
2022.04.27 14:14:24 LOG7[0]: Remote descriptor (FD=11) closed
2022.04.27 14:14:24 LOG7[0]: Local descriptor (FD=3) closed
2022.04.27 14:14:24 LOG7[0]: Service [pvoutput.org] finished (0 left)
^C2022.04.27 14:14:33 LOG7[ui]: Found 1 ready file descriptor(s)
2022.04.27 14:14:33 LOG7[ui]: FD=4 events=0x2001 revents=0x1
2022.04.27 14:14:33 LOG7[ui]: FD=9 events=0x2001 revents=0x0
2022.04.27 14:14:33 LOG7[ui]: Dispatching a signal from the signal pipe
2022.04.27 14:14:33 LOG3[ui]: Received SIGINT; terminating
2022.04.27 14:14:33 LOG7[ui]: Leak detection table utilization: 15/997, 1.50%
2022.04.27 14:14:33 LOG7[ui]: No pid file to remove
2022.04.27 14:14:33 LOG7[ui]: Terminating the cron thread
2022.04.27 14:14:33 LOG6[ui]: Terminating 1 service thread(s)
2022.04.27 14:14:33 LOG6[ui]: Service threads terminated
2022.04.27 14:14:33 LOG7[ui]: Unbinding service [pvoutput.org]
2022.04.27 14:14:33 LOG7[ui]: Service [pvoutput.org] closed (FD=9)
2022.04.27 14:14:33 LOG7[ui]: Service [pvoutput.org] closed
vidar:/tmp #
(bei der grünen Zeile startete ein stinknormales wget -O - http://localhost:8088, das dann zu pvoutput.org verbunden wurde) und auch im strace ist nichts zu sehen, daß da irgendein Key geöffnet würde:
Rich (BBCode):
vidar:/tmp # grep open stunnel.strace.279*
stunnel.strace.27928:openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
stunnel.strace.27928:openat(AT_FDCWD, "/lib64/libssl.so.1.1", O_RDONLY|O_CLOEXEC) = 3
stunnel.strace.27928:openat(AT_FDCWD, "/lib64/libcrypto.so.1.1", O_RDONLY|O_CLOEXEC) = 3
stunnel.strace.27928:openat(AT_FDCWD, "/lib64/libwrap.so.0", O_RDONLY|O_CLOEXEC) = 3
stunnel.strace.27928:openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
stunnel.strace.27928:openat(AT_FDCWD, "/lib64/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
stunnel.strace.27928:openat(AT_FDCWD, "/lib64/.libcrypto.so.1.1.hmac", O_RDONLY) = -1 ENOENT (No such file or directory)
stunnel.strace.27928:openat(AT_FDCWD, "/proc/sys/crypto/fips_enabled", O_RDONLY) = 3
stunnel.strace.27928:openat(AT_FDCWD, "/dev/null", O_RDWR)   = 3
stunnel.strace.27928:openat(AT_FDCWD, "/etc/ssl/openssl.cnf", O_RDONLY) = 4
stunnel.strace.27928:openat(AT_FDCWD, "/etc/localtime", O_RDONLY|O_CLOEXEC) = 4
stunnel.strace.27928:openat(AT_FDCWD, "/etc/stunnel/stunnel.conf", O_RDONLY|O_NONBLOCK|O_CLOEXEC) = 8
stunnel.strace.27928:openat(AT_FDCWD, "/etc/stunnel/conf.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 9
stunnel.strace.27928:openat(AT_FDCWD, "/etc/gai.conf", O_RDONLY|O_CLOEXEC) = 8
stunnel.strace.27928:openat(AT_FDCWD, "/etc/crypto-policies/back-ends/openssl.config", O_RDONLY) = 8
stunnel.strace.27928:openat(AT_FDCWD, "/var/log/stunnel.log", O_WRONLY|O_CREAT|O_APPEND|O_NONBLOCK|O_CLOEXEC, 0640) = 10
stunnel.strace.27929:openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 4
stunnel.strace.27929:openat(AT_FDCWD, "/lib64/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 4
vidar:/tmp #
Es GIBT also (mit passender Konfiguration) KEINEN Zugriff auf einen privaten Schlüssel oder ein Zertifikat, solange man wirklich nur einen "client"-Service so konfiguriert hat, wie das oben zu sehen ist. Daher MUSS es da noch irgendeinen anderen Parameter geben - ggf. wird der ja vom Freetz-Interface automatisch gesetzt. Denn der eigentliche Zweck dieses Pakets war es ja einmal (dahin zielt auch die Beschreibung bzw. das Beispiel in der Freetz-Dokumentation), als TLS-Server für das Freetz-GUI zu dienen und dafür braucht es dann tatsächlich ein eigenes Zertifikat (das auch "self-signed" sein kann).

Ich habe eigentlich die denkbar trivialste Anwendung und bekomme es nicht hin. Schade.
Nicht aufgeben ... vielleicht funkt ja tatsächlich nur das Freetz-GUI dazwischen. Ich würde aber, bevor ich mich da "in die Tiefe stürze", gerne erst einmal sicher sein, daß es nicht doch nur an einem Konfigurationsfehler auf Deiner Seite liegt.

Es ist schon einige Jahre her, daß ich mich zuletzt mit dem stunnel-Paket in Freetz befaßt habe (https://www.ip-phone-forum.de/threads/fritz-box-zertifikat-auf-der-box-für-andere-software-mit-tls-verschlüsselung-benutzen.279420/#post-2096745) und auch dabei ging es eigentlich ums Patches des Programms und nicht um die Konfigurationsmöglichkeiten in der Freetz-Oberfläche: https://github.com/Freetz/freetz/pull/16/commits/6a1978de3922915f3d11afac8a9a2acf77f7108d

Ohne mir das ganz genau anzusehen, weiß ich aber nicht (auch weil ich selbst gar kein Freetz oder Freetz-NG nutze auf einer Box), ob da tatsächlich IMMER ein Server-Dienst konfiguriert wird oder ob man auch eine "custom config" hinterlegen kann, bei der die Konfiguration NICHT beim Start aus Einstellungen im GUI konfiguriert wird. Wobei auch ein ständig aktiver Server-Dienst ja noch KEIN K.O.-Kriterium sein muß, WENN Du den Key denn korrekt erstellst (was wieder zum Beginn dieses Beitrags führt).
 
Zuletzt bearbeitet:
Der Fehler war bei mir ähnlich, dann hab ich das gefunden
und entgegen der Anleitung hier
den host.key so erzeugt
openssl genrsa 2048 > host.key
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.