Hi Matt,
Kindly provide your inputs for the below mail.
Thanks & Regards,
Nagalakshmi V J
From: Nagalakshmi V J
Sent: 22 October 2019 10:41:40
To: Matt Caswell ; openssl-users@openssl.org
Cc: Nagalakshmi V J
Subject: RE: OpenSSL compilation errors in Windows
Thanks Rich.
openssl version -a
…
OPENSSLDIR: "/usr/local/openssl-1.0.2a/ssl"
—
That tells me the dir openssl is looking in.
ls /usr/local/openssl-1.0.2a/ssl
total 36
drwxr-xr-x 6 root root 4096 2019-10-23 16:34 .
drwxr-xr-x 7 root root 4096 2019-10-22 12:27 ..
drwxr-xr-x 2 root root 4
On 23/10/2019 12:32, Johannes Bauer wrote:
> One step further... I've peeked at s_server.c and copied some of that
> code. I.e., concretely I now am at:
>
> const unsigned char tls13_aes128gcmsha256_id[] = { 0x13, 0x01 };
> const SSL_CIPHER *cipher = SSL_CIPHER_find(ssl, tls13_aes128gcmsha256_i
On 23/10/2019 10:24, Johannes Bauer wrote:
> Hi list,
>
> I'm in the process of refactoring/updating code that has been using
> TLS-PSK with TLSv1.2 for a number of years successfully. I want to
> upgrade it so that it uses TLSv1.3 exclusively.
>
> I find it *exceptionally* hard to wrap my hea
On Wed, Oct 23, 2019 at 01:21:54PM +, Salz, Rich via openssl-users wrote:
> >Is there a way for me to piggyback a void* inside the SSL structure so
> that I can access it from within the callback?
>
> Yes, you can use SSL_set_app_data and SSL_get_app_data which are documented
> in h
> From: tobias.w...@t-systems.com [mailto:tobias.w...@t-systems.com]
> Sent: Wednesday, October 23, 2019 02:11
>
> Our PKCS11 module development will discontinue and therefore I can`t use it
> anymore, but the idea is great and very interesting.
> To give more details we need a callback or similar
Suppose I want to verify a certificate, and I've collected some CRLs
and some OCSP responses. How can I do that?
If I just want to verify revocation for the end certificate (so
X509_V_FLAG_CRL_CHECK rather than X509_V_FLAG_CRL_CHECK_ALL) then
that's straightforward: I use X509_verify_cert without t
On 23.10.19 15:21, Salz, Rich wrote:
>>Is there a way for me to piggyback a void* inside the SSL structure so
> that I can access it from within the callback?
>
> Yes, you can use SSL_set_app_data and SSL_get_app_data which are documented
> in https://github.com/openssl/openssl/pull/10216
>Is there a way for me to piggyback a void* inside the SSL structure so
that I can access it from within the callback?
Yes, you can use SSL_set_app_data and SSL_get_app_data which are documented in
https://github.com/openssl/openssl/pull/10216 (and due to be merged to master
soon)
Hi list,
yet another question. In my process with TLS13-PSK, I've noticed that
the PSK callback does not have a user-definable callback context value.
However, the callback is passed the SSL* which I created when the
session was established.
Is there a way for me to piggyback a void* inside the S
On 23.10.19 11:24, Johannes Bauer wrote:
> All error checking omitted for now, this is obviously just a sample.
> When I try to connect to my server on the command line using s_client:
>
> $ openssl s_client -connect 127.0.0.1:12345 -psk_identity foo -psk 001122
>
> The server pukes:
>
> PSK serve
Hi list,
I'm in the process of refactoring/updating code that has been using
TLS-PSK with TLSv1.2 for a number of years successfully. I want to
upgrade it so that it uses TLSv1.3 exclusively.
I find it *exceptionally* hard to wrap my head around the new API and
the documentation/manpages are extr
Our PKCS11 module development will discontinue and therefore I can`t use it
anymore, but the idea is great and very interesting.
To give more details we need a callback or similar mechanism to replace the
signature created in Certificate TLS message with our signature coming from the
card reade
13 matches
Mail list logo