0

I am trying to connect to a customer from my Centos7 server,

the customer is running Stunnel server, and I am the client.

I cannot establish a handshake and am getting the following err message in /var/log/messages, getting a Handshake Failure

Jan 27 12:49:24 qbtch2 stunnel: LOG6[25]: SNI: sending servername: 123.111.172.34
Jan 27 12:49:24 qbtch2 stunnel: LOG6[25]: Peer certificate not required
Jan 27 12:49:24 qbtch2 stunnel: LOG3[25]: SSL_connect: s23_clnt.c:769: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Jan 27 12:49:24 qbtch2 stunnel: LOG5[25]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket

my openssl versions

root@qbtch2 /e/stunnel# rpm -qa | grep openssl
openssl-libs-1.0.2k-12.el7.i686
openssl098e-0.9.8e-29.el7.centos.3.x86_64
openssl-1.0.2k-12.el7.x86_64
openssl-devel-1.0.2k-12.el7.x86_64
openssl-libs-1.0.2k-12.el7.x86_64

my Stunnel version,

root@qbtch2 /e/stunnel# rpm -qa | grep stunnel
stunnel-5.54-1.el7.x86_64

my stunnel config looks like this, Im using the customer's Key and Cert to connect (client mode)

root@qbtch2 /e/stunnel# cat stunnel.conf 
debug = 7
foreground = no
chroot = /var/run/stunnel
setuid = nobody
setgid = nobody
pid = /stunnel.pid
ciphers = PSK
PSKsecrets = /etc/stunnel/psk.txt
socket = l:SO_KEEPALIVE=1
socket = r:SO_KEEPALIVE=1

[ ABC ]
client = yes
accept = 127.0.0.1:8228
connect = 123.111.172.34:8228
cert = /etc/stunnel/certs/customerABC/uat/cert.pem
key = /etc/stunnel/certs/customerABC/uat/key.pem
CAfile = /etc/stunnel/certs/customerABC/uat/CACerts.pem
verifyChain = yes
checkHost = 123.111.172.34
sslVersion = TLSv1.2
options = NO_SSLv2
options = NO_SSLv3

I can connect to the customer using openssl s_connect and get a handshake, 

root@qbtch2 /e/stunnel# openssl s_client -connect 123.111.172.34:8228 -cert certs/customerABC/uat/cert.pem -key certs/customerABC/uat/key.pem -tls1_2

I get this in return, 

root@qbtch2 /e/stunnel# openssl s_client -connect 112.13.172.34:8228 -cert certs/CustomerABC/uat/cert.pem -key certs/CustomerABC/uat/key.pem 
CONNECTED(00000003)
depth=2 C = US, ST = NEW YORK, L = NEW YORK, O = CustomerABC LP, OU = R&D, CN = System Security Root CA, emailAddress = caadmin@CustomerABC.com
verify error:num=19:self signed certificate in certificate chain
---
Certificate chain
 0 s:/C=US/ST=New York/O=CustomerABC L.P./OU=Test/CN=Testbeta.CustomerABC.com
   i:/C=US/ST=NEW YORK/L=NEW YORK/O=CustomerABC LP/OU=Test/CN=Test Connectivity
 1 s:/C=US/ST=NEW YORK/L=NEW YORK/O=CustomerABC LP/OU=Test/CN=Test Connectivity
   i:/C=US/ST=NEW YORK/L=NEW YORK/O=CustomerABC LP/OU=R&D/CN=System Security Root CA/emailAddress=caadmin@CustomerABC.com
 2 s:/C=US/ST=NEW YORK/L=NEW YORK/O=CustomerABC LP/OU=R&D/CN=System Security Root CA/emailAddress=caadmin@CustomerABC.com
   i:/C=US/ST=NEW YORK/L=NEW YORK/O=CustomerABC LP/OU=R&D/CN=System Security Root CA/emailAddress=caadmin@CustomerABC.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFpzCCA4+gAwIBAgIQc9qYG4Sl83koJYfu5YBKXjANBgkqhkiG9w0BAQsFADBz
MQswCQYDVQQGEwJVUzERMA8GA1UECBMITkVXIFlPUksxETAPBgNVBAcTCE5FVyBZ
T1JLMRUwEwYDVQQKEwxCbG9vbWJlcmcgTFAxDDAKBgNVBAsTA0ZJWDEZMBcGA1UE
AxMQRklYIENvbm5lY3Rpdml0eTAeFw0xOTA1MTUxNjQyNDJaFw0yMDAyMDkxNjQy
NDJaMGcxCzAJBgNVBAYTAlVTMREwDwYDVQQIDAhOZXcgWW9yazEXMBUGA1UECgwO
Qmxvb21iZXJnIEwuUC4xDDAKBgNVBAsMA0ZJWDEeMBwGA1UEAwwVZml4YmV0YS5i
bG9vbWJlcmcuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA26dq
JLQ9P8lHDRQYi4XoNcM8DXijx/A0L7mNFxLwoFxrl2Y67tjrZRVINcbZdrMP/m/R
2o5vR8USHKRT7HWEwJwdQ3MN829IMngXhhiNK/zps3Xnyw4luvXs53E1YgqgH/du
INXe8TPOzQxCU79jPIxtIYkXHMJ5KdhODxxHV2bZke8r9RzgFNO2fCGm/67dZFYR
X90+b+p4UlOe5QQp1/0hGdBbQhG3lZn+rPMgSIK8rPU0yAMUI9bqqEMNshFof1PQ
o7V8X2ewXLSM6E4NG3+ZCzlr1iUCAuX7C8n28DBV4weFWlhXJvT3Zfkxexfm3YWd
94Z9C4MWoq/sB5GKKwIDAQABo4IBQTCCAT0wCQYDVR0TBAIwADALBgNVHQ8EBAMC
BaAwHQYDVR0lBBYwFAYIKwYBB75UHAwEGCCsGAQUFBwMCMIIBAgYDVR0RBIH6MIH3
ghVmaXhiZXRhLmJsb29tYmVyZy5jb22CGWZpeGJldGEtYWltLmJsb29tYmVyZy5j
b22CGmZpeGJldGEtdG9tcy5ibG9vbWJlcmcuY29tghpmaXhiZXRhLWRhc2guYmxv
b21iZXJnLmNvbYIcZml4YmV0YS1zc2VvbXMuYmxvb21iZXJnLmNvbYIYZml4YmV0
YS10Yi5ibG9vbWJlcmcuY29tg9pmaXhiZXRhLWZpY2MuYmxvb21iZXJnLmNvbYIa
Zml4YmV0YS1lbXN4LmJsb29tYmVyZy5jb22CG2ZpeGJldGEtZXRvbXMuYmxvb21i
ZXJnLmNvbTANBgkqhkiG9w0BAQsFAAOCAgEAPm78N260OC3cmgSSQrcq2m3rd3NM
IGSrUaMDI7YxmBgtJsS0rwKIBaWwYuS0f6SrDWP5ILGHf7q2QwxVS01sSA/ilu9c
7+U3Srv8OQlNyP0+gwv+D1rabcfUulNsVSJy0B3gL8VfkBNqWECucNRbgv77/CR
6fSevWW2gsnGpRFQ1m9cr9h0hN/ssbaBTYD9MNlgoapQBgEXie/GoHqYxW0Pk+I6
0Jbj0dCacmpbeFYtFe2lWavnDUIpUozYQsi64XHg6m8uWokQPPmA/BOBfGh3sUgw
B5kkblXTgTt/lXpqG8GXBHAbxeJhtsNymvcJH1HOrL9FghOEJ9DUPCDqh821VWGC
WOScaJ18SbbxhBomG3BOrXvViOPUIG1oCJ22ch6J+u5TGA2OHtUSqxBnkaKETVxn
JYDUqNqoFoVeuxR/YYNTdo2LPer5Wb2YZ9OD/Hp9zERI85miW+w+Us7gF62JYnI/
ZfC2WdHcqBqZjfy+HXGGA5PMDX8SqacRXmpZsHmPHjUlWO/HLmY2icHs90IVOI3L
zntyG7J6Z6iN4TcZdEtXW/G73oX38T7IuYAPX7YDVvsTmNPMAz8r56L9ItQ4RzMs
5Y3jNN3iud+gudsc8ldSzWbW3Tdivc1xI9nLPxGzw3tAM+f5hXxKAzFc36J13L//
BZDdv9LU66xDLjQ=
-----END CERTIFICATE-----
subject=/C=US/ST=New York/O=CustomerABC L.P./OU=Test/CN=Testbeta.CustomerABC.com
issuer=/C=US/ST=NEW YORK/L=NEW YORK/O=CustomerABC LP/OU=Test/CN=Test Connectivity
---
Acceptable client certificate CA names
/C=US/ST=NEW YORK/L=NEW YORK/O=CustomerABC LP/OU=R&D/CN=System Security Root CA/emailAddress=caadmin@CustomerABC.com
/C=US/ST=NEW YORK/L=NEW YORK/O=CustomerABC LP/OU=Test/CN=Test Connectivity
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5634 bytes and written 2041 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: B34275808CDxxx3A5ED9AB49F14023B17E32A1A33B5A5B5D2DE96A419491A93201CF247A94BA2119801437CDA3D00B4122
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1580150434
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---

so the handshake is there, but not when I try to bring up the Stunnel.

any clues where to troubleshoot this?

thanks.

perfecto25
  • 288
  • 3
  • 7
  • "Verify return code: 19 (self signed certificate in certificate chain)" means the client is not validating the remote certificate, and this will fail the connection (certification validation comes after protocol parameters negotiation). You need to add this certificate in client truststore or use another certificate instead. – Patrick Mevzek Jan 28 '20 at 17:33
  • Thanks Patrick, it looks like its picking up the handshake Service [ ABC ] accepted connection from 192.168.38.7:56763 s_connect: connecting 123.111.172.34:8228 s_connect: connected 123.111.172.34:8228 Service [ ABC ] connected remote server from 192.168.38.21:49848 SNI: sending servername: 123.111.172.34 – perfecto25 Jan 28 '20 at 18:03
  • Peer certificate required Certificate accepted at depth=2: C=US, ST=NEW YORK, L=NEW YORK, O=CustomerABC LP, OU=R&D, CN=System Security Root CA, emailAddress=dmin@CustomerABC.com Certificate accepted at depth=1: C=US, ST=NEW YORK, L=NEW YORK, O=CustomerABC LP, OU=FIX, CN=FIX Connectivity CERT: No subject checks configured – perfecto25 Jan 28 '20 at 18:09
  • Certificate accepted at depth=0: C=US, ST=New York, O=CustomerABC L.P., OU=FIX, CN=fb.CustomerABC.com Client CA: C=US, ST=NEW YORK, L=NEW YORK, O=CustomerABC LP, OU=R&D, CN=System Security Root CA, emailAddress=caadmin@CustomerABC.com Client CA: C=US, ST=NEW YORK, L=NEW YORK, O=CustomerABC LP, OU=FIX, CN=FIX Connectivity TLSv1.2 ciphersuite: ECDHE-RSA-AES256-GCM-SHA384 (256-bit encryption) TLS connected: new session negotiated – perfecto25 Jan 28 '20 at 18:09

1 Answers1

1

the issue seems to be that I have a global PSK setting for my other stunnel connections, putting the PSK to local configs seems to fix this,

ie, going from this,

root@qbtch2 /e/stunnel# cat stunnel.conf 
debug = 7
foreground = no
chroot = /var/run/stunnel
setuid = nobody
setgid = nobody
pid = /stunnel.pid
ciphers = PSK
PSKsecrets = /etc/stunnel/psk.txt
socket = l:SO_KEEPALIVE=1
socket = r:SO_KEEPALIVE=1

[ SOME PSK CONN ]
accept = 1234
connect = blah:1234

[ ABC ]
client = yes
accept = 127.0.0.1:8228
connect = 123.111.172.34:8228
cert = /etc/stunnel/certs/customerABC/uat/cert.pem
key = /etc/stunnel/certs/customerABC/uat/key.pem
CAfile = /etc/stunnel/certs/customerABC/uat/CACerts.pem
verifyChain = yes
checkHost = 123.111.172.34
sslVersion = TLSv1.2
options = NO_SSLv2
options = NO_SSLv3

to this,

root@qbtch2 /e/stunnel# cat stunnel.conf 
debug = 7
foreground = no
chroot = /var/run/stunnel
setuid = nobody
setgid = nobody
pid = /stunnel.pid

socket = l:SO_KEEPALIVE=1
socket = r:SO_KEEPALIVE=1

[ SOME PSK CONN ]
accept = 1234
connect = blah:1234
ciphers = PSK
PSKsecrets = /etc/stunnel/psk.txt

[ ABC ]
client = yes
accept = 127.0.0.1:8228
connect = 123.111.172.34:8228
cert = /etc/stunnel/certs/customerABC/uat/cert.pem
key = /etc/stunnel/certs/customerABC/uat/key.pem
CAfile = /etc/stunnel/certs/customerABC/uat/CACerts.pem
verifyChain = no
checkHost = 123.111.172.34
sslVersion = TLSv1.2
options = NO_SSLv2
options = NO_SSLv3

moving the PSK setting to local configs vs global fixes this. Also, I had to disable "verifyChain" to get rid of the handshake error message

perfecto25
  • 288
  • 3
  • 7