Re: [openssl-users] Alert number 43

[Jeffrey Walton]

> 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 failure:s3_pkt.c:598:
>
>
> I found the the following URL about this:
>
> http://stackoverflow.com/questions/14435839/ssl-alert-43-when-doing-client-authentication-in-ssl?answertab=oldest#tab-top
>
> My question: Does this indicate something wrong with server side
> certificate like the URL said?

Netscape Cert Type was recently removed, IIRC.

OpenSSL servers [used to?] have a bug where they can't use the EC key
pair they generated for use with an EC-based certificate. Also see
http://wiki.openssl.org/index.php/Elliptic_Curve_Cryptography#Named_Curves.

Post the certificate. Use `openssl s_client -connect :
-tls1 -servername  | openssl x509 -text -noout`

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Alert number 43

[David Li]

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 failure:s3_pkt.c:598:


I found the the following URL about this:

http://stackoverflow.com/questions/14435839/ssl-alert-43-when-doing-client-authentication-in-ssl?answertab=oldest#tab-top

My question: Does this indicate something wrong with server side
certificate like the URL said?

Thanks.

David
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Oleg Andriyanov]

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 
single |X509_STORE|. Basically, when certificate is received from a 
client, I create new |X509_STORE_CTX|, initialize it with a single (say, 
global) |X509_STORE|, and feed a worker thread with a checking routine 
which calls |X509_verify_cert|.


The question is, does this kind of thread-sharing of |X509_STORE| need 
any external locking provided by an application?


Particularly, I'm worried because |X509_STORE_CTX_init| takes a 
non-const pointer of my |X509_STORE|. Probably, this is because this 
function modifies reference counters inside the store, which is 
thread-safe provided that locking callbacks are set during 
initialization of the library. There should be no other non-const access 
to the store, right?


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Viktor Dukhovni]

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 "i", to cater to the distinguishing between "dotted" and
> "dotless" letter I in Turkish natural language.  It is the only
> known locales to case map an ASCII character differently than the
> basic ASCII algorithm presumed by the standard for Internet host
> names.

Indeed, but the hostname comparison code in OpenSSL 1.0.2+ does
not uses none of the locale-sensitive tolower(), toupper(),
str[n]casecmp() to do name comparison:

/* Compare while ASCII ignoring case. */
static int equal_nocase(const unsigned char *pattern, size_t pattern_len,
const unsigned char *subject, size_t subject_len,
unsigned int flags)
{
skip_prefix(, _len, subject_len, flags);
if (pattern_len != subject_len)
return 0;
while (pattern_len) {
unsigned char l = *pattern;
unsigned char r = *subject;
/* The pattern must not contain NUL characters. */
if (l == 0)
return 0;
if (l != r) {
if ('A' <= l && l <= 'Z')
l = (l - 'A') + 'a';
if ('A' <= r && r <= 'Z')
r = (r - 'A') + 'a';
if (l != r)
return 0;
}
++pattern;
++subject;
--pattern_len;
}
return 1;
}

The only use of strncasecmp() is to compare the first four characters
of an A-label with with "xn--".  No known locale breaks that, and
there's no "xn--" in "www.hotmail.com".

The inputs are required to be A-labels, so Unicode is out of scope:

https://www.openssl.org/docs/man1.1.0/crypto/X509_check_host.html

Per section 6.4.2 of RFC 6125, name values representing
international domain names must be given in A-label form. The
namelen argument must be the number of characters in the name
string or zero in which case the length is calculated with
strlen(name). When name starts with a dot (e.g ".example.com"),
it will be matched by a certificate valid for any sub-domain
of name, (see also X509_CHECK_FLAG_SINGLE_LABEL_SUBDOMAINS
below).

Perhaps similar language should be added to:

https://www.openssl.org/docs/man1.1.0/ssl/SSL_set1_host.html

SSL_set1_host() sets the expected DNS hostname to name clearing
any previously specified host name or names. If name is NULL,
or the empty string the list of hostnames is cleared, and name
checks are not performed on the peer certificate. When a
non-empty name is specified, certificate verification automatically
checks the peer hostname via X509_check_host with flags as
specified via SSL_set_hostflags(). Clients that enable DANE
TLSA authentication via SSL_dane_enable should leave it to that
function to set the primary reference identifier of the peer,
and should not call SSL_set1_host().

Some users may not delve deeper and read the X509_check_host()
documentation.  Documentation patches welcome.

> So something, in either OpenSSL or curl (or a combination) may
> (on the OPs system) be using a locale-sensitive function to
> compare e.g. "hotmail.com" and "HOTMAIL.COM", where some kind
> of locale-neutral function should be used to avoid the special
> handling that the Unicode standard specifies for the letter "I"
> in Turkish.
> 
> >I see nothing in the OpenSSL X.509 stack that would be sensitive
> >to this locale.  In particular, with OpenSSL >= 1.0.2 doing the
> >hostname check, both:

It is hard to see where OpenSSL could be going astray.  It is true
that on Windows OpenSSL provides an OPENSSL_str[n]casecmp() that
compares by mapping to upper case.  Perhaps libcurl is using
that?

The name constraint code might hypothetically not work right in
the Turkish locale, because it uses the locale-sensitive strcasecmp().
That should be fixed, but is not pertinent to the OP's report.

-- 
Viktor.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jakob Bohm]

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

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 "i", to cater to the distinguishing between "dotted" and
"dotless" letter I in Turkish natural language.  It is the only
known locales to case map an ASCII character differently than the
basic ASCII algorithm presumed by the standard for Internet host
names.

So something, in either OpenSSL or curl (or a combination) may
(on the OPs system) be using a locale-sensitive function to
compare e.g. "hotmail.com" and "HOTMAIL.COM", where some kind
of locale-neutral function should be used to avoid the special
handling that the Unicode standard specifies for the letter "I"
in Turkish.


I see nothing in the OpenSSL X.509 stack that would be sensitive
to this locale.  In particular, with OpenSSL >= 1.0.2 doing the
hostname check, both:

 LANG=tr_TR.UTF-8 /Volumes/gitvol/viktor/ssl/OpenSSL_1_0_2/bin/openssl 
s_client -connect www.hotmail.com:443 -CAfile /tmp/bundle.pem -verify_hostname 
www.hotmail.com

and

 LC_CTYPE=tr_TR.UTF-8 /Volumes/gitvol/viktor/ssl/OpenSSL_1_0_2/bin/openssl 
s_client -connect www.hotmail.com:443 -CAfile /tmp/bundle.pem -verify_hostname 
www.hotmail.com

return success.  OpenSSL 1.0.1 and earlier do not do hostname
checks, that's left to the application.  With 1.0.1 the chain alone
verifies just fine:

 $ LC_CTYPE=tr_TR.UTF-8 /.../OpenSSL_1_0_1/bin/openssl s_client -connect 
www.hotmail.com:443 -CAfile /tmp/bundle.pem
 CONNECTED(0003)
 depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 
2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary 
Certification Authority - G5
 verify return:1
 depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN 
= Symantec Class 3 EV SSL CA - G3
 verify return:1
 depth=0 1.3.6.1.4.1.311.60.2.1.3 = US, 1.3.6.1.4.1.311.60.2.1.2 = 
Washington, businessCategory = Private Organization, serialNumber = 600413485, 
C = US, postalCode = 98052, ST = Washington, L = Redmond, street = 1 Microsoft 
Way, O = Microsoft Corporation, OU = Outlook Kahuna BAY-A Jun2015, CN = 
mail.live.com
 verify return:1
 ---
 Certificate chain
  0 
s:/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Washington/businessCategory=Private
 
Organization/serialNumber=600413485/C=US/postalCode=98052/ST=Washington/L=Redmond/street=1
 Microsoft Way/O=Microsoft Corporation/OU=Outlook Kahuna BAY-A 
Jun2015/CN=mail.live.com
i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec 
Class 3 EV SSL CA - G3
  1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec 
Class 3 EV SSL CA - G3
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 
VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary 
Certification Authority - G5
 ---
 Server certificate
 -BEGIN CERTIFICATE-
 ...
 -END CERTIFICATE-
 
subject=/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Washington/businessCategory=Private
 
Organization/serialNumber=600413485/C=US/postalCode=98052/ST=Washington/L=Redmond/street=1
 Microsoft Way/O=Microsoft Corporation/OU=Outlook Kahuna BAY-A 
Jun2015/CN=mail.live.com
 issuer=/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec 
Class 3 EV SSL CA - G3
 ---
 No client certificate CA names sent
 ---
 SSL handshake has read 5342 bytes and written 511 bytes
 ---
 New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384
 Server public key is 2048 bit
 Secure Renegotiation IS supported
 Compression: NONE
 Expansion: NONE
 SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-AES256-SHA384
Session-ID: ...
Session-ID-ctx:
Master-Key: ...
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1478018209
Timeout   : 300 (sec)
Verify return code: 0 (ok)

So it seems that any problem lies with libcurl.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Viktor Dukhovni]

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 OpenSSL X.509 stack that would be sensitive
to this locale.  In particular, with OpenSSL >= 1.0.2 doing the
hostname check, both:

LANG=tr_TR.UTF-8 /Volumes/gitvol/viktor/ssl/OpenSSL_1_0_2/bin/openssl 
s_client -connect www.hotmail.com:443 -CAfile /tmp/bundle.pem -verify_hostname 
www.hotmail.com

and

LC_CTYPE=tr_TR.UTF-8 /Volumes/gitvol/viktor/ssl/OpenSSL_1_0_2/bin/openssl 
s_client -connect www.hotmail.com:443 -CAfile /tmp/bundle.pem -verify_hostname 
www.hotmail.com

return success.  OpenSSL 1.0.1 and earlier do not do hostname
checks, that's left to the application.  With 1.0.1 the chain alone
verifies just fine:

$ LC_CTYPE=tr_TR.UTF-8 /.../OpenSSL_1_0_1/bin/openssl s_client -connect 
www.hotmail.com:443 -CAfile /tmp/bundle.pem
CONNECTED(0003)
depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = 
"(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 
Public Primary Certification Authority - G5
verify return:1
depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN = 
Symantec Class 3 EV SSL CA - G3
verify return:1
depth=0 1.3.6.1.4.1.311.60.2.1.3 = US, 1.3.6.1.4.1.311.60.2.1.2 = 
Washington, businessCategory = Private Organization, serialNumber = 600413485, 
C = US, postalCode = 98052, ST = Washington, L = Redmond, street = 1 Microsoft 
Way, O = Microsoft Corporation, OU = Outlook Kahuna BAY-A Jun2015, CN = 
mail.live.com
verify return:1
---
Certificate chain
 0 
s:/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Washington/businessCategory=Private
 
Organization/serialNumber=600413485/C=US/postalCode=98052/ST=Washington/L=Redmond/street=1
 Microsoft Way/O=Microsoft Corporation/OU=Outlook Kahuna BAY-A 
Jun2015/CN=mail.live.com
   i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec 
Class 3 EV SSL CA - G3
 1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec 
Class 3 EV SSL CA - G3
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, 
Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification 
Authority - G5
---
Server certificate
-BEGIN CERTIFICATE-
...
-END CERTIFICATE-

subject=/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Washington/businessCategory=Private
 
Organization/serialNumber=600413485/C=US/postalCode=98052/ST=Washington/L=Redmond/street=1
 Microsoft Way/O=Microsoft Corporation/OU=Outlook Kahuna BAY-A 
Jun2015/CN=mail.live.com
issuer=/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec 
Class 3 EV SSL CA - G3
---
No client certificate CA names sent
---
SSL handshake has read 5342 bytes and written 511 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-AES256-SHA384
Session-ID: ...
Session-ID-ctx:
Master-Key: ...
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1478018209
Timeout   : 300 (sec)
Verify return code: 0 (ok)

So it seems that any problem lies with libcurl.

-- 
Viktor.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Camiel C. Coppelmans]

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
packet, passing a new buffer with a different length to the SSL_Write
function, it returns the error SSL_ERROR_SSL with the following details:

*140701061253440:error:1409F07F:SSL routines:ssl3_write_pending:bad write
retry:s3_pkt.c:1097*

Meaning that SSL_Write was actually expecting us to call it again with the
same buffer and length that was used when it returned SSL_ERROR_SYSCALL.

It turns out that when SSL_Write returned SSL_ERROR_SYSCALL, errno value
was set to 11 (EAGAIN or EWOULDBLOCK), so I figured out that, although
openssl didn't explicitly indicate us to try again, the underling socket
did, therefore I started to handle this specific scenario the same way I
would if SSL_Write would have returned SSL_ERROR_WANT_WRITE, and it worked.

My question is: Is it ok to trust the errno in this scenario? Can I handle
it that way I handled?

And two: If Openssl is expecting us to retry the SSL_Write call, it should
have returned SSL_ERROR_WANT_WRITE, like it does for all other scenarios.
So, maybe it is something to be improved for a future release.

This issue happened in the following versions: 0.9.8zb and 1.0.2e

Thanks,
Camiel
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[The Doctor]

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 hacked configuration, right?
> 
> Cheers,
> Richard

Certainly,

My configuration script is


#!/usr/local/bin/bash
CC=/usr/local/bin/clang39  ./Configure --prefix=/usr/ BSD-x86_64 enable-gmp 
experimental-jpake enable-rfc3779 enable-shared zlib-dynamic disable-sctp 
experimental-store enable-ssl-trace enable-unit-test; make depend

> 
> In message <20161031142938.ga97...@doctor.nl2k.ab.ca> on Mon, 31 Oct 2016 
> 08:29:38 -0600, The Doctor  said:
> 
> doctor> I saw this yesterday as well
> doctor> 
> doctor> ../util/shlib_wrap.sh ./heartbeat_test
> doctor> test_dtls1_not_bleeding failed: expected return value 0, received -1
> doctor> ** test_dtls1_not_bleeding failed **
> doctor> 
> doctor> test_dtls1_not_bleeding_empty_payload failed: expected return value 
> 0, received -1
> doctor> ** test_dtls1_not_bleeding_empty_payload failed **
> doctor> 
> doctor> test_tls1_not_bleeding failed: expected return value 0, received -1
> doctor> ** test_tls1_not_bleeding failed **
> doctor> 
> doctor> test_tls1_not_bleeding_empty_payload failed: expected return value 0, 
> received -1
> doctor> ** test_tls1_not_bleeding_empty_payload failed **
> doctor> 
> doctor> 4 tests failed
> doctor> *** Error code 1
> doctor> 
> doctor> Stop.
> doctor> make[1]: stopped in 
> /usr/source/openssl-1.0.2-stable-SNAP-20161031/test
> doctor> *** Error code 1
> doctor> 
> doctor> Please fix
> doctor> 
> doctor> -- 
> doctor> Member - Liberal International This is doctor@@nl2k.ab.ca Ici 
> doctor@@nl2k.ab.ca
> doctor> God,Queen and country!Never Satan President Republic!Beware 
> AntiChrist rising! 
> doctor> http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on 
> Atheism
> doctor> Time for the USA to hold a referendum on its republic and vote to 
> dissolve!! 
> doctor> -- 
> doctor> openssl-dev mailing list
> doctor> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> doctor> 

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Time for the USA to hold a referendum on its republic and vote to dissolve!! 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Nauman Hameed]

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 any of these in FIPS and/or 
non-FIPS mode with the OpenSSL 1.0.2j + FOM 2.0.10?

If it is not possible to use these in FIPS or non-FIPS modes with above 
versions, which versions should be used? Please note that we are using the 
Microsoft Windows platform.

Thanks

Regards
Nauman
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Richard Levitte]

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 <20161031142938.ga97...@doctor.nl2k.ab.ca> on Mon, 31 Oct 2016 
08:29:38 -0600, The Doctor  said:

doctor> I saw this yesterday as well
doctor> 
doctor> ../util/shlib_wrap.sh ./heartbeat_test
doctor> test_dtls1_not_bleeding failed: expected return value 0, received -1
doctor> ** test_dtls1_not_bleeding failed **
doctor> 
doctor> test_dtls1_not_bleeding_empty_payload failed: expected return value 0, 
received -1
doctor> ** test_dtls1_not_bleeding_empty_payload failed **
doctor> 
doctor> test_tls1_not_bleeding failed: expected return value 0, received -1
doctor> ** test_tls1_not_bleeding failed **
doctor> 
doctor> test_tls1_not_bleeding_empty_payload failed: expected return value 0, 
received -1
doctor> ** test_tls1_not_bleeding_empty_payload failed **
doctor> 
doctor> 4 tests failed
doctor> *** Error code 1
doctor> 
doctor> Stop.
doctor> make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161031/test
doctor> *** Error code 1
doctor> 
doctor> Please fix
doctor> 
doctor> -- 
doctor> Member - Liberal International This is doctor@@nl2k.ab.ca Ici 
doctor@@nl2k.ab.ca
doctor> God,Queen and country!Never Satan President Republic!Beware AntiChrist 
rising! 
doctor> http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
doctor> Time for the USA to hold a referendum on its republic and vote to 
dissolve!! 
doctor> -- 
doctor> openssl-dev mailing list
doctor> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
doctor> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Ernst Maurer]

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
> > 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 course, I
> > built from the head of git.)
> >
> > P.S. I need this for the linking with Microsoft REST SDK (aka Casablanca)
>
> There are two generations of OpenSSL in flight at the moment:
>
> - 1.0.2, the 'old' one. Libs are named libeay32.* and ssleay32.*
> - 1.1.0, the 'new' one. Libs are named libcrypto*.* and libssl*.*
>
> 1.1.0 was released quite recently, so there's a good chance existing
> clients are more compatible with 1.0.2.
>
> We're building 1.0.2 from released source packages so I'm not sure
> about the details, but if you have a git clone there should be a tag
> or branch you could check out.
>
> - Kim
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeremy Farrell]

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 of 2019, and its latest release is 1.0.2j. 
It's available from the downloads page at 
https://www.openssl.org/source/ and there may be built binary 
distributions available elsewhere.


Regards,
  jjf

On 01/11/2016 09:25, 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 and ssleay32 some depricated version ? 
and recommend me to go throu the git history for a looking for? (of 
course, I built from the head of git.)


P.S. I need this for the linking with Microsoft REST SDK (aka Casablanca)

Rgds,
Ernst

On Tue, Nov 1, 2016 at 7:30 AM Jeremy Farrell 
> wrote:


I think this depends on what version of OpenSSL you're using and
whether you're using static or dynamic libraries, none of which
you mention. There were changes in library names in recent
releases. Try reviewing the various NOTES, INSTALL, and README
files for whichever version of OpenSSL you are working with.

Note also that there are substantial API changes between major
releases of OpenSSL; if the thing you are building expects
particular names for the static or import library files, that
suggests it probably expects a particular API version (not the
newest one if it's expecting those names). If you use whatever
version of OpenSSL the other library is expecting, it should have
files with the expected names.

Regards,
jjf

On 31/10/2016 11:41, Ernst Maurer wrote:

hi

I'm not using openssl daily , just need to build and link it with
another library.
that lib requires libeay32.lib and ssleay32.lib.
Are these  ones from OpenSSL distribution?
I've tried two options:
1. download a few pre-built versions of the  binaries
2. build own binaries from latest git

both cases don't contain these lib (and dll) files.
please assist

Rgds,
Ernst




--
J. J. Farrell
Not speaking for Oracle

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[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
> 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 course, I
> built from the head of git.)
>
> P.S. I need this for the linking with Microsoft REST SDK (aka Casablanca)

There are two generations of OpenSSL in flight at the moment:

- 1.0.2, the 'old' one. Libs are named libeay32.* and ssleay32.*
- 1.1.0, the 'new' one. Libs are named libcrypto*.* and libssl*.*

1.1.0 was released quite recently, so there's a good chance existing
clients are more compatible with 1.0.2.

We're building 1.0.2 from released source packages so I'm not sure
about the details, but if you have a git clone there should be a tag
or branch you could check out.

- Kim
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Ernst Maurer]

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 course, I
built from the head of git.)

P.S. I need this for the linking with Microsoft REST SDK (aka Casablanca)

Rgds,
Ernst

On Tue, Nov 1, 2016 at 7:30 AM Jeremy Farrell 
wrote:

I think this depends on what version of OpenSSL you're using and whether
you're using static or dynamic libraries, none of which you mention. There
were changes in library names in recent releases. Try reviewing the various
NOTES, INSTALL, and README files for whichever version of OpenSSL you are
working with.

Note also that there are substantial API changes between major releases of
OpenSSL; if the thing you are building expects particular names for the
static or import library files, that suggests it probably expects a
particular API version (not the newest one if it's expecting those names).
If you use whatever version of OpenSSL the other library is expecting, it
should have files with the expected names.

Regards,
jjf

On 31/10/2016 11:41, Ernst Maurer wrote:

hi

I'm not using openssl daily , just need to build and link it with another
library.
that lib requires libeay32.lib and ssleay32.lib.
Are these  ones from OpenSSL distribution?
I've tried two options:
1. download a few pre-built versions of the  binaries
2. build own binaries from latest git

both cases don't contain these lib (and dll) files.
please assist

Rgds,
Ernst


-- 
J. J. Farrell
Not speaking for Oracle.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users