On Sat, Feb 27, 2016, Nounou Dadoun wrote:
> That gives me something to work with, the server is using openssl 1.0.2d, the
> client openssl 1.0.1h
>
Also does the server side pass "make test"? Especially test/sha512t
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial te
On Sat, Feb 27, 2016, Jeffrey Walton wrote:
> This came up recently on Stack Overflow. The server code specified
> SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, but failed to call
> SSL_CTX_set_client_CA_list. The connection did not fail as expected.
>
> Looking at the man page for SSL_CTX_s
On Sat, Feb 27, 2016, Nounou Dadoun wrote:
> That gives me something to work with, the server is using openssl 1.0.2d, the
> client openssl 1.0.1h
>
> I'd actually had an earlier interop problem between them (which I had a
> mailing list discussion about here:
> http://openssl.6102.n7.nabble.c
Hi Jeff,
The test I just ran was done with NO custom callback :
SSL_CTX_set_verify( pCtx, AUTH_REQUIRE, NULL );
with AUTH_REQUIRE defined as ( SSL_VERIFY_PEER |
SSL_VERIFY_FAIL_IF_NO_PEER_CERT )
-Message d'origine-
De : Jeffrey Walton [mailto:noloa...@gmail.com]
Envoyé : samedi 27 févri
> I have a server code whose context is configured with SSL_VERIFY_PEER |
> SSL_VERIFY_FAIL_IF_NO_PEER_CERT and which do not call
> SSL_CTX_set_client_CA_list().
> In this case, handshake is failing as expected when clients didn't send a
> certificate.
Thanks Michel.
Does your server use the defa
Really ?
As your post alarmed me, I tried my tests programs again and didn't noticed
anything wrong.
I have a server code whose context is configured with SSL_VERIFY_PEER |
SSL_VERIFY_FAIL_IF_NO_PEER_CERT and which do not call
SSL_CTX_set_client_CA_list().
In this case, handshake is failing as exp
That's a useful thing to try - given the earlier mismatch, I suspect that it
may be something in the hash calculation that's not quite lining up and causing
the signature match to fail. thanks for the suggestion .. N
From: openssl-users [openssl-users-bou
> On Feb 27, 2016, at 4:25 PM, Nounou Dadoun wrote:
>
> I agree but that's not the side I'm working on; the client is already widely
> distributed and if we can identify that as the interop problem then I can
> make an argument to the client team to upgrade but that doesn't solve the
> curren
I agree but that's not the side I'm working on; the client is already widely
distributed and if we can identify that as the interop problem then I can make
an argument to the client team to upgrade but that doesn't solve the currently
deployed problem ... N
__
This came up recently on Stack Overflow. The server code specified
SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, but failed to call
SSL_CTX_set_client_CA_list. The connection did not fail as expected.
Looking at the man page for SSL_CTX_set_verify [1] and
SSL_CTX_set_client_CA_list [2] it loo
> On Feb 27, 2016, at 3:49 PM, Kurt Roeckx wrote:
>
> On Sat, Feb 27, 2016 at 07:45:18PM +, Nounou Dadoun wrote:
>> PLATFORM=VC-WIN64A
>
> Can you try a build with no-asm?
Or perhaps with 1.0.1r, why stick with 1.0.1h???
--
Viktor.
--
openssl-users mailing list
To unsubscribe:
That's the client side configuration (the server is actually running on arm)
but I can get the client team to try it ... N
From: openssl-users [openssl-users-boun...@openssl.org] on behalf of Kurt
Roeckx [k...@roeckx.be]
Sent: February 27, 2016 12:49 PM
To
On Sat, Feb 27, 2016 at 07:45:18PM +, Nounou Dadoun wrote:
> PLATFORM=VC-WIN64A
Can you try a build with no-asm?
Kurt
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
That gives me something to work with, the server is using openssl 1.0.2d, the
client openssl 1.0.1h
I'd actually had an earlier interop problem between them (which I had a mailing
list discussion about here:
http://openssl.6102.n7.nabble.com/Failed-TLSv1-2-handshake-td61528.html#a61630
) where
On Sat, Feb 27, 2016 at 06:23:43PM +, Dr. Stephen Henson wrote:
> On Sat, Feb 27, 2016, Nounou Dadoun wrote:
>
> > Thanks for the response,
> >
> > I'm not sure what you're saying here other than TLS 1.2 client cert auth
> > processing is different from TLS x (where x<1.2); I would assume tha
On Sat, Feb 27, 2016, Nounou Dadoun wrote:
> Thanks for the response,
>
> I'm not sure what you're saying here other than TLS 1.2 client cert auth
> processing is different from TLS x (where x<1.2); I would assume that the
> range of mechanisms would expand to include more robust algorithms as ti
great!
Thanks, I'll give it a try, this looks promising enough :)
On Sat, Feb 27, 2016 at 7:42 PM, Michel wrote:
> Hi,
>
>
>
> Quoting Andy about applink : "New code should rather abstain from using
> above mentioned subset of OpenSSL API (whatever using FILE*)".
>
>
>
> So using the bio* versi
Hi,
Quoting Andy about applink : "New code should rather abstain from using above
mentioned subset of OpenSSL API (whatever using FILE*)".
So using the bio* version instead,
PEM_write_bio_SSL_SESSION( bio_st*, ssl_session_st*)
PEM_read_bio_SSL_SESSION( bio_st*, ssl_session_st**, int (ch
18 matches
Mail list logo
