Hi. Can someone tell me why Stunnel stops at wating 10s? Log:
2020.03.12 09:43:36 LOG6[main]: Initializing service [x3_x4_DICOM_BFT_client] 2020.03.12 09:43:36 LOG7[main]: Ciphers: HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK 2020.03.12 09:43:36 LOG7[main]: TLSv1.3 ciphersuites: TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256 2020.03.12 09:43:36 LOG7[main]: TLS options: 0x02100004 (+0x00000000, -0x00000000) 2020.03.12 09:43:36 LOG6[main]: Loading certificate from file: x1.dc.x2.se_201900604.pem 2020.03.12 09:43:36 LOG6[main]: Certificate loaded from file: x1.dc.x2.se_201900604.pem 2020.03.12 09:43:36 LOG6[main]: Loading private key from file: x1.dc.x2.se_201900604.pem 2020.03.12 09:43:36 LOG6[main]: Private key loaded from file: x1.dc.x2.se_201900604.pem 2020.03.12 09:43:36 LOG7[main]: Private key check succeeded 2020.03.12 09:43:36 LOG4[main]: Service [x3_x4_DICOM_BFT_client] uses "verifyChain" without subject checks 2020.03.12 09:43:36 LOG4[main]: Use "checkHost" or "checkIP" to restrict trusted certificates 2020.03.12 09:43:36 LOG5[main]: Configuration successful 2020.03.12 09:43:36 LOG7[main]: Binding service [x3_x4_HL7_BFT_client] 2020.03.12 09:43:36 LOG7[main]: Listening file descriptor created (FD=380) 2020.03.12 09:43:36 LOG7[main]: Setting accept socket options (FD=380) 2020.03.12 09:43:36 LOG7[main]: Option SO_EXCLUSIVEADDRUSE set on accept socket 2020.03.12 09:43:36 LOG6[main]: Service [x3_x4_HL7_BFT_client] (FD=380) bound to 127.0.0.1:46161 2020.03.12 09:43:36 LOG7[main]: Binding service [x3_x4_DICOM_BFT_client] 2020.03.12 09:43:36 LOG7[main]: Listening file descriptor created (FD=492) 2020.03.12 09:43:36 LOG7[main]: Setting accept socket options (FD=492) 2020.03.12 09:43:36 LOG7[main]: Option SO_EXCLUSIVEADDRUSE set on accept socket 2020.03.12 09:43:36 LOG6[main]: Service [x3_x4_DICOM_BFT_client] (FD=492) bound to 127.0.0.1:46162 2020.03.12 09:43:36 LOG7[cron]: Cron thread initialized 2020.03.12 09:43:36 LOG6[cron]: Executing cron jobs 2020.03.12 09:43:36 LOG6[cron]: Cron jobs completed in 0 seconds 2020.03.12 09:43:36 LOG7[cron]: Waiting 86400 seconds 2020.03.12 09:44:37 LOG7[main]: Found 1 ready file descriptor(s) 2020.03.12 09:44:37 LOG7[main]: FD=380 ifds=r-x ofds=r-- 2020.03.12 09:44:37 LOG7[main]: FD=388 ifds=r-x ofds=--- 2020.03.12 09:44:37 LOG7[main]: Service [SOS_SYNGO_HL7_BFT_client] accepted (FD=508) from 127.0.0.1:50299 2020.03.12 09:44:37 LOG7[main]: Creating a new thread 2020.03.12 09:44:37 LOG7[main]: New thread created 2020.03.12 09:44:37 LOG7[0]: Service [x3_x4_HL7_BFT_client] started 2020.03.12 09:44:37 LOG7[0]: Setting local socket options (FD=508) 2020.03.12 09:44:37 LOG7[0]: Option TCP_NODELAY set on local socket 2020.03.12 09:44:37 LOG5[0]: Service [x3_x4_HL7_BFT_client] accepted connection from 127.0.0.1:50299 2020.03.12 09:44:37 LOG6[0]: s_connect: connecting 10.67.6.106:6161 2020.03.12 09:44:37 LOG7[0]: s_connect: s_poll_wait 10.67.6.106:6161: waiting 10 seconds
Thanks in advance //Janne
On Fri, Mar 13, 2020 at 09:42:27AM +0000, Jan Falk wrote:
Hi. Can someone tell me why Stunnel stops at wating 10s? Log:
2020.03.12 09:43:36 LOG6[main]: Initializing service [x3_x4_DICOM_BFT_client]
[snip]
2020.03.12 09:44:37 LOG7[0]: Service [x3_x4_HL7_BFT_client] started 2020.03.12 09:44:37 LOG7[0]: Setting local socket options (FD=508) 2020.03.12 09:44:37 LOG7[0]: Option TCP_NODELAY set on local socket 2020.03.12 09:44:37 LOG5[0]: Service [x3_x4_HL7_BFT_client] accepted connection from 127.0.0.1:50299 2020.03.12 09:44:37 LOG6[0]: s_connect: connecting 10.67.6.106:6161 2020.03.12 09:44:37 LOG7[0]: s_connect: s_poll_wait 10.67.6.106:6161: waiting 10 seconds
Have you made sure that there is something listening on port 6161 of the 10.67.6.106 host and that the host that stunnel is running on can establish a connection to it? No firewalls, no routing problems or anything like that?
What happens if you run - on the host that stunnel runs on - this:
nc -v -z 10.67.6.106 6161
...and also, if stunnel is supposed to establish a secure connection to that host (that is, if stunnel is working in client mode):
openssl s_client -connect 10.67.6.106:6161
The first command should exit immediately and tell you that a TCP connection was established successfully; the second one should also try to negotiate a TLS connection and show you what the server on the other side tells you after the connection has been established.
G'luck, Peter
Thanks Peter for a quick reply. Yes we have a connection with reciving server, in wireshark I can see that vi get three ack:s on establishment. As I understand it, on third Ack the TLS is supposed to be sent, but instead my Stunnel halts on 10 sek. And there I stand..... The reciving server is not reply to non-crypted communication. //Janne
-----Ursprungligt meddelande----- Från: Peter Pentchev roam@ringlet.net Skickat: den 13 mars 2020 11:44 Till: Jan Falk jan.falk@sll.se Kopia: stunnel-users@stunnel.org Ämne: Re: [stunnel-users] S-tunnel will not send TLS
On Fri, Mar 13, 2020 at 09:42:27AM +0000, Jan Falk wrote:
Hi. Can someone tell me why Stunnel stops at wating 10s? Log:
2020.03.12 09:43:36 LOG6[main]: Initializing service [x3_x4_DICOM_BFT_client]
[snip]
2020.03.12 09:44:37 LOG7[0]: Service [x3_x4_HL7_BFT_client] started 2020.03.12 09:44:37 LOG7[0]: Setting local socket options (FD=508) 2020.03.12 09:44:37 LOG7[0]: Option TCP_NODELAY set on local socket 2020.03.12 09:44:37 LOG5[0]: Service [x3_x4_HL7_BFT_client] accepted connection from 127.0.0.1:50299 2020.03.12 09:44:37 LOG6[0]: s_connect: connecting 10.67.6.106:6161 2020.03.12 09:44:37 LOG7[0]: s_connect: s_poll_wait 10.67.6.106:6161: waiting 10 seconds
Have you made sure that there is something listening on port 6161 of the 10.67.6.106 host and that the host that stunnel is running on can establish a connection to it? No firewalls, no routing problems or anything like that?
What happens if you run - on the host that stunnel runs on - this:
nc -v -z 10.67.6.106 6161
...and also, if stunnel is supposed to establish a secure connection to that host (that is, if stunnel is working in client mode):
openssl s_client -connect 10.67.6.106:6161
The first command should exit immediately and tell you that a TCP connection was established successfully; the second one should also try to negotiate a TLS connection and show you what the server on the other side tells you after the connection has been established.
G'luck, Peter
-- Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
On Fri, Mar 13, 2020 at 11:19:16AM +0000, Jan Falk wrote: [format recovered]
Peter Pentchev wrote:
On Fri, Mar 13, 2020 at 09:42:27AM +0000, Jan Falk wrote:
Hi. Can someone tell me why Stunnel stops at wating 10s? Log:
2020.03.12 09:43:36 LOG6[main]: Initializing service [x3_x4_DICOM_BFT_client]
[snip]
2020.03.12 09:44:37 LOG7[0]: Service [x3_x4_HL7_BFT_client] started 2020.03.12 09:44:37 LOG7[0]: Setting local socket options (FD=508) 2020.03.12 09:44:37 LOG7[0]: Option TCP_NODELAY set on local socket 2020.03.12 09:44:37 LOG5[0]: Service [x3_x4_HL7_BFT_client] accepted connection from 127.0.0.1:50299 2020.03.12 09:44:37 LOG6[0]: s_connect: connecting 10.67.6.106:6161 2020.03.12 09:44:37 LOG7[0]: s_connect: s_poll_wait 10.67.6.106:6161: waiting 10 seconds
Have you made sure that there is something listening on port 6161 of the 10.67.6.106 host and that the host that stunnel is running on can establish a connection to it? No firewalls, no routing problems or anything like that?
What happens if you run - on the host that stunnel runs on - this:
nc -v -z 10.67.6.106 6161
...and also, if stunnel is supposed to establish a secure connection to that host (that is, if stunnel is working in client mode):
openssl s_client -connect 10.67.6.106:6161
The first command should exit immediately and tell you that a TCP connection was established successfully; the second one should also try to negotiate a TLS connection and show you what the server on the other side tells you after the connection has been established.
Thanks Peter for a quick reply.
Yes we have a connection with reciving server, in wireshark I can see that vi get three ack:s on establishment. As I understand it, on third Ack the TLS is supposed to be sent, but instead my Stunnel halts on 10 sek. And there I stand.....
The reciving server is not reply to non-crypted communication.
OK, so at least the network troubles may be ruled out... to some extent.
Can you show us your stunnel configuration file? Is stunnel supposed to connect to this service in its client mode (stunnel accepts a plaintext connection and connects to a TLS service), or in server mode (stunnel accepts a TLS connection, connects to a plaintext service)?
If stunnel is supposed to run in client mode, that means that whatever is listening for incoming TCP connections on 10.67.6.106:6161 should not only accept the connection, but also start a TLS negotiation, and the "openssl s_client" command I posted above should show you this TLS negotiation. If this does not happen - if s_client does not show you a TLS negotiation, server names, certificates, etc - then something is wrong with the service running at 10.67.6.106:6161; you should make sure that this is fixed before attempting to get stunnel to talk to it.
G'luck, Peter
Thanks Peter, I really appriciate your support.
The config file is just a little edited by me, but I think that you can see how it's set up:
[SOS_SYNGO_HL7_BFT_client]
client = yes
accept = 46161
connect = Xn1.x1.x2.se:6161
cert = ds3000-03.x3.x2.se.pem
verify = 2
CAfile = CAFile.pem
[SOS_SYNGO_DICOM_BFT_client]
client = yes
accept = 46162
connect = Xn2.x1.x2.se:6162
cert = ds3000-03.x3.x2.se.pem
verify = 2
CAfile = CAFile.pem
Is there a way to copy inhold of opensll shell-window and make it anonymos before I make it public?
It ends as this screenshot at least:
[cid:image001.png@01D5F93C.54C1D200]
//Janne
Jan Falk
MTA
08 616 1721
-----Ursprungligt meddelande----- Från: Peter Pentchev roam@ringlet.net Skickat: den 13 mars 2020 12:53 Till: Jan Falk jan.falk@sll.se Kopia: stunnel-users@stunnel.org Ämne: Re: SV: [stunnel-users] S-tunnel will not send TLS
On Fri, Mar 13, 2020 at 11:19:16AM +0000, Jan Falk wrote:
[format recovered]
Peter Pentchev wrote:
On Fri, Mar 13, 2020 at 09:42:27AM +0000, Jan Falk wrote:
Hi.
Can someone tell me why Stunnel stops at wating 10s? Log:
2020.03.12 09:43:36 LOG6[main]: Initializing service
[x3_x4_DICOM_BFT_client]
[snip]
2020.03.12 09:44:37 LOG7[0]: Service [x3_x4_HL7_BFT_client]
started
2020.03.12 09:44:37 LOG7[0]: Setting local socket options (FD=508)
2020.03.12 09:44:37 LOG7[0]: Option TCP_NODELAY set on local
socket
2020.03.12 09:44:37 LOG5[0]: Service [x3_x4_HL7_BFT_client]
accepted connection from 127.0.0.1:50299
2020.03.12 09:44:37 LOG6[0]: s_connect: connecting
10.67.6.106:6161
2020.03.12 09:44:37 LOG7[0]: s_connect: s_poll_wait 10.67.6.106:6161:
waiting 10 seconds
Have you made sure that there is something listening on port 6161 of
the
10.67.6.106 host and that the host that stunnel is running on can
establish a connection to it? No firewalls, no routing problems or
anything like that?
What happens if you run - on the host that stunnel runs on - this:
nc -v -z 10.67.6.106 6161
...and also, if stunnel is supposed to establish a secure connection
to that host (that is, if stunnel is working in client mode):
openssl s_client -connect 10.67.6.106:6161
The first command should exit immediately and tell you that a TCP
connection was established successfully; the second one should also
try to negotiate a TLS connection and show you what the server on
the other side tells you after the connection has been established.
Thanks Peter for a quick reply.
Yes we have a connection with reciving server, in wireshark I can see
that vi get three ack:s on establishment. As I understand it, on third
Ack the TLS is supposed to be sent, but instead my Stunnel halts on 10
sek. And there I stand.....
The reciving server is not reply to non-crypted communication.
OK, so at least the network troubles may be ruled out... to some extent.
Can you show us your stunnel configuration file? Is stunnel supposed to connect to this service in its client mode (stunnel accepts a plaintext connection and connects to a TLS service), or in server mode (stunnel accepts a TLS connection, connects to a plaintext service)?
If stunnel is supposed to run in client mode, that means that whatever is listening for incoming TCP connections on 10.67.6.106:6161 should not only accept the connection, but also start a TLS negotiation, and the "openssl s_client" command I posted above should show you this TLS negotiation. If this does not happen - if s_client does not show you a TLS negotiation, server names, certificates, etc - then something is wrong with the service running at 10.67.6.106:6161; you should make sure that this is fixed before attempting to get stunnel to talk to it.
G'luck,
Peter
--
Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org}mailto:roam@%7bringlet.net,debian.org,FreeBSD.org%7d pp@storpool.commailto:pp@storpool.com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Hi again. In the beginning of the OpenSLL command I get:
OpenSSL> s_client -connect 10.67.6.106:6161 CONNECTED(000000D0) Can't use SSL_get_servername depth=0 C = SE, L = Stockholm, O = O1, CN = Xn1.x1.x2.se, serialNumber = SE?-AHH8 verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = SE, L = Stockholm, O = O1, CN = Xn1.x1.x2.se, serialNumber = SE?-AHH8 verify error:num=21:unable to verify the first certificate verify return:1 4696:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1536:SSL alert number 40 --- Certificate chain 0 s:C = SE, L = Stockholm, O = O1, CN = Xn1.x1.x2.se, serialNumber = SE?-AHH8 i:C = SE, O = O2, CN = SITHS Type 3 CA v1 PP --- Server certificate -----BEGIN CERTIFICATE-----
I can see that I have a error 20 and 21, is there a certificate-issue? In Stunnel-log there's no such identification.... //Janne
Jan Falk MTA [cid:image002.jpg@01D525EB.8E815300]http://www.sodersjukhuset.se/ 08 616 1721
Från: Jan Falk Skickat: den 13 mars 2020 13:36 Till: Peter Pentchev roam@ringlet.net Kopia: stunnel-users@stunnel.org Ämne: SV: SV: [stunnel-users] S-tunnel will not send TLS
Thanks Peter, I really appriciate your support.
The config file is just a little edited by me, but I think that you can see how it's set up:
[SOS_SYNGO_HL7_BFT_client]
client = yes
accept = 46161
connect = Xn1.x1.x2.se:6161
cert = ds3000-03.x3.x2.se.pem
verify = 2
CAfile = CAFile.pem
[SOS_SYNGO_DICOM_BFT_client]
client = yes
accept = 46162
connect = Xn2.x1.x2.se:6162
cert = ds3000-03.x3.x2.se.pem
verify = 2
CAfile = CAFile.pem
Is there a way to copy inhold of opensll shell-window and make it anonymos before I make it public?
It ends as this screenshot at least:
[cid:image003.png@01D5F94E.675FBAF0]
//Janne
Jan Falk
MTA
08 616 1721
-----Ursprungligt meddelande----- Från: Peter Pentchev <roam@ringlet.netmailto:roam@ringlet.net> Skickat: den 13 mars 2020 12:53 Till: Jan Falk <jan.falk@sll.semailto:jan.falk@sll.se> Kopia: stunnel-users@stunnel.orgmailto:stunnel-users@stunnel.org Ämne: Re: SV: [stunnel-users] S-tunnel will not send TLS
On Fri, Mar 13, 2020 at 11:19:16AM +0000, Jan Falk wrote:
[format recovered]
Peter Pentchev wrote:
On Fri, Mar 13, 2020 at 09:42:27AM +0000, Jan Falk wrote:
Hi.
Can someone tell me why Stunnel stops at wating 10s? Log:
2020.03.12 09:43:36 LOG6[main]: Initializing service
[x3_x4_DICOM_BFT_client]
[snip]
2020.03.12 09:44:37 LOG7[0]: Service [x3_x4_HL7_BFT_client]
started
2020.03.12 09:44:37 LOG7[0]: Setting local socket options (FD=508)
2020.03.12 09:44:37 LOG7[0]: Option TCP_NODELAY set on local
socket
2020.03.12 09:44:37 LOG5[0]: Service [x3_x4_HL7_BFT_client]
accepted connection from 127.0.0.1:50299
2020.03.12 09:44:37 LOG6[0]: s_connect: connecting
10.67.6.106:6161
2020.03.12 09:44:37 LOG7[0]: s_connect: s_poll_wait 10.67.6.106:6161:
waiting 10 seconds
Have you made sure that there is something listening on port 6161 of
the
10.67.6.106 host and that the host that stunnel is running on can
establish a connection to it? No firewalls, no routing problems or
anything like that?
What happens if you run - on the host that stunnel runs on - this:
nc -v -z 10.67.6.106 6161
...and also, if stunnel is supposed to establish a secure connection
to that host (that is, if stunnel is working in client mode):
openssl s_client -connect 10.67.6.106:6161
The first command should exit immediately and tell you that a TCP
connection was established successfully; the second one should also
try to negotiate a TLS connection and show you what the server on
the other side tells you after the connection has been established.
Thanks Peter for a quick reply.
Yes we have a connection with reciving server, in wireshark I can see
that vi get three ack:s on establishment. As I understand it, on third
Ack the TLS is supposed to be sent, but instead my Stunnel halts on 10
sek. And there I stand.....
The reciving server is not reply to non-crypted communication.
OK, so at least the network troubles may be ruled out... to some extent.
Can you show us your stunnel configuration file? Is stunnel supposed to connect to this service in its client mode (stunnel accepts a plaintext connection and connects to a TLS service), or in server mode (stunnel accepts a TLS connection, connects to a plaintext service)?
If stunnel is supposed to run in client mode, that means that whatever is listening for incoming TCP connections on 10.67.6.106:6161 should not only accept the connection, but also start a TLS negotiation, and the "openssl s_client" command I posted above should show you this TLS negotiation. If this does not happen - if s_client does not show you a TLS negotiation, server names, certificates, etc - then something is wrong with the service running at 10.67.6.106:6161; you should make sure that this is fixed before attempting to get stunnel to talk to it.
G'luck,
Peter
--
Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org}mailto:roam@%7bringlet.net,debian.org,FreeBSD.org%7d pp@storpool.commailto:pp@storpool.com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13