Re: [openssl-users] libraries after the build for WIn platform

Thank you for the reply, I've tried to build dynamic version (import lib + dll) so I see the libs like: openssl.lib libcrypto.lib capi.lib and some other ones, so do you mean that libeay32 and ssleay32 some depricated version ? and recommend me to go throu the git history for a looking for? (of

Re: [openssl-users] libraries after the build for WIn platform

Hi Ernst, On Tue, Nov 1, 2016 at 10:25 AM, Ernst Maurer wrote: > Thank you for the reply, > I've tried to build dynamic version (import lib + dll) so I see the libs > like: > openssl.lib > libcrypto.lib > capi.lib > and some other ones, > > so do you mean that libeay32

Re: [openssl-users] libraries after the build for WIn platform

I'd recommend using the official releases rather than the work-in-progress code at the head of git. Whoever looks after the library which needs OpenSSL should be able to tell you what version it needs, but from those names it's the 1.0.2 branch or earlier. 1.0.2 will be supported until the end

Re: [openssl-users] libraries after the build for WIn platform

Thank you! That is clear. вт, 01 ноя 2016 г., 12:47 Kim Gräsman : > Hi Ernst, > > On Tue, Nov 1, 2016 at 10:25 AM, Ernst Maurer > wrote: > > Thank you for the reply, > > I've tried to build dynamic version (import lib + dll) so I see the libs > >

Re: [openssl-users] [openssl-dev] Still seeing test failure in openssl 1.0.2 SNAPHOT 20161031

I just tested on two systems, Debian [unstable] and FreeBSD 8.4, and in both cases, that test goes through with no trouble at all. Could you tell us your exact configuration? If I recall correctly, you have your own hacked configuration, right? Cheers, Richard In message

[openssl-users] Key wrapping methods for NIST 800-38F

Hi Guys We are using OpenSLL 1.0.2j with FIPS Object Module (FOM) 2.0.10. We want to implement a key-wrapping mechanism in accordance with NIST publication 800-38F. This publication requires use of AES Key Wrap, AES Key Wrap With Padding, or Triple DEA Key Wrap. I wanted to know if we can use

Re: [openssl-users] [openssl-dev] Still seeing test failure in openssl 1.0.2 SNAPHOT 20161031

On Tue, Nov 01, 2016 at 10:54:39AM +0100, Richard Levitte wrote: > I just tested on two systems, Debian [unstable] and FreeBSD 8.4, and > in both cases, that test goes through with no trouble at all. > > Could you tell us your exact configuration? If I recall correctly, > you have your own

[openssl-users] SSL_Write() returns error SSL_ERROR_SYSCALL with errno 11, and it wants caller to try again

Hi, I did encounter a situation which I think could be better handled by openssl lib. In my system, when working under heavy load, sometimes while calling SSL_Write, it will return SSL_ERROR_SYSCALL, which we treated as an error and aborted the operation. Next time, when we wanted to send a new

Re: [openssl-users] Problems with cert authentication under Turkish locale

On Tue, Nov 01, 2016 at 06:15:01PM +0100, Jakob Bohm wrote: > >>The issue is triggered in libcurl but it seems to come out of libssl. It > >>seems to be > > Note that the Turkish UNICODE locales have the unusual property > that the uppercase/lowercase routines do not match ASCII "I" to > ASCII

Re: [openssl-users] Problems with cert authentication under Turkish locale

On Tue, Nov 01, 2016 at 04:28:18PM +0100, Sebastian Kloska wrote: [ Redirecting to openssl-users. ] > We have problems authenticating a a CERT while LC_CTYPE is set to > tr_TR.UTF-8 > > The issue is triggered in libcurl but it seems to come out of libssl. It > seems to be I see nothing in the

Re: [openssl-users] Problems with cert authentication under Turkish locale

On 01/11/2016 17:42, Viktor Dukhovni wrote: On Tue, Nov 01, 2016 at 04:28:18PM +0100, Sebastian Kloska wrote: [ Redirecting to openssl-users. ] (I cannot see the original posts, as I am only subscribed to -users). We have problems authenticating a a CERT while LC_CTYPE is set to tr_TR.UTF-8

[openssl-users] Is it safe to share single X509_STORE between multiple threads for verifying certificate?

Hello, I'd like a clarify a little bit about multithreaded use of X509_verify_cert. Use case: I want connections to be accepted and served in a network thread and delegate all certificate checking to another thread (or even thread pool). CA for all certificates to be checked is stored in a

Re: [openssl-users] Alert number 43

> When I tested a remote server using s_client, it responded with: > > verify return:1 > > 139790582232992:error:14094413:SSL routines:SSL3_READ_BYTES:sslv3 > alert unsupported certificate:s3_pkt.c:1259:SSL alert number 43 > > 139790582232992:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl >

[openssl-users] Alert number 43

Hi, When I tested a remote server using s_client, it responded with: verify return:1 139790582232992:error:14094413:SSL routines:SSL3_READ_BYTES:sslv3 alert unsupported certificate:s3_pkt.c:1259:SSL alert number 43 139790582232992:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake