Alternative for structure opaque X509 & X509_STORE_CTX

Hi Matt, Seen this comment in GitHub OpenSSL 1.1.0 made many structures opaque. You cannot directly access the fields inside the X509 structure any more. Instead you must use accessor functions. In this case, as @slontis says, you must use the function X509_get0_sign

Re: fips 140-2 module conditions and compilation target app

I think you've got the fist of the restriction.  You cannot make any changes to the source code, build files or the commands you use to build the FOM.  None are acceptable if you want a FIPS validate outcome.  I.e. you will lose the FIPS 140-2 validation state if you change anything. Pauli

fips 140-2 module conditions and compilation target app

hi, I develop my application and I need to use OpenSSL 1.0.2 with the OpenSSL FIPS Object Module 2.0. I know that OpenSSL 3.0 was released, but unfortunately I must use OpenSSL 1.0.2. I have read OpenSSL FIPS Object Module 2.0 documentation and I have one misunderstanding. *"note that as a con

Re: "DST Root CA X3" expiry workaround for OpenSSL 1.0.1, 1.0.0 and 0.9.8 client applications

I got a call on Thursday from my mom asking why Apple Mail couldn't SMTP deliver to my LE signed SMTP server. She forgot how to start teamviewer, so a Saturday morning trip to the small town she lives in later... and it she looks like a problem with anchors. On a brand new MacOS system from thi

Re: Store Mgmt and keys loading ( keyform ENG )

OK, thank you very much for your comments, that's clear. On Mon, 4 Oct 2021, 15:45 Tomas Mraz, wrote: > No, that's wrong. The dgst and other apps in OpenSSL-3.0 were already > modified to use OSSL_STORE API to load keys. So you do not need to > specify keyform=ENGINE if your key is provided by a

Re: Store Mgmt and keys loading ( keyform ENG )

No, that's wrong. The dgst and other apps in OpenSSL-3.0 were already modified to use OSSL_STORE API to load keys. So you do not need to specify keyform=ENGINE if your key is provided by a provider that supports the STORE functionality for some special URL scheme. You just specify the right URL wit

Re: Store Mgmt and keys loading ( keyform ENG )

Thank you for your comment. Am I wrong then in saying that dgst and possibly other apps are not ready to be used with providers rather than engines in the case you need keyform=ENGINE ? On Mon, 4 Oct 2021, 14:13 Tomas Mraz, wrote: > You would have to implement a STORE provider that handles you

Re: Store Mgmt and keys loading ( keyform ENG )

You would have to implement a STORE provider that handles your special url scheme and then the keys would be referenced by the yourscheme://any-identifier-you-have. Of course the application (i.e., the openssl application which already does this) would have to use the OSSL_STORE API to load the key

Re: Store Mgmt and keys loading ( keyform ENG )

I checked the sources, I found that keyform cannot be set to ENGINE if engine is not specified in the command options, this is in the function make_engine_url() called from load_key() when format==FORMAT_ENGINE. I am not specifying engine in the dgst command options as I am using a provider. I woul

Re: Store Mgmt and keys loading ( keyform ENG )

Forgot to write, I am using Openssl 3.0. Thank you On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana, wrote: > Hello, > I am doing my own provider starting from the default provider's code. > I have now a question, I am seeing the STOREMGMT operation is required to > interpret the URI of input pr

Re: Why custom RSA engine is not calling default RSA method?

Dear Shariful, Could you please try the patch from https://github.com/openssl/openssl/pull/16734? On Wed, Sep 29, 2021 at 6:59 PM Dmitry Belyavsky wrote: > Dear Shariful, > > Yes. You have to provide all the RSA_METHO functions your app is going to > use. > > On Tue, Sep 28, 2021 at 5:46 PM Sha

Store Mgmt and keys loading ( keyform ENG )

Hello, I am doing my own provider starting from the default provider's code. I have now a question, I am seeing the STOREMGMT operation is required to interpret the URI of input private key, I would like that the string passed by the user for input key is not interpret as file to open but just my

Re: Use of ossl_unused in err.h.in

Please raise a github issue for this. Matt On 02/10/2021 17:19, Arran Cudbard-Bell wrote: In current master HEAD and 3.0.0 calling ERR_GET_REASON throws the following warning: src/lib/tls/session.c:1323:43: warning: 'ERR_GET_REASON' was marked unused but was used [-Wused-but-marked-unused]