> From: Wall, Stephen, Monday, November 28, 2016 6:52 AM
>
> > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
> > Behalf Of Ludwig, Mark
> >
> > A customer claims to have configured the web (app) server to only allow
> > TLS 1.2
> > (by
Greetings,
We have embedded OpenSSL 1.0.2j in our application order to securely
communicate with a Java Servlet engine (such as Tomcat). Our application uses
SSLv23_method(), so I expect it to negotiate up through TLS 1.2 (right?).
A customer claims to have configured the web (app)
> From: Salz, Rich, Wednesday, November 30, 2016 9:38 AM
>
> > We're moving up to OpenSSL 1.0.2j from OpenSSL 0.9.8, and
> > noticed that the SSL functions based on SSL_ctrl() changed from returning
> > type int to returning type long.
>
> The "proper" answer is to not use long, but rather sized
Greetings,
We're moving up to OpenSSL 1.0.2j from OpenSSL 0.9.8, and noticed
that the SSL
functions based on SSL_ctrl() changed from returning type int to returning type
long.
It's not clear why this is necessary, by spot-checking the documented numerical
domain of the
return values of the
> From: Jakob Bohm, Thursday, June 08, 2017 12:32 PM
>
> On 08/06/2017 18:48, Baojun Wang wrote:
> > Also on Windows (64-bit), openssl produces libssl-1_1-x64.dll as well
> > as libcrypto-1_1-x64.dll, this could be painful for application who
> > has to specify openssl dependency, for example now
> From: Michael Wojcik, Wednesday, November 08, 2017 7:03 AM
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] Help compiling on HPUX
>
> > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Dan Freed
> > Sent: Tuesday, November 07, 2017 19:14
> > To:
> From: Bill Kurland, Tuesday, April 17, 2018 4:19 PM
>
> I'm trying to build openssl-1.1.0h on AIX 6.1 with the ultimate goal of
> building the IO::Socket::SSL perl module.
>
> make fails when creating libcrypto.a and libssl.a because, it seems, the *.o
> files are in a format not recognized
> From: Dennis Clarke, Friday, March 15, 2019 8:33 AM
>
> On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
> > My guess is that your binary is loading the system's shared libraries.
> > To find out whether this is the case, try
> >
> > ldd bin/openssl
> >
> > If my assumption is correct, you
+1 on the point: firm expiration date without firm replacement date ... really?!
We have to hope that the firm expiration date will actually move if the
replacement isn't ready before then ... and that doesn't begin to account for
the calendar time to get the new one certified
Thanks,
Mark
Thanks, from someone else who builds no-shared and will need this mod.
From: openssl-users On Behalf Of John
Unsworth
Sent: Thursday, May 16, 2019 5:47 AM
To: openssl-users@openssl.org
Subject: RE: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix
In the absence of any steer
10 matches
Mail list logo