- stunnel-users - stunnel.org

TR: using sTunnel with Chrome
by Pierre DUPONT 06 Sep '19

06 Sep '19

De : Pierre DUPONT Envoyé : jeudi 5 septembre 2019 16:55 À : 'stunnel-users(a)stunnel.org' <stunnel-users(a)stunnel.org> Cc : _sav.bibli <sav.bibli(a)nedap.fr>; Philippe ANQUETIN <philippe.anquetin(a)nedap.fr> Objet : using sTunnel with Chrome Good day to all. So far, I can't succeed to use Chrome with sTunnel. I use these versions sTunnel : 5.55 (downloaded today...) Chrome is 76.0.3809 132 [cid:[email protected]] Here is my configuration for sTunnel : ; Sample stunnel configuration file for Win32 by Michal Trojnara 2002-2019 ; 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 * ; ************************************************************************** ; Debugging stuff (may be useful for troubleshooting) ;debug = info ;output = stunnel.log ; Enable FIPS 140-2 mode if needed for compliance ;fips = yes ; Microsoft CryptoAPI engine allows for authentication with private keys ; stored in the Windows certificate store ; Each section using this feature also needs the "engineId = capi" option ;engine = capi ; You also need to disable TLS 1.2 or later, because the CryptoAPI engine ; currently does not support PSS ;sslVersionMax = TLSv1.1 ; 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:softhsm2.dll ;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 = conf.d ; ************************************************************************** ; * Service definitions (at least one service has to be defined) * ; ************************************************************************** ; ***************************************** Example TLS client mode services [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 [gmail-imap] client = yes accept = 127.0.0.1:143 connect = imap.gmail.com:993 verifyChain = yes CAfile = ca-certs.pem checkHost = imap.gmail.com OCSPaia = yes [gmail-smtp] client = yes accept = 127.0.0.1:25 connect = smtp.gmail.com:465 verifyChain = yes CAfile = ca-certs.pem checkHost = smtp.gmail.com OCSPaia = yes ; Encrypted HTTP proxy authenticated with a client certificate ; located in the Windows certificate store ;[example-proxy] ;client = yes ;accept = 127.0.0.1:8080 ;connect = example.com:8443 ;engineId = capi ; 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 = stunnel.pem ;[imaps] ;accept = 993 ;connect = 143 ;cert = 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 = stunnel.pem ; TLS front-end to a web server [https] accept = 443 connect = 81 cert = 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 cmd.exe protected with PSK-authenticated TLS ; Create "secrets.txt" containing IDENTITY:KEY pairs ;[cmd] ;accept = 1337 ;exec = c:\windows\system32\cmd.exe ;execArgs = cmd.exe ;PSKsecrets = secrets.txt ; vim:ft=dosini The 81 connect port is used by our local webservice : http://localhost:81/nedaprfidwebservice.asmx which runs OK [cid:[email protected]] The problem is when I try to import the certificate. It looks OK giving these informations [cid:[email protected]] [cid:[email protected]] However, I cannot connect on https [cid:[email protected]] I tried several things found browsing the list, like building a certificate with openssl req -new -x509 -days 365 -nodes -config stunnel.cnf -out stunnel.crt -keyout stunnel.crt No result so the only solution I see now is to call you for some help... With kind regards, Cordiales salutations de Pierre Dupont Support S.A.V. & Développement Bibliothèques Courriel S.A.V. : sav.bibli(a)nedap.fr<mailto:[email protected]> Téléphone : 06 13 99 69 38 - 01.61.03.03 18 8/10 Chemin d'Andrésy 95610 Eragny sur Oise [NEDAP LOGO - INLINE - RGB]

1 0

High cpu usage 2016 server
by Cooper, Dave 02 Sep '19

02 Sep '19

Using latest version of stunnel. Running on 3 separate 2016 servers. On each server stunnel is consuming 40% of the cpu even though no end point is even connected. Sent from my iPhone ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ***MBS DISCLAIMER*** Multi-Bank Securities, Inc. (MBS) cannot be held responsible for errors regarding time and/or price on buy/sell requests via e-mail. Information provided in this email has been prepared from sources to be reliable, but is not guaranteed and is not a complete summary or statement of all data necessary for making an investment decision. This is for informational purposes only and does not constitute a recommendation, please confirm all information before investing. Securities discussed are subject to availability and change in price and yield. Changes to assumptions may have a material impact on returns. Past performance is not indicative of future returns. Additional information is available upon request. This email is intended only for the entity or person to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of this information by entities or persons other than the intended recipient is prohibited. If you receive this message in error, please contact the sender immediately and delete the material from your computer. If you no longer wish to receive e-mails from MBS, please forward this email to compliance(a)mbssecurities.com and place the word REMOVE in the subject line

1 0

Re: [stunnel-users] stunnel-users Digest, Vol 181, Issue 3
by Eric Eberhard 28 Aug '19

28 Aug '19

No. If it ain’t broke, don’t fix it! Old saying but still relevant. The continual updates in all modern software may fix something – and another broken. IMO. I know I am a minority on this this group but an old tried and true setup has great value. Experience, reduces updates and adds to stability. We don’t change our code unless we must. We think it is more stable. Don’t listen to me if you are the type that must have every update ASAP Listen to me if you don’t need the latest and greatest and your app works properly. Study the new version and make a plan to move forward when the time is right. We often move forward to the previous stable release. Often months or even a year later. If the improvements are for things you don’t use, put them off. Look at exactly what the release notes say to help you decide if the update is worth it, you might find it improves only functionality you don’t use. It saves time and money and does not introduce new bugs. We use a very unpopular method – we use inetd. This releases you from all the server management code which is very very very hard to make work on all systems as they work so differently. We are on IBM with AIX (Unix). I doubt a lot of people are testing that configuration. Stunnel is very good at not requiring you to update one step at a time! You can skip safely. Enough blather. I am sure there are a lot of people that disagree with me. And they are likely correct in certain situations. We suggest you look at your situation and and see if you can skip releases … All opinion, not fact. I am old-school so keep that in mind! Good Luck, Eric From: Brent Kimberley [mailto:[email protected]] Sent: Wednesday, August 28, 2019 8:16 AM To: stunnel-users(a)stunnel.org; Eric Eberhard <flash(a)vicsmba.com> Cc: daniel.trickett(a)milliporesigma.com Subject: Re: [stunnel-users] stunnel-users Digest, Vol 181, Issue 3 Have you tried RFC8410? On Thursday, August 22, 2019, 04:00:43 p.m. EDT, Eric Eberhard <flash(a)vicsmba.com <mailto:[email protected]> > wrote: <snip>We use similar logic with one stunnel and have millions of transactions daily... [4+10+1 mil XML+web calls]. <snip>R

1 0

Re: [stunnel-users] stunnel-users Digest, Vol 181, Issue 3
by Eric Eberhard 28 Aug '19

28 Aug '19

Thanks :) -- I think Daniel can solve his problem. If for some reason he cannot make the app server output clear text he has to do it as you laid out. If he can, he can do one stunnel with TLSv1.2 by making the app output clear text. Both will work and should be secure. I’d do the latter is possible – way less overhead doing encryption. We use similar logic with one stunnel and have millions of transactions daily (XML not cXML but that does not matter – ours are often fairly large as in 100s of MB). Encrypting clear to SSLv3 then back to clear to TLSv1.2 is three encryptions along that path instead of one by making the app output clear text. The app will also shrink if that matters as it won’t need encryption code. E From: stunnel-users [mailto:[email protected]] On Behalf Of Brent Kimberley Sent: Thursday, August 22, 2019 7:29 AM To: stunnel-users(a)stunnel.org Subject: Re: [stunnel-users] stunnel-users Digest, Vol 181, Issue 3 >>there is no reason to connect to localhost with any security Should server/interface consolidation trigger functional/technical rework prior to go live? As per the diagram: the app server node x TLS engine node interface is wrapped in SSL the internal localhost x localhost interface is in the clear the TLS engine node x punchout-vendor node is wrapped in TLSv1.2 >> SNI flag (RFC 3546) Good catch. ---------------------------------------------------------------------- Message: 1 Date: Wed, 21 Aug 2019 08:01:08 -0700 From: "Eric Eberhard" <flash(a)vicsmba.com <mailto:[email protected]> > To: "'Brent Kimberley'" <brent_kimberley(a)rogers.com <mailto:[email protected]> >, <stunnel-users(a)stunnel.org <mailto:[email protected]> > Thank you -- what I had in mind but I am not that fancy with the setups as we use one. We go from our application in clear text to stunnel TLSv1.2 which is clearly easier. I did make this work for a short while a long time ago and did not save the files. Plus no may people's horror we use inetd. Of course we only transfer 4 million XML docs per day and handle 10 million Web calls and another million connections for credit cards, etc. I have been told that if I had serious volume inetd is slower -:) but I have not noticed enough of a slowdown to matter. And inetd (at least on an IBM AIX server) is dead reliable and easy. As a curiosity -- as I often see people coding unnecessarily -- there is no reason to connect to localhost with any security at all unless your app can only output SSLv3 which would imply a 3rd party vendor. The traffic never hits the network in any way -- not even the network card -- it goes directly to/from the TCP/IP stack which is why I mentioned just making the app send clear text to one stunnel that outputs TLSv1.2 ... if possible (may not be if it is something you don't have source to). Eric -----Original Message----- From: Brent Kimberley [mailto:[email protected] <mailto:[email protected]> ] Sent: Tuesday, August 20, 2019 6:42 AM To: stunnel-users(a)stunnel.org <mailto:[email protected]> Cc: daniel.trickett(a)milliporesigma.com <mailto:[email protected]> ; flash(a)vicsmba.com <mailto:[email protected]> Subject: Re: stunnel-users Digest, Vol 181, Issue 1 Your mileage may vary. ############################################################################### # From internal application to external host ############################################################################### # [Int_Init] -> [Int_Term] -> [Ext_Init] -> [Ext_Term] ############################################################################### # [internal_initiator] ---ssl---> [Internal terminator] # [Internal terminator] ---http---> [external Initiator] # [external Initiator] ---tls---> [external terminator] ############################################################################### # https://www.stunnel.org/static/stunnel.html <https://www.stunnel.org/static/stunnel.html%20> ############################################################################### [Internal_Terminator] options = SSLv3 client = no accept = host_ip:443 connect = localhost:54321 CAfile = int_init_wallet.pem cert = int_term_pub.pem key = int_term_priv.pem [External_Initiator] options = SINGLE_ECDH_USE options = SINGLE_DH_USE ciphers = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256 verify = 3? client = yes options = TLSv1.2 accept = localhost:54321 connect = externalhostname:443 verifyChain = yes renegotiation = no CAfile = ext_term_wallet.pem cert = ext_init_pub.pem key = ext_init_priv.pem ---------------------------------------------------------------------- Date: Mon, 19 Aug 2019 18:21:18 +0000 From: Daniel Trickett <daniel.trickett(a)milliporesigma.com <mailto:[email protected]> > To: "stunnel-users(a)stunnel.org <mailto:[email protected]> " <stunnel-users(a)stunnel.org <mailto:[email protected]> > Subject: [stunnel-users] https to https proxy Hi, Our punchout vendor switched their site to only accept tls 1.2 over the weekend. Unfortunately our application will only support SSL. We are using stunnel with other vendors but can control the inbound host name. This recent one is one we can't manage as it is the software provider. I found a solution for doing https to https. I'm unclear how I get the first https traffic to route to stunnel as the initial call will be from the application will be to the external host.. Any thoughts on whether this would work for my situation? Appreciate any thoughts.. [Tunnel_in] client = yes accept = host_ip:443 connect = localhost:54321 [Tunnel_out] client = no accept = localhost:54321 connect = externalhostname:443 Best regards, Dan

3 2

Re: [stunnel-users] stunnel-users Digest, Vol 181, Issue 3
by Brent Kimberley 22 Aug '19

22 Aug '19

>>there is no reason to connect to localhost with any security Should server/interface consolidation trigger functional/technical rework prior to go live? As per the diagram: the app server node x TLS engine node interface is wrapped in SSL the internal localhost x localhost interface is in the clear the TLS engine node x punchout-vendor node is wrapped in TLSv1.2 >> SNI flag (RFC 3546)Good catch. ---------------------------------------------------------------------- Message: 1 Date: Wed, 21 Aug 2019 08:01:08 -0700 From: "Eric Eberhard" <flash(a)vicsmba.com> To: "'Brent Kimberley'" <brent_kimberley(a)rogers.com>, <stunnel-users(a)stunnel.org> Thank you -- what I had in mind but I am not that fancy with the setups as we use one. We go from our application in clear text to stunnel TLSv1.2 which is clearly easier. I did make this work for a short while a long time ago and did not save the files. Plus no may people's horror we use inetd. Of course we only transfer 4 million XML docs per day and handle 10 million Web calls and another million connections for credit cards, etc. I have been told that if I had serious volume inetd is slower -:) but I have not noticed enough of a slowdown to matter. And inetd (at least on an IBM AIX server) is dead reliable and easy. As a curiosity -- as I often see people coding unnecessarily -- there is no reason to connect to localhost with any security at all unless your app can only output SSLv3 which would imply a 3rd party vendor. The traffic never hits the network in any way -- not even the network card -- it goes directly to/from the TCP/IP stack which is why I mentioned just making the app send clear text to one stunnel that outputs TLSv1.2 ... if possible (may not be if it is something you don't have source to). Eric -----Original Message----- From: Brent Kimberley [mailto:[email protected]] Sent: Tuesday, August 20, 2019 6:42 AM To: stunnel-users(a)stunnel.org Cc: daniel.trickett(a)milliporesigma.com; flash(a)vicsmba.com Subject: Re: stunnel-users Digest, Vol 181, Issue 1 Your mileage may vary. ############################################################################### # From internal application to external host ############################################################################### # [Int_Init] -> [Int_Term] -> [Ext_Init] -> [Ext_Term] ############################################################################### # [internal_initiator] ---ssl---> [Internal terminator] # [Internal terminator] ---http---> [external Initiator] # [external Initiator] ---tls---> [external terminator] ############################################################################### # https://www.stunnel.org/static/stunnel.html ############################################################################### [Internal_Terminator] options = SSLv3 client = no accept = host_ip:443 connect = localhost:54321 CAfile = int_init_wallet.pem cert = int_term_pub.pem key = int_term_priv.pem [External_Initiator] options = SINGLE_ECDH_USE options = SINGLE_DH_USE ciphers = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256 verify = 3? client = yes options = TLSv1.2 accept = localhost:54321 connect = externalhostname:443 verifyChain = yes renegotiation = no CAfile = ext_term_wallet.pem cert = ext_init_pub.pem key = ext_init_priv.pem ---------------------------------------------------------------------- Date: Mon, 19 Aug 2019 18:21:18 +0000 From: Daniel Trickett <daniel.trickett(a)milliporesigma.com> To: "stunnel-users(a)stunnel.org" <stunnel-users(a)stunnel.org> Subject: [stunnel-users] https to https proxy Hi, Our punchout vendor switched their site to only accept tls 1.2 over the weekend. Unfortunately our application will only support SSL. We are using stunnel with other vendors but can control the inbound host name. This recent one is one we can't manage as it is the software provider. I found a solution for doing https to https. I'm unclear how I get the first https traffic to route to stunnel as the initial call will be from the application will be to the external host.. Any thoughts on whether this would work for my situation? Appreciate any thoughts.. [Tunnel_in] client = yes accept = host_ip:443 connect = localhost:54321 [Tunnel_out] client = no accept = localhost:54321 connect = externalhostname:443 Best regards, Dan

1 0

Re: [stunnel-users] stunnel-users Digest, Vol 181, Issue 1
by Eric Eberhard 21 Aug '19

21 Aug '19

Thank you -- what I had in mind but I am not that fancy with the setups as we use one. We go from our application in clear text to stunnel TLSv1.2 which is clearly easier. I did make this work for a short while a long time ago and did not save the files. Plus no may people's horror we use inetd. Of course we only transfer 4 million XML docs per day and handle 10 million Web calls and another million connections for credit cards, etc. I have been told that if I had serious volume inetd is slower -:) but I have not noticed enough of a slowdown to matter. And inetd (at least on an IBM AIX server) is dead reliable and easy. As a curiosity -- as I often see people coding unnecessarily -- there is no reason to connect to localhost with any security at all unless your app can only output SSLv3 which would imply a 3rd party vendor. The traffic never hits the network in any way -- not even the network card -- it goes directly to/from the TCP/IP stack which is why I mentioned just making the app send clear text to one stunnel that outputs TLSv1.2 ... if possible (may not be if it is something you don't have source to). Eric -----Original Message----- From: Brent Kimberley [mailto:[email protected]] Sent: Tuesday, August 20, 2019 6:42 AM To: stunnel-users(a)stunnel.org Cc: daniel.trickett(a)milliporesigma.com; flash(a)vicsmba.com Subject: Re: stunnel-users Digest, Vol 181, Issue 1 Your mileage may vary. ############################################################################### # From internal application to external host ############################################################################### # [Int_Init] -> [Int_Term] -> [Ext_Init] -> [Ext_Term] ############################################################################### # [internal_initiator] ---ssl---> [Internal terminator] # [Internal terminator] ---http---> [external Initiator] # [external Initiator] ---tls---> [external terminator] ############################################################################### # https://www.stunnel.org/static/stunnel.html ############################################################################### [Internal_Terminator] options = SSLv3 client = no accept = host_ip:443 connect = localhost:54321 CAfile = int_init_wallet.pem cert = int_term_pub.pem key = int_term_priv.pem [External_Initiator] options = SINGLE_ECDH_USE options = SINGLE_DH_USE ciphers = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256 verify = 3? client = yes options = TLSv1.2 accept = localhost:54321 connect = externalhostname:443 verifyChain = yes renegotiation = no CAfile = ext_term_wallet.pem cert = ext_init_pub.pem key = ext_init_priv.pem ---------------------------------------------------------------------- Date: Mon, 19 Aug 2019 18:21:18 +0000 From: Daniel Trickett <daniel.trickett(a)milliporesigma.com> To: "stunnel-users(a)stunnel.org" <stunnel-users(a)stunnel.org> Subject: [stunnel-users] https to https proxy Hi, Our punchout vendor switched their site to only accept tls 1.2 over the weekend. Unfortunately our application will only support SSL. We are using stunnel with other vendors but can control the inbound host name. This recent one is one we can't manage as it is the software provider. I found a solution for doing https to https. I'm unclear how I get the first https traffic to route to stunnel as the initial call will be from the application will be to the external host.. Any thoughts on whether this would work for my situation? Appreciate any thoughts.. [Tunnel_in] client = yes accept = host_ip:443 connect = localhost:54321 [Tunnel_out] client = no accept = localhost:54321 connect = externalhostname:443 Best regards, Dan

1 0

Re: [stunnel-users] https to https proxy
by Eric Eberhard 20 Aug '19

20 Aug '19

I'll bite - probably missing something. Why not have your application output clear text to stunnel and set stunnel to TLSv1.2? In other words, drop the SSL from your application. If that won't work I think you can do it with two stunnels (I got it to work once before I did the above). One accepts SSLv3 and outputs clear text . it is the client=no option. The output goes to a stunnel that is client=yes and is set to TLSv1.2 . which outputs to your final destination. The output from the client=no would be to localhost on some port that fires the second stunnel. I suspect you have to use different port numbers. All guesses as I am not sure exactly what you are doing . but if it helps, great :) Eric From: stunnel-users [mailto:[email protected]] On Behalf Of Daniel Trickett Sent: Monday, August 19, 2019 11:21 AM To: stunnel-users(a)stunnel.org Subject: [stunnel-users] https to https proxy Hi, Our punchout vendor switched their site to only accept tls 1.2 over the weekend. Unfortunately our application will only support SSL. We are using stunnel with other vendors but can control the inbound host name. This recent one is one we can't manage as it is the software provider. I found a solution for doing https to https. I'm unclear how I get the first https traffic to route to stunnel as the initial call will be from the application will be to the external host.. Any thoughts on whether this would work for my situation? Appreciate any thoughts.. [Tunnel_in] client = yes accept = host_ip:443 connect = localhost:54321 [Tunnel_out] client = no accept = localhost:54321 connect = externalhostname:443 Best regards, Dan

2 1

Re: [stunnel-users] stunnel-users Digest, Vol 181, Issue 1
by Brent Kimberley 20 Aug '19

20 Aug '19

Your mileage may vary. ############################################################################### # From internal application to external host ############################################################################### # [Int_Init] -> [Int_Term] -> [Ext_Init] -> [Ext_Term] ############################################################################### # [internal_initiator] ---ssl---> [Internal terminator] # [Internal terminator] ---http---> [external Initiator] # [external Initiator] ---tls---> [external terminator] ############################################################################### # https://www.stunnel.org/static/stunnel.html ############################################################################### [Internal_Terminator] options = SSLv3 client = no accept = host_ip:443 connect = localhost:54321 CAfile = int_init_wallet.pem cert = int_term_pub.pem key = int_term_priv.pem [External_Initiator] options = SINGLE_ECDH_USE options = SINGLE_DH_USE ciphers = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256 verify = 3? client = yes options = TLSv1.2 accept = localhost:54321 connect = externalhostname:443 verifyChain = yes renegotiation = no CAfile = ext_term_wallet.pem cert = ext_init_pub.pem key = ext_init_priv.pem ---------------------------------------------------------------------- Date: Mon, 19 Aug 2019 18:21:18 +0000 From: Daniel Trickett <daniel.trickett(a)milliporesigma.com> To: "stunnel-users(a)stunnel.org" <stunnel-users(a)stunnel.org> Subject: [stunnel-users] https to https proxy Hi, Our punchout vendor switched their site to only accept tls 1.2 over the weekend. Unfortunately our application will only support SSL. We are using stunnel with other vendors but can control the inbound host name. This recent one is one we can't manage as it is the software provider. I found a solution for doing https to https. I'm unclear how I get the first https traffic to route to stunnel as the initial call will be from the application will be to the external host.. Any thoughts on whether this would work for my situation? Appreciate any thoughts.. [Tunnel_in] client = yes accept = host_ip:443 connect = localhost:54321 [Tunnel_out] client = no accept = localhost:54321 connect = externalhostname:443 Best regards, Dan

1 0

https to https proxy
by Daniel Trickett 19 Aug '19

19 Aug '19

Hi, Our punchout vendor switched their site to only accept tls 1.2 over the weekend. Unfortunately our application will only support SSL. We are using stunnel with other vendors but can control the inbound host name. This recent one is one we can't manage as it is the software provider. I found a solution for doing https to https. I'm unclear how I get the first https traffic to route to stunnel as the initial call will be from the application will be to the external host.. Any thoughts on whether this would work for my situation? Appreciate any thoughts.. [Tunnel_in] client = yes accept = host_ip:443 connect = localhost:54321 [Tunnel_out] client = no accept = localhost:54321 connect = externalhostname:443 Best regards, Dan

1 0

Working OCSP example instructions?
by Mark Currie 24 Jul '19

24 Jul '19

Hi, Does anyone have a link to detailed instructions of a working example of Stunnel with OCSP? (including certificate creation if possible) I came across one some time back but can no longer find it. I would greatly appreciate any help with this. I wasn't able to get any replies to my earlier posting showing my problem: https://www.stunnel.org/pipermail/stunnel-users/2019-July/006451.html

1 0