Hi
> -Original Message-
> From: Gaurav Jain
> Sent: Monday, January 10, 2022 1:12 PM
> To: John Baldwin ; bor...@mellanox.com; openssl-
> us...@openssl.org; m...@openssl.org
> Cc: Varun Sethi ; Pankaj Gupta
> Subject: RE: [EXT] Re: KTLS with openssl 3.0 fail with error
> ENOTCONN(Transpor
I'm not aware of a PKCS#11 provider being available at this point.
Pauli
On 13/1/22 5:02 am, Graham Leggett via openssl-users wrote:
On 13 Dec 2021, at 12:15, Tomas Mraz wrote:
One option would be for a provider to provide provider-storemgmt
implementation to load a key from its special URI
On 13 Dec 2021, at 12:15, Tomas Mraz wrote:
> One option would be for a provider to provide provider-storemgmt
> implementation to load a key from its special URI. You'd then use
> OSSL_STORE from the application to load a private key from that special
> URI.
>
> Another, rather simplistic, appr
On Wed, 2022-01-12 at 09:41 +0100, Milan Kaše wrote:
> By further comparing the scenario with the built-in file provider and
> my external provider I found that this has something to do with
> library contexts.
>
> When x509_pubkey_ex_d2i_ex tries to decode the certificate's public
> key it always
By further comparing the scenario with the built-in file provider and
my external provider I found that this has something to do with
library contexts.
When x509_pubkey_ex_d2i_ex tries to decode the certificate's public
key it always uses the default library context. When loading a
certificate fro
