Got a customer moving from HP VMS (Integrity) to VSI. They currently use STunnel-4_20 from HP with SSL1 V1.0.20 (OpenSSL 1.0.2o), and a test upgrade to VSI VMS without updating SSL1 has it working in the same environment. This is using self signed certs (CA on VMS) and strictly within the company's networks.

The VSI STunnel V5.56 says it was built with OpenSSL V1.1.1g and statically linked. The package does NOT list SSL/SSL1 as a prereq in the release notes; does that mean it should work as a standalone package without regard to the version of SSL/SSL1 installed (or if SSL/SSL1 is even installed at all)?

I'm waiting on the customer to provide their VSI support info, so asking here first. Thanks!

On Tuesday, 11 April 2023 at 15:33:55 UTC+1, Rich Jordan wrote:
> Got a customer moving from HP VMS (Integrity) to VSI. They currently use STunnel-4_20 from HP with SSL1 V1.0.20 (OpenSSL 1.0.2o), and a test upgrade to VSI VMS without updating SSL1 has it working in the same environment. This is using self signed certs (CA on VMS) and strictly within the company's networks.
>
> The VSI STunnel V5.56 says it was built with OpenSSL V1.1.1g and statically linked. The package does NOT list SSL/SSL1 as a prereq in the release notes; does that mean it should work as a standalone package without regard to the version of SSL/SSL1 installed (or if SSL/SSL1 is even installed at all)?
>
> I'm waiting on the customer to provide their VSI support info, so asking here first. Thanks!

As it is statically linked, there is no call out to the SSL shareable images. Rather all the required SSL modules are already included in the image, leaving no pre-requisites.
I understand that the next VSI stunnel release will be statically linked with SSL 3.0.x.

I personally maintain a port of stunnel for OpenVMS for our customers. i used to link the image dynamically against the shareable SSLx images. However, as the clients vary widely in their installed levels of SSLSSL1/SSL3, I now link our image statically with SSL3 and am able to implement it regardless of the client's patch levels.

On Tuesday, April 11, 2023 at 2:49:08 PM UTC-5, Duncan Morris wrote:
> On Tuesday, 11 April 2023 at 15:33:55 UTC+1, Rich Jordan wrote:
> > Got a customer moving from HP VMS (Integrity) to VSI. They currently use STunnel-4_20 from HP with SSL1 V1.0.20 (OpenSSL 1.0.2o), and a test upgrade to VSI VMS without updating SSL1 has it working in the same environment. This is using self signed certs (CA on VMS) and strictly within the company's networks.
> >
> > The VSI STunnel V5.56 says it was built with OpenSSL V1.1.1g and statically linked. The package does NOT list SSL/SSL1 as a prereq in the release notes; does that mean it should work as a standalone package without regard to the version of SSL/SSL1 installed (or if SSL/SSL1 is even installed at all)?
> >
> > I'm waiting on the customer to provide their VSI support info, so asking here first. Thanks!
> As it is statically linked, there is no call out to the SSL shareable images. Rather all the required SSL modules are already included in the image, leaving no pre-requisites.
> I understand that the next VSI stunnel release will be statically linked with SSL 3.0.x.
>
> I personally maintain a port of stunnel for OpenVMS for our customers. i used to link the image dynamically against the shareable SSLx images. However, as the clients vary widely in their installed levels of SSLSSL1/SSL3, I now link our image statically with SSL3 and am able to implement it regardless of the client's patch levels.

Thanks for replying.

We installed it on the test server and aimed it at the existing certs, and it looks like we'll have to build a new CA and generate new certs. The new Stunnel won't start with what we have, complaining about
":SSL routines:SSL_CTX_use_certificate:ca md too weak".

The existing server certs are only good for 4 more months and are the only ones using this in-house CA so its not a major issue, just an additional to-do. Hopefully the SSL1 on VMS procedures haven't changed too much so the docs we wrote up last time are still valid.

Thanks

On Wednesday, 12 April 2023 at 17:02:47 UTC+1, Rich Jordan wrote:
> On Tuesday, April 11, 2023 at 2:49:08 PM UTC-5, Duncan Morris wrote:
> > On Tuesday, 11 April 2023 at 15:33:55 UTC+1, Rich Jordan wrote:
> > > Got a customer moving from HP VMS (Integrity) to VSI. They currently use STunnel-4_20 from HP with SSL1 V1.0.20 (OpenSSL 1.0.2o), and a test upgrade to VSI VMS without updating SSL1 has it working in the same environment. This is using self signed certs (CA on VMS) and strictly within the company's networks.
> > >
> > > The VSI STunnel V5.56 says it was built with OpenSSL V1.1.1g and statically linked. The package does NOT list SSL/SSL1 as a prereq in the release notes; does that mean it should work as a standalone package without regard to the version of SSL/SSL1 installed (or if SSL/SSL1 is even installed at all)?
> > >
> > > I'm waiting on the customer to provide their VSI support info, so asking here first. Thanks!
> > As it is statically linked, there is no call out to the SSL shareable images. Rather all the required SSL modules are already included in the image, leaving no pre-requisites.
> > I understand that the next VSI stunnel release will be statically linked with SSL 3.0.x.
> >
> > I personally maintain a port of stunnel for OpenVMS for our customers. i used to link the image dynamically against the shareable SSLx images. However, as the clients vary widely in their installed levels of SSLSSL1/SSL3, I now link our image statically with SSL3 and am able to implement it regardless of the client's patch levels.
> Thanks for replying.
>
> We installed it on the test server and aimed it at the existing certs, and it looks like we'll have to build a new CA and generate new certs. The new Stunnel won't start with what we have, complaining about
> ":SSL routines:SSL_CTX_use_certificate:ca md too weak".
>
> The existing server certs are only good for 4 more months and are the only ones using this in-house CA so its not a major issue, just an additional to-do. Hopefully the SSL1 on VMS procedures haven't changed too much so the docs we wrote up last time are still valid.
>
> Thanks

Rich, I would recommend checking out the stunnel manual for several new parameters relating to security.
https://www.stunnel.org/static/stunnel.html

Particularly look at the new securityLevel = LEVEL option. The default setting is probably responsible for complaining out the existing CA and certs..

On Wednesday, April 12, 2023 at 2:52:29 PM UTC-5, Duncan Morris wrote:
> On Wednesday, 12 April 2023 at 17:02:47 UTC+1, Rich Jordan wrote:
> > On Tuesday, April 11, 2023 at 2:49:08 PM UTC-5, Duncan Morris wrote:
> > > On Tuesday, 11 April 2023 at 15:33:55 UTC+1, Rich Jordan wrote:
> > > > Got a customer moving from HP VMS (Integrity) to VSI. They currently use STunnel-4_20 from HP with SSL1 V1.0.20 (OpenSSL 1.0.2o), and a test upgrade to VSI VMS without updating SSL1 has it working in the same environment. This is using self signed certs (CA on VMS) and strictly within the company's networks.
> > > >
> > > > The VSI STunnel V5.56 says it was built with OpenSSL V1.1.1g and statically linked. The package does NOT list SSL/SSL1 as a prereq in the release notes; does that mean it should work as a standalone package without regard to the version of SSL/SSL1 installed (or if SSL/SSL1 is even installed at all)?
> > > >
> > > > I'm waiting on the customer to provide their VSI support info, so asking here first. Thanks!
> > > As it is statically linked, there is no call out to the SSL shareable images. Rather all the required SSL modules are already included in the image, leaving no pre-requisites.
> > > I understand that the next VSI stunnel release will be statically linked with SSL 3.0.x.
> > >
> > > I personally maintain a port of stunnel for OpenVMS for our customers.. i used to link the image dynamically against the shareable SSLx images. However, as the clients vary widely in their installed levels of SSLSSL1/SSL3, I now link our image statically with SSL3 and am able to implement it regardless of the client's patch levels.
> > Thanks for replying.
> >
> > We installed it on the test server and aimed it at the existing certs, and it looks like we'll have to build a new CA and generate new certs. The new Stunnel won't start with what we have, complaining about
> > ":SSL routines:SSL_CTX_use_certificate:ca md too weak".
> >
> > The existing server certs are only good for 4 more months and are the only ones using this in-house CA so its not a major issue, just an additional to-do. Hopefully the SSL1 on VMS procedures haven't changed too much so the docs we wrote up last time are still valid.
> >
> > Thanks
> Rich, I would recommend checking out the stunnel manual for several new parameters relating to security.
> https://www.stunnel.org/static/stunnel.html
>
> Particularly look at the new securityLevel = LEVEL option. The default setting is probably responsible for complaining out the existing CA and certs.

Thanks, I actually did try that option based on recommendations (on Stunnel for other platforms) that I found, but still get the same failure message. Still working on it, but again it isn't a big sacrifice to create a new CA and certs, so the customer may choose to go that route. Certainly would be more secure.

Rich