Since this seems to be a certificate issue, would it be possible
to make the server log all the certificate checking steps and
errors with the failing certificates.
One obvious test would be to try connecting to the "openssl s_server"
utility with a similar configuration and lots of debug options
In a test harness I'm writing I'm adding in a facility to check the validity
of an EC public key according to the 4 tests of X9.62.
The curve and point I supply to EC_POINT_is_at_infinity works fine.
However, when I come to use EC_POINT_is_on_curve it fails. The error return
indicates the e
>> If no application data is available then you get the -1 (for SSL_read()) or
>> 0 (for SSL_read_ex()) return code. You also get that return code for other
>> types of issues, and you are supposed to call SSL_get_error() to interpret
>> it.
>
> In this case SSL_get_error() returns 2 (SSL_ERROR
> On 23/01/2019 14:04, Arran Cudbard-Bell wrote:
>> I'm working with wpa_supplicant to try and fix up its EAP-TTLS and EAP-PEAP
>> implementations to work correctly with TLS 1.3 and session tickets.
>>
>> Where a new_session_ticket message is sent after client/server finish, calls
>> to SSL_read()
Yes, it works if I deactivate client auth.
Concerning the cipher: I use one specific cipher on server and on client side.
This is the only cipher supported by the actual hardware client.
Concerning the sigalg: I've had big trouble with this because due to bug in the
client I need to restrict the
On 24/01/2019 15:33, Matt Caswell wrote:
>
>
> On 24/01/2019 11:00, Scharfenberg, Carsten wrote:
>> Thanks for your answer, Matt.
>>
>> Obviously the issue is caused by the server.
>>
>> Currently I have two servers:
>> 1. The legacy server running IIS
>> 2. The new server running HAProxy
>> I
On 24/01/2019 11:00, Scharfenberg, Carsten wrote:
> Thanks for your answer, Matt.
>
> Obviously the issue is caused by the server.
>
> Currently I have two servers:
> 1. The legacy server running IIS
> 2. The new server running HAProxy
> I also have two clients:
> 1. the actual hardware client
On Thursday, 24 January 2019 12:00:03 CET Scharfenberg, Carsten wrote:
> Thanks for your answer, Matt.
>
> Obviously the issue is caused by the server.
the issue still could be in a client and it was just exposed by the new, more
strict server behaviour
> Currently I have two servers:
> 1. The
Thanks for your answer, Matt.
Obviously the issue is caused by the server.
Currently I have two servers:
1. The legacy server running IIS
2. The new server running HAProxy
I also have two clients:
1. the actual hardware client equipped with a hardware security module
2. curl using a client certi
On 24/01/2019 09:19, Scharfenberg, Carsten wrote:
> Hello everybody,
>
> I’ve just joined this group because I hope you guys can help me with my
> problem.
>
> I'm using haproxy 1.8.17 and openssl 1.1.1a from Debian testing to serve TLS
> 1.2
> connections with client authentication.
> The
Hello everybody,
I've just joined this group because I hope you guys can help me with my problem.
I'm using haproxy 1.8.17 and openssl 1.1.1a from Debian testing to serve TLS
1.2 connections with client authentication.
The TLS handshake runs through fine. But then the server answers with a Decry
11 matches
Mail list logo