The beauty of this solution is that, aside from the local configuration changes, the client and the server are both unaware on the encrypted tunnel shared between the listeners. > The server side stunnel listener will unencrypt the traffic received and forward it to the original destination port configured for application. >The stunnel listener on the server will be using an unallocated high port. > The stunnel listener on the client will send this encrypted traffic to another stunnel listener on the server. For example, if the clients local application configuration points to the target server at 1.2.3.4:9103, this would need to be modified to point to 127.0.0.1:9103, which is where the stunnel client is listening.

*** CAVEAT*** There will be other small configuration changes that need to be made on the the client.

All of the traffic the local stunnel listener receives will be ssl/tls encrypted and pushed out over the wire. The client sends data to this local listener in precisely the same way that it would have sent it to the remote server. I have added the CA certificate to the client_Access_stunnel.On the client side, stunnel will set up a listener on local host using the same port that was configured to listen on the target server.Server: pid = /var/run/stunnel/server.pidĬert = /opt/quasar/cert/certs/stunnels/server.pem

What I am trying to do is to use a stunnel client and with verify 3 it authenticates the user based on the certificate.Ĭlient: cert = /stunnel/client_Access_stunnel.pemĬAfile = /stunnel/client_Access_stunnel.pem I have 2x stunnels linux based, 1 server, 1 client.

Stunnel cert