From piotr.lobacz at softgent.com  Tue Jun  1 14:57:50 2021
From: piotr.lobacz at softgent.com (Piotr Lobacz)
Date: Tue, 1 Jun 2021 14:57:50 +0000
Subject: ODP: CSR creation using pkcs11 dynamic engine
In-Reply-To: <AM0PR10MB320457A88F44DC643E156CB1E4219@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
References: <AM0PR10MB32046949C603D1DB54E92245E4229@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <AM0PR10MB32049BF846CE7740A7AA789EE4229@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <CAKuzo_h6HCPn0TiVLvKz864H9ktE5g9mHa40wev0bF5tuqeNKQ@mail.gmail.com>
 <AM0PR10MB3204EACFF7E9DBE259773DC3E4229@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <CAKuzo_iDbuv_qFTsQEEt5PwoGn126DCmjd-LKhTEaKLgJ0jnrg@mail.gmail.com>
 <AM0PR10MB320453BCE7C4B3088C1C504DE4219@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>,
 <CAKuzo_iV4ROS-PUY0ykLwcOT-xFqSHm+fHA0wj4bSOMZkFDeuw@mail.gmail.com>,
 <AM0PR10MB320457A88F44DC643E156CB1E4219@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <AM0PR10MB320423FB9E76CD9924DD1E04E43E9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>

Hi,
i have managed to find the engine method static EVP_PKEY *load_privkey(ENGINE *engine, const char *s_key_id, UI_METHOD *ui_method, void *callback_data) in libp11 package. I have also made a printf callback and i see the output that method is being called, but the problem is that i think i need to set this flag RSA_FLAG_EXT_PKEY in EVP_PKEY object which i don't know how to do is it even possible?

BR
Piotr ?obacz
________________________________
Od: openssl-users <openssl-users-bounces at openssl.org> w imieniu u?ytkownika Piotr Lobacz <piotr.lobacz at softgent.com>
Wys?ane: sobota, 29 maja 2021 20:12
Do: Selva Nair <selva.nair at gmail.com>
DW: openssl-users at openssl.org <openssl-users at openssl.org>
Temat: ODP: CSR creation using pkcs11 dynamic engine

Hi, unfortunately that is not that simple :( These methods are not being exposed by the dotnet. Porting them would take to much time because of the method struct. Recompiling the whole dotnet sdk is also not an option.

You know, i've been reading your mail and keep thinking and for now i see that the fastest way is to simply modify libp11 proxy engine in EVP_load_private_key method. First i can verify there the EVP_test_flag on the key and second modify the engine flags. This way i will be 100% sure that the problem is on dotnet side. Because when i was testing this key on the token i was generating 1024 bit length key and written it's length to the console. Than i have erased it completly and generated a new key pair with modified key length to 2048. The output result was changed: 1024 -> 2048. So the conclusion was that the key i taken correclty.

I will check this on monday and keep you inform. Have a nice weekend.

BR
Piotr
________________________________
Od: Selva Nair <selva.nair at gmail.com>
Wys?ane: sobota, 29 maja 2021 03:34
Do: Piotr Lobacz <piotr.lobacz at softgent.com>
Temat: Re: CSR creation using pkcs11 dynamic engine

Hi,

I will also check these flags of my RSA object using RSA_test_flags and give you the answer. In the meantime as you have already told, the experts in here can share their knowledge, but i rather suspect that all you said is correct :] and the bug is in the dotnet implementation...

You could probably work around it by getting the method from the key using meth = RSA_get_method(rsa) and then setting the flag on the method using RSA_meth_set_flags(meth, flags). May not be a nice thing to do to a method owned by the engine, but should work if those API are exposed via dotnet.

If this is indeed the problem, you could try lobbying two places: dotnet devs to add a check for flags in the key, and libp11/pkcs11 engine devs to also set the flags on the method. One of them may oblige, depending on their thoughts on what is "right".

Selva
[https://softgent.com/wp-content/uploads/2020/01/Zasob-14.png]<https://www.softgent.com>

Softgent Sp. z o.o., Budowlanych 31d, 80-298 Gdansk, POLAND

KRS: 0000674406, NIP: 9581679801, REGON: 367090912

www.softgent.com

S?d Rejonowy Gda?sk-P??noc w Gda?sku, VII Wydzia? Gospodarczy Krajowego Rejestru S?dowego

KRS 0000674406, Kapita? zak?adowy: 25 000,00 z? wp?acony w ca?o?ci.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210601/4e08775b/attachment.html>

From selva.nair at gmail.com  Tue Jun  1 15:15:13 2021
From: selva.nair at gmail.com (Selva Nair)
Date: Tue, 1 Jun 2021 11:15:13 -0400
Subject: CSR creation using pkcs11 dynamic engine
In-Reply-To: <AM0PR10MB320423FB9E76CD9924DD1E04E43E9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
References: <AM0PR10MB32046949C603D1DB54E92245E4229@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <AM0PR10MB32049BF846CE7740A7AA789EE4229@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <CAKuzo_h6HCPn0TiVLvKz864H9ktE5g9mHa40wev0bF5tuqeNKQ@mail.gmail.com>
 <AM0PR10MB3204EACFF7E9DBE259773DC3E4229@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <CAKuzo_iDbuv_qFTsQEEt5PwoGn126DCmjd-LKhTEaKLgJ0jnrg@mail.gmail.com>
 <AM0PR10MB320453BCE7C4B3088C1C504DE4219@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <CAKuzo_iV4ROS-PUY0ykLwcOT-xFqSHm+fHA0wj4bSOMZkFDeuw@mail.gmail.com>
 <AM0PR10MB320457A88F44DC643E156CB1E4219@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <AM0PR10MB320423FB9E76CD9924DD1E04E43E9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <CAKuzo_geLJxXZvQFqMdDP3W3CGrjPsRM0X3_1kt+zD=RV6aFzA@mail.gmail.com>

Hi Piotr,

On Tue, Jun 1, 2021 at 10:57 AM Piotr Lobacz <piotr.lobacz at softgent.com>
wrote:

> Hi,
> i have managed to find the engine method static EVP_PKEY
> *load_privkey(ENGINE *engine, const char *s_key_id, UI_METHOD *ui_method,
> void *callback_data) in libp11 package. I have also made a printf callback
> and i see the output that method is being called, but the problem is that i
> think i need to set this flag RSA_FLAG_EXT_PKEY in EVP_PKEY object which
> i don't know how to do is it even possible?
>

The flag on the key is always set by libp11 (look for RSA_set_key in
p11_rsa.c). What it doesn't set is any flags on the method -- which you
wanted to satisfy dotnet. For testing you could add it -- look for
PKCS11_get_rsa_method in the same file.

Selva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210601/0cf76a47/attachment.html>

From selva.nair at gmail.com  Tue Jun  1 15:18:05 2021
From: selva.nair at gmail.com (Selva Nair)
Date: Tue, 1 Jun 2021 11:18:05 -0400
Subject: CSR creation using pkcs11 dynamic engine
In-Reply-To: <CAKuzo_geLJxXZvQFqMdDP3W3CGrjPsRM0X3_1kt+zD=RV6aFzA@mail.gmail.com>
References: <AM0PR10MB32046949C603D1DB54E92245E4229@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <AM0PR10MB32049BF846CE7740A7AA789EE4229@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <CAKuzo_h6HCPn0TiVLvKz864H9ktE5g9mHa40wev0bF5tuqeNKQ@mail.gmail.com>
 <AM0PR10MB3204EACFF7E9DBE259773DC3E4229@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <CAKuzo_iDbuv_qFTsQEEt5PwoGn126DCmjd-LKhTEaKLgJ0jnrg@mail.gmail.com>
 <AM0PR10MB320453BCE7C4B3088C1C504DE4219@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <CAKuzo_iV4ROS-PUY0ykLwcOT-xFqSHm+fHA0wj4bSOMZkFDeuw@mail.gmail.com>
 <AM0PR10MB320457A88F44DC643E156CB1E4219@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <AM0PR10MB320423FB9E76CD9924DD1E04E43E9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <CAKuzo_geLJxXZvQFqMdDP3W3CGrjPsRM0X3_1kt+zD=RV6aFzA@mail.gmail.com>
Message-ID: <CAKuzo_ivKk+_4dgvEvN_oejjWfLuhnaZZu+PS5=P8=XRTsAJyQ@mail.gmail.com>

On Tue, Jun 1, 2021 at 11:15 AM Selva Nair <selva.nair at gmail.com> wrote:
>
> Hi Piotr,
>
> On Tue, Jun 1, 2021 at 10:57 AM Piotr Lobacz <piotr.lobacz at softgent.com> wrote:
>>
>> Hi,
>> i have managed to find the engine method static EVP_PKEY *load_privkey(ENGINE *engine, const char *s_key_id, UI_METHOD *ui_method, void *callback_data) in libp11 package. I have also made a printf callback and i see the output that method is being called, but the problem is that i think i need to set this flag RSA_FLAG_EXT_PKEY in EVP_PKEY object which i don't know how to do is it even possible?
>
>
> The flag on the key is always set by libp11 (look for RSA_set_key in p11_rsa.c).

Read that as RSA_set_flags, not RSA_set_key

selva

From piotr.lobacz at softgent.com  Tue Jun  1 15:18:56 2021
From: piotr.lobacz at softgent.com (Piotr Lobacz)
Date: Tue, 1 Jun 2021 15:18:56 +0000
Subject: ODP: CSR creation using pkcs11 dynamic engine
In-Reply-To: <CAKuzo_geLJxXZvQFqMdDP3W3CGrjPsRM0X3_1kt+zD=RV6aFzA@mail.gmail.com>
References: <AM0PR10MB32046949C603D1DB54E92245E4229@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <AM0PR10MB32049BF846CE7740A7AA789EE4229@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <CAKuzo_h6HCPn0TiVLvKz864H9ktE5g9mHa40wev0bF5tuqeNKQ@mail.gmail.com>
 <AM0PR10MB3204EACFF7E9DBE259773DC3E4229@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <CAKuzo_iDbuv_qFTsQEEt5PwoGn126DCmjd-LKhTEaKLgJ0jnrg@mail.gmail.com>
 <AM0PR10MB320453BCE7C4B3088C1C504DE4219@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <CAKuzo_iV4ROS-PUY0ykLwcOT-xFqSHm+fHA0wj4bSOMZkFDeuw@mail.gmail.com>
 <AM0PR10MB320457A88F44DC643E156CB1E4219@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <AM0PR10MB320423FB9E76CD9924DD1E04E43E9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>,
 <CAKuzo_geLJxXZvQFqMdDP3W3CGrjPsRM0X3_1kt+zD=RV6aFzA@mail.gmail.com>
Message-ID: <AM0PR10MB320496012270D93DA3308328E43E9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>

Hi Selva,
btw. i have found one issue in libp11 package https://github.com/OpenSC/libp11/issues/304 and i have used 0.4.10 i will check firstly with 0.4.11 and give you answer.

BR
Piotr
________________________________
Od: Selva Nair <selva.nair at gmail.com>
Wys?ane: wtorek, 1 czerwca 2021 17:15
Do: Piotr Lobacz <piotr.lobacz at softgent.com>
DW: openssl-users at openssl.org <openssl-users at openssl.org>
Temat: Re: CSR creation using pkcs11 dynamic engine

Hi Piotr,

On Tue, Jun 1, 2021 at 10:57 AM Piotr Lobacz <piotr.lobacz at softgent.com<mailto:piotr.lobacz at softgent.com>> wrote:
Hi,
i have managed to find the engine method static EVP_PKEY *load_privkey(ENGINE *engine, const char *s_key_id, UI_METHOD *ui_method, void *callback_data) in libp11 package. I have also made a printf callback and i see the output that method is being called, but the problem is that i think i need to set this flag RSA_FLAG_EXT_PKEY in EVP_PKEY object which i don't know how to do is it even possible?

The flag on the key is always set by libp11 (look for RSA_set_key in p11_rsa.c). What it doesn't set is any flags on the method -- which you wanted to satisfy dotnet. For testing you could add it -- look for PKCS11_get_rsa_method in the same file.

Selva
[https://softgent.com/wp-content/uploads/2020/01/Zasob-14.png]<https://www.softgent.com>

Softgent Sp. z o.o., Budowlanych 31d, 80-298 Gdansk, POLAND

KRS: 0000674406, NIP: 9581679801, REGON: 367090912

www.softgent.com

S?d Rejonowy Gda?sk-P??noc w Gda?sku, VII Wydzia? Gospodarczy Krajowego Rejestru S?dowego

KRS 0000674406, Kapita? zak?adowy: 25 000,00 z? wp?acony w ca?o?ci.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210601/934969a8/attachment.html>

From piotr.lobacz at softgent.com  Tue Jun  1 15:34:08 2021
From: piotr.lobacz at softgent.com (Piotr Lobacz)
Date: Tue, 1 Jun 2021 15:34:08 +0000
Subject: ODP: CSR creation using pkcs11 dynamic engine
In-Reply-To: <AM0PR10MB320496012270D93DA3308328E43E9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
References: <AM0PR10MB32046949C603D1DB54E92245E4229@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <AM0PR10MB32049BF846CE7740A7AA789EE4229@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <CAKuzo_h6HCPn0TiVLvKz864H9ktE5g9mHa40wev0bF5tuqeNKQ@mail.gmail.com>
 <AM0PR10MB3204EACFF7E9DBE259773DC3E4229@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <CAKuzo_iDbuv_qFTsQEEt5PwoGn126DCmjd-LKhTEaKLgJ0jnrg@mail.gmail.com>
 <AM0PR10MB320453BCE7C4B3088C1C504DE4219@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <CAKuzo_iV4ROS-PUY0ykLwcOT-xFqSHm+fHA0wj4bSOMZkFDeuw@mail.gmail.com>
 <AM0PR10MB320457A88F44DC643E156CB1E4219@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <AM0PR10MB320423FB9E76CD9924DD1E04E43E9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>,
 <CAKuzo_geLJxXZvQFqMdDP3W3CGrjPsRM0X3_1kt+zD=RV6aFzA@mail.gmail.com>,
 <AM0PR10MB320496012270D93DA3308328E43E9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <AM0PR10MB32047FCBE987856380E21494E43E9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>

Ok not fixed in 0.4.11 it is fixed in master branch... i need to build it from master.
________________________________
Od: openssl-users <openssl-users-bounces at openssl.org> w imieniu u?ytkownika Piotr Lobacz <piotr.lobacz at softgent.com>
Wys?ane: wtorek, 1 czerwca 2021 17:18
Do: Selva Nair <selva.nair at gmail.com>
DW: openssl-users at openssl.org <openssl-users at openssl.org>
Temat: ODP: CSR creation using pkcs11 dynamic engine

Hi Selva,
btw. i have found one issue in libp11 package https://github.com/OpenSC/libp11/issues/304 and i have used 0.4.10 i will check firstly with 0.4.11 and give you answer.

BR
Piotr
________________________________
Od: Selva Nair <selva.nair at gmail.com>
Wys?ane: wtorek, 1 czerwca 2021 17:15
Do: Piotr Lobacz <piotr.lobacz at softgent.com>
DW: openssl-users at openssl.org <openssl-users at openssl.org>
Temat: Re: CSR creation using pkcs11 dynamic engine

Hi Piotr,

On Tue, Jun 1, 2021 at 10:57 AM Piotr Lobacz <piotr.lobacz at softgent.com<mailto:piotr.lobacz at softgent.com>> wrote:
Hi,
i have managed to find the engine method static EVP_PKEY *load_privkey(ENGINE *engine, const char *s_key_id, UI_METHOD *ui_method, void *callback_data) in libp11 package. I have also made a printf callback and i see the output that method is being called, but the problem is that i think i need to set this flag RSA_FLAG_EXT_PKEY in EVP_PKEY object which i don't know how to do is it even possible?

The flag on the key is always set by libp11 (look for RSA_set_key in p11_rsa.c). What it doesn't set is any flags on the method -- which you wanted to satisfy dotnet. For testing you could add it -- look for PKCS11_get_rsa_method in the same file.

Selva
[https://softgent.com/wp-content/uploads/2020/01/Zasob-14.png]<https://www.softgent.com>

Softgent Sp. z o.o., Budowlanych 31d, 80-298 Gdansk, POLAND

KRS: 0000674406, NIP: 9581679801, REGON: 367090912

www.softgent.com

S?d Rejonowy Gda?sk-P??noc w Gda?sku, VII Wydzia? Gospodarczy Krajowego Rejestru S?dowego

KRS 0000674406, Kapita? zak?adowy: 25 000,00 z? wp?acony w ca?o?ci.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210601/52314098/attachment-0001.html>

From piotr.lobacz at softgent.com  Tue Jun  1 15:36:51 2021
From: piotr.lobacz at softgent.com (Piotr Lobacz)
Date: Tue, 1 Jun 2021 15:36:51 +0000
Subject: ODP: CSR creation using pkcs11 dynamic engine
In-Reply-To: <AM0PR10MB32047FCBE987856380E21494E43E9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
References: <AM0PR10MB32046949C603D1DB54E92245E4229@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <AM0PR10MB32049BF846CE7740A7AA789EE4229@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <CAKuzo_h6HCPn0TiVLvKz864H9ktE5g9mHa40wev0bF5tuqeNKQ@mail.gmail.com>
 <AM0PR10MB3204EACFF7E9DBE259773DC3E4229@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <CAKuzo_iDbuv_qFTsQEEt5PwoGn126DCmjd-LKhTEaKLgJ0jnrg@mail.gmail.com>
 <AM0PR10MB320453BCE7C4B3088C1C504DE4219@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <CAKuzo_iV4ROS-PUY0ykLwcOT-xFqSHm+fHA0wj4bSOMZkFDeuw@mail.gmail.com>
 <AM0PR10MB320457A88F44DC643E156CB1E4219@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <AM0PR10MB320423FB9E76CD9924DD1E04E43E9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>,
 <CAKuzo_geLJxXZvQFqMdDP3W3CGrjPsRM0X3_1kt+zD=RV6aFzA@mail.gmail.com>,
 <AM0PR10MB320496012270D93DA3308328E43E9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>,
 <AM0PR10MB32047FCBE987856380E21494E43E9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <AM0PR10MB3204BA662CDF472449C26A13E43E9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>

Sorry my bad i was checking bad position in the file...
________________________________
Od: openssl-users <openssl-users-bounces at openssl.org> w imieniu u?ytkownika Piotr Lobacz <piotr.lobacz at softgent.com>
Wys?ane: wtorek, 1 czerwca 2021 17:34
Do: Selva Nair <selva.nair at gmail.com>
DW: openssl-users at openssl.org <openssl-users at openssl.org>
Temat: ODP: CSR creation using pkcs11 dynamic engine

Ok not fixed in 0.4.11 it is fixed in master branch... i need to build it from master.
________________________________
Od: openssl-users <openssl-users-bounces at openssl.org> w imieniu u?ytkownika Piotr Lobacz <piotr.lobacz at softgent.com>
Wys?ane: wtorek, 1 czerwca 2021 17:18
Do: Selva Nair <selva.nair at gmail.com>
DW: openssl-users at openssl.org <openssl-users at openssl.org>
Temat: ODP: CSR creation using pkcs11 dynamic engine

Hi Selva,
btw. i have found one issue in libp11 package https://github.com/OpenSC/libp11/issues/304 and i have used 0.4.10 i will check firstly with 0.4.11 and give you answer.

BR
Piotr
________________________________
Od: Selva Nair <selva.nair at gmail.com>
Wys?ane: wtorek, 1 czerwca 2021 17:15
Do: Piotr Lobacz <piotr.lobacz at softgent.com>
DW: openssl-users at openssl.org <openssl-users at openssl.org>
Temat: Re: CSR creation using pkcs11 dynamic engine

Hi Piotr,

On Tue, Jun 1, 2021 at 10:57 AM Piotr Lobacz <piotr.lobacz at softgent.com<mailto:piotr.lobacz at softgent.com>> wrote:
Hi,
i have managed to find the engine method static EVP_PKEY *load_privkey(ENGINE *engine, const char *s_key_id, UI_METHOD *ui_method, void *callback_data) in libp11 package. I have also made a printf callback and i see the output that method is being called, but the problem is that i think i need to set this flag RSA_FLAG_EXT_PKEY in EVP_PKEY object which i don't know how to do is it even possible?

The flag on the key is always set by libp11 (look for RSA_set_key in p11_rsa.c). What it doesn't set is any flags on the method -- which you wanted to satisfy dotnet. For testing you could add it -- look for PKCS11_get_rsa_method in the same file.

Selva
[https://softgent.com/wp-content/uploads/2020/01/Zasob-14.png]<https://www.softgent.com>

Softgent Sp. z o.o., Budowlanych 31d, 80-298 Gdansk, POLAND

KRS: 0000674406, NIP: 9581679801, REGON: 367090912

www.softgent.com

S?d Rejonowy Gda?sk-P??noc w Gda?sku, VII Wydzia? Gospodarczy Krajowego Rejestru S?dowego

KRS 0000674406, Kapita? zak?adowy: 25 000,00 z? wp?acony w ca?o?ci.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210601/b8603750/attachment.html>

From piotr.lobacz at softgent.com  Tue Jun  1 15:43:58 2021
From: piotr.lobacz at softgent.com (Piotr Lobacz)
Date: Tue, 1 Jun 2021 15:43:58 +0000
Subject: ODP: CSR creation using pkcs11 dynamic engine
In-Reply-To: <AM0PR10MB3204BA662CDF472449C26A13E43E9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
References: <AM0PR10MB32046949C603D1DB54E92245E4229@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <AM0PR10MB32049BF846CE7740A7AA789EE4229@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <CAKuzo_h6HCPn0TiVLvKz864H9ktE5g9mHa40wev0bF5tuqeNKQ@mail.gmail.com>
 <AM0PR10MB3204EACFF7E9DBE259773DC3E4229@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <CAKuzo_iDbuv_qFTsQEEt5PwoGn126DCmjd-LKhTEaKLgJ0jnrg@mail.gmail.com>
 <AM0PR10MB320453BCE7C4B3088C1C504DE4219@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <CAKuzo_iV4ROS-PUY0ykLwcOT-xFqSHm+fHA0wj4bSOMZkFDeuw@mail.gmail.com>
 <AM0PR10MB320457A88F44DC643E156CB1E4219@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
 <AM0PR10MB320423FB9E76CD9924DD1E04E43E9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>,
 <CAKuzo_geLJxXZvQFqMdDP3W3CGrjPsRM0X3_1kt+zD=RV6aFzA@mail.gmail.com>,
 <AM0PR10MB320496012270D93DA3308328E43E9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>,
 <AM0PR10MB32047FCBE987856380E21494E43E9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>,
 <AM0PR10MB3204BA662CDF472449C26A13E43E9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <AM0PR10MB3204FB442CE4C4F7197C9EF2E43E9@AM0PR10MB3204.EURPRD10.PROD.OUTLOOK.COM>

Ok i have written printf in src/p11_rsa.c to check if i'm entering the RSA_set_flags callback and yes i am. Printf is being displayed but i still got this error, which shouldn't be any more.
________________________________
Od: openssl-users <openssl-users-bounces at openssl.org> w imieniu u?ytkownika Piotr Lobacz <piotr.lobacz at softgent.com>
Wys?ane: wtorek, 1 czerwca 2021 17:36
Do: Selva Nair <selva.nair at gmail.com>
DW: openssl-users at openssl.org <openssl-users at openssl.org>
Temat: ODP: CSR creation using pkcs11 dynamic engine

Sorry my bad i was checking bad position in the file...
________________________________
Od: openssl-users <openssl-users-bounces at openssl.org> w imieniu u?ytkownika Piotr Lobacz <piotr.lobacz at softgent.com>
Wys?ane: wtorek, 1 czerwca 2021 17:34
Do: Selva Nair <selva.nair at gmail.com>
DW: openssl-users at openssl.org <openssl-users at openssl.org>
Temat: ODP: CSR creation using pkcs11 dynamic engine

Ok not fixed in 0.4.11 it is fixed in master branch... i need to build it from master.
________________________________
Od: openssl-users <openssl-users-bounces at openssl.org> w imieniu u?ytkownika Piotr Lobacz <piotr.lobacz at softgent.com>
Wys?ane: wtorek, 1 czerwca 2021 17:18
Do: Selva Nair <selva.nair at gmail.com>
DW: openssl-users at openssl.org <openssl-users at openssl.org>
Temat: ODP: CSR creation using pkcs11 dynamic engine

Hi Selva,
btw. i have found one issue in libp11 package https://github.com/OpenSC/libp11/issues/304 and i have used 0.4.10 i will check firstly with 0.4.11 and give you answer.

BR
Piotr
________________________________
Od: Selva Nair <selva.nair at gmail.com>
Wys?ane: wtorek, 1 czerwca 2021 17:15
Do: Piotr Lobacz <piotr.lobacz at softgent.com>
DW: openssl-users at openssl.org <openssl-users at openssl.org>
Temat: Re: CSR creation using pkcs11 dynamic engine

Hi Piotr,

On Tue, Jun 1, 2021 at 10:57 AM Piotr Lobacz <piotr.lobacz at softgent.com<mailto:piotr.lobacz at softgent.com>> wrote:
Hi,
i have managed to find the engine method static EVP_PKEY *load_privkey(ENGINE *engine, const char *s_key_id, UI_METHOD *ui_method, void *callback_data) in libp11 package. I have also made a printf callback and i see the output that method is being called, but the problem is that i think i need to set this flag RSA_FLAG_EXT_PKEY in EVP_PKEY object which i don't know how to do is it even possible?

The flag on the key is always set by libp11 (look for RSA_set_key in p11_rsa.c). What it doesn't set is any flags on the method -- which you wanted to satisfy dotnet. For testing you could add it -- look for PKCS11_get_rsa_method in the same file.

Selva
[https://softgent.com/wp-content/uploads/2020/01/Zasob-14.png]<https://www.softgent.com>

Softgent Sp. z o.o., Budowlanych 31d, 80-298 Gdansk, POLAND

KRS: 0000674406, NIP: 9581679801, REGON: 367090912

www.softgent.com

S?d Rejonowy Gda?sk-P??noc w Gda?sku, VII Wydzia? Gospodarczy Krajowego Rejestru S?dowego

KRS 0000674406, Kapita? zak?adowy: 25 000,00 z? wp?acony w ca?o?ci.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210601/c81650e4/attachment-0001.html>

From jb-openssl at wisemo.com  Tue Jun  1 15:57:34 2021
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 1 Jun 2021 17:57:34 +0200
Subject: FW: X509_verify_cert() rejects all trusted certs with "default"
 X509_VERIFY_PARAM
In-Reply-To: <DM6PR18MB27007A735DE8300CA0C15B4BF9229@DM6PR18MB2700.namprd18.prod.outlook.com>
References: <1D5ACC3B-7D04-4CAA-A642-FC61D65E7552@sharp.fm>
 <DM6PR18MB27007A735DE8300CA0C15B4BF9229@DM6PR18MB2700.namprd18.prod.outlook.com>
Message-ID: <2fbcc14f-08c9-74b0-ef23-f7a950ddea94@wisemo.com>

On 2021-05-28 22:50, Michael Wojcik wrote:

> Just realized I sent this directly to Graham instead of to the list.
>
> -----Original Message-----
> From: Michael Wojcik
> Sent: Friday, 28 May, 2021 09:37
> To: 'Graham Leggett' <minfrin at sharp.fm>
> Subject: RE: X509_verify_cert() rejects all trusted certs with "default" X509_VERIFY_PARAM
>
>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Graham
>> Leggett via openssl-users
>> Sent: Friday, 28 May, 2021 06:30
>>
>> I am lost - I can fully understand what the code is doing, but I can?t see
>> why openssl only trusts certs with ?anyExtendedKeyUsage?.
> Interesting. I wondered if this might be enforcing some RFC 5280 or CA / Browser Forum Baseline Requirements rule.
>
> 5280 4.2.1.12 says:
>
>     In general, this
>     extension will appear only in end entity certificates.
>
> and
>
>     If the extension is present, then the certificate MUST only be used
>     for one of the purposes indicated.
>
> Your certificate has serverAuth and emailProtection, yes? So it cannot be used to sign other certificates, and OpenSSL is correct as far as that goes. 5280 doesn't define an EKU for signing certificates; so perhaps the intent of the OpenSSL code is "if EKU is present, this probably can't be used as a CA cert without violating 5280, but I'll look for this 'any' usage just in case and allow that".
>
> The errata for 5280 and the RFCs which update it do not appear to affect this section.
There is a very common extension to the validation of X.509
certificates (which should ideally be available as an option
parameter to OpenSSL validation APIs): The EKU in a CA:True
certificate limits the end cert EKU values that are acceptable.
The rule is NOT applied to ocspSigning due to a conflict with
that EKU authorizing the CA public key to sign OCSP responses
for the parent CA.

For example a CA with EKU=emailProtection,clientAuth cannot be
used to issue valid EKU=serverAuth certificates, however it can
still issue a delegated EKU=ocspSigning delegated OCSP signing
certificate.

In this filtering anyExtendedKeyUsage acts as a wildcard
indicating a universal CA, and ? In practice, the complete
absence of the EKU extension acts as an equivalent wildcard.

The OpenSSL 3 code discussed, as described by Graham, appears
to incorrectly apply the wildcard check without ORing it with
the normal check for inclusion of the usage for which the chain
is built and validated.? (I recommend that where such filtering
is done, it is part of chain building as different chains may
succeed for different usages).

> The CA/BF BR 7.1.2.1, the part of the certificate profile that covers root certificates, says:
>
>     d. extKeyUsage
>        This extension MUST NOT be present.
>
> Now, there's no particular reason for OpenSSL to enforce CA/BF BR, and good reason for it not to (the "CA" part refers to commercial CAs, and not all clients are browsers). But it's more evidence that root certificates, at least, should not have extKeyUsage because browsers can correctly reject those.
>
> The CA/BF profile is more complicated regarding what it calls "subordinate" certificates, aka intermediates, so for non-root trust anchors there are cases where you can get away with extKeyUsage. But a good rule is "only put extKeyUsage on entity [leaf] certificates".
>
>
> So that really leaves us with the question "do we want OpenSSL enforcing the extKeyUsage rules of RFC 5280?". And I'm tempted to say yes. In principle, the basicConstraints CA flag and the keyUsage keyCertSign option should suffice for this, but defense in depth, and in cryptographic protocols consistency is extremely important.
>
The CAB/F "guidelines" tend to include arbitrary restrictions above and 
beyond what good X.509 software libraries should do, such as limiting 
validity to 1 year, requiring end certificate holders to be magically 
able to respond to sudden revocations for bureaucratic reasons etc.? Or 
as quoted by Michael, a rule that all roots must be universal roots with 
the no-EKU implicit wildcard.
Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From Michael.Wojcik at microfocus.com  Tue Jun  1 17:32:22 2021
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 1 Jun 2021 17:32:22 +0000
Subject: FW: X509_verify_cert() rejects all trusted certs with "default"
 X509_VERIFY_PARAM
In-Reply-To: <2fbcc14f-08c9-74b0-ef23-f7a950ddea94@wisemo.com>
References: <1D5ACC3B-7D04-4CAA-A642-FC61D65E7552@sharp.fm>
 <DM6PR18MB27007A735DE8300CA0C15B4BF9229@DM6PR18MB2700.namprd18.prod.outlook.com>
 <2fbcc14f-08c9-74b0-ef23-f7a950ddea94@wisemo.com>
Message-ID: <DM6PR18MB27009DFE67C2109003AC180DF93E9@DM6PR18MB2700.namprd18.prod.outlook.com>

> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Jakob
> Bohm via openssl-users
> Sent: Tuesday, 1 June, 2021 09:58
>
> There is a very common extension to the validation of X.509
> certificates (which should ideally be available as an option
> parameter to OpenSSL validation APIs): The EKU in a CA:True
> certificate limits the end cert EKU values that are acceptable.
> The rule is NOT applied to ocspSigning due to a conflict with
> that EKU authorizing the CA public key to sign OCSP responses
> for the parent CA.
>
> For example a CA with EKU=emailProtection,clientAuth cannot be
> used to issue valid EKU=serverAuth certificates, however it can
> still issue a delegated EKU=ocspSigning delegated OCSP signing
> certificate.
>
> In this filtering anyExtendedKeyUsage acts as a wildcard
> indicating a universal CA, and   In practice, the complete
> absence of the EKU extension acts as an equivalent wildcard.

Makes sense. It would be nice if this were standardized as an update to RFC 5280.

> The OpenSSL 3 code discussed, as described by Graham, appears
> to incorrectly apply the wildcard check without ORing it with
> the normal check for inclusion of the usage for which the chain
> is built and validated.  (I recommend that where such filtering
> is done, it is part of chain building as different chains may
> succeed for different usages).

Yeah, I suspected that, but I wanted to see if other people more familiar with this area of the code were going to comment.

> The CAB/F "guidelines" tend to include arbitrary restrictions above and
> beyond what good X.509 software libraries should do, such as limiting
> validity to 1 year, requiring end certificate holders to be magically
> able to respond to sudden revocations for bureaucratic reasons etc.  Or
> as quoted by Michael, a rule that all roots must be universal roots with
> the no-EKU implicit wildcard.

Agreed. I refer our customers to the CA/BF Basic Requirements when they're dealing with browsers and mainstream web servers -- since those programs are often written to follow the CA/BF rules -- but try to make it clear that the CA/BF doesn't control PKIX.

--
Michael Wojcik

From lothar.belle at gmail.com  Mon Jun  7 18:26:28 2021
From: lothar.belle at gmail.com (Lothar Belle)
Date: Mon, 7 Jun 2021 20:26:28 +0200
Subject: =?UTF-8?Q?Compile_openssl=C3=9F1=2E1=2E1k_on_CentOS8?=
Message-ID: <CAKcSgFevsuZBwfJ_m0-MbZHT3RMtWzog+2Zvtor4T+ZbJgV22Q@mail.gmail.com>

Hi,
recently I compiled openssl-1.1.1k on CentOS-8
but when I am using libcrypto.so.1.1 I get errors like:

libk5crypto.so.3: undefined symbol: EVP_KDF_ctrl, version OPENSSL_1_1_1b

Obviously RedHat added additional features into there own libraries,
but using the same version/naming.
See https://bugzilla.redhat.com/show_bug.cgi?id=1829790

I tried also to apply the patches, but they don?t work with the latest
source code

https://git.centos.org/rpms/openssl/blob/c8/f/SOURCES/openssl-1.1.1-evp-kdf.patch

The suggested solution renaming the libraries didn?t work neither for me.

But we want to use the latest version, including all security fixes,
therefore I can?t use the build-in version.

Has anybody a solution for this?
Is it planned to implement such features in official OpenSSL in the near future?

Kind Regards,
Lothar

From a.cudbardb at freeradius.org  Mon Jun  7 19:01:04 2021
From: a.cudbardb at freeradius.org (Arran Cudbard-Bell)
Date: Mon, 7 Jun 2021 14:01:04 -0500
Subject: What's the rationale behind ssl-trace not being built by default?
Message-ID: <7EB90CAE-9E90-4B40-BE88-0E4DE425644C@freeradius.org>

The tables to convert extension IDs and compression methods to humanly readable names are not available outside ssl/t1_trace.c.

SSL_trace() itself produces reams of helpful information as handshakes progress, and is particularly useful for dealing with encrypted handshakes, where wireshark et al don't provide useful output.

What is the rationale for ssl-trace to be disabled by default?  Was it purely to keep binary sizes down, or was there a security aspect to the decision?

-Arran
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210607/3da13bbc/attachment-0001.sig>

From matt at openssl.org  Mon Jun  7 21:57:47 2021
From: matt at openssl.org (Matt Caswell)
Date: Mon, 7 Jun 2021 22:57:47 +0100
Subject: What's the rationale behind ssl-trace not being built by default?
In-Reply-To: <7EB90CAE-9E90-4B40-BE88-0E4DE425644C@freeradius.org>
References: <7EB90CAE-9E90-4B40-BE88-0E4DE425644C@freeradius.org>
Message-ID: <77efcb10-8edf-8779-c942-dd4b4e37d1d6@openssl.org>



On 07/06/2021 20:01, Arran Cudbard-Bell wrote:
> The tables to convert extension IDs and compression methods to humanly readable names are not available outside ssl/t1_trace.c.
> 
> SSL_trace() itself produces reams of helpful information as handshakes progress, and is particularly useful for dealing with encrypted handshakes, where wireshark et al don't provide useful output.
> 
> What is the rationale for ssl-trace to be disabled by default?  Was it purely to keep binary sizes down, or was there a security aspect to the decision?

Its a really good question and I've often wondered the same thing. The 
decision was made before my time. I suspect it was about keeping binary 
sizes down, but I can't imagine it would make that much difference. I 
have previously considered turning it on by default but never quite got 
around to it.

Matt

From a.cudbardb at freeradius.org  Mon Jun  7 23:09:58 2021
From: a.cudbardb at freeradius.org (Arran Cudbard-Bell)
Date: Mon, 7 Jun 2021 18:09:58 -0500
Subject: What's the rationale behind ssl-trace not being built by default?
In-Reply-To: <77efcb10-8edf-8779-c942-dd4b4e37d1d6@openssl.org>
References: <7EB90CAE-9E90-4B40-BE88-0E4DE425644C@freeradius.org>
 <77efcb10-8edf-8779-c942-dd4b4e37d1d6@openssl.org>
Message-ID: <CA0B6064-10D8-4350-B433-232A32C2E375@freeradius.org>



> On Jun 7, 2021, at 4:57 PM, Matt Caswell <matt at openssl.org> wrote:
> 
> 
> 
> On 07/06/2021 20:01, Arran Cudbard-Bell wrote:
>> The tables to convert extension IDs and compression methods to humanly readable names are not available outside ssl/t1_trace.c.
>> SSL_trace() itself produces reams of helpful information as handshakes progress, and is particularly useful for dealing with encrypted handshakes, where wireshark et al don't provide useful output.
>> What is the rationale for ssl-trace to be disabled by default?  Was it purely to keep binary sizes down, or was there a security aspect to the decision?
> 
> Its a really good question and I've often wondered the same thing. The decision was made before my time. I suspect it was about keeping binary sizes down, but I can't imagine it would make that much difference. I have previously considered turning it on by default but never quite got around to it.

If you don't have any objections I could submit a PR to enable it by default?  I'd image that the platforms that'd care about a few extra kb are in the minority, and it makes such a huge difference having SSL_trace() when trying to debug TLS 1.3 issues.

-Arran
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210607/40b03825/attachment.sig>

From matt at openssl.org  Tue Jun  8 07:10:34 2021
From: matt at openssl.org (Matt Caswell)
Date: Tue, 8 Jun 2021 08:10:34 +0100
Subject: What's the rationale behind ssl-trace not being built by default?
In-Reply-To: <CA0B6064-10D8-4350-B433-232A32C2E375@freeradius.org>
References: <7EB90CAE-9E90-4B40-BE88-0E4DE425644C@freeradius.org>
 <77efcb10-8edf-8779-c942-dd4b4e37d1d6@openssl.org>
 <CA0B6064-10D8-4350-B433-232A32C2E375@freeradius.org>
Message-ID: <4d425961-7b2f-b47f-6636-f18d2461a21b@openssl.org>



On 08/06/2021 00:09, Arran Cudbard-Bell wrote:
> 
> 
>> On Jun 7, 2021, at 4:57 PM, Matt Caswell <matt at openssl.org> wrote:
>>
>>
>>
>> On 07/06/2021 20:01, Arran Cudbard-Bell wrote:
>>> The tables to convert extension IDs and compression methods to humanly readable names are not available outside ssl/t1_trace.c.
>>> SSL_trace() itself produces reams of helpful information as handshakes progress, and is particularly useful for dealing with encrypted handshakes, where wireshark et al don't provide useful output.
>>> What is the rationale for ssl-trace to be disabled by default?  Was it purely to keep binary sizes down, or was there a security aspect to the decision?
>>
>> Its a really good question and I've often wondered the same thing. The decision was made before my time. I suspect it was about keeping binary sizes down, but I can't imagine it would make that much difference. I have previously considered turning it on by default but never quite got around to it.
> 
> If you don't have any objections I could submit a PR to enable it by default?  I'd image that the platforms that'd care about a few extra kb are in the minority, and it makes such a huge difference having SSL_trace() when trying to debug TLS 1.3 issues.

I have no objections although you'll have to be quick if you want it 
considered for 3.0. Since it would just be about changing the default 
people that care about the extra kb can still disable it.

Matt


From janjust at nikhef.nl  Tue Jun  8 07:35:58 2021
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Tue, 8 Jun 2021 09:35:58 +0200
Subject: =?UTF-8?Q?Re:_Compile_openssl=c3=9f1.1.1k_on_CentOS8?=
In-Reply-To: <CAKcSgFevsuZBwfJ_m0-MbZHT3RMtWzog+2Zvtor4T+ZbJgV22Q@mail.gmail.com>
References: <CAKcSgFevsuZBwfJ_m0-MbZHT3RMtWzog+2Zvtor4T+ZbJgV22Q@mail.gmail.com>
Message-ID: <e86b12ee-7b4f-911b-f6b2-661a6ad98015@nikhef.nl>

Hi,

On 07/06/21 20:26, Lothar Belle wrote:
> Hi,
> recently I compiled openssl-1.1.1k on CentOS-8
> but when I am using libcrypto.so.1.1 I get errors like:
>
> libk5crypto.so.3: undefined symbol: EVP_KDF_ctrl, version OPENSSL_1_1_1b
>
> Obviously RedHat added additional features into there own libraries,
> but using the same version/naming.
> See https://bugzilla.redhat.com/show_bug.cgi?id=1829790
>
> I tried also to apply the patches, but they don?t work with the latest
> source code
>
> https://git.centos.org/rpms/openssl/blob/c8/f/SOURCES/openssl-1.1.1-evp-kdf.patch
>
> The suggested solution renaming the libraries didn?t work neither for me.
>
> But we want to use the latest version, including all security fixes,
> therefore I can?t use the build-in version.
>
> Has anybody a solution for this?
> Is it planned to implement such features in official OpenSSL in the near future?
>
CentOS 8(.3) uses openssl 1.1.1g *with security backports*? . The whole 
idea of an enterprise OS like RHEL 8 is that you fix packages at certain 
version (e.g. kernel 4.18.0, gcc 8.3.1, openssl 1.1.1g) and that those 
versions will remain (mostly) constant throughout the life cycle of the OS.
Redhat backports security fixes from newer releases into this 1.1.1g 
release, thus one can claim that "rhel8 openssl 1.1.1g" is as safe (or 
unsafe) as the stock version of openssl 1.1.1k.

If you don't like this, then switch to a distro that does not use this 
"version pinning" - the downside of that will that you will be doing 
upgrades very frequently.

As you found out, it is nearly impossible to swap out the existing 
openssl 1.1.1g with a "stock" openssl version, as RedHat/CentOS have 
applied patches to it. My advice would be: don't even try. If you *have 
to* use openssl 1.1.1k, then switch to Fedora or to Ubuntu (not the LTS 
releases). But keep in mind:
- debian 10 uses openssl 1.1.1d
- ubuntu seems to be at openssl 1.1.1j
etc.

HTH,

JJK



From halmurray+openssl at sonic.net  Tue Jun  8 09:23:26 2021
From: halmurray+openssl at sonic.net (Hal Murray)
Date: Tue, 08 Jun 2021 02:23:26 -0700
Subject: =?UTF-8?Q?Re:_Compile_openssl=c3=9f1.1.1k_on_CentOS8?=
In-Reply-To: Message from Jan Just Keijser <janjust@nikhef.nl> of "Tue,
 08 Jun 2021 09:35:58 +0200." <e86b12ee-7b4f-911b-f6b2-661a6ad98015@nikhef.nl>
Message-ID: <20210608092326.0F1EE40605C@ip-64-139-1-69.sjc.megapath.net>


janjust at nikhef.nl said:
> As you found out, it is nearly impossible to swap out the existing  openssl
> 1.1.1g with a "stock" openssl version, as RedHat/CentOS have  applied patches
> to it. My advice would be: don't even try. If you *have  to* use openssl
> 1.1.1k, then switch to Fedora or to Ubuntu (not the LTS  releases). But keep
> in mind: - debian 10 uses openssl 1.1.1d - ubuntu seems to be at openssl
> 1.1.1j etc. 

There are two cases.  One is where you want to replace the system libraries so 
that all the installed programs that use libssl will now use your new version. 
 I agree doing that is crazy.  That's what distros are for.

But if you are working on a program and you want that one program to use a new 
version, that's not so hard.  The trick is to install your new version of 
openssl in /usr/local/ (or wherever).  Then you have to patch the build recipe 
for your program to look there.  This is how you would get your program ready 
for 3.0.0 or get a program that needs TLS1.3 to work on a distro that is stuck 
in the dark ages.

I use:
    ./config --prefix=/usr/local/ssl --openssldir=/usr/local/ssl shared
to build and install OpenSSL, then, for waf:
        ctx.env.INCLUDES = ["/usr/local/ssl/include"]
        ctx.env.LIBPATH = ["/usr/local/ssl/lib"]

I don't remember where I found that config line.


-- 
These are my opinions.  I hate spam.




From laurent at elanor.org  Tue Jun  8 10:01:24 2021
From: laurent at elanor.org (Laurent Blume)
Date: Tue, 8 Jun 2021 12:01:24 +0200
Subject: Checking a single signature from several in S/MIME
Message-ID: <e080567b-8b3c-47aa-5644-780c3b554fe2@elanor.org>

Hello list,

I'm signing a file using SMIME with 2 signers.

When trying to check the signature with only one of the two signers, it 
fails with a "signer certificate not found". Using both signers, it 
succeeds.

Is there a way to be able to check the signature with a single signer, 
not all of them?

// Signing

openssl smime -binary -sign -nodetach -in file -out file.signed -inkey 
key1.pem -signer cert1.pem -inkey key2.pem -signer cert2.pem

// this command fails with signer certificate not found"

openssl smime -binary -verify -nointern -noverify -certfile cert1.pem 
-in file.sign -out file.checked

// this command succeeds and write both certificates in file.signer

openssl smime -binary -verify -noverify -certfile cert1.pem -in 
file.sign -out file.checked -signer file.signer

// This command succeeds
openssl smime -binary -verify -nointern -noverify -certfile file.signer 
-in file.sign -out file.checked

thanks in advance for any suggestion,

Laurent




From pramod.illuri at gmail.com  Tue Jun  8 10:36:54 2021
From: pramod.illuri at gmail.com (Illuri Pramod)
Date: Tue, 8 Jun 2021 16:06:54 +0530
Subject: Openssl FIPS 186-4 Support
Message-ID: <CABcPUNdXLvKY=bWgmMStCZz+PeQ0jWy7_w4NG3DJ16k8vdTt4A@mail.gmail.com>

Hello All,

I am looking for options to support fips 186-4 in openssl 1.0.2. Oracle FOM
based out of fips object module (FOM) 2.0.13, which is available in public
domain, claims to have 186-4 support as per the documentation. However, I
didn't find the specific diff/API, which added this support.

Ref :
https://github.com/oracle/solaris-openssl-fips

Could someone help me point out which API or code section corresponds to
supporting fips 186-4 in the oracle FOM module ?


Thanks,
Pramod.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210608/308568b1/attachment-0001.html>

From pramod.illuri at gmail.com  Tue Jun  8 11:12:49 2021
From: pramod.illuri at gmail.com (Illuri Pramod)
Date: Tue, 8 Jun 2021 16:42:49 +0530
Subject: Openssl FIPS 186-4 Support
In-Reply-To: <CABcPUNdXLvKY=bWgmMStCZz+PeQ0jWy7_w4NG3DJ16k8vdTt4A@mail.gmail.com>
References: <CABcPUNdXLvKY=bWgmMStCZz+PeQ0jWy7_w4NG3DJ16k8vdTt4A@mail.gmail.com>
Message-ID: <CABcPUNchvowfn6exB=GfvaKSezs51fpgfUPQHTP0fvpt8Z3qwA@mail.gmail.com>

To be more specific, Please help me point out the API, which supports *RSA
186-4 key generation*.

Thanks,
Pramod.


On Tue, Jun 8, 2021 at 4:06 PM Illuri Pramod <pramod.illuri at gmail.com>
wrote:

> Hello All,
>
> I am looking for options to support fips 186-4 in openssl 1.0.2. Oracle
> FOM based out of fips object module (FOM) 2.0.13, which is available in
> public domain, claims to have 186-4 support as per the documentation.
> However, I didn't find the specific diff/API, which added this support.
>
> Ref :
> https://github.com/oracle/solaris-openssl-fips
>
> Could someone help me point out which API or code section corresponds to
> supporting fips 186-4 in the oracle FOM module ?
>
>
> Thanks,
> Pramod.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210608/2fe8f675/attachment.html>

From hkario at redhat.com  Tue Jun  8 11:48:47 2021
From: hkario at redhat.com (Hubert Kario)
Date: Tue, 08 Jun 2021 13:48:47 +0200
Subject: What's the rationale behind ssl-trace not being built by
 =?iso-8859-1?Q?default=3F?=
In-Reply-To: <7EB90CAE-9E90-4B40-BE88-0E4DE425644C@freeradius.org>
References: <7EB90CAE-9E90-4B40-BE88-0E4DE425644C@freeradius.org>
Message-ID: <fc0aa2f8-d8ec-4807-bf5c-38bdbf90503b@redhat.com>

On Monday, 7 June 2021 21:01:04 CEST, Arran Cudbard-Bell wrote:
> The tables to convert extension IDs and compression methods to 
> humanly readable names are not available outside ssl/t1_trace.c.
>
> SSL_trace() itself produces reams of helpful information as 
> handshakes progress, and is particularly useful for dealing with 
> encrypted handshakes, where wireshark et al don't provide useful 
> output.

Note that many tools are able to produce a keyfile that wireshark can use
to decrypt the encrypted parts of handshake and exchanged data too.

Look for SSLKEYLOGFILE in https://wiki.wireshark.org/TLS

It's supported in clients like Firefox and curl, as well as in servers,
like httpd: https://github.com/apache/httpd/pull/74

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic


From hkario at redhat.com  Tue Jun  8 12:05:18 2021
From: hkario at redhat.com (Hubert Kario)
Date: Tue, 08 Jun 2021 14:05:18 +0200
Subject: Compile =?iso-8859-1?Q?openssl=DF1.1.1k_on_CentOS8?=
In-Reply-To: <CAKcSgFevsuZBwfJ_m0-MbZHT3RMtWzog+2Zvtor4T+ZbJgV22Q@mail.gmail.com>
References: <CAKcSgFevsuZBwfJ_m0-MbZHT3RMtWzog+2Zvtor4T+ZbJgV22Q@mail.gmail.com>
Message-ID: <4f824edc-3768-4652-8ac2-62ae46e80c00@redhat.com>

On Monday, 7 June 2021 20:26:28 CEST, Lothar Belle wrote:
> Hi,
> recently I compiled openssl-1.1.1k on CentOS-8
> but when I am using libcrypto.so.1.1 I get errors like:
>
> libk5crypto.so.3: undefined symbol: EVP_KDF_ctrl, version OPENSSL_1_1_1b
>
> Obviously RedHat added additional features into there own libraries,
> but using the same version/naming.
> See https://bugzilla.redhat.com/show_bug.cgi?id=1829790
>
> I tried also to apply the patches, but they don?t work with the latest
> source code
>
> https://git.centos.org/rpms/openssl/blob/c8/f/SOURCES/openssl-1.1.1-evp-kdf.patch
>
> The suggested solution renaming the libraries didn?t work neither for me.
>
> But we want to use the latest version, including all security fixes,
> therefore I can?t use the build-in version.

Please note that packages in RHEL, and thus, later, in CentOS, include
security fixes: https://access.redhat.com/security/updates/backporting
even if their package version is older than the newest upstream release.

But that's not the only reason why those packages have additional patches,
they also have them to better integrate with the rest of the system:
https://access.redhat.com/articles/3655361
or integrate with features like system-wide crypto policies:
https://access.redhat.com/articles/3666211
or, as in the case of the openssl-1.1.1-evp-kdf.patch, to provide features
from newer releases (like 3.0.0) in an older ABI release.

So I'd strongly suggest against replacting the .so files of any low-level
library, in any distribution, not just RHEL or CentOS.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic


From jb-openssl at wisemo.com  Tue Jun  8 12:59:05 2021
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 8 Jun 2021 14:59:05 +0200
Subject: Best practice for distributions that freeze OpenSSL versions and
 backports
Message-ID: <896b8343-5d61-0660-ca93-dd64b6d2f3a6@wisemo.com>

Dear team,

It would be nice if there was a user- and security-friendly best 
practice document for distributions (such as Linux distributions) that 
freeze on an OpenSSL release version (such as 1.1.1z) and then backport 
any important fixes.

Perhaps something like the following:

1. The distributor shall seek to backport as many upstream security 
fixes as possible and shall sign up to receive advance confidential 
copies of such code changes to attempt a coordinated release at the same 
time as the upstream release.

1.1. The version number frozen on should be from the upstream branch 
with the latest upstream maintenance end date available at the time of 
freezing the version.

2. Any such backport-patched version (as source, library, shared 
library, and/or openssl binary shall be provided with a document named: 
README.fixes with distribution appropriate extension for such files 
(like .txt or .gz)) listing the following:

2.1 The version number of the most recent upstream release version 
considered at the time of last document update.

2.2 The version number of the upstream release version chosen as the 
frozen base, and the date when that choice was made.

2.3 The current differences from that most recent upstream release 
version, specifying any upstream security advisories and public CVEs not 
completely fixed, but still listing any and all non-security 
enhancements not included.

2.4 The current differences from the named frozen base version, with any 
net changes back and forth cancelled out (thus not a changelog).? Any 
change fixing a security issue shall list the upstream security advisory 
and public CVE.

2.5. The distribution maintainers that did the backporting and writing 
of the document, and (if different) the contact point for reporting 
issues/bugs in the backport work.

3. The README.fixes document should, if possible, be made available to 
the upstream project


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded	


From a.cudbardb at freeradius.org  Tue Jun  8 22:00:09 2021
From: a.cudbardb at freeradius.org (Arran Cudbard-Bell)
Date: Tue, 8 Jun 2021 17:00:09 -0500
Subject: What's the rationale behind ssl-trace not being built by default?
In-Reply-To: <fc0aa2f8-d8ec-4807-bf5c-38bdbf90503b@redhat.com>
References: <7EB90CAE-9E90-4B40-BE88-0E4DE425644C@freeradius.org>
 <fc0aa2f8-d8ec-4807-bf5c-38bdbf90503b@redhat.com>
Message-ID: <7E449778-63F2-48FB-8243-46683A8C2028@freeradius.org>



> On Jun 8, 2021, at 6:48 AM, Hubert Kario <hkario at redhat.com> wrote:
> 
> On Monday, 7 June 2021 21:01:04 CEST, Arran Cudbard-Bell wrote:
>> The tables to convert extension IDs and compression methods to humanly readable names are not available outside ssl/t1_trace.c.
>> 
>> SSL_trace() itself produces reams of helpful information as handshakes progress, and is particularly useful for dealing with encrypted handshakes, where wireshark et al don't provide useful output.
> 
> Note that many tools are able to produce a keyfile that wireshark can use
> to decrypt the encrypted parts of handshake and exchanged data too.
> 
> Look for SSLKEYLOGFILE in https://wiki.wireshark.org/TLS
> 
> It's supported in clients like Firefox and curl, as well as in servers,
> like httpd: https://github.com/apache/httpd/pull/74

That's very interesting, I'll look into providing support for keylog files in FreeRADIUS as well.

PR for enabling ssl-trace by default is open here: https://github.com/openssl/openssl/pull/15665

-Arran
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210608/b9e18ce2/attachment.sig>

From jschauma at netmeister.org  Wed Jun  9 16:32:59 2021
From: jschauma at netmeister.org (Jan Schaumann)
Date: Wed, 9 Jun 2021 12:32:59 -0400
Subject: enforce ALPN overlap?
Message-ID: <20210609163259.GB21790@netmeister.org>

Hello,

Based on https://alpaca-attack.com/, I was looking at
how a TLS connection with ALPN set to e.g., "banana"
by the client to a server that has ALPN set to "h2"
would behave.  For example:

$ openssl s_server -www -accept 443 -alpn h2 \
	-key /tmp/key.pem -cert /tmp/cert.pem

and

$ openssl s_client -connect localhost:443 -alpn banana

It seems that OpenSSL will simply not negotiate ALPN,
but leave the connection open:

[...]
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
[...]
---
read R BLOCK

In Go, a recent commit changed their behavior to
enforce ALPN overlap:
https://github.com/golang/go/commit/90d6bbbe42c15d444c1da0a1c293192d6f735a8e


Is there any plan or consideration to follow that
approach?

-Jan

From jschauma at netmeister.org  Wed Jun  9 16:38:39 2021
From: jschauma at netmeister.org (Jan Schaumann)
Date: Wed, 9 Jun 2021 12:38:39 -0400
Subject: enforce ALPN overlap?
In-Reply-To: <20210609163259.GB21790@netmeister.org>
References: <20210609163259.GB21790@netmeister.org>
Message-ID: <20210609163838.GA12784@netmeister.org>

Jan Schaumann via openssl-users <openssl-users at openssl.org> wrote:

> New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384

Same for TLS 1.2, btw.  (I accidentally copied the
default output when writing the email.)

-Jan

From tomas at openssl.org  Wed Jun  9 16:43:34 2021
From: tomas at openssl.org (Tomas Mraz)
Date: Wed, 09 Jun 2021 18:43:34 +0200
Subject: enforce ALPN overlap?
In-Reply-To: <20210609163259.GB21790@netmeister.org>
References: <20210609163259.GB21790@netmeister.org>
Message-ID: <7a3e9a963effc887fb67317c4a7ce3e09e3b1192.camel@openssl.org>

On Wed, 2021-06-09 at 12:32 -0400, Jan Schaumann via openssl-users
wrote:
> Hello,
> 
> Based on https://alpaca-attack.com/, I was looking at
> how a TLS connection with ALPN set to e.g., "banana"
> by the client to a server that has ALPN set to "h2"
> would behave.  For example:
> 
> $ openssl s_server -www -accept 443 -alpn h2 \
> 	-key /tmp/key.pem -cert /tmp/cert.pem
> 
> and
> 
> $ openssl s_client -connect localhost:443 -alpn banana
> 
> It seems that OpenSSL will simply not negotiate ALPN,
> but leave the connection open:
> 
> [...]
> New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
> Server public key is 2048 bit
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> Early data was not sent
> [...]
> ---
> read R BLOCK
> 
> In Go, a recent commit changed their behavior to
> enforce ALPN overlap:
> https://github.com/golang/go/commit/90d6bbbe42c15d444c1da0a1c293192d6f735a8e
> 
> 
> Is there any plan or consideration to follow that
> approach?

The OpenSSL library allows the alpn application callback to decide.
Please see https://github.com/openssl/openssl/issues/2708

Also in the master branch the callback in the s_server application is
already changed to reject the connection in such case.
https://github.com/openssl/openssl/pull/11415

But even in 1.1.1 this is very well possible in 3rd party servers. 

-- 
Tom?? Mr?z
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]



From kevin at myplaceonline.com  Fri Jun 11 20:48:50 2021
From: kevin at myplaceonline.com (Kevin Grigorenko)
Date: Fri, 11 Jun 2021 20:48:50 +0000
Subject: Using keylog_callback with LD_PRELOAD
Message-ID: <f8317196-61a7-43f0-bf94-a9800f03466c@mtasv.net>

Hi, I want to use keylog_callback with LD_PRELOAD (i.e. without modifying
 the program to call 
SSL_CTX_set_keylog_callback). For testing, I'm using curl compiled with
 openssl. First, let's confirm curl is using 
SSL_CTX_set_keylog_callback only if there's an SSLKEYLOGFILE by using
 ltrace. With the envar, 
SSL_CTX_set_keylog_callback is called:

$ SSLKEYLOGFILE=/tmp/tls.log ltrace -e SSL_CTX_set_keylog_callback curl
 https://www.openssl.org/robots.txt
libcurl.so.4->SSL_CTX_set_keylog_callback(0x55afd55bc0c0, 0x7f497df43fa0, 0,
 0) = 1
User-agent: *
Disallow: /source/old
Disallow: err404.html
+++ exited (status 0) +++

This prints data to /tmp/tls.log as expected. Without the envar,
 SSL_CTX_set_keylog_callback isn't called as expected:

$ ltrace -e SSL_CTX_set_keylog_callback curl
 https://www.openssl.org/robots.txt
User-agent: *
Disallow: /source/old
Disallow: err404.html
+++ exited (status 0) +++

Next, I downloaded openssl and compiled it locally and wrote the following
 program that hooks into SSL_CTX_new to 
directly set keylog_callback before calling the real SSL_CTX_new. The
 callback function simply writes the data to stderr:

#define _GNU_SOURCE
#include <stdlib.h>
#include <stdio.h>
#include <dlfcn.h>
#include <ssl/ssl_local.h>

static void keylog_callback(const SSL *ssl, const char *line) {
 ? fprintf(stderr, "%s\n", line);
}

SSL_CTX *SSL_CTX_new(const SSL_METHOD *meth) {
 ? SSL_CTX* (*real_SSL_CTX_new)(const SSL_METHOD *meth) = dlsym(RTLD_NEXT,
 "SSL_CTX_new");
 ? if (!real_SSL_CTX_new) {
 ??? fprintf(stderr, "Could not find real SSL_CTX_new\n");
 ??? exit(1);
 ? }
 ? #ifdef DEBUG
 ? fprintf(stderr, "Calling real SSL_CTX_new\n");
 ? #endif
 ? SSL_CTX *ctx = real_SSL_CTX_new(meth);
 ? if (ctx != NULL) {
 ??? ctx->keylog_callback = keylog_callback;
 ??? fprintf(stderr, "[%s:%d:%s] Set custom keylog_callback to %p\n",
 __FILE__, __LINE__, __func__, ctx->keylog_callback);
 ? }
 ? #ifdef DEBUG
 ? fprintf(stderr, "Return ctx %p\n", ctx);
 ? #endif
 ? return ctx;
}

Compile the shared library:

gcc -g -Wall -o openssl_keylogfile.so -shared -fPIC keylogfile.c -lcrypto
 -lssl -I/usr/local/src/openssl 
-I/usr/local/src/openssl/include -DDEBUG

Finally, run curl again with this shared library (and obviously without
 SSLKEYLOGFILE so that curl doesn't call 
SSL_CTX_set_keylog_callback and override the above function pointer). It
 prints that it has set keylog_callback but 
keylog_callback is never called:

$ LD_PRELOAD=/work/openssl/openssl_sslkeylogfile/openssl_keylogfile.so curl
 https://www.openssl.org/robots.txt
Calling real SSL_CTX_new
[keylogfile.c:23:SSL_CTX_new] Set custom keylog_callback to 0x7fd1aa7bf139
Return ctx 0x55809c1310c0
User-agent: *
Disallow: /source/old
Disallow: err404.html

Any ideas?

Thanks,

-- 
Kevin Grigorenko


From gaardiolor at gmail.com  Sat Jun 12 20:20:22 2021
From: gaardiolor at gmail.com (Gaardiolor)
Date: Sat, 12 Jun 2021 22:20:22 +0200
Subject: openssl verify question
Message-ID: <ca0823cb-dbe8-fca7-b724-53b392a1827f@gmail.com>

Hello,

My openssl-1.0.2k-21.0.1.el7_9.x86_64 verify fails with HSM-signed 
certificates. The HSM is causing other issues and is likely misbehaving, 
I think this is a HSM bug. I'm sure I'm using the correct server.crt and 
rootca.crt.

$ openssl verify -CAfile rootca.crt server.crt
server.crt: C <snip>
error 7 at 0 depth lookup:certificate signature failure
139734096439184:error:0D0680A8:asn1 encoding 
routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1239:
139734096439184:error:0D07803A:asn1 encoding 
routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:405:Type=X509_SIG
139734096439184:error:0D0C5006:asn1 encoding 
routines:ASN1_item_verify:EVP lib:a_verify.c:249:


I tried doing the verification manually like so:

Extracting the 'to be signed' part of the server.crt:
openssl asn1parse -in server.crt -strparse 4 -out server.tbs

sha256 that:
cat server.tbs | openssl sha256 -binary > server.tbs.sha256

Extracting the signature from the server.crt:
openssl asn1parse -in server.crt -strparse 569 -out server.sig

Extracting the public key from rootca.crt:
openssl x509 -in rootca.crt -noout -pubkey > rootca.pub

Decrypting the signature:
openssl rsautl -inkey rootca.pub -pubin -in server.sig -out 
server.sig.decrypted

Comparing server.tbs.sha256 and server.sig.decrypted .

When I compare those, they are exactly the same. But that's the thing, I 
think server.sig.decrypted should be prepended with a sha256 designator 
30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20, which is 
missing. I do see this designator with working certificates. I suspect 
this is the problem.

Is that designator mandatory and likely the cause of my issue ? 
https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.1.2 suggests 
it's mandatory.. but I'm not sure if I'm looking at the right section.

Thanks.

From Sanjeev.Kumar-Mishra at rbbn.com  Mon Jun 14 07:33:48 2021
From: Sanjeev.Kumar-Mishra at rbbn.com (Kumar Mishra, Sanjeev)
Date: Mon, 14 Jun 2021 07:33:48 +0000
Subject: Not getting some macros for setting some BIO commands
Message-ID: <SN2PR03MB2319144DA2D28D7297BB7A39A6319@SN2PR03MB2319.namprd03.prod.outlook.com>

Hi,

I am upgrading the code of OpenSSL 1.0 to 3.0. I am not getting some macros for setting some BIO commands for example -

BIO_CTRL_GET_PKT_COUNT
BIO_CTRL_GET_PKT_LEN
BIO_CTRL_SET_PKT_COUNT etc.

What is alternative of above macros ? How I work around this ?

Thanks With Best Regards,
Sanjeev Kumar Mishra

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210614/1e5e70e1/attachment-0001.html>

From tomas at openssl.org  Mon Jun 14 07:41:50 2021
From: tomas at openssl.org (Tomas Mraz)
Date: Mon, 14 Jun 2021 09:41:50 +0200
Subject: Not getting some macros for setting some BIO commands
In-Reply-To: <SN2PR03MB2319144DA2D28D7297BB7A39A6319@SN2PR03MB2319.namprd03.prod.outlook.com>
References: <SN2PR03MB2319144DA2D28D7297BB7A39A6319@SN2PR03MB2319.namprd03.prod.outlook.com>
Message-ID: <fd45ab8264384040962369f82bfb9c230625988d.camel@openssl.org>

Hi,
you must be using some custom patched OpenSSL build. There is
no BIO_CTRL_GET_PKT_COUNT in OpenSSL 1.0.x releases as released by the
OpenSSL project.

Tomas Mraz

On Mon, 2021-06-14 at 07:33 +0000, Kumar Mishra, Sanjeev wrote:
> Hi,
> 
> I am upgrading the code of OpenSSL 1.0 to 3.0. I am not getting some
> macros for setting some BIO commands for example -
> 
> BIO_CTRL_GET_PKT_COUNT
> BIO_CTRL_GET_PKT_LEN
> BIO_CTRL_SET_PKT_COUNT etc.
> 
> What is alternative of above macros ? How I work around this ?
> 
> Thanks With Best Regards,
> Sanjeev Kumar Mishra
> 
> Notice: This e-mail together with any attachments may contain
> information of Ribbon Communications Inc. and its Affiliates that is
> confidential and/or proprietary for the sole use of the intended
> recipient. Any review, disclosure, reliance or distribution by others
> or forwarding without express permission is strictly prohibited. If
> you are not the intended recipient, please notify the sender
> immediately and then delete all copies, including any attachments.
-- 
Tom?? Mr?z
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]



From estellnb at elstel.org  Mon Jun 14 09:20:45 2021
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Mon, 14 Jun 2021 11:20:45 +0200
Subject: using the DSA signature algorithm of OpenSSL
Message-ID: <86dc6964-6087-9ced-4699-abeac6352c5f@elstel.org>

   I wanna use the DSA signature algorithms of OpenSSL to verify RRSIG 
and DNSKEY DNSSEC resource records. This is described in RFC2536 (a very 
short RFC).
   As far as I could try it out (see my attachement) there are two ways 
to sign and verify with OpenSSL/DSA: via the EVP interface and via the 
DSA interface directly. If I try to sign with one method and verify with 
the other that fails. What standards do these methods conform to, what 
is the difference between them and what do I need for my purpose? Also I 
have found two different ways to create a DSA key yielding apparently 
different results (see the sample code). Basically for me it is about 
verifying signatures, not about creating such signatures.

<<program output:>>
(pub)key: 
3081F13081A906072A8648CE38040130819D024100EECFDC5C3B730FE9D0A3D25C4B8EF27A7F93D7A8A0047065DB55D881A40CC11A620D65C5BD3A720D187300B25A59E051CCB203BBE13731FC7E65B6371D1CFDD9021500B6334A5665A680A9D017C760CFDEF2FD1FECF6A90241008D7623CF35A041F469B32EDA37ECF551485154047E11FE10DA003FEAB1DF88007860C1F0AE32990B29B52EE6DB6BAFDF1A7FF9FD76CFD5B417861ABE3782F4C3034300024019A7A450C6FE998742DF5D3E0F59C2E9D7D90D6861DA6E912AEB66BCA202FFBE981A381414213BB5504B582AC27A1ACFB8B203366A076BCCF179FC471C2E4CB7
asn1 repr of pubkey is the same
signed message: (method #1, DSA interface)
302C02146F4A174CF347EF3FD2796D1858CADBD4A033DA1F02147DA2FB1329E82509C699806D92BB0713272C1651
signed message: 46 Bytes
signature valid
signed message: (method #2, EVP interface)
302C02142F5296C21FA0956049F124A58621084ADF680BB402140BDD997234B82C901999FA096EFB697D864086BD
signed message: 46 Bytes
authentic  			(verified with the same method)
invalid signature		(verified with the other first method)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dsatest_nolib.c
Type: text/x-csrc
Size: 5191 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210614/a58a258e/attachment.c>

From estellnb at elstel.org  Mon Jun 14 09:34:36 2021
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Mon, 14 Jun 2021 11:34:36 +0200
Subject: using the DSA signature algorithm of OpenSSL
In-Reply-To: <86dc6964-6087-9ced-4699-abeac6352c5f@elstel.org>
References: <86dc6964-6087-9ced-4699-abeac6352c5f@elstel.org>
Message-ID: <7bfe156c-3318-3945-305a-edb7e0aa9b9b@elstel.org>

Oops, forgot to sha1; now it works.

Am 14.06.21 um 11:20 schrieb Elmar Stellnberger via openssl-users:
>  ? I wanna use the DSA signature algorithms of OpenSSL to verify RRSIG 
> and DNSKEY DNSSEC resource records. This is described in RFC2536 (a very 
> short RFC).
>  ? As far as I could try it out (see my attachement) there are two ways 
> to sign and verify with OpenSSL/DSA: via the EVP interface and via the 
> DSA interface directly. If I try to sign with one method and verify with 
> the other that fails. What standards do these methods conform to, what 
> is the difference between them and what do I need for my purpose? Also I 
> have found two different ways to create a DSA key yielding apparently 
> different results (see the sample code). Basically for me it is about 
> verifying signatures, not about creating such signatures.
> 
> <<program output:>>
> (pub)key: 
> 3081F13081A906072A8648CE38040130819D024100EECFDC5C3B730FE9D0A3D25C4B8EF27A7F93D7A8A0047065DB55D881A40CC11A620D65C5BD3A720D187300B25A59E051CCB203BBE13731FC7E65B6371D1CFDD9021500B6334A5665A680A9D017C760CFDEF2FD1FECF6A90241008D7623CF35A041F469B32EDA37ECF551485154047E11FE10DA003FEAB1DF88007860C1F0AE32990B29B52EE6DB6BAFDF1A7FF9FD76CFD5B417861ABE3782F4C3034300024019A7A450C6FE998742DF5D3E0F59C2E9D7D90D6861DA6E912AEB66BCA202FFBE981A381414213BB5504B582AC27A1ACFB8B203366A076BCCF179FC471C2E4CB7 
> 
> asn1 repr of pubkey is the same
> signed message: (method #1, DSA interface)
> 302C02146F4A174CF347EF3FD2796D1858CADBD4A033DA1F02147DA2FB1329E82509C699806D92BB0713272C1651 
> 
> signed message: 46 Bytes
> signature valid
> signed message: (method #2, EVP interface)
> 302C02142F5296C21FA0956049F124A58621084ADF680BB402140BDD997234B82C901999FA096EFB697D864086BD 
> 
> signed message: 46 Bytes
> authentic????????????? (verified with the same method)
> invalid signature??????? (verified with the other first method)

From janjust at nikhef.nl  Thu Jun 17 07:18:42 2021
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Thu, 17 Jun 2021 09:18:42 +0200
Subject: openssl verify question
In-Reply-To: <ca0823cb-dbe8-fca7-b724-53b392a1827f@gmail.com>
References: <ca0823cb-dbe8-fca7-b724-53b392a1827f@gmail.com>
Message-ID: <60d92a02-714f-cc12-a430-533015175041@nikhef.nl>

Hi,

On 12/06/21 22:20, Gaardiolor wrote:
> Hello,
>
> My openssl-1.0.2k-21.0.1.el7_9.x86_64 verify fails with HSM-signed 
> certificates. The HSM is causing other issues and is likely 
> misbehaving, I think this is a HSM bug. I'm sure I'm using the correct 
> server.crt and rootca.crt.
>
> $ openssl verify -CAfile rootca.crt server.crt
> server.crt: C <snip>
> error 7 at 0 depth lookup:certificate signature failure
> 139734096439184:error:0D0680A8:asn1 encoding 
> routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1239:
> 139734096439184:error:0D07803A:asn1 encoding 
> routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:405:Type=X509_SIG
> 139734096439184:error:0D0C5006:asn1 encoding 
> routines:ASN1_item_verify:EVP lib:a_verify.c:249:
>
just wondering: why and how are you using an HSM to verify a certificate 
(without including a private key) ?? is the certificate stored only on 
the HSM?? is it possible to get it off the HSM?

Also, how are you connecting the HSM to OpenSSL? via opensc-pkcs11 ?? 
you should have an openssl.cnf file somewhere for this.

HTH,

JJK



> I tried doing the verification manually like so:
>
> Extracting the 'to be signed' part of the server.crt:
> openssl asn1parse -in server.crt -strparse 4 -out server.tbs
>
> sha256 that:
> cat server.tbs | openssl sha256 -binary > server.tbs.sha256
>
> Extracting the signature from the server.crt:
> openssl asn1parse -in server.crt -strparse 569 -out server.sig
>
> Extracting the public key from rootca.crt:
> openssl x509 -in rootca.crt -noout -pubkey > rootca.pub
>
> Decrypting the signature:
> openssl rsautl -inkey rootca.pub -pubin -in server.sig -out 
> server.sig.decrypted
>
> Comparing server.tbs.sha256 and server.sig.decrypted .
>
> When I compare those, they are exactly the same. But that's the thing, 
> I think server.sig.decrypted should be prepended with a sha256 
> designator 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20, 
> which is missing. I do see this designator with working certificates. 
> I suspect this is the problem.
>
> Is that designator mandatory and likely the cause of my issue ? 
> https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.1.2 suggests 
> it's mandatory.. but I'm not sure if I'm looking at the right section.
>
> Thanks.


From matt at openssl.org  Thu Jun 17 13:36:33 2021
From: matt at openssl.org (Matt Caswell)
Date: Thu, 17 Jun 2021 13:36:33 +0000
Subject: OpenSSL version 3.0.0-beta1 published
Message-ID: <20210617133633.GA24818@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


   OpenSSL version 3.0 beta 1 released
   ===================================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   OpenSSL 3.0 is currently in beta.

   OpenSSL 3.0 beta 1 has now been made available.

   Note: This OpenSSL pre-release has been provided for testing ONLY.
   It should NOT be used for security critical purposes.

   Specific notes on upgrading to OpenSSL 3.0 from previous versions are
   available in the OpenSSL Migration Guide, here:

        https://www.openssl.org/docs/manmaster/man7/migration_guide.html

   The beta release is available for download via HTTPS and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

     * https://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-3.0.0-beta1.tar.gz
      Size: 14878832
      SHA1 checksum:  4b48947969bb3c989ba95ac4bdc4a78e70212d2b
      SHA256 checksum:  7bfedc9a1062cbd2aabc294acc93cbd5259e6e7bd5bbe38e454cc6a32564029f

   The checksums were calculated using the following commands:

    openssl sha1 openssl-3.0.0-beta1.tar.gz
    openssl sha256 openssl-3.0.0-beta1.tar.gz

   Please download and check this beta release as soon as possible.
   To report a bug, open an issue on GitHub:

    https://github.com/openssl/openssl/issues

   Please check the release notes and mailing lists to avoid duplicate
   reports of known issues. (Of course, the source is also available
   on GitHub.)

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmDLSDUACgkQ2cTSbQ5g
RJHPJQf9GACe9xem5BnK1EPAJtWkXxKZS3NOThT5rp6mCArFCVX3Vvrmui/PUgL2
+EPA9o96G6SJ/AypFyH/SUYfK2weC7LmPGgZ4kk0Od/rn/JE+Pkbk1IyqTb3QnUz
LlMIB69m8vx/IJqP/FSCY224iP+gtCzyQvktxra1dLab7SJtDiTtcvvSKv20jd1+
9V9GSPIrl1G7dU+aWG/jZRZ1g8lmVEoZ/d3wKpddU3A31mSWxyt8Yc5/gRC74NmU
EGCHY+6hrrRIoJkIiywlk9HoFQNHf3OT0pK1F8Igfredos6dulUKxcK2jk0gJjQY
IG7aAF+ZcysQZ5y0iUksHhb296mRNA==
=Jk01
-----END PGP SIGNATURE-----

From matt at openssl.org  Thu Jun 17 13:42:30 2021
From: matt at openssl.org (Matt Caswell)
Date: Thu, 17 Jun 2021 14:42:30 +0100
Subject: Blog post
Message-ID: <02973d70-3b7d-0ed0-0fc4-c5ad4107d3d7@openssl.org>

For anyone interested I've written a blog post to accompany the 3.0 beta 
1 release. You can read it here:

https://www.openssl.org/blog/blog/2021/06/17/OpenSSL3.0ReleaseCandidate/

Matt

From openssl-users at dukhovni.org  Thu Jun 17 13:49:36 2021
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 17 Jun 2021 09:49:36 -0400
Subject: openssl verify question
In-Reply-To: <ca0823cb-dbe8-fca7-b724-53b392a1827f@gmail.com>
References: <ca0823cb-dbe8-fca7-b724-53b392a1827f@gmail.com>
Message-ID: <YMtS8KD2xoni76BK@straasha.imrryr.org>

On Sat, Jun 12, 2021 at 10:20:22PM +0200, Gaardiolor wrote:

> When I compare those, they are exactly the same. But that's the thing, I 
> think server.sig.decrypted should be prepended with a sha256 designator 
> 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20, which is 
> missing. I do see this designator with working certificates. I suspect 
> this is the problem.
>
> Is that designator mandatory and likely the cause of my issue ? 

Yes, PKCS#1 signatures must have an algorithm OID prefix.

-- 
    Viktor.

From jb-openssl at wisemo.com  Thu Jun 17 14:15:39 2021
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 17 Jun 2021 16:15:39 +0200
Subject: openssl verify question
In-Reply-To: <YMtS8KD2xoni76BK@straasha.imrryr.org>
References: <ca0823cb-dbe8-fca7-b724-53b392a1827f@gmail.com>
 <YMtS8KD2xoni76BK@straasha.imrryr.org>
Message-ID: <2e63fb2d-a537-1c8a-05b2-161e1a54ca64@wisemo.com>

On 2021-06-17 15:49, Viktor Dukhovni wrote:
> On Sat, Jun 12, 2021 at 10:20:22PM +0200, Gaardiolor wrote:
>
>> When I compare those, they are exactly the same. But that's the thing, I
>> think server.sig.decrypted should be prepended with a sha256 designator
>> 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20, which is
>> missing. I do see this designator with working certificates. I suspect
>> this is the problem.
>>
>> Is that designator mandatory and likely the cause of my issue ?
> Yes, PKCS#1 signatures must have an algorithm OID prefix.
>
Please beware that a few years ago, I found that a particular Symantec
server signedlong term messages (timestamping countersignatures)
without that prefix, using animplied algorithm of SHA-1.

It may thus be necessary for CMS implementations to accept such
signatures for that special case until they naturally expire,
and maybe a few years past that.

Defining a sufficiently narrow exception is left as an exercise
for implementors.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From steffen at sdaoden.eu  Thu Jun 17 14:43:32 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 17 Jun 2021 16:43:32 +0200
Subject: OpenSSL version 3.0.0-beta1 published
In-Reply-To: <20210617133633.GA24818@openssl.org>
References: <20210617133633.GA24818@openssl.org>
Message-ID: <20210617144332.dk9KY%steffen@sdaoden.eu>

Hello.

Matt Caswell wrote in
 <20210617133633.GA24818 at openssl.org>:
 ...
 |   OpenSSL version 3.0 beta 1 released
 ...

Congratulations after a lot of work!

Fyi, i have $PERL5OPT=-C permanently in my environment, in
conjunction with LC_ALL=en_US.utf8 this results in the build error
as below.  Prefixing LC_ALL=C fixes this.

  #?0|kent:src$ MYPREFIX=$HOME/$USR/opt/.ossl3 make -j4 openssl
  cd tls-openssl.git &&\
  if [ -f NULL ]; then git checkout `cat NULL`; fi &&\
  ./config --prefix=/home/steffen/usr-kent-linux-x86_64/opt/.ossl3 zlib-dynamic shared \
          no-deprecated no-async threads no-tests \
          -Wl,-rpath,'' &&\
  make &&\
   make install_sw &&  make install_ssldirs; \
  { git clean -fxd; git reset --hard HEAD;\
  git checkout arena-manager-null; } >/dev/null
  Switched to branch 'master'
  Your branch is up to date with 'origin/master'.
  Configuring OpenSSL version 3.0.0-beta2-dev for target linux-x86_64
  Using os-specific seed configuration
  Creating configdata.pm
  Running configdata.pm
  Creating Makefile.in
  syswrite() isn't allowed on :utf8 handles at /usr/lib/perl5/5.32/File/Copy.pm line 181.
  Switched to branch 'arena-manager-null'

Ciao,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From matt at openssl.org  Thu Jun 17 14:47:57 2021
From: matt at openssl.org (Matt Caswell)
Date: Thu, 17 Jun 2021 15:47:57 +0100
Subject: OpenSSL version 3.0.0-beta1 published
In-Reply-To: <20210617144332.dk9KY%steffen@sdaoden.eu>
References: <20210617133633.GA24818@openssl.org>
 <20210617144332.dk9KY%steffen@sdaoden.eu>
Message-ID: <33db69e0-0f9b-c559-43f7-e5a2f85a48dd@openssl.org>



On 17/06/2021 15:43, Steffen Nurpmeso wrote:
> Fyi, i have $PERL5OPT=-C permanently in my environment, in
> conjunction with LC_ALL=en_US.utf8 this results in the build error
> as below.  Prefixing LC_ALL=C fixes this.

Thanks. I submitted this as an issue on github here:

https://github.com/openssl/openssl/issues/15805

Matt

> 
>    #?0|kent:src$ MYPREFIX=$HOME/$USR/opt/.ossl3 make -j4 openssl
>    cd tls-openssl.git &&\
>    if [ -f NULL ]; then git checkout `cat NULL`; fi &&\
>    ./config --prefix=/home/steffen/usr-kent-linux-x86_64/opt/.ossl3 zlib-dynamic shared \
>            no-deprecated no-async threads no-tests \
>            -Wl,-rpath,'' &&\
>    make &&\
>     make install_sw &&  make install_ssldirs; \
>    { git clean -fxd; git reset --hard HEAD;\
>    git checkout arena-manager-null; } >/dev/null
>    Switched to branch 'master'
>    Your branch is up to date with 'origin/master'.
>    Configuring OpenSSL version 3.0.0-beta2-dev for target linux-x86_64
>    Using os-specific seed configuration
>    Creating configdata.pm
>    Running configdata.pm
>    Creating Makefile.in
>    syswrite() isn't allowed on :utf8 handles at /usr/lib/perl5/5.32/File/Copy.pm line 181.
>    Switched to branch 'arena-manager-null'

From steffen at sdaoden.eu  Thu Jun 17 15:12:09 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 17 Jun 2021 17:12:09 +0200
Subject: OpenSSL version 3.0.0-beta1 published
In-Reply-To: <33db69e0-0f9b-c559-43f7-e5a2f85a48dd@openssl.org>
References: <20210617133633.GA24818@openssl.org>
 <20210617144332.dk9KY%steffen@sdaoden.eu>
 <33db69e0-0f9b-c559-43f7-e5a2f85a48dd@openssl.org>
Message-ID: <20210617151209.s_zNU%steffen@sdaoden.eu>

Matt Caswell wrote in
 <33db69e0-0f9b-c559-43f7-e5a2f85a48dd at openssl.org>:
 |On 17/06/2021 15:43, Steffen Nurpmeso wrote:
 |> Fyi, i have $PERL5OPT=-C permanently in my environment, in
 |> conjunction with LC_ALL=en_US.utf8 this results in the build error
 |> as below.  Prefixing LC_ALL=C fixes this.
 |
 |Thanks. I submitted this as an issue on github here:
 |
 |https://github.com/openssl/openssl/issues/15805

Thank you very much.  Yes, sorry, i have no account.

P.S.: my perl knowledge has become rusty, and even many years ago
i needed help on IRC to learn that binmode STDOUT even applies to
command line arguments of started programs!  (Thanks in public
again to the forgotten name on perl IRC on 2013-05-06, i could not
have solved that, yet need to start child programs with UTF-8ified
command line arguments.)

P.P.S.: Tom?? Mr?z: aren't you part of PAM project too?  Off-topic
here, but i had written a somewhat primitive yet i think nicely working

  pam_xdg.so is a PAM module that manages creation of the
  XDG_RUNTIME_DIR directory, as well as injection of environment
  variables denoting all directories specified by the XDG Base
  Directory Specification:
         https://specifications.freedesktop.org/basedir-spec/basedir-spec-
         latest.html
  into user sessions.

yet the mailing-list is hosted by RedHat, and somehow i could not
subscribe to _that_ screen, maybe script related, i do not know.
Just in case of interest [1-3].  ISC license, but you could have
it Public Domain if you want.

  [1] https://git.sdaoden.eu/browse?p=s-toolbox.git;a=blob;f=pam_xdg.c;hb=master
  [2] https://git.sdaoden.eu/browse?p=s-toolbox.git;a=blob;f=pam_xdg.8;hb=master

  [3] https://git.sdaoden.eu/browse?p=s-toolbox.git;a=blob;f=pam_xdg.makefile;hb=master

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From tomas at openssl.org  Thu Jun 17 15:19:31 2021
From: tomas at openssl.org (Tomas Mraz)
Date: Thu, 17 Jun 2021 17:19:31 +0200
Subject: [OffTopic] PAM
In-Reply-To: <20210617151209.s_zNU%steffen@sdaoden.eu>
References: <20210617133633.GA24818@openssl.org>
 <20210617144332.dk9KY%steffen@sdaoden.eu>
 <33db69e0-0f9b-c559-43f7-e5a2f85a48dd@openssl.org>
 <20210617151209.s_zNU%steffen@sdaoden.eu>
Message-ID: <11264f92f87def629df40cf0b7f7b0cc8f43fbe4.camel@openssl.org>

On Thu, 2021-06-17 at 17:12 +0200, Steffen Nurpmeso wrote:
> 
> P.P.S.: Tom?? Mr?z: aren't you part of PAM project too?  Off-topic
> here, but i had written a somewhat primitive yet i think nicely
> working

Yes. I am.

>   pam_xdg.so is a PAM module that manages creation of the
>   XDG_RUNTIME_DIR directory, as well as injection of environment
>   variables denoting all directories specified by the XDG Base
>   Directory Specification:
>          
> https://specifications.freedesktop.org/basedir-spec/basedir-spec-
>          latest.html
>   into user sessions.
> 
> yet the mailing-list is hosted by RedHat, and somehow i could not
> subscribe to _that_ screen, maybe script related, i do not know.
> Just in case of interest [1-3].  ISC license, but you could have
> it Public Domain if you want.

The PAM developer discussion is on:
pam-developers at lists.fedorahosted.org

If you could submit the module as PR on the GitHub Linux PAM project
[0], it would be considered.

I know, that would require getting a GitHub account.

[0] https://github.com/linux-pam/linux-pam

Regards,

-- 
Tom?? Mr?z
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]



From a.cudbardb at freeradius.org  Thu Jun 17 15:56:31 2021
From: a.cudbardb at freeradius.org (Arran Cudbard-Bell)
Date: Thu, 17 Jun 2021 10:56:31 -0500
Subject: Cleaning up async jobs
Message-ID: <C8A07F0E-E164-4C92-8575-ADD7AD237C47@freeradius.org>

I'm taking a first pass at getting asynchronous certificate validation and
asynchronous stateful session-resumption working in our application.

In callbacks, when we need to perform an asynchronous action, we setup
our own internal state (bound to the SSL *) to detail what action is going
to be performed, then call ASYNC_pause_job().

SSL_read() returns -1, we call SSL_get_error and check for
SSL_ERROR_WANT_ASYNC.

We check our internal state structure to figure out the asynchronous action
we need to perform, perform it, then call SSL_read() again.

This is all fine, it works well.

In our application active requests can be cancelled if they run for too long.
If a request is cancelled after ASYNC_pause_job() has been called but
before SSL_read() has been called (i.e the job is paused) what would be
the correct way to handle this without leaking memory?

I can see SSL_free() calls ASYNC_WAIT_CTX_free, so we shouldn't
leak ASYNC_WAIT_CTXs, but heap allocated memory that's not
associated with the SSL * or any of its associated structures would
theoretically still  be leaked.

The obvious way of handling this is to mark up the request as cancelled,
call SSL_read() and check the request's cancellation state after each call
to  ASYNC_pause_job() inside the callback.

Is there something we can call either before SSL_read() or from within the
callback to encourage OpenSSL to terminate the handshake and not call
any more callbacks?  Is there a better way to handle the cancellations?

Many Thanks,
-Arran


Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210617/f99f33e3/attachment-0001.sig>

From ethan.rahn at gmail.com  Thu Jun 17 17:35:22 2021
From: ethan.rahn at gmail.com (Ethan Rahn)
Date: Thu, 17 Jun 2021 10:35:22 -0700
Subject: Blog post
In-Reply-To: <02973d70-3b7d-0ed0-0fc4-c5ad4107d3d7@openssl.org>
References: <02973d70-3b7d-0ed0-0fc4-c5ad4107d3d7@openssl.org>
Message-ID: <CAEW9rAg2EMB4vhb8EzCP3C0JLhJ-G7e0_cZ=29Fy_posJVcu3A@mail.gmail.com>

Hello Matt,

Love the blog post, and of course a hearty thanks to everyone who worked on
the project to get it to this point.

Is the plan still to continue with the FIPS 140-2 validation instead of
140-3? Apologies for the lack of a first party source but
https://www.leidos.com/insights/fips-140-and-common-criteria-industry-updates-march-2020
lists Sept 22, 2021 as the last day for FIPS 140-2 submissions. Is OpenSSL
3.0 going to be submitted by then?

Cheers,

Ethan

On Thu, Jun 17, 2021, 06:43 Matt Caswell <matt at openssl.org> wrote:

> For anyone interested I've written a blog post to accompany the 3.0 beta
> 1 release. You can read it here:
>
> https://www.openssl.org/blog/blog/2021/06/17/OpenSSL3.0ReleaseCandidate/
>
> Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210617/f7c752d8/attachment.html>

From matt at openssl.org  Thu Jun 17 18:42:57 2021
From: matt at openssl.org (Matt Caswell)
Date: Thu, 17 Jun 2021 19:42:57 +0100
Subject: Blog post
In-Reply-To: <CAEW9rAg2EMB4vhb8EzCP3C0JLhJ-G7e0_cZ=29Fy_posJVcu3A@mail.gmail.com>
References: <02973d70-3b7d-0ed0-0fc4-c5ad4107d3d7@openssl.org>
 <CAEW9rAg2EMB4vhb8EzCP3C0JLhJ-G7e0_cZ=29Fy_posJVcu3A@mail.gmail.com>
Message-ID: <6e13df42-808a-42f8-ae78-5b42f65edec0@openssl.org>

On 17/06/2021 18:35, Ethan Rahn wrote:
> Hello Matt,
> 
> Love the blog post, and of course a hearty thanks to everyone who worked 
> on the project to get it to this point.
> 
> Is the plan still to continue with the FIPS 140-2 validation instead of 
> 140-3? Apologies for the lack of a first party source but 
> https://www.leidos.com/insights/fips-140-and-common-criteria-industry-updates-march-2020 
> <https://www.leidos.com/insights/fips-140-and-common-criteria-industry-updates-march-2020> 
> lists Sept 22, 2021 as the last day for FIPS 140-2 submissions. Is 
> OpenSSL 3.0 going to be submitted by then?

Yes we plan to submit a 140-2 validation by the September deadline.

Matt


> 
> Cheers,
> 
> Ethan
> 
> On Thu, Jun 17, 2021, 06:43 Matt Caswell <matt at openssl.org 
> <mailto:matt at openssl.org>> wrote:
> 
>     For anyone interested I've written a blog post to accompany the 3.0
>     beta
>     1 release. You can read it here:
> 
>     https://www.openssl.org/blog/blog/2021/06/17/OpenSSL3.0ReleaseCandidate/
>     <https://www.openssl.org/blog/blog/2021/06/17/OpenSSL3.0ReleaseCandidate/>
> 
>     Matt
> 

From steffen at sdaoden.eu  Thu Jun 17 23:52:09 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Fri, 18 Jun 2021 01:52:09 +0200
Subject: [OffTopic] PAM
In-Reply-To: <11264f92f87def629df40cf0b7f7b0cc8f43fbe4.camel@openssl.org>
References: <20210617133633.GA24818@openssl.org>
 <20210617144332.dk9KY%steffen@sdaoden.eu>
 <33db69e0-0f9b-c559-43f7-e5a2f85a48dd@openssl.org>
 <20210617151209.s_zNU%steffen@sdaoden.eu>
 <11264f92f87def629df40cf0b7f7b0cc8f43fbe4.camel@openssl.org>
Message-ID: <20210617235209.zKwIA%steffen@sdaoden.eu>

Yes, off-topic, sorry.

Tomas Mraz wrote in
 <11264f92f87def629df40cf0b7f7b0cc8f43fbe4.camel at openssl.org>:
 |On Thu, 2021-06-17 at 17:12 +0200, Steffen Nurpmeso wrote:
 |> 
 |> P.P.S.: Tom?? Mr?z: aren't you part of PAM project too?  Off-topic
 |> here, but i had written a somewhat primitive yet i think nicely
 |> working
 |
 |Yes. I am.
 |
 |>   pam_xdg.so is a PAM module that manages creation of the
 |>   XDG_RUNTIME_DIR directory, as well as injection of environment
 |>   variables denoting all directories specified by the XDG Base
 |>   Directory Specification:
 |>          
 |> https://specifications.freedesktop.org/basedir-spec/basedir-spec-
 |>          latest.html
 |>   into user sessions.
 |> 
 |> yet the mailing-list is hosted by RedHat, and somehow i could not
 |> subscribe to _that_ screen, maybe script related, i do not know.
 |> Just in case of interest [1-3].  ISC license, but you could have
 |> it Public Domain if you want.
 |
 |The PAM developer discussion is on:
 |pam-developers at lists.fedorahosted.org

Ah, i was trying pam-list at redhat.com without success.  I even
tried to contact the administrators, but nothing as silence.  ..So
i was waiting until some day i see one of the names mentioned.

 |If you could submit the module as PR on the GitHub Linux PAM project
 |[0], it would be considered.
 |
 |I know, that would require getting a GitHub account.
 |
 |[0] https://github.com/linux-pam/linux-pam

Yes, ach, no.  It is just a trivial thing, and not even needed on
the omnipresent systemd Linux; i was just writing it because
someone here on (systemd-free) CRUX Linux was carrying along some
PAM-module daemon written in a language noone has the interpreter
for by default, that did nothing but managing a session counter
... rundird it was, written in zig.  (It fooled me to believe that
PAM could gracefully handle sessions, i did not think about it
myself; until a "daemonized" / reparented to init shell script was
living in a directory that should have been gone, and then
i rewrote the module to the minimum implementation that it is.)

 |No matter how far down the wrong road you've gone, turn back.
 |                                          Turkish proverb
 |[You'll know whether the road is wrong if you carefully listen to your
 |conscience.]

Ah! and oh! on my evil subconsciousness.

Good night.

(And sorry again for bringing this off-topic thing here.)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From samsapi01 at protonmail.ch  Fri Jun 18 04:38:44 2021
From: samsapi01 at protonmail.ch (sami0l)
Date: Fri, 18 Jun 2021 04:38:44 +0000
Subject: reg: question about SSL server cert verification
Message-ID: <IU8xBCaKUiiyv5XKtR2uWucLMWdHLVrcD8iWjA1klQt39HG20I6pA1cGiCChQfeDXLfOPOWhePz09VJ5G6g4-f9zxQD92y1QJWNM6IK8khE=@protonmail.ch>

I'm curious how exactly an SSL client verifies an SSL server's certificate which is signed by a CA. So, during the SSL handshake, when the server sends its certificate, will the SSL client first checks the `Issuer`'s `CN` field from the x509 SSL certificate that it received for example, and compares against all the `CN`s of all the certificates stored `/etc/ssl/certs` of that client and if it matches any one of them, next it checks the signature of the received certificate by parsing the public key from that CA cert located in `/etc/ssl/certs/someCA.crt` and performers the decryption and checks the signature of the received certificate and if the signature matches, the browser accepts the certificate since it just verified that it's signed by the CA which is located in `/etc/ssl/certs` and uses that cert? Is this how the SSL client verifies the certificate when it receives a server's certificate during the handshake process? If not, It'd be really helpful if someone could explain me how it's exactly done.

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210618/5be9c5ce/attachment.html>

From jb-openssl at wisemo.com  Fri Jun 18 13:09:47 2021
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 18 Jun 2021 15:09:47 +0200
Subject: reg: question about SSL server cert verification
In-Reply-To: <IU8xBCaKUiiyv5XKtR2uWucLMWdHLVrcD8iWjA1klQt39HG20I6pA1cGiCChQfeDXLfOPOWhePz09VJ5G6g4-f9zxQD92y1QJWNM6IK8khE=@protonmail.ch>
References: <IU8xBCaKUiiyv5XKtR2uWucLMWdHLVrcD8iWjA1klQt39HG20I6pA1cGiCChQfeDXLfOPOWhePz09VJ5G6g4-f9zxQD92y1QJWNM6IK8khE=@protonmail.ch>
Message-ID: <fbd71870-9095-ff21-d987-8789ee3a19be@wisemo.com>

On 2021-06-18 06:38, sami0l via openssl-users wrote:
> I'm curious how exactly an SSL client verifies an SSL server's 
> certificate which is signed by a CA. So, during the SSL handshake, 
> when the server sends its certificate, will the SSL client first 
> checks the `Issuer`'s `CN` field from the x509 SSL certificate that it 
> received for example, and compares against all the `CN`s of all the 
> certificates stored `/etc/ssl/certs` of that client and if it matches 
> any one of them, next it checks the signature of the received 
> certificate by parsing the public key from that CA cert located in 
> `/etc/ssl/certs/someCA.crt` and performers the decryption and checks 
> the signature of the received certificate and if the signature 
> matches, the browser accepts the certificate since it just verified 
> that it's signed by the CA which is located in `/etc/ssl/certs` and 
> uses that cert? Is this how the SSL client verifies the certificate 
> when it receives a server's certificate during the handshake process? 
> If not, It'd be really helpful if someone could explain me how it's 
> exactly done.
>
>
No, here is what really happens:

First the owner of the server (or a program they use) find
the chain of intermediary certificates which leads from
their actual certificate to a commonly trusted root
certificate, Lets say the chain is:
RootA->CrossB->IntermediaryC->IntermediaryD->EndCertServer.
This list of certificates is put in a server config file
and the complete list is sent in each SSL handshake and
every CMS signed message.

Now the client simply works backwards through that list,
checking if each certificate signed the next one or claims
to be signed by a certificate in /etc/certs.? This lookup
is done based on the complete distinguished name, not just
the CN part of it.? At every step, the certificate may be
referenced by a "key identifier" instead of the
distinguished name, and some clients will compare that
instead of the distinguished name.

The big complications are:

1. The server owner may have configured the "wrong" list and
clients may or may not work around that.

2. Not all clients trust the same exact list of root CAs,
hence the invention of "cross-signed roots", which are
intermediary certificates with the same name and public
key as a not-known-everywhere root, but signed by an
already-known-everywhere root.

3. Not all clients react the same way when the server
includes a cross certificate in the list.? Some recognize
the cross as the same as a root they trust and declare
success without having to trust the (possibly old)
compatibility root, others check only the compatibility
root and get confused when that old root dies.

4. Some quality checkers (looking at you QualSys) object
strongly to the server including the root itself in its
list, because the root is supposed to be on all the clients
that trust it.? But experienced human client users can
actually use an included root to make informed decisions
about trust errors.

OpenSSL documentation tends to bury its handling of all
this way too deep inside the programmer documentation
rather than explaining things clearly in the end user
documentation.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From Michael.Wojcik at microfocus.com  Fri Jun 18 14:23:01 2021
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 18 Jun 2021 14:23:01 +0000
Subject: reg: question about SSL server cert verification
In-Reply-To: <fbd71870-9095-ff21-d987-8789ee3a19be@wisemo.com>
References: <IU8xBCaKUiiyv5XKtR2uWucLMWdHLVrcD8iWjA1klQt39HG20I6pA1cGiCChQfeDXLfOPOWhePz09VJ5G6g4-f9zxQD92y1QJWNM6IK8khE=@protonmail.ch>
 <fbd71870-9095-ff21-d987-8789ee3a19be@wisemo.com>
Message-ID: <DM6PR18MB2700C6A3715A47C24DF148EFF90D9@DM6PR18MB2700.namprd18.prod.outlook.com>

> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Jakob
> Bohm via openssl-users
> Sent: Friday, 18 June, 2021 07:10
> To: openssl-users at openssl.org
> Subject: Re: reg: question about SSL server cert verification
>
> On 2021-06-18 06:38, sami0l via openssl-users wrote:
> > I'm curious how exactly an SSL client verifies an SSL server's
> > certificate which is signed by a CA.

> >
> No, here is what really happens:
>
> First the owner of the server (or a program they use) find
> the chain of intermediary certificates which leads from
> their actual certificate to a commonly trusted root
> certificate, Lets say the chain is:
> RootA->CrossB->IntermediaryC->IntermediaryD->EndCertServer.
> This list of certificates is put in a server config file
> and the complete list is sent in each SSL handshake and
> every CMS signed message.

We hope. But, of course, as Jakob says, there are many misconfigured servers.

> Now the client simply works backwards through that list,
> checking if each certificate signed the next one or claims
> to be signed by a certificate in /etc/certs.  This lookup
> is done based on the complete distinguished name, not just
> the CN part of it. At every step, the certificate may be
> referenced by a "key identifier" instead of the
> distinguished name, and some clients will compare that
> instead of the distinguished name.

And there are a whole bunch of other checks: signature, validity dates, key usage, basic constraints...

Also, the correspondence between the peer identity as requested by the client, and as represented by the entity certificate, should not be done using the CN component of the Subject DN (as OP suggested), but by comparing against the Subject Alternative Name extension values. The subject CN should only be used as a last resort; some applications may refuse to allow a CN match and insist on an X.509v3 certificate with a valid SAN.

(Jakob knows all this.)

Certificate chain validation is a very complicated topic. I put together an internal presentation with an overview of it some years back and it was a dozen or more slides, and I only touched on the major points. It's not something that can be covered thoroughly in an email discussion.


> The big complications are:

Numerous. Jakob's list is a good one, but I'm sure we can come up with others. Like, say, the enormous mess which is revocation.

My advice, for someone who wants to understand the certificate-validation process in TLS, is:

1. Start with one or more books that explain TLS at length. I don't know offhand of a single book which covers the protocol in its current form and all of the many, many aspects of using it in an interoperable fashion. My best suggestion would be to read Rescorla's /SSL and TLS/, which is old but provides a foundation, and Ristic's /Bulletproof TLS/, which describes using TLS in practice and has recently been updated.

2. Experiment using tools such as openssl s_client and s_server to ground that understanding.

3. Read RFC 5280, Public Key Infrastructure - X.509 ("PKIX") and the CA/Browser Forum's Basic Requirements.
        PKIX is the standard for using X.509 certificates for a PKI on the Internet; it certainly isn't always followed, but it will give you an idea of what sorts of rules a TLS application is supposed to obey when validating a peer's certificate chain.
        The CA/BF BR is a standard promulgated by and for commercial CAs and browser manufacturers. It doesn't apply to other TLS participants, but again it shows what sorts of rules those prominent ones are *expected* to follow. Other applications, and private CAs (for example, organizational CAs), might or might not follow similar rules. At any rate, it shows how some participants might be picky about things like the Extended Key Usage (EKU) extension for certificates in the chain, or why they might reject a valid certificate because they're imposing tighter requirements (e.g. the maximum difference between the validity dates).

4. Be aware that pretty much all implementations are buggy in one way or another. If you get into this, you can find all sorts of research documenting errors in certificate validation. That's particularly true when you get into more-complex validation graphs, as Jakob wrote regarding cross-signing. If you subscribe to Hanno Bock's /Bulletproof TLS/ newsletter, and/or read some of the back issues, you'll see how often someone identifies some sort of misbehavior in this area.

So I suppose the answer to your original question is "no, no one can explain certificate validation". It's unlikely there's a single person on the planet who has comprehensive knowledge of all the funky corners of X.509 PKI. (Someone - PGN, maybe - wrote a presentation years ago that covered, among other things, some of the many certificate policies published by various national governments. That's just one example of an X.509-related mess that almost no one pays attention to.)

In practice you can learn enough about it to diagnose most certificate-validation problems. But it takes time and effort.

--
Michael Wojcik

From openssl-users at dukhovni.org  Fri Jun 18 15:07:43 2021
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 18 Jun 2021 11:07:43 -0400
Subject: reg: question about SSL server cert verification
In-Reply-To: <fbd71870-9095-ff21-d987-8789ee3a19be@wisemo.com>
References: <IU8xBCaKUiiyv5XKtR2uWucLMWdHLVrcD8iWjA1klQt39HG20I6pA1cGiCChQfeDXLfOPOWhePz09VJ5G6g4-f9zxQD92y1QJWNM6IK8khE=@protonmail.ch>
 <fbd71870-9095-ff21-d987-8789ee3a19be@wisemo.com>
Message-ID: <YMy2v44+QDWzT2Mc@straasha.imrryr.org>

On Fri, Jun 18, 2021 at 03:09:47PM +0200, Jakob Bohm via openssl-users wrote:

> Now the client simply works backwards through that list, checking if
> each certificate signed the next one or claims to be signed by a
> certificate in /etc/certs.? This lookup is done based on the complete
> distinguished name, not just the CN part of it.? At every step, the
> certificate may be referenced by a "key identifier" instead of the
> distinguished name, and some clients will compare that instead of the
> distinguished name.

All extant (non-EOL) OpenSSL releases prioritise the local trust-store
over the remotely provided CA certificate list when building the
certificate chain.  The remote chain is used only when no match is found
in the trust store.  As as a matching issuer is found in the trust store
all further lookups are from the trust store only.

If the local trust store contains only "root CAs", and the remote peer
provides the rest of the chain, with no overlap in the subject
distinguished names, the behaviour is not observably different from
Jakob's description.

Differences are observed once the local trust store contains some
intermediate certificates or the remote chain provides a cross cert for
which the local store instead contains a corresponding (same subject
name and keyid) self-signed root, or the cross cert is in the local
store, but the remote peer sends a root.  In all such cases chain
construction uses the certs from the trust store.  This tends to produce
less surprising (and ideally better, or at least what you implicitly
asked for) results.

-- 
    Viktor.

From jb-openssl at wisemo.com  Fri Jun 18 15:37:33 2021
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 18 Jun 2021 17:37:33 +0200
Subject: reg: question about SSL server cert verification
In-Reply-To: <DM6PR18MB2700C6A3715A47C24DF148EFF90D9@DM6PR18MB2700.namprd18.prod.outlook.com>
References: <IU8xBCaKUiiyv5XKtR2uWucLMWdHLVrcD8iWjA1klQt39HG20I6pA1cGiCChQfeDXLfOPOWhePz09VJ5G6g4-f9zxQD92y1QJWNM6IK8khE=@protonmail.ch>
 <fbd71870-9095-ff21-d987-8789ee3a19be@wisemo.com>
 <DM6PR18MB2700C6A3715A47C24DF148EFF90D9@DM6PR18MB2700.namprd18.prod.outlook.com>
Message-ID: <abbff4c2-85ca-ab51-35ee-0e028cc5d50b@wisemo.com>

On 2021-06-18 16:23, Michael Wojcik wrote:

>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Jakob
>> Bohm via openssl-users
>> Sent: Friday, 18 June, 2021 07:10
>> To: openssl-users at openssl.org
>> Subject: Re: reg: question about SSL server cert verification
>>
>> On 2021-06-18 06:38, sami0l via openssl-users wrote:
>>> I'm curious how exactly an SSL client verifies an SSL server's
>>> certificate which is signed by a CA.
>> No, here is what really happens:
>>
>> First the owner of the server (or a program they use) find
>> the chain of intermediary certificates which leads from
>> their actual certificate to a commonly trusted root
>> certificate, Lets say the chain is:
>> RootA->CrossB->IntermediaryC->IntermediaryD->EndCertServer.
>> This list of certificates is put in a server config file
>> and the complete list is sent in each SSL handshake and
>> every CMS signed message.
> We hope. But, of course, as Jakob says, there are many misconfigured servers.
>
>> Now the client simply works backwards through that list,
>> checking if each certificate signed the next one or claims
>> to be signed by a certificate in /etc/certs.  This lookup
>> is done based on the complete distinguished name, not just
>> the CN part of it. At every step, the certificate may be
>> referenced by a "key identifier" instead of the
>> distinguished name, and some clients will compare that
>> instead of the distinguished name.
> And there are a whole bunch of other checks: signature, validity dates, key usage, basic constraints...
Those checks would presumably happen after chain building,
verifying that signatures, dates, key usage and other constraints
are correct.
> Also, the correspondence between the peer identity as requested by the client, and as represented by the entity certificate, should not be done using the CN component of the Subject DN (as OP suggested), but by comparing against the Subject Alternative Name extension values. The subject CN should only be used as a last resort; some applications may refuse to allow a CN match and insist on an X.509v3 certificate with a valid SAN.
>
> (Jakob knows all this.)
Actually, I have heard of nothing at all proposing the use of
SANs on CA certificates or their use in chain building.? Hence
why I refer only to matching the complete DN and/or matching
the "key identifier" field.
>
> Certificate chain validation is a very complicated topic. I put together an internal presentation with an overview of it some years back and it was a dozen or more slides, and I only touched on the major points. It's not something that can be covered thoroughly in an email discussion.
However it is something that should be documented in OpenSSL
documents such as the "verify(1ssl)" manpage, but somehow isn't.

For example, some versions of that manpage fail to specify which
name restrictions are checked, which are ignored, and which ones
fail even if they shouldn't.

>
>> The big complications are:
> Numerous. Jakob's list is a good one, but I'm sure we can come up with others. Like, say, the enormous mess which is revocation.
Revocation checks would also be part of the post-chain-building
checks.

> My advice, for someone who wants to understand the certificate-validation process in TLS, is:
> [Snipped: List of academic texts for those who want to implement their own X.509 code]

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From steffen at sdaoden.eu  Fri Jun 18 15:43:00 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Fri, 18 Jun 2021 17:43:00 +0200
Subject: OpenSSL version 3.0.0-beta1 published
In-Reply-To: <20210617151209.s_zNU%steffen@sdaoden.eu>
References: <20210617133633.GA24818@openssl.org>
 <20210617144332.dk9KY%steffen@sdaoden.eu>
 <33db69e0-0f9b-c559-43f7-e5a2f85a48dd@openssl.org>
 <20210617151209.s_zNU%steffen@sdaoden.eu>
Message-ID: <20210618154300.OgeCp%steffen@sdaoden.eu>

Steffen Nurpmeso wrote in
 <20210617151209.s_zNU%steffen at sdaoden.eu>:
 |Matt Caswell wrote in
 | <33db69e0-0f9b-c559-43f7-e5a2f85a48dd at openssl.org>:
 ||On 17/06/2021 15:43, Steffen Nurpmeso wrote:
 ||> Fyi, i have $PERL5OPT=-C permanently in my environment, in
 ||> conjunction with LC_ALL=en_US.utf8 this results in the build error
 ||> as below.  Prefixing LC_ALL=C fixes this.
 ||
 ||Thanks. I submitted this as an issue on github here:
 ||
 ||https://github.com/openssl/openssl/issues/15805
 |
 |Thank you very much.  Yes, sorry, i have no account.

I think the thread comes to the right conclusion.  That $PERL5OPT
habit of mine seems to come from the years 2002/3, perl 5.8.0 /
5.8.1, and i instead changed all of mine and reomved $PERL5OPT
from my program environment.

Ciao,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From janjust at nikhef.nl  Fri Jun 18 15:51:16 2021
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Fri, 18 Jun 2021 17:51:16 +0200
Subject: OpenSSL version 3.0.0-beta1 published
In-Reply-To: <20210617133633.GA24818@openssl.org>
References: <20210617133633.GA24818@openssl.org>
Message-ID: <3b6f0bdc-c8fa-8663-bf11-fa7ef4b03c86@nikhef.nl>

Hi,

On 17/06/21 15:36, Matt Caswell wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>     OpenSSL version 3.0 beta 1 released
>     ===================================
>
>     OpenSSL - The Open Source toolkit for SSL/TLS
>     https://www.openssl.org/
>
>     OpenSSL 3.0 is currently in beta.
>
>     OpenSSL 3.0 beta 1 has now been made available.
>
>     Note: This OpenSSL pre-release has been provided for testing ONLY.
>     It should NOT be used for security critical purposes.
>
>     Specific notes on upgrading to OpenSSL 3.0 from previous versions are
>     available in the OpenSSL Migration Guide, here:
>
>          https://www.openssl.org/docs/manmaster/man7/migration_guide.html
>
>     The beta release is available for download via HTTPS and FTP from the
>     following master locations (you can find the various FTP mirrors under
>     https://www.openssl.org/source/mirror.html):
>
>       * https://www.openssl.org/source/
>       * ftp://ftp.openssl.org/source/
>
>     The distribution file name is:
>
>      o openssl-3.0.0-beta1.tar.gz
>        Size: 14878832
>        SHA1 checksum:  4b48947969bb3c989ba95ac4bdc4a78e70212d2b
>        SHA256 checksum:  7bfedc9a1062cbd2aabc294acc93cbd5259e6e7bd5bbe38e454cc6a32564029f
>
>     The checksums were calculated using the following commands:
>
>      openssl sha1 openssl-3.0.0-beta1.tar.gz
>      openssl sha256 openssl-3.0.0-beta1.tar.gz
>
>     Please download and check this beta release as soon as possible.
>     To report a bug, open an issue on GitHub:
>
>      https://github.com/openssl/openssl/issues
>
>     Please check the release notes and mailing lists to avoid duplicate
>     reports of known issues. (Of course, the source is also available
>     on GitHub.)
>
>    
excellent news - I've downloaded it and played with it a bit; it 
compiles fine and all tests pass on CentOS 7 and Fedora 32+33 .
I've managed to compile ppp-2.4.9 with it and apart from the deprecated 
ENGINE functions it builds OK (with a minor patch to ppp itself which I 
will upload shortly).

However, I was wondering if anyone has ported/refactored the pkcs11 
engine stuff for OpenSSL 3.0 already?? is this on the TODO list for the 
OpenSC/pkcs11 team?? If I wanted to try to refactor the opensc-pkcs11 
module, how would I start?

thanks for all your hard work,

JJK / Jan Just Keijser


From openssl-users at dukhovni.org  Fri Jun 18 16:00:49 2021
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 18 Jun 2021 12:00:49 -0400
Subject: reg: question about SSL server cert verification
In-Reply-To: <abbff4c2-85ca-ab51-35ee-0e028cc5d50b@wisemo.com>
References: <IU8xBCaKUiiyv5XKtR2uWucLMWdHLVrcD8iWjA1klQt39HG20I6pA1cGiCChQfeDXLfOPOWhePz09VJ5G6g4-f9zxQD92y1QJWNM6IK8khE=@protonmail.ch>
 <fbd71870-9095-ff21-d987-8789ee3a19be@wisemo.com>
 <DM6PR18MB2700C6A3715A47C24DF148EFF90D9@DM6PR18MB2700.namprd18.prod.outlook.com>
 <abbff4c2-85ca-ab51-35ee-0e028cc5d50b@wisemo.com>
Message-ID: <YMzDMY9PbtDV6Klv@straasha.imrryr.org>

On Fri, Jun 18, 2021 at 05:37:33PM +0200, Jakob Bohm via openssl-users wrote:

> > Also, the correspondence between the peer identity as requested by
> > the client, and as represented by the entity certificate, should not
> > be done using the CN component of the Subject DN (as OP suggested),
> > but by comparing against the Subject Alternative Name extension
> > values. The subject CN should only be used as a last resort; some
> > applications may refuse to allow a CN match and insist on an X.509v3
> > certificate with a valid SAN.
> >
> > (Jakob knows all this.)
> Actually, I have heard of nothing at all proposing the use of
> SANs on CA certificates or their use in chain building.

The discussion of SANs was only about the EE cert name matching.  Indeed
chain building only matches the issuer DN against the CA subject DN, and
if present authority key id against CA's subject key id (or general name
+ serial from AKID against CA issuer / serial).

-- 
    Viktor.

From Michael.Wojcik at microfocus.com  Fri Jun 18 17:10:25 2021
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 18 Jun 2021 17:10:25 +0000
Subject: reg: question about SSL server cert verification
In-Reply-To: <abbff4c2-85ca-ab51-35ee-0e028cc5d50b@wisemo.com>
References: <IU8xBCaKUiiyv5XKtR2uWucLMWdHLVrcD8iWjA1klQt39HG20I6pA1cGiCChQfeDXLfOPOWhePz09VJ5G6g4-f9zxQD92y1QJWNM6IK8khE=@protonmail.ch>
 <fbd71870-9095-ff21-d987-8789ee3a19be@wisemo.com>
 <DM6PR18MB2700C6A3715A47C24DF148EFF90D9@DM6PR18MB2700.namprd18.prod.outlook.com>
 <abbff4c2-85ca-ab51-35ee-0e028cc5d50b@wisemo.com>
Message-ID: <DM6PR18MB2700D8E87FB672F8B611E45DF90D9@DM6PR18MB2700.namprd18.prod.outlook.com>

> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Jakob
> Bohm via openssl-users
> Sent: Friday, 18 June, 2021 09:38
>
> On 2021-06-18 16:23, Michael Wojcik wrote:
>
> >> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Jakob
> >> Bohm via openssl-users
> >> Sent: Friday, 18 June, 2021 07:10
> >> To: openssl-users at openssl.org
> >> Subject: Re: reg: question about SSL server cert verification
> >>
> > And there are a whole bunch of other checks: signature, validity dates, key
> > usage, basic constraints...
>
> Those checks would presumably happen after chain building,
> verifying that signatures, dates, key usage and other constraints
> are correct.

Well, that depends on the implementation; it could perform those checks while building the chain, as each certificate is added to the chain. My point was that they'll happen eventually, since the OP's question was pretty broad.

> > Also, the correspondence between the peer identity as requested by the
> > client, and as represented by the entity certificate, should not be done
> > using the CN component of the Subject DN (as OP suggested), but by comparing
> > against the Subject Alternative Name extension values....
> >
> > (Jakob knows all this.)
>
> Actually, I have heard of nothing at all proposing the use of
> SANs on CA certificates or their use in chain building.  Hence
> why I refer only to matching the complete DN and/or matching
> the "key identifier" field.

I was only talking about the entity ("server", in this case) certificate above. The original message wasn't clear about whether the OP understood the use of SANs for the entity certificate and its validation against the peer name presented by the local application.

> However it is something that should be documented in OpenSSL
> documents such as the "verify(1ssl)" manpage, but somehow isn't.

Yes, that would be ideal. But, of course, someone needs to write that documentation.

> Revocation checks would also be part of the post-chain-building
> checks.

Yeah. I was looking at the bigger verification process.

> > My advice, for someone who wants to understand the certificate-validation
> > process in TLS, is:
> > [Snipped: List of academic texts for those who want to implement their own
> > X.509 code]

Well, opinions can differ. I've dealt with many, many customers who simply couldn't diagnose PKI issues because they didn't understand all the technical aspects of the process. They didn't know that browsers were rejecting the entity certificates generated by their internal CA because they had CA: TRUE in the Basic Constraints. They didn't understand that an entity certificate with no SANs wouldn't match both the bare hostname and the FQDN. They didn't understand how to manually construct the chain to understand which intermediate certificates they needed.

PKIX is a horrible mess of arcane specifications, requirements, and implementation ideosyncracies. In my experience, extensive technical knowledge is required to diagnose even a decent subset of the more common failure modes.

--
Michael Wojcik

From pauli at openssl.org  Sat Jun 19 00:25:45 2021
From: pauli at openssl.org (Dr Paul Dale)
Date: Sat, 19 Jun 2021 10:25:45 +1000
Subject: OpenSSL version 3.0.0-beta1 published
In-Reply-To: <3b6f0bdc-c8fa-8663-bf11-fa7ef4b03c86@nikhef.nl>
References: <20210617133633.GA24818@openssl.org>
 <3b6f0bdc-c8fa-8663-bf11-fa7ef4b03c86@nikhef.nl>
Message-ID: <3789c498-e62d-6bd0-a109-4abe8838339c@openssl.org>


>
> However, I was wondering if anyone has ported/refactored the pkcs11 
> engine stuff for OpenSSL 3.0 already?? is this on the TODO list for 
> the OpenSC/pkcs11 team?? If I wanted to try to refactor the 
> opensc-pkcs11 module, how would I start?

PKCS #11 support is one (of many) possible items that will be considered 
for future versions of OpenSSL.? The technical and management committees 
will be discussing which items are going to be worked on for the 
subsequent release in the not too distant future.

I'll also note that PKCS #11 considerations were prominent through the 
3.0 design process.? A PKCS #11 provider is expected to be possible with 
minimal (hopefully no) changes to the provider / libcrypto interface.


Pauli


From jb-openssl at wisemo.com  Sun Jun 20 02:08:19 2021
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Sun, 20 Jun 2021 04:08:19 +0200
Subject: reg: question about SSL server cert verification
In-Reply-To: <YMy2v44+QDWzT2Mc@straasha.imrryr.org>
References: <IU8xBCaKUiiyv5XKtR2uWucLMWdHLVrcD8iWjA1klQt39HG20I6pA1cGiCChQfeDXLfOPOWhePz09VJ5G6g4-f9zxQD92y1QJWNM6IK8khE=@protonmail.ch>
 <fbd71870-9095-ff21-d987-8789ee3a19be@wisemo.com>
 <YMy2v44+QDWzT2Mc@straasha.imrryr.org>
Message-ID: <c2f51038-6ca3-e725-9fe0-d61e8031eba0@wisemo.com>

On 2021-06-18 17:07, Viktor Dukhovni wrote:

> On Fri, Jun 18, 2021 at 03:09:47PM +0200, Jakob Bohm via openssl-users wrote:
>
>> Now the client simply works backwards through that list, checking if
>> each certificate signed the next one or claims to be signed by a
>> certificate in /etc/certs.? This lookup is done based on the complete
>> distinguished name, not just the CN part of it.? At every step, the
>> certificate may be referenced by a "key identifier" instead of the
>> distinguished name, and some clients will compare that instead of the
>> distinguished name.
> All extant (non-EOL) OpenSSL releases prioritise the local trust-store
> over the remotely provided CA certificate list when building the
> certificate chain.  The remote chain is used only when no match is found
> in the trust store.  As as a matching issuer is found in the trust store
> all further lookups are from the trust store only.
>
> If the local trust store contains only "root CAs", and the remote peer
> provides the rest of the chain, with no overlap in the subject
> distinguished names, the behaviour is not observably different from
> Jakob's description.
>
> Differences are observed once the local trust store contains some
> intermediate certificates or the remote chain provides a cross cert for
> which the local store instead contains a corresponding (same subject
> name and keyid) self-signed root, or the cross cert is in the local
> store, but the remote peer sends a root.  In all such cases chain
> construction uses the certs from the trust store.  This tends to produce
> less surprising (and ideally better, or at least what you implicitly
> asked for) results.
>
Interesting, earlier today, I observed the confusing effect of
"openssl verify" treating -trusted_first as always on while keeping
document wording suggesting it is an actual option, not historical
remnants of yet another feature removed by the new OpenSSL
management.

-- 
Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10 
<tel:+4531131610>
This message is only for its intended recipient, delete if misaddressed.
WiseMo - Remote Service Management for PCs, Phones and Embedded


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

From openssl-users at dukhovni.org  Sun Jun 20 18:39:16 2021
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 20 Jun 2021 14:39:16 -0400
Subject: reg: question about SSL server cert verification
In-Reply-To: <c2f51038-6ca3-e725-9fe0-d61e8031eba0@wisemo.com>
References: <IU8xBCaKUiiyv5XKtR2uWucLMWdHLVrcD8iWjA1klQt39HG20I6pA1cGiCChQfeDXLfOPOWhePz09VJ5G6g4-f9zxQD92y1QJWNM6IK8khE=@protonmail.ch>
 <fbd71870-9095-ff21-d987-8789ee3a19be@wisemo.com>
 <YMy2v44+QDWzT2Mc@straasha.imrryr.org>
 <c2f51038-6ca3-e725-9fe0-d61e8031eba0@wisemo.com>
Message-ID: <E49DA420-9683-4751-B2B2-2118C6A882BF@dukhovni.org>

> On 19 Jun 2021, at 10:08 pm, Jakob Bohm via openssl-users <openssl-users at openssl.org> wrote:
> 
>> Differences are observed once the local trust store contains some
>> intermediate certificates or the remote chain provides a cross cert for
>> which the local store instead contains a corresponding (same subject
>> name and keyid) self-signed root, or the cross cert is in the local
>> store, but the remote peer sends a root.  In all such cases chain
>> construction uses the certs from the trust store.  This tends to produce
>> less surprising (and ideally better, or at least what you implicitly
>> asked for) results.
> 
> Interesting, earlier today, I observed the confusing effect of
> "openssl verify" treating -trusted_first as always on while keeping
> document wording suggesting it is an actual option, not historical
> remnants of yet another feature removed by the new OpenSSL
> management.

I think it would be best to avoid the insinuating tone.  The change
to trusted-first was requested by users, who provided well-motivated
use-cases that are broken otherwise.

If you want full control of the chain with verify(1) use the "-trusted"
and "-untrusted" options (the "-trusted" option pre?mpts the default trust
store).

If the documentation is confusing, please open an issue or pull request,
this is a community project, I am sorry you're feeling left out, but the
answer to that is to participate.

-- 
	Viktor.


From mcr at sandelman.ca  Tue Jun 22 02:23:06 2021
From: mcr at sandelman.ca (Michael Richardson)
Date: Mon, 21 Jun 2021 22:23:06 -0400
Subject: 3.0 beta1 feedback about (shared) library names
Message-ID: <24915.1624328586@localhost>


I downloaded and compiled opensssl 3.0.0-beta1 from git today.
I installed into a private prefix.

While my debian desktop system has:

%ls -l /usr/lib/x86_64-linux-gnu/libssl*
-rw-r--r-- 1 root root  357056 Jul  8  2020 /usr/lib/x86_64-linux-gnu/libssl3.so
-rw-r--r-- 1 root root 1000534 Feb 16 17:08 /usr/lib/x86_64-linux-gnu/libssl.a
lrwxrwxrwx 1 root root      13 Feb 16 17:08 /usr/lib/x86_64-linux-gnu/libssl.so -> libssl.so.1.1
-rw-r--r-- 1 root root  435704 Jul  4  2017 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
-rw-r--r-- 1 root root  431232 Dec 23  2019 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
-rw-r--r-- 1 root root  593696 Feb 16 17:08 /usr/lib/x86_64-linux-gnu/libssl.so.1.1

%ls -l /usr/lib/x86_64-linux-gnu/libcrypto*
-rw-r--r-- 1 root root 5399144 Feb 16 17:08 /usr/lib/x86_64-linux-gnu/libcrypto.a
lrwxrwxrwx 1 root root      16 Feb 16 17:08 /usr/lib/x86_64-linux-gnu/libcrypto.so -> libcrypto.so.1.1
-rw-r--r-- 1 root root 2494464 Jul  4  2017 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
-rw-r--r-- 1 root root 2504576 Dec 23  2019 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2
-rw-r--r-- 1 root root 3031904 Feb 16 17:08 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1

WTF is libssl3.so?  I still don't know, but:

%dpkg -S /usr/lib/x86_64-linux-gnu/libssl3.so
libnss3:amd64: /usr/lib/x86_64-linux-gnu/libssl3.so
something up there that should be concerning, because maybe it will cause confusion.

My newly installed openssl 3 has:

%ls -l /sandel/3rd/openssl3/lib
total 16188
drwxr-xr-x 2 mcr mcr    4096 Jun 21 21:29 engines-3/
-rw-r--r-- 1 mcr mcr 9307420 Jun 21 21:29 libcrypto.a
lrwxrwxrwx 1 mcr mcr      14 Jun 21 21:29 libcrypto.so -> libcrypto.so.3*
-rwxr-xr-x 1 mcr mcr 5205856 Jun 21 21:29 libcrypto.so.3*
-rw-r--r-- 1 mcr mcr 1251782 Jun 21 21:29 libssl.a
lrwxrwxrwx 1 mcr mcr      11 Jun 21 21:29 libssl.so -> libssl.so.3*
-rwxr-xr-x 1 mcr mcr  794496 Jun 21 21:29 libssl.so.3*
drwxr-xr-x 2 mcr mcr    4096 Jun 21 21:29 ossl-modules/
drwxr-xr-x 2 mcr mcr    4096 Jun 21 21:29 pkgconfig/

So I see that the versioned .so file will be somewhat related to the version.
Distros will be able to ship openssl1.x and openssl3.x shared libraries at
the same time.

But, having both "libssl-dev" and "libssl3-dev" installed at the same time is
going to be a problem.

I think that the differences in ABI may be significant enough that you should
consider calling it "libssl3" and "libcrypto3".  Yeah, maybe that's uncool,
but it may be pragmatic.

{ps: I am working on the ruby openssl library next to see what happens}

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210621/ba6dd506/attachment.sig>

From bkaduk at akamai.com  Tue Jun 22 04:05:54 2021
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Mon, 21 Jun 2021 21:05:54 -0700
Subject: 3.0 beta1 feedback about (shared) library names
In-Reply-To: <24915.1624328586@localhost>
References: <24915.1624328586@localhost>
Message-ID: <20210622040553.GG19992@akamai.com>

On Mon, Jun 21, 2021 at 10:23:06PM -0400, Michael Richardson wrote:
> 
> I downloaded and compiled opensssl 3.0.0-beta1 from git today.
> I installed into a private prefix.
> 
> While my debian desktop system has:
> 
> %ls -l /usr/lib/x86_64-linux-gnu/libssl*
> -rw-r--r-- 1 root root  357056 Jul  8  2020 /usr/lib/x86_64-linux-gnu/libssl3.so
> -rw-r--r-- 1 root root 1000534 Feb 16 17:08 /usr/lib/x86_64-linux-gnu/libssl.a
> lrwxrwxrwx 1 root root      13 Feb 16 17:08 /usr/lib/x86_64-linux-gnu/libssl.so -> libssl.so.1.1
> -rw-r--r-- 1 root root  435704 Jul  4  2017 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
> -rw-r--r-- 1 root root  431232 Dec 23  2019 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
> -rw-r--r-- 1 root root  593696 Feb 16 17:08 /usr/lib/x86_64-linux-gnu/libssl.so.1.1
> 
> %ls -l /usr/lib/x86_64-linux-gnu/libcrypto*
> -rw-r--r-- 1 root root 5399144 Feb 16 17:08 /usr/lib/x86_64-linux-gnu/libcrypto.a
> lrwxrwxrwx 1 root root      16 Feb 16 17:08 /usr/lib/x86_64-linux-gnu/libcrypto.so -> libcrypto.so.1.1
> -rw-r--r-- 1 root root 2494464 Jul  4  2017 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
> -rw-r--r-- 1 root root 2504576 Dec 23  2019 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2
> -rw-r--r-- 1 root root 3031904 Feb 16 17:08 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
> 
> WTF is libssl3.so?  I still don't know, but:
> 
> %dpkg -S /usr/lib/x86_64-linux-gnu/libssl3.so
> libnss3:amd64: /usr/lib/x86_64-linux-gnu/libssl3.so
> something up there that should be concerning, because maybe it will cause confusion.

NSS is the mozilla TLS stack, used by firefox/etc.

> My newly installed openssl 3 has:
> 
> %ls -l /sandel/3rd/openssl3/lib
> total 16188
> drwxr-xr-x 2 mcr mcr    4096 Jun 21 21:29 engines-3/
> -rw-r--r-- 1 mcr mcr 9307420 Jun 21 21:29 libcrypto.a
> lrwxrwxrwx 1 mcr mcr      14 Jun 21 21:29 libcrypto.so -> libcrypto.so.3*
> -rwxr-xr-x 1 mcr mcr 5205856 Jun 21 21:29 libcrypto.so.3*
> -rw-r--r-- 1 mcr mcr 1251782 Jun 21 21:29 libssl.a
> lrwxrwxrwx 1 mcr mcr      11 Jun 21 21:29 libssl.so -> libssl.so.3*
> -rwxr-xr-x 1 mcr mcr  794496 Jun 21 21:29 libssl.so.3*
> drwxr-xr-x 2 mcr mcr    4096 Jun 21 21:29 ossl-modules/
> drwxr-xr-x 2 mcr mcr    4096 Jun 21 21:29 pkgconfig/
> 
> So I see that the versioned .so file will be somewhat related to the version.
> Distros will be able to ship openssl1.x and openssl3.x shared libraries at
> the same time.
> 
> But, having both "libssl-dev" and "libssl3-dev" installed at the same time is
> going to be a problem.

This is typically solved at the distro layer, not by "upstream" ... often by
just saying you only get to have one installed at a time, and making you swap
back and forth.

Other times the packages will create "-multidev" libraries that install into
a subdirectory, e.g., krb5-multidev installs into /usr/lib/{triple}/mit-krb5
and there's a libkrb5-dev that makes symlinks from the parent directory.

-Ben

> I think that the differences in ABI may be significant enough that you should
> consider calling it "libssl3" and "libcrypto3".  Yeah, maybe that's uncool,
> but it may be pragmatic.
> 
> {ps: I am working on the ruby openssl library next to see what happens}
> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
> 



From Raffy.Revestual at Emerson.com  Tue Jun 22 04:18:25 2021
From: Raffy.Revestual at Emerson.com (Revestual, Raffy [AUTOSOL/PSS/MNL])
Date: Tue, 22 Jun 2021 04:18:25 +0000
Subject: Can OpenSSL handle multiple authentication mechanisms on the same SSL
 context?
In-Reply-To: <PH0PR10MB4453C71A8514CD044485A6EDE7099@PH0PR10MB4453.namprd10.prod.outlook.com>
References: <PH0PR10MB4453C71A8514CD044485A6EDE7099@PH0PR10MB4453.namprd10.prod.outlook.com>
Message-ID: <PH0PR10MB445347F4CDCFDFC34555CB41E7099@PH0PR10MB4453.namprd10.prod.outlook.com>

Also asked this question in stackoverflow.com

https://stackoverflow.com/questions/68077419/can-openssl-handle-multiple-authentication-mechanisms-on-the-same-ssl-context

We are trying to support a server that would support PSK and SRP authentication mechanisms. However, when we run to try to run callbacks for both on the same context, only the PSK callbacks are being detected:

SSL_CTX_set_psk_server_callback(m_ctx, psk_out_of_bound_serv_cb);

SSL_CTX_set_srp_username_callback(m_ctx, srp_server_param_cb);

SRP and PSK works currently in our code if you only set one callback or the other. I tried to register SRP first but doing this didn't change the fact the only PSK was working. So an alternative would be to set these individually on the SSL context. I have also confirmed that SRP and PSK cipher suites when combined when being set is a non-issue.

Would multiple callbacks for different mechanisms work simultaneously on the same SSL context?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210622/7da55f81/attachment-0001.html>

From bkaduk at akamai.com  Tue Jun 22 05:39:23 2021
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Mon, 21 Jun 2021 22:39:23 -0700
Subject: Can OpenSSL handle multiple authentication mechanisms on the
 same SSL context?
In-Reply-To: <PH0PR10MB445347F4CDCFDFC34555CB41E7099@PH0PR10MB4453.namprd10.prod.outlook.com>
References: <PH0PR10MB4453C71A8514CD044485A6EDE7099@PH0PR10MB4453.namprd10.prod.outlook.com>
 <PH0PR10MB445347F4CDCFDFC34555CB41E7099@PH0PR10MB4453.namprd10.prod.outlook.com>
Message-ID: <20210622053922.GH19992@akamai.com>

On Tue, Jun 22, 2021 at 04:18:25AM +0000, Revestual, Raffy [AUTOSOL/PSS/MNL] wrote:
> Also asked this question in stackoverflow.com
> 
> https://urldefense.com/v3/__https://stackoverflow.com/questions/68077419/can-openssl-handle-multiple-authentication-mechanisms-on-the-same-ssl-context__;!!GjvTz_vk!DeBGhsJS1c6OIusGcUpz3NpRsG2S3kReo2omn1ch1-B6mJ1ZvmGuj5awlkmShw$ 
> 
> We are trying to support a server that would support PSK and SRP authentication mechanisms. However, when we run to try to run callbacks for both on the same context, only the PSK callbacks are being detected:
> 
> SSL_CTX_set_psk_server_callback(m_ctx, psk_out_of_bound_serv_cb);
> 
> SSL_CTX_set_srp_username_callback(m_ctx, srp_server_param_cb);
> 
> SRP and PSK works currently in our code if you only set one callback or the other. I tried to register SRP first but doing this didn't change the fact the only PSK was working. So an alternative would be to set these individually on the SSL context. I have also confirmed that SRP and PSK cipher suites when combined when being set is a non-issue.
> 
> Would multiple callbacks for different mechanisms work simultaneously on the same SSL context?

The situation is somewhat different between TLS 1.3 and prior versions (e.g., TLS 1.2).
Since there isn't currently a defined SRP option for TLS 1.3, I assume you are targeting TLS 1.2

I think you need to say more about your testing -- whether SRP or PSK is being attempted
for TLS 1.2 is at the control of the client, as the ClientKeyExchange protocol message will
have a different structure for using SRP vs using PSK.  If your client is never trying
SRP, then of course your SRP callback will never be called.

So, how are you testing the various scenarios?

-Ben

From Raffy.Revestual at Emerson.com  Tue Jun 22 05:49:58 2021
From: Raffy.Revestual at Emerson.com (Revestual, Raffy [AUTOSOL/PSS/MNL])
Date: Tue, 22 Jun 2021 05:49:58 +0000
Subject: [EXTERNAL] Re: Can OpenSSL handle multiple authentication
 mechanisms on the same SSL context?
In-Reply-To: <20210622053922.GH19992@akamai.com>
References: <PH0PR10MB4453C71A8514CD044485A6EDE7099@PH0PR10MB4453.namprd10.prod.outlook.com>
 <PH0PR10MB445347F4CDCFDFC34555CB41E7099@PH0PR10MB4453.namprd10.prod.outlook.com>
 <20210622053922.GH19992@akamai.com>
Message-ID: <PH0PR10MB44532DBB8EB187F4AC07BC89E7099@PH0PR10MB4453.namprd10.prod.outlook.com>

Thanks for the response Ben!

We are targeting TLS1.2. For testing, we have one server that has both callbacks enabled. On the client side, we have two clients, 1 establishing SRP connections with the usual calls (set_srp_username,set_srp_password) and it works. The other client establishes connections via PSK. 

Running callback only for SRP on the server with a client connecting via SRP works. Its just that when you try to add a PSK callback on the server with the SRP callback, the SRP callbacks don't work anymore for SRP clients when PSK clients are still able to with both callbacks being triggered/registered. 

Here is a quick summary of the test scenarios we have:
1. SRP client with SRP callback only - works
2. PSK client with PSK callback only - works
3. SRP client with SRP+PSK callbacks - doesn't work
4. PSK client with SRP+PSK callbacks - works

Main issue is that the SRP callback doesn't seem to play well with PSK callback. Let me know if there is any other information I may have not supplied so I can try to explain further.

Raffy
 
-----Original Message-----
From: Benjamin Kaduk <bkaduk at akamai.com> 
Sent: Tuesday, June 22, 2021 1:39 PM
To: Revestual, Raffy [AUTOSOL/PSS/MNL] <Raffy.Revestual at Emerson.com>
Cc: openssl-users at openssl.org
Subject: [EXTERNAL] Re: Can OpenSSL handle multiple authentication mechanisms on the same SSL context?

On Tue, Jun 22, 2021 at 04:18:25AM +0000, Revestual, Raffy [AUTOSOL/PSS/MNL] wrote:
> Also asked this question in stackoverflow.com
> 
> https://urldefense.com/v3/__https://stackoverflow.com/questions/680774
> 19/can-openssl-handle-multiple-authentication-mechanisms-on-the-same-s
> sl-context__;!!GjvTz_vk!DeBGhsJS1c6OIusGcUpz3NpRsG2S3kReo2omn1ch1-B6mJ
> 1ZvmGuj5awlkmShw$
> 
> We are trying to support a server that would support PSK and SRP authentication mechanisms. However, when we run to try to run callbacks for both on the same context, only the PSK callbacks are being detected:
> 
> SSL_CTX_set_psk_server_callback(m_ctx, psk_out_of_bound_serv_cb);
> 
> SSL_CTX_set_srp_username_callback(m_ctx, srp_server_param_cb);
> 
> SRP and PSK works currently in our code if you only set one callback or the other. I tried to register SRP first but doing this didn't change the fact the only PSK was working. So an alternative would be to set these individually on the SSL context. I have also confirmed that SRP and PSK cipher suites when combined when being set is a non-issue.
> 
> Would multiple callbacks for different mechanisms work simultaneously on the same SSL context?

The situation is somewhat different between TLS 1.3 and prior versions (e.g., TLS 1.2).
Since there isn't currently a defined SRP option for TLS 1.3, I assume you are targeting TLS 1.2

I think you need to say more about your testing -- whether SRP or PSK is being attempted for TLS 1.2 is at the control of the client, as the ClientKeyExchange protocol message will have a different structure for using SRP vs using PSK.  If your client is never trying SRP, then of course your SRP callback will never be called.

So, how are you testing the various scenarios?

-Ben

From whissi at gentoo.org  Tue Jun 22 12:12:28 2021
From: whissi at gentoo.org (Thomas Deutschmann)
Date: Tue, 22 Jun 2021 14:12:28 +0200
Subject: How to query current settings/policies?
Message-ID: <f85e787e-a5ab-4f59-5783-f8aed69eb7de@gentoo.org>

Hi,

with OpenSSL 3 defaulting to TLS security level 1, applications trying 
to make a TLSv1/1.1 connection will fail.

I wonder if there is a proper way to detect current security level.

I.e. how about test suites which need to know if they have to skip a 
test or not?

For example, I am currently looking at MySQL which has a test to ensure, 
that you are still able to connect to TLS 1.3 enabled server with 
TLSv1/1.1: 
https://github.com/mysql/mysql-server/blob/mysql-8.0.25/mysql-test/suite/auth_sec/t/tls13_tls1.test

The test already knows about the fact that system could have restricted 
minimum TLS version, see 
https://github.com/mysql/mysql-server/blob/mysql-8.0.25/mysql-test/include/not_min_protocol_tlsv12.inc

However, this solution isn't stable: It's just parsing some files from 
hard coded paths (what about OPENSSL_CONF environment variable?) and 
guesses.

Furthermore it knows nothing about Gentoo Linux for example. But even 
with Ubuntu, you could have a policy in place which overrides set 
OPENSSL_TLS_SECURITY_LEVEL=2 from configure.

Is there a way to use openssl CLI to query this information and allow 
test suites for example to skip tests on a more reliable way? Or what's 
the recommended way for tests?


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210622/44fd4344/attachment.sig>

From tomas at openssl.org  Tue Jun 22 12:53:07 2021
From: tomas at openssl.org (Tomas Mraz)
Date: Tue, 22 Jun 2021 14:53:07 +0200
Subject: How to query current settings/policies?
In-Reply-To: <f85e787e-a5ab-4f59-5783-f8aed69eb7de@gentoo.org>
References: <f85e787e-a5ab-4f59-5783-f8aed69eb7de@gentoo.org>
Message-ID: <0efffb4616775a8eaec2f87621c77f184821a5b4.camel@openssl.org>

On Tue, 2021-06-22 at 14:12 +0200, Thomas Deutschmann wrote:
> Hi,
> 
> with OpenSSL 3 defaulting to TLS security level 1, applications
> trying 
> to make a TLSv1/1.1 connection will fail.
> 
> I wonder if there is a proper way to detect current security level.
> 
> I.e. how about test suites which need to know if they have to skip a 
> test or not?
> 
> For example, I am currently looking at MySQL which has a test to
> ensure, 
> that you are still able to connect to TLS 1.3 enabled server with 
> TLSv1/1.1: 
> https://github.com/mysql/mysql-server/blob/mysql-8.0.25/mysql-test/suite/auth_sec/t/tls13_tls1.test
> 
> The test already knows about the fact that system could have
> restricted 
> minimum TLS version, see 
> https://github.com/mysql/mysql-server/blob/mysql-8.0.25/mysql-test/include/not_min_protocol_tlsv12.inc
> 
> However, this solution isn't stable: It's just parsing some files
> from 
> hard coded paths (what about OPENSSL_CONF environment variable?) and 
> guesses.
> 
> Furthermore it knows nothing about Gentoo Linux for example. But
> even 
> with Ubuntu, you could have a policy in place which overrides set 
> OPENSSL_TLS_SECURITY_LEVEL=2 from configure.
> 
> Is there a way to use openssl CLI to query this information and
> allow 
> test suites for example to skip tests on a more reliable way? Or
> what's 
> the recommended way for tests?

There is already such feature request:
https://github.com/openssl/openssl/issues/14570

Unfortunately it was not implemented in time for beta1 so this is now
Post 3.0 item.

I would recommend explicitly setting security level 0 via a cipher
string when executing the test.

-- 
Tom?? Mr?z
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]



From mwood at iupui.edu  Tue Jun 22 13:09:57 2021
From: mwood at iupui.edu (Mark H. Wood)
Date: Tue, 22 Jun 2021 09:09:57 -0400
Subject: How to query current settings/policies?
In-Reply-To: <0efffb4616775a8eaec2f87621c77f184821a5b4.camel@openssl.org>
References: <f85e787e-a5ab-4f59-5783-f8aed69eb7de@gentoo.org>
 <0efffb4616775a8eaec2f87621c77f184821a5b4.camel@openssl.org>
Message-ID: <YNHhJQOlnL6L29Do@IUPUI.Edu>

On Tue, Jun 22, 2021 at 02:53:07PM +0200, Tomas Mraz wrote:
> On Tue, 2021-06-22 at 14:12 +0200, Thomas Deutschmann wrote:
> > Hi,
> > 
> > with OpenSSL 3 defaulting to TLS security level 1, applications
> > trying 
> > to make a TLSv1/1.1 connection will fail.
> > 
> > I wonder if there is a proper way to detect current security level.
> > 
> > I.e. how about test suites which need to know if they have to skip a 
> > test or not?
> > 
> > For example, I am currently looking at MySQL which has a test to
> > ensure, 
> > that you are still able to connect to TLS 1.3 enabled server with 
> > TLSv1/1.1: 
> > https://github.com/mysql/mysql-server/blob/mysql-8.0.25/mysql-test/suite/auth_sec/t/tls13_tls1.test
> > 
> > The test already knows about the fact that system could have
> > restricted 
> > minimum TLS version, see 
> > https://github.com/mysql/mysql-server/blob/mysql-8.0.25/mysql-test/include/not_min_protocol_tlsv12.inc
> > 
> > However, this solution isn't stable: It's just parsing some files
> > from 
> > hard coded paths (what about OPENSSL_CONF environment variable?) and 
> > guesses.
> > 
> > Furthermore it knows nothing about Gentoo Linux for example. But
> > even 
> > with Ubuntu, you could have a policy in place which overrides set 
> > OPENSSL_TLS_SECURITY_LEVEL=2 from configure.
> > 
> > Is there a way to use openssl CLI to query this information and
> > allow 
> > test suites for example to skip tests on a more reliable way? Or
> > what's 
> > the recommended way for tests?
> 
> There is already such feature request:
> https://github.com/openssl/openssl/issues/14570
> 
> Unfortunately it was not implemented in time for beta1 so this is now
> Post 3.0 item.
> 
> I would recommend explicitly setting security level 0 via a cipher
> string when executing the test.

I second the motion.  If a test is sensitive to some setting of the
code under test, then the test should set it.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210622/5f73c656/attachment.sig>

From levitte at openssl.org  Tue Jun 22 17:44:44 2021
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 22 Jun 2021 19:44:44 +0200
Subject: 3.0 beta1 feedback about (shared) library names
In-Reply-To: <24915.1624328586@localhost>
References: <24915.1624328586@localhost>
Message-ID: <874kdprdyr.wl-levitte@openssl.org>

On Tue, 22 Jun 2021 04:23:06 +0200,
Michael Richardson wrote:
> 
> WTF is libssl3.so?  I still don't know, but:
> 
> %dpkg -S /usr/lib/x86_64-linux-gnu/libssl3.so
> libnss3:amd64: /usr/lib/x86_64-linux-gnu/libssl3.so
> something up there that should be concerning, because maybe it will cause confusion.

Here's how to take a closer look at Debian packages:

    $ apt show libnss3
    Package: libnss3
    Version: 2:3.67-1
    Priority: optional
    Section: libs
    Source: nss
    Maintainer: Maintainers of Mozilla-related packages <team+pkg-mozilla at tracker.debian.org>
    Installed-Size: 4,173 kB
    Depends: libc6 (>= 2.14), libnspr4 (>= 2:4.12), libsqlite3-0 (>= 3.5.9)
    Conflicts: libnss3-1d (<< 2:3.13.4-2)
    Homepage: http://www.mozilla.org/projects/security/pki/nss/
    Tag: role::shared-lib
    Download-Size: 1,316 kB
    APT-Manual-Installed: no
    APT-Sources: http://ftp.se.debian.org/debian unstable/main amd64 Packages
    Description: Network Security Service libraries
     This is a set of libraries designed to support cross-platform development
     of security-enabled client and server applications. It can support SSLv2
     and  v4, TLS, PKCS #5, #7, #11, #12, S/MIME, X.509 v3 certificates and
     other security standards.

As you can see, libnss3 packages Mozilla's NSS project, not OpenSSL.

I just had a look at the source of that package, and it makes it clear
that libnss3.so is actually the NSS project's own name for their SSL
library, so this isn't even a packaging problem.

> But, having both "libssl-dev" and "libssl3-dev" installed at the same time is
> going to be a problem.

Not really.  Programs that are built against OpenSSL's libraries will
use the files from libssl-dev, and programs that are built against
Mozilla's NSS libraries will use the files from libssl3-dev.

Yes, I agree that it's unfortunate that the library names are so
similar, because confusion.  I understand that.

> I think that the differences in ABI may be significant enough that you should
> consider calling it "libssl3" and "libcrypto3".  Yeah, maybe that's uncool,
> but it may be pragmatic.

It's not at all pragmatic, let alone not at all cool, seeing that
libssl3 isn't ours.  I hope you understand this at this point.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From Sanjeev.Kumar-Mishra at rbbn.com  Wed Jun 23 08:12:41 2021
From: Sanjeev.Kumar-Mishra at rbbn.com (Kumar Mishra, Sanjeev)
Date: Wed, 23 Jun 2021 08:12:41 +0000
Subject: Not getting some macros for FIPS
Message-ID: <SN2PR03MB231908F50B30A224FD08925EA6089@SN2PR03MB2319.namprd03.prod.outlook.com>

Hi,

I am upgrading the code of OpenSSL 1.0 to 3.0. I am not getting some macros for FIPS example -

FIPS_TEST_INTEGRITY
FIPS_R_PAIRWISE_TEST_FAILED
FIPS_R_DRBG_STUCK etc.

What is alternative of above macros ? How I work around this ? What header file do I need to include for these macro in OpenSSL 3.0 beta ?

Thanks With Best Regards,
Sanjeev Kumar Mishra

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210623/62584000/attachment.html>

From tomas at openssl.org  Wed Jun 23 08:51:05 2021
From: tomas at openssl.org (Tomas Mraz)
Date: Wed, 23 Jun 2021 10:51:05 +0200
Subject: Not getting some macros for FIPS
In-Reply-To: <SN2PR03MB231908F50B30A224FD08925EA6089@SN2PR03MB2319.namprd03.prod.outlook.com>
References: <SN2PR03MB231908F50B30A224FD08925EA6089@SN2PR03MB2319.namprd03.prod.outlook.com>
Message-ID: <d27d3307fff800e484a47bafa2275d8e2c7db572.camel@openssl.org>

On Wed, 2021-06-23 at 08:12 +0000, Kumar Mishra, Sanjeev wrote:
> Hi,
> 
> I am upgrading the code of OpenSSL 1.0 to 3.0. I am not getting some
> macros for FIPS example -
> 
> FIPS_TEST_INTEGRITY
> FIPS_R_PAIRWISE_TEST_FAILED
> FIPS_R_DRBG_STUCK etc.

It is unclear what you're doing with those macros. They had not much
use outside of the old FIPS module source. The OpenSSL 3.0 uses a
completely different concept to implement a FIPS module - that is the
FIPS provider.

Have you read 
https://www.openssl.org/docs/manmaster/man7/migration_guide.html ?

> Notice: This e-mail together with any attachments may contain
> information of Ribbon Communications Inc. and its Affiliates that is
> confidential and/or proprietary for the sole use of the intended
> recipient. Any review, disclosure, reliance or distribution by others
> or forwarding without express permission is strictly prohibited. If
> you are not the intended recipient, please notify the sender
> immediately and then delete all copies, including any attachments.

It's a little bit strange to send e-mails with such notices to public
mailing lists where the intented recipient is _anyone_.

-- 
Tom?? Mr?z
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]



From levitte at openssl.org  Wed Jun 23 09:23:41 2021
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 23 Jun 2021 11:23:41 +0200
Subject: 3.0 beta1 feedback about (shared) library names
In-Reply-To: <8832.1624391910@localhost>
References: <24915.1624328586@localhost> <874kdprdyr.wl-levitte@openssl.org>
 <8832.1624391910@localhost>
Message-ID: <8735t9q6hu.wl-levitte@openssl.org>

On Tue, 22 Jun 2021 21:58:30 +0200,
Michael Richardson wrote:
> 
> Richard Levitte <levitte at openssl.org> wrote:
>     >> But, having both "libssl-dev" and "libssl3-dev" installed at the same
>     >> time is going to be a problem.
> 
>     > Not really.  Programs that are built against OpenSSL's libraries will
>     > use the files from libssl-dev, and programs that are built against
>     > Mozilla's NSS libraries will use the files from libssl3-dev.
> 
> If both can be installed at the same time, great.

As far as I can tell, the Mozilla NSS Debian packages and the OpenSSL
Debian packages do not trample on each other, so they can be installed
at the same time.  Debian is generally pretty good at ensuring this.

>     > It's not at all pragmatic, let alone not at all cool, seeing that
>     > libssl3 isn't ours.  I hope you understand this at this point.
> 
> a) I think that Mozilla/Debian should plan to rename libssl3.so.
>    Obviously, that name comes from the era of "SSL 3.0" vs "TLS1.3".

I'm actually more ready to assume that the '3' is due to NSS being at
version 3.x as well.  They ship other libraries as well, with that
same number:

    grep '\.so' /var/lib/dpkg/info/libnss3\:amd64.list 
    /usr/lib/x86_64-linux-gnu/libnss3.so
    /usr/lib/x86_64-linux-gnu/libnssutil3.so
    /usr/lib/x86_64-linux-gnu/libsmime3.so
    /usr/lib/x86_64-linux-gnu/libssl3.so
    /usr/lib/x86_64-linux-gnu/nss/libfreebl3.so
    /usr/lib/x86_64-linux-gnu/nss/libfreeblpriv3.so
    /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so
    /usr/lib/x86_64-linux-gnu/nss/libnssdbm3.so
    /usr/lib/x86_64-linux-gnu/nss/libsoftokn3.so

However, if you want Debian to change how they package libnss, then
you should talk with them.  I would be surprised if they did, though,
because that would mean that libnss libraries would be named
differently on different platforms, and that's quite a can of worms.

> b) what I meant was uncool was that the next version of "libssl.so.1"
>    would be "libssl3.so.3" rather than "libssl.so.3"
>    Actually, at that point, you could consider "libopenssl.so.3".

Our library isn't named in a way that you deem uncool, so I guess
we're fine ;-)

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From david.raingeard at gmail.com  Thu Jun 24 13:06:12 2021
From: david.raingeard at gmail.com (david raingeard)
Date: Thu, 24 Jun 2021 15:06:12 +0200
Subject: openssl 1.1.1k on solaris 2.6 sparc
Message-ID: <CAFvDS1RnLPXMedqagRYCZgJGsUvTqT=F1p=PbUEV00hJLMjF4w@mail.gmail.com>

Hello,

I compiled it using sun compiler, with some modifications to the source
code.

However :)

 openssl s_client -connect google.com:443 -tls1_2

works fine !

But
  openssl s_client -connect google.com:443 -tls1_3

fails on CRYPTO_memcmp.

For easy debugging, I have made a copy of  CRYPTO_memcmp in gcm128,
called CRYPTO_gcm128_memcmp.

Here is what I get (added some log ?). As you can see, ctx->Xi.c and tag
don't match.

I have looked for hours to find why, with no luck yet.
Any idea how to debug this ? Some tests to run to check if everything is ok
?


crypto/modes/gcm128.c:1931 ctx->EK0.u[0]=a2e1d0203e9a02ca
crypto/modes/gcm128.c:1932 ctx->EK0.u[1]=9fc11c97afde22db
crypto/modes/gcm128.c:1933 ctx->Xi.u[0]=a22699a2cb77c69d
crypto/modes/gcm128.c:1934 ctx->Xi.u[1]=5af190e82eeffaf3
crypto/modes/gcm128.c:1937 after xor:
crypto/modes/gcm128.c:1938 ctx->Xi.u[0]=c74982f5edc457
crypto/modes/gcm128.c:1939 ctx->Xi.u[1]=c5308c7f8131d828
crypto/modes/gcm128.c:1941
crypto/modes/gcm128.c:1834 CRYPTO_gcm128_memcmp
        len=16
00^a7
c7^c1
49^4d
82^51
f5^0b
ed^25
c4^ae
57^26
c5^d2
30^66
8c^33
7f^82
81^0f
31^75
d8^a4
28^e0
crypto/modes/gcm128.c:1842 CRYPTO_gcm128_memcmp
crypto/modes/gcm128.c:1957 ret = 255
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210624/5ee43c89/attachment.html>

From Michael.Wojcik at microfocus.com  Thu Jun 24 13:37:45 2021
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 24 Jun 2021 13:37:45 +0000
Subject: openssl 1.1.1k on solaris 2.6 sparc
In-Reply-To: <CAFvDS1RnLPXMedqagRYCZgJGsUvTqT=F1p=PbUEV00hJLMjF4w@mail.gmail.com>
References: <CAFvDS1RnLPXMedqagRYCZgJGsUvTqT=F1p=PbUEV00hJLMjF4w@mail.gmail.com>
Message-ID: <DM6PR18MB27002A2C090A909EEE5B53D6F9079@DM6PR18MB2700.namprd18.prod.outlook.com>

> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of david raingeard
> Sent: Thursday, 24 June, 2021 07:06

> I compiled it using sun compiler, with some modifications to the source code.

If memory serves, OpenSSL doesn't work on Solaris SPARC if built using the Sun compiler. You have to use GCC. I'm pretty sure we discovered this in our SPARC product builds.

This, and some other platform issues (there's one with GCC optimization on x86 64-bit, the details of which escape me now), are things I keep hoping to find time to dig into, but more-pressing work never seems to ease up.

--
Michael Wojcik

From wieland at purdue.edu  Thu Jun 24 13:44:38 2021
From: wieland at purdue.edu (Jeff Wieland)
Date: Thu, 24 Jun 2021 09:44:38 -0400
Subject: openssl 1.1.1k on solaris 2.6 sparc
In-Reply-To: <ecd36759171348d993b50442751138e8@BY5PR22MB1940.namprd22.prod.outlook.com>
References: <CAFvDS1RnLPXMedqagRYCZgJGsUvTqT=F1p=PbUEV00hJLMjF4w@mail.gmail.com>
 <ecd36759171348d993b50442751138e8@BY5PR22MB1940.namprd22.prod.outlook.com>
Message-ID: <251feb4d-6cff-ed22-9578-f7d66d79272f@purdue.edu>

Michael Wojcik wrote:
>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of david raingeard
>> Sent: Thursday, 24 June, 2021 07:06
>> I compiled it using sun compiler, with some modifications to the source code.
> If memory serves, OpenSSL doesn't work on Solaris SPARC if built using the Sun compiler. You have to use GCC. I'm pretty sure we discovered this in our SPARC product builds.
>
> This, and some other platform issues (there's one with GCC optimization on x86 64-bit, the details of which escape me now), are things I keep hoping to find time to dig into, but more-pressing work never seems to ease up.
>
> --
> Michael Wojcik

You can build it on Solaris 10 SPARC, using Studio 12.2 for 32 bit, and
Studio 12.4 for 64 bit.? Make sure that these are fully patched up.

--
Jeff Wieland, UNIX Systems Administrator
Purdue University IT Infrastructure Services UNIX Platforms


From david.raingeard at gmail.com  Fri Jun 25 05:44:10 2021
From: david.raingeard at gmail.com (david raingeard)
Date: Fri, 25 Jun 2021 07:44:10 +0200
Subject: openssl 1.1.1 debugging
Message-ID: <CAFvDS1TwTx1-gtVg2_53b7p=q76Ft21+ZSduXqEHo-FHZU-RFQ@mail.gmail.com>

hello

is it possible to have some kind of debug server which will always use the
same data, so i can debug the code ?

i mean i have openssl working with tls 1.3 and ssl3 on unbuntu, which i
could compare the logs with the ones on the sparc, so i can find out where
it goes wrong ?

thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210625/18df0284/attachment-0001.html>

From sanumesh at in.ibm.com  Fri Jun 25 07:01:49 2021
From: sanumesh at in.ibm.com (Sandeep Umesh)
Date: Fri, 25 Jun 2021 07:01:49 +0000
Subject: openssl 3.0 beta versus actual
Message-ID: <OFF7971AAD.AC99C254-ON002586FF.00263162-002586FF.00269EA9@notes.na.collabserv.com>

An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210625/488510b6/attachment.html>

From matt at openssl.org  Fri Jun 25 08:22:13 2021
From: matt at openssl.org (Matt Caswell)
Date: Fri, 25 Jun 2021 09:22:13 +0100
Subject: openssl 3.0 beta versus actual
In-Reply-To: <OFF7971AAD.AC99C254-ON002586FF.00263162-002586FF.00269EA9@notes.na.collabserv.com>
References: <OFF7971AAD.AC99C254-ON002586FF.00263162-002586FF.00269EA9@notes.na.collabserv.com>
Message-ID: <f2f14fc7-b031-15e2-4a0e-c1b86ab81f9f@openssl.org>



On 25/06/2021 08:01, Sandeep Umesh wrote:
> Hello
> While the beta version has been released now, please let us know if 
> there is any timeline to release the actual 3.0 version ?
> What changes are expected to be 3.0 version compared to its beta ? it is 
> restricted to bug-fixes only ?

We are expecting 3.0 actual to be released in Q3 of this year.

Beta is bug fixes only - no new features.

Matt


From frans at fransdb.nl  Fri Jun 25 18:08:48 2021
From: frans at fransdb.nl (Frans de Boer)
Date: Fri, 25 Jun 2021 20:08:48 +0200
Subject: ICC and printers
Message-ID: <d0c1cab0-a9b0-f8cd-610b-4e5568d3d4b5@fransdb.nl>

LS,

I keep getting the message "

You need Gnome Color Management installed in order to calibrate devices" 
when I select Color Management in the System Setting under KDE.

The thing is, colord as well as the gnome-color-manager are both 
installed. So, why does it not see the the latter program?

Anybody experience with it?

Regards, Frans.

-- 
A: Yes, just like that                            A: Ja, net zo
Q: Oh, Just like reading a book backwards         Q: Oh, net als een boek achterstevoren lezen
A: Because it upsets the natural flow of a story  A: Omdat het de natuurlijke gang uit het verhaal haalt
Q: Why is top-posting annoying?                   Q: Waarom is Top-posting zo irritant?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210625/55887d97/attachment.html>

From frans at fransdb.nl  Fri Jun 25 18:11:02 2021
From: frans at fransdb.nl (Frans de Boer)
Date: Fri, 25 Jun 2021 20:11:02 +0200
Subject: ICC and printers - wrong list
In-Reply-To: <d0c1cab0-a9b0-f8cd-610b-4e5568d3d4b5@fransdb.nl>
References: <d0c1cab0-a9b0-f8cd-610b-4e5568d3d4b5@fransdb.nl>
Message-ID: <716104de-ba38-0666-7f05-5918c2f632ec@fransdb.nl>

On 6/25/21 8:08 PM, Frans de Boer wrote:
> LS,
>
> I keep getting the message "
>
> You need Gnome Color Management installed in order to calibrate 
> devices" when I select Color Management in the System Setting under KDE.
>
> The thing is, colord as well as the gnome-color-manager are both 
> installed. So, why does it not see the the latter program?
>
> Anybody experience with it?
>
> Regards, Frans.
>
> -- 
> A: Yes, just like that                            A: Ja, net zo
> Q: Oh, Just like reading a book backwards         Q: Oh, net als een boek achterstevoren lezen
> A: Because it upsets the natural flow of a story  A: Omdat het de natuurlijke gang uit het verhaal haalt
> Q: Why is top-posting annoying?                   Q: Waarom is Top-posting zo irritant?
Sorry, wrong list :)


From levitte at openssl.org  Fri Jun 25 20:26:52 2021
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 25 Jun 2021 22:26:52 +0200
Subject: email notice [was: Not getting some macros for FIPS]
In-Reply-To: <d27d3307fff800e484a47bafa2275d8e2c7db572.camel@openssl.org>
References: <SN2PR03MB231908F50B30A224FD08925EA6089@SN2PR03MB2319.namprd03.prod.outlook.com>
 <d27d3307fff800e484a47bafa2275d8e2c7db572.camel@openssl.org>
Message-ID: <871r8pr8qb.wl-levitte@openssl.org>

On Wed, 23 Jun 2021 10:51:05 +0200,
Tomas Mraz wrote:
> 
> On Wed, 2021-06-23 at 08:12 +0000, Kumar Mishra, Sanjeev wrote:
> 
> > Notice: This e-mail together with any attachments may contain
> > information of Ribbon Communications Inc. and its Affiliates that is
> > confidential and/or proprietary for the sole use of the intended
> > recipient. Any review, disclosure, reliance or distribution by others
> > or forwarding without express permission is strictly prohibited. If
> > you are not the intended recipient, please notify the sender
> > immediately and then delete all copies, including any attachments.
> 
> It's a little bit strange to send e-mails with such notices to public
> mailing lists where the intented recipient is _anyone_.

Those notices are a bit amusing, yeah.  Of course, Sanjeev can't be
blamed for this, as we can probably assume that it's a corporate
filter that automagically adds those.

And oh boy!  openssl-users having almost 3000 subscribers, that's
quite a lot of people to chase down and ensure they have destroyed all
copies, I tell ya!  "Good luck" is probably an appropriate response
;-)

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From michel.sales at free.fr  Sat Jun 26 22:46:21 2021
From: michel.sales at free.fr (Michel)
Date: Sun, 27 Jun 2021 00:46:21 +0200
Subject: Can OpenSSL handle multiple authentication mechanisms on the same
 SSL context?
References: <PH0PR10MB4453C71A8514CD044485A6EDE7099@PH0PR10MB4453.namprd10.prod.outlook.com>
 <PH0PR10MB445347F4CDCFDFC34555CB41E7099@PH0PR10MB4453.namprd10.prod.outlook.com>
Message-ID: <003701d76add$16243fb0$426cbf10$@sales@free.fr>

> We are trying to support a server that would support PSK and SRP
authentication mechanisms.
[.]
> Would multiple callbacks for different mechanisms work simultaneously on
the same SSL context?

My quick answer is Yes.

In a recent past I did some [multi-threaded] servers using both SRP and PSK
on the same context and I don't recall having encountered any problem.

I believe it was OpenSSL  1.1.1f using TLS 1.2 under Windows 32bits.

 

Hope it helps,

 

Michel.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210627/1743edce/attachment-0001.html>

From Raffy.Revestual at Emerson.com  Sun Jun 27 18:26:07 2021
From: Raffy.Revestual at Emerson.com (Revestual, Raffy [AUTOSOL/PSS/MNL])
Date: Sun, 27 Jun 2021 18:26:07 +0000
Subject: [EXTERNAL] RE: Can OpenSSL handle multiple authentication
 mechanisms on the same SSL context?
In-Reply-To: <001f01d76ad9$6f075d00$4d161700$@sales@OnLine.fr>
References: <PH0PR10MB4453C71A8514CD044485A6EDE7099@PH0PR10MB4453.namprd10.prod.outlook.com>
 <PH0PR10MB445347F4CDCFDFC34555CB41E7099@PH0PR10MB4453.namprd10.prod.outlook.com>
 <001f01d76ad9$6f075d00$4d161700$@sales@OnLine.fr>
Message-ID: <PH0PR10MB44536C6D6186BA4F6437B3ADE7049@PH0PR10MB4453.namprd10.prod.outlook.com>

Thanks for the reply Michel! Looks like both SRP and PSK could co-exist on the same context.

I also just got this to work. The only quirk that made this work is that I had to set the maximum version of the TLS version to 1.2 from the client side via SSL_CTX_set_max_proto_version. This was a peculiar thing as if the binaries you're using has TLS 1.3 support( I'm on 1.1.1k and knowing SRP doesn't work anymore in 1.3) this might have messed something along the way.

Raffy

From: Michel <michel.sales at OnLine.fr>
Sent: Sunday, June 27, 2021 6:20 AM
To: openssl-users at openssl.org
Cc: Revestual, Raffy [AUTOSOL/PSS/MNL] <Raffy.Revestual at Emerson.com>
Subject: [EXTERNAL] RE: Can OpenSSL handle multiple authentication mechanisms on the same SSL context?


> We are trying to support a server that would support PSK and SRP authentication mechanisms.
[...]
> Would multiple callbacks for different mechanisms work simultaneously on the same SSL context?

My quick answer is Yes.
In a recent past I did some [multi-threaded] servers using both SRP and PSK on the same context and I don't recall having encountered any problem.
I believe it was OpenSSL  1.1.1f using TLS 1.2 under Windows 32bits.

Hope it helps,

Michel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210627/ac05983c/attachment.html>

From marianodaniel at icloud.com  Sun Jun 27 22:28:32 2021
From: marianodaniel at icloud.com (=?utf-8?Q?Mariano_Gedisman-C=C3=B3rdoba?=)
Date: Mon, 28 Jun 2021 00:28:32 +0200
Subject: "Expecting: ANY PRIVATE KEY"
Message-ID: <11D95EB4-9BDD-4820-B52F-476CAA10D6FB@icloud.com>

Hello everyone!
I have googled this error to no avail, but all answers don?t seem to adjust to my particular case, or maybe I?m too novice at figuring it out.

I have this key file:

-----BEGIN OPENSSH PRIVATE KEY??
[key here]
-----END OPENSSH PRIVATE KEY??

I?m trying to use this key in order to log in to my Google cloud instance through browser console, and I get the following error:
"Error: Failed to read key. The key file must be ECDSA or RSA in PEM format. "

I googled how to achieve this, and tried the following on my local machine:
$ openssl rsa -in id_rsa.txt -out id_rsa.pem -outform PEM

Sadly, I run into this error:
unable to load Private Key
56081:error:0906D06C:PEM routines:PEM_read_bio:no start line:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59.60.2/src/crypto/pem/pem_lib.c:648:Expecting: ANY PRIVATE KEY

As I said, Google did throw some clues, but nothing conclusive.
Note: I am running OS X El Cap.

Can anyone point out what am I doing wrong?

Thanks a lot in advance and I wish you a really good week!


From michel.sales at online.fr  Sun Jun 27 23:02:46 2021
From: michel.sales at online.fr (Michel)
Date: Mon, 28 Jun 2021 01:02:46 +0200
Subject: "Expecting: ANY PRIVATE KEY"
In-Reply-To: <11D95EB4-9BDD-4820-B52F-476CAA10D6FB@icloud.com>
References: <11D95EB4-9BDD-4820-B52F-476CAA10D6FB@icloud.com>
Message-ID: <001301d76ba8$8db228a0$a91679e0$@sales@online.fr>

Hi Mariano,

My quick answer : your key file looks like an (old ?) custom *OpenSSH* format that *OpenSSL* cannot read natively.
You should easily find an OpenSSH command or other free tools to converts between formats.

Hope it helps,

Michel.

-----Message d'origine-----
De : openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de Mariano Gedisman-C?rdoba via openssl-users
Envoy? : lundi 28 juin 2021 00:29
? : openssl-users at openssl.org
Objet : "Expecting: ANY PRIVATE KEY"

Hello everyone!
I have googled this error to no avail, but all answers don?t seem to adjust to my particular case, or maybe I?m too novice at figuring it out.

I have this key file:

-----BEGIN OPENSSH PRIVATE KEY??
[key here]
-----END OPENSSH PRIVATE KEY??

I?m trying to use this key in order to log in to my Google cloud instance through browser console, and I get the following error:
"Error: Failed to read key. The key file must be ECDSA or RSA in PEM format. "

I googled how to achieve this, and tried the following on my local machine:
$ openssl rsa -in id_rsa.txt -out id_rsa.pem -outform PEM

Sadly, I run into this error:
unable to load Private Key
56081:error:0906D06C:PEM routines:PEM_read_bio:no start line:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59.60.2/src/crypto/pem/pem_lib.c:648:Expecting: ANY PRIVATE KEY

As I said, Google did throw some clues, but nothing conclusive.
Note: I am running OS X El Cap.

Can anyone point out what am I doing wrong?

Thanks a lot in advance and I wish you a really good week!


From sage at sagegerard.com  Mon Jun 28 03:44:11 2021
From: sage at sagegerard.com (Sage Gerard)
Date: Mon, 28 Jun 2021 03:44:11 +0000
Subject: How did I break this signature library?
Message-ID: <3843ab11-9bb9-68ab-93fa-b69157805ab2@sagegerard.com>

Hi all,

Context: https://github.com/zyrolasting/xiden/blob/master/crypto/crypto.c

I compile this small EVP program into a dynamic library, in which
libcrypto is statically linked. A nearby Racket program needs this
dynamic library for a foreign function interface. I do things in an odd
order, but I am able to create and verify signatures with this setup.

Let's say the library's output signature is in file.sha1.sig, and the
signature was created using the unencoded SHA-1 digest in file.sha1. I
would compare verification output using my host 1.1.1f binary using:

$ <file.sha1 openssl pkeyutl -sign -verify -pubin -inkey public.pem
-sigfile file.sha1.sig

Signature verification fails, so I made a mistake. I'm confused because
the program still (broadly) follows the wiki, and it verifies its own
valid-looking signatures successfully.

Can the library and binary disagree because of different OpenSSL
versions? If not, what did I do to make them produce different output
for the same CHF and keypair?

--
~slg



From marianodaniel at icloud.com  Mon Jun 28 21:00:57 2021
From: marianodaniel at icloud.com (=?utf-8?Q?Mariano_Gedisman-C=C3=B3rdoba?=)
Date: Mon, 28 Jun 2021 23:00:57 +0200
Subject: "Expecting: ANY PRIVATE KEY"
In-Reply-To: <001301d76ba8$8db228a0$a91679e0$@sales@online.fr>
References: <11D95EB4-9BDD-4820-B52F-476CAA10D6FB@icloud.com>
 <001301d76ba8$8db228a0$a91679e0$@sales@online.fr>
Message-ID: <6BCAF27B-0114-4D05-8DBA-29B84B8F39D8@icloud.com>


> On 28.06.2021, at 01:02, Michel <michel.sales at online.fr> wrote:
> 
> Hi Mariano,
> 
> My quick answer : your key file looks like an (old ?) custom *OpenSSH* format that *OpenSSL* cannot read natively.
> You should easily find an OpenSSH command or other free tools to converts between formats.
> 
> Hope it helps,
> 
> Michel.
> 

Hello Michel! Thank you for your prompt response. I will follow your advice. I did try some OpenSSH options before (ssh-keygen -i and such) but kept getting errors.

Reason why I?m so insistent is because I got locked out from my VM for some odd reason, and all contingencies do not seem to work, so I guess I would try to gain access through cloud console, and also learn from this experience.

I will dig more into the OpenSSH side of things. Thanks again!

--Mariano





> -----Message d'origine-----
> De : openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de Mariano Gedisman-C?rdoba via openssl-users
> Envoy? : lundi 28 juin 2021 00:29
> ? : openssl-users at openssl.org
> Objet : "Expecting: ANY PRIVATE KEY"
> 
> Hello everyone!
> I have googled this error to no avail, but all answers don?t seem to adjust to my particular case, or maybe I?m too novice at figuring it out.
> 
> I have this key file:
> 
> -----BEGIN OPENSSH PRIVATE KEY??
> [key here]
> -----END OPENSSH PRIVATE KEY??
> 
> I?m trying to use this key in order to log in to my Google cloud instance through browser console, and I get the following error:
> "Error: Failed to read key. The key file must be ECDSA or RSA in PEM format. "
> 
> I googled how to achieve this, and tried the following on my local machine:
> $ openssl rsa -in id_rsa.txt -out id_rsa.pem -outform PEM
> 
> Sadly, I run into this error:
> unable to load Private Key
> 56081:error:0906D06C:PEM routines:PEM_read_bio:no start line:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59.60.2/src/crypto/pem/pem_lib.c:648:Expecting: ANY PRIVATE KEY
> 
> As I said, Google did throw some clues, but nothing conclusive.
> Note: I am running OS X El Cap.
> 
> Can anyone point out what am I doing wrong?
> 
> Thanks a lot in advance and I wish you a really good week!
> 


From kevin.lengauer at adnovum.ch  Tue Jun 29 09:29:14 2021
From: kevin.lengauer at adnovum.ch (Kevin Lengauer)
Date: Tue, 29 Jun 2021 09:29:14 +0000
Subject: SM2/3/4 algorithm based TLS connections
Message-ID: <f63a4e38410749db906153be3cad3e5a@adnovum.ch>

Dear openssl-team and users

Is it possible with OpenSSL 1.1.1k to do a TLS handshake using key material and certificate based on SM2/SM3/SM4 assuming I somehow got my hands on such keys/certificates?
I think it is only possible with OpenSSL 3.0 to create them.

After checking the web and the source code of the recent OpenSSL 1.1.1k version I doubt that this is possible and also did not find any corresponding cipher suites.
Is this assumption correct or is there a way to do a TLS1.2 or TLS1.3 handshake with the aforementioned algorithms?
I am aware that the Chinese "GM/T 0024" protocol is not part of OpenSSL (yet) based on this github issue: https://github.com/openssl/openssl/issues/12473

Thanks for any responses and help.
Best regards
Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210629/edff431c/attachment.html>

From david.raingeard at gmail.com  Tue Jun 29 09:58:03 2021
From: david.raingeard at gmail.com (david raingeard)
Date: Tue, 29 Jun 2021 11:58:03 +0200
Subject: Compilation issues
Message-ID: <CAFvDS1Sg-dEj-KvdFNYaNKvbp1C_TGNC5uTeSZKxASmE4HNqEQ@mail.gmail.com>

Hello,

Technically, why prevents openssl 1.1.1g from compiling correctly on some
operating systems like Solaris 2.6, CentOS 7.8,... ?

thank you !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210629/e1edfd2d/attachment.html>

From matt at openssl.org  Tue Jun 29 10:02:29 2021
From: matt at openssl.org (Matt Caswell)
Date: Tue, 29 Jun 2021 11:02:29 +0100
Subject: SM2/3/4 algorithm based TLS connections
In-Reply-To: <f63a4e38410749db906153be3cad3e5a@adnovum.ch>
References: <f63a4e38410749db906153be3cad3e5a@adnovum.ch>
Message-ID: <b1add398-e5c2-dc53-cddd-41e3856412a5@openssl.org>



On 29/06/2021 10:29, Kevin Lengauer wrote:
> Dear openssl-team and users
> 
> Is it possible with OpenSSL 1.1.1k to do a TLS handshake using key 
> material and certificate based on SM2/SM3/SM4 assuming I somehow got my 
> hands on such keys/certificates?
> 
> I think it is only possible with OpenSSL 3.0 to create them.
> 
> After checking the web and the source code of the recent OpenSSL 1.1.1k 
> version I doubt that this is possible and also did not find any 
> corresponding cipher suites.
> 
> Is this assumption correct or is there a way to do a TLS1.2 or TLS1.3 
> handshake with the aforementioned algorithms?

You are correct, there are no suitable ciphersuites and it is not 
possible to add an SM2 based certificate to an SSL_CTX/SSL.


> 
> I am aware that the Chinese ?GM/T 0024? protocol is not part of OpenSSL 
> (yet) based on this github issue: 
> https://github.com/openssl/openssl/issues/12473 
> <https://github.com/openssl/openssl/issues/12473>

Correct.

Matt


From kevin.lengauer at adnovum.ch  Tue Jun 29 10:06:32 2021
From: kevin.lengauer at adnovum.ch (Kevin Lengauer)
Date: Tue, 29 Jun 2021 10:06:32 +0000
Subject: SM2/3/4 algorithm based TLS connections
In-Reply-To: <b1add398-e5c2-dc53-cddd-41e3856412a5@openssl.org>
References: <f63a4e38410749db906153be3cad3e5a@adnovum.ch>,
 <b1add398-e5c2-dc53-cddd-41e3856412a5@openssl.org>
Message-ID: <E1C77AA8-1091-4ABF-88D4-5970D5078C01@adnovum.ch>

Dear Matt

Thank you for the quick reply and confirmation.

Regards
Kevin

> Am 29.06.2021 um 12:02 schrieb Matt Caswell <matt at openssl.org>:
> 
> ?
> 
>> On 29/06/2021 10:29, Kevin Lengauer wrote:
>> Dear openssl-team and users
>> Is it possible with OpenSSL 1.1.1k to do a TLS handshake using key material and certificate based on SM2/SM3/SM4 assuming I somehow got my hands on such keys/certificates?
>> I think it is only possible with OpenSSL 3.0 to create them.
>> After checking the web and the source code of the recent OpenSSL 1.1.1k version I doubt that this is possible and also did not find any corresponding cipher suites.
>> Is this assumption correct or is there a way to do a TLS1.2 or TLS1.3 handshake with the aforementioned algorithms?
> 
> You are correct, there are no suitable ciphersuites and it is not possible to add an SM2 based certificate to an SSL_CTX/SSL.
> 
> 
>> I am aware that the Chinese ?GM/T 0024? protocol is not part of OpenSSL (yet) based on this github issue: https://github.com/openssl/openssl/issues/12473 <https://github.com/openssl/openssl/issues/12473>
> 
> Correct.
> 
> Matt
> 

From vinod9987 at gmail.com  Tue Jun 29 11:12:29 2021
From: vinod9987 at gmail.com (vinod mg)
Date: Tue, 29 Jun 2021 16:42:29 +0530
Subject: Need help in removing secp521r1 from openssl-1.1.1g and adding
 TLS_GREASE_BA cipher.
Message-ID: <CALLSHhw0g1Nca9vGg3dWeyhvXRUq0C86GiLYouiipqtvFOvqeg@mail.gmail.com>

Hi All,

I am bit a newbie and need some assistance in couple of things -

1) Supress or a way to remove secp521r1 from the currenlty installed
openssl.
2) Add the cipher - "0xbaba   TLS_GREASE_BA   GREASE" like we see in chrome.

I am ok with custom install as well, if above cannot be done with already
installed openssl package. Please share any wiki I can follow to
impliment the same.

~]# openssl ecparam -list_curves

  secp224r1 : NIST/SECG curve over a 224 bit prime field

  secp256k1 : SECG curve over a 256 bit prime field

  secp384r1 : NIST/SECG curve over a 384 bit prime field

  *secp521r1 : NIST/SECG curve over a 521 bit prime field*

  prime256v1: X9.62/SECG curve over a 256 bit prime field

I am using below OS and version-

# cat /etc/redhat-release

Red Hat Enterprise Linux release 8.3 (Ootpa)

# openssl  version -a

OpenSSL 1.1.1g FIPS  21 Apr 2020

built on: Thu Mar 25 16:46:53 2021 UTC

platform: linux-x86_64

options:  bn(64,64) md2(char) rc4(16x,int) des(int) idea(int) blowfish(ptr)

compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -O2 -g -pipe
-Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-Wa,--noexecstack -Wa,--generate-missing-build-notes=yes
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld -DOPENSSL_USE_NODELETE
-DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM
-DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM
-DPOLY1305_ASM -DZLIB -DNDEBUG -DPURIFY -DDEVRANDOM="\"/dev/urandom\""
-DSYSTEM_CIPHERS_FILE="/etc/crypto-policies/back-ends/openssl.config"

OPENSSLDIR: "/etc/pki/tls"

ENGINESDIR: "/usr/lib64/engines-1.1"

Seeding source: os-specific

engines:  rdrand dynamic

Really appriciate your time and help, thanks in advance.

Thanks,
Vinod
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210629/9ce59e1f/attachment-0001.html>

From janjust at nikhef.nl  Tue Jun 29 16:06:45 2021
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Tue, 29 Jun 2021 18:06:45 +0200
Subject: Compilation issues
In-Reply-To: <CAFvDS1Sg-dEj-KvdFNYaNKvbp1C_TGNC5uTeSZKxASmE4HNqEQ@mail.gmail.com>
References: <CAFvDS1Sg-dEj-KvdFNYaNKvbp1C_TGNC5uTeSZKxASmE4HNqEQ@mail.gmail.com>
Message-ID: <0a649e12-4094-08e5-22a6-39796e35467f@nikhef.nl>

On 29/06/21 11:58, david raingeard wrote:
> Hello,
>
> Technically, why prevents openssl 1.1.1g from compiling correctly on some
> operating systems like Solaris 2.6, CentOS 7.8,... ?
>
>
you will have to provide more details - openssl 1.1.1g compiles just 
fine on CentOS 7 (7.9 in my case).

Can't talk about Solaris 2.6 , other than that it has been out of 
support since July 2006.

HTH,

JJK


From david.raingeard at gmail.com  Tue Jun 29 16:31:54 2021
From: david.raingeard at gmail.com (david raingeard)
Date: Tue, 29 Jun 2021 18:31:54 +0200
Subject: Compilation issues
In-Reply-To: <0a649e12-4094-08e5-22a6-39796e35467f@nikhef.nl>
References: <CAFvDS1Sg-dEj-KvdFNYaNKvbp1C_TGNC5uTeSZKxASmE4HNqEQ@mail.gmail.com>
 <0a649e12-4094-08e5-22a6-39796e35467f@nikhef.nl>
Message-ID: <CAFvDS1RomHYxqO-UWe1v6K9ZBYsY2hch2d5Gj7oZ1kzzt2VO=g@mail.gmail.com>

Ok, here it is. It compiled mostly ok (some fixes for solaris 2.6, like
inttypes.h instead of stdint).
The test suite fails (dubious error).

*Tls 1.2 works* just fine (*openssl s_client -connect google.com:443
<http://google.com:443> -tls1_2 -trace*)

but *Tls 1.3 fails* starting when the *ApplicationData *record is received.

I added some log to know what it does. It uses cipher *AES_256_GCM_SHA384*.

It fails in *EVP_DecryptFinal_ex*, as you can see, the 16 bytes don't match.

I compiled OpenSSL with the exact same flags on ubuntu, and it doesn't have
the issue on this os.

crypto/evp/evp_enc.c:590 cipher nid 901
crypto/modes/gcm128.c:1906 ctx->EK0.u[0]=feb43481e257b3
crypto/modes/gcm128.c:1907 ctx->EK0.u[1]=3318fafcfb9e16ff
crypto/modes/gcm128.c:1908 ctx->Xi.u[0]=f8f7981d11c157e0
crypto/modes/gcm128.c:1909 ctx->Xi.u[1]=724b8338c6785f7b
crypto/modes/gcm128.c:1912 after xor:
crypto/modes/gcm128.c:1913 ctx->Xi.u[0]=f8092c2990230053
crypto/modes/gcm128.c:1914 ctx->Xi.u[1]=415379c43de64984
crypto/modes/gcm128.c:1806 CRYPTO_gcm128_memcmp
        len=16
f8^2c
09^7e
2c^a9
29^77
90^80
23^c4
00^72
53^98
41^3b
53^e0
79^0a
c4^08
3d^5e
e6^89
49^c9
84^f9
crypto/modes/gcm128.c:1814 CRYPTO_gcm128_memcmp
crypto/modes/gcm128.c:1932 ret = 255



Here is the full log (sorry) :

bash-3.2# ./openssl s_client -connect google.com:443 -tls1_3 -trace

ssl/ssl_lib.c:823

ssl/ssl_lib.c:825

ssl/ssl_lib.c:653

CONNECTED(00000005)

ssl/ssl_lib.c:653

ssl/record/rec_layer_s3.c:1056

ssl/record/rec_layer_s3.c:1059

ssl/record/rec_layer_s3.c:1062

Sent Record

Header:

  Version = TLS 1.0 (0x301)

  Content Type = Handshake (22)

  Length = 229

ssl/record/rec_layer_s3.c:1067 SSL_TREAT_AS_TLS13(s)=0
s->enc_write_ctx=0x00000000

ssl/record/rec_layer_s3.c:1076

ssl/record/rec_layer_s3.c:1079

    ClientHello, Length=225

      client_version=0x303 (TLS 1.2)

      Random:

        gmt_unix_time=0xEC7463F6

        random_bytes (len=28):
08D00001DEAC51B17E7F98F63D3BB21F3406961A6460434C4BBA5DD0

      session_id (len=32):
FBD7A5070B19BE55FE33E41BD61E55CF6C9485D1915DD42B6FCB95F87E9981B6

      cipher_suites (len=8)

        {0x13, 0x02} TLS_AES_256_GCM_SHA384

        {0x13, 0x03} TLS_CHACHA20_POLY1305_SHA256

        {0x13, 0x01} TLS_AES_128_GCM_SHA256

        {0x00, 0xFF} TLS_EMPTY_RENEGOTIATION_INFO_SCSV

      compression_methods (len=1)

        No Compression (0x00)

      extensions, length = 144

        extension_type=server_name(0), length=15

          0000 - 00 0d 00 00 0a 67 6f 6f-67 6c 65 2e 63 6f 6d   .....
google.com

        extension_type=ec_point_formats(11), length=4

          uncompressed (0)

          ansiX962_compressed_prime (1)

          ansiX962_compressed_char2 (2)

        extension_type=supported_groups(10), length=12

          ecdh_x25519 (29)

          secp256r1 (P-256) (23)

          ecdh_x448 (30)

          secp521r1 (P-521) (25)

          secp384r1 (P-384) (24)

        extension_type=session_ticket(35), length=0

        extension_type=encrypt_then_mac(22), length=0

        extension_type=extended_master_secret(23), length=0

        extension_type=signature_algorithms(13), length=30

          ecdsa_secp256r1_sha256 (0x0403)

          ecdsa_secp384r1_sha384 (0x0503)

          ecdsa_secp521r1_sha512 (0x0603)

          ed25519 (0x0807)

          ed448 (0x0808)

          rsa_pss_pss_sha256 (0x0809)

          rsa_pss_pss_sha384 (0x080a)

          rsa_pss_pss_sha512 (0x080b)

          rsa_pss_rsae_sha256 (0x0804)

          rsa_pss_rsae_sha384 (0x0805)

          rsa_pss_rsae_sha512 (0x0806)

          rsa_pkcs1_sha256 (0x0401)

          rsa_pkcs1_sha384 (0x0501)

          rsa_pkcs1_sha512 (0x0601)

        extension_type=supported_versions(43), length=3

          TLS 1.3 (772)

        extension_type=psk_key_exchange_modes(45), length=2

          psk_dhe_ke (1)

        extension_type=key_share(51), length=38

            NamedGroup: ecdh_x25519 (29)

            key_exchange:  (len=32):
ED28A72CB2111BBB8BB7716D0FB83A4748C884BB462A83D6E1AB156FE0712E3F


ssl/record/rec_layer_s3.c:1310 calling ssl3_get_record

ssl/record/ssl3_record.c:197 ssl3_get_record called

Received Record

Header:

  Version = TLS 1.2 (0x303)

  Content Type = Handshake (22)

  Length = 122

ssl/record/ssl3_record.c:465

ssl/record/ssl3_record.c:497

ssl/record/ssl3_record.c:531

ssl/record/ssl3_record.c:535 ssl version 0x0304 method 0x10000

ssl/record/ssl3_record.c:537 enc_err=1

ssl/record/ssl3_record.c:575

ssl/record/ssl3_record.c:586

ssl/record/ssl3_record.c:655

ssl/record/ssl3_record.c:701

ssl/record/ssl3_record.c:705

ssl/record/ssl3_record.c:721

ssl/record/ssl3_record.c:762

ssl/record/ssl3_record.c:813

ssl/record/ssl3_record.c:827

ssl/record/rec_layer_s3.c:1312

ssl/record/rec_layer_s3.c:1318

ssl/record/rec_layer_s3.c:1320

ssl/record/rec_layer_s3.c:1329

ssl/record/rec_layer_s3.c:1335

ssl/record/rec_layer_s3.c:1341

ssl/record/rec_layer_s3.c:1345

ssl/record/rec_layer_s3.c:1354

ssl/record/rec_layer_s3.c:1360

ssl/record/rec_layer_s3.c:1367

ssl/record/rec_layer_s3.c:1381

ssl/record/rec_layer_s3.c:1389

ssl/record/rec_layer_s3.c:1403

ssl/record/rec_layer_s3.c:1412

ssl/record/rec_layer_s3.c:1422

ssl/record/rec_layer_s3.c:1425

ssl/record/rec_layer_s3.c:1429

ssl/record/rec_layer_s3.c:1443

ssl/record/rec_layer_s3.c:1472

ssl/record/rec_layer_s3.c:1475

ssl/record/rec_layer_s3.c:1481

ssl/record/rec_layer_s3.c:1487

ssl/record/rec_layer_s3.c:1335

ssl/record/rec_layer_s3.c:1341

ssl/record/rec_layer_s3.c:1345

ssl/record/rec_layer_s3.c:1354

ssl/record/rec_layer_s3.c:1360

ssl/record/rec_layer_s3.c:1367

ssl/record/rec_layer_s3.c:1381

ssl/record/rec_layer_s3.c:1389

ssl/record/rec_layer_s3.c:1403

ssl/record/rec_layer_s3.c:1412

ssl/record/rec_layer_s3.c:1422

ssl/record/rec_layer_s3.c:1429

ssl/record/rec_layer_s3.c:1443

ssl/record/rec_layer_s3.c:1472

ssl/record/rec_layer_s3.c:1475

ssl/record/rec_layer_s3.c:1481

ssl/record/rec_layer_s3.c:1487

    ServerHello, Length=118

      server_version=0x303 (TLS 1.2)

      Random:

        gmt_unix_time=0x7F9CA9DE

        random_bytes (len=28):
D6F6EFA5BCBB089010FA1573D92A29ACBFCE84FFE68B6D0736976BE5

      session_id (len=32):
FBD7A5070B19BE55FE33E41BD61E55CF6C9485D1915DD42B6FCB95F87E9981B6

      cipher_suite {0x13, 0x02} TLS_AES_256_GCM_SHA384

      compression_method: No Compression (0x00)

      extensions, length = 46

        extension_type=key_share(51), length=36

            NamedGroup: ecdh_x25519 (29)

            key_exchange:  (len=32):
AB9BEF12592BBE53425F317364F34CDB0076B9B3669B0B3C58BECA5A30F62534

        extension_type=supported_versions(43), length=2

            TLS 1.3 (772)


ssl/statem/statem_lib.c:2004 vent version 0x0304

ssl/record/rec_layer_s3.c:1335

ssl/record/rec_layer_s3.c:1341

ssl/record/rec_layer_s3.c:1310 calling ssl3_get_record

ssl/record/ssl3_record.c:197 ssl3_get_record called

Received Record

Header:

  Version = TLS 1.2 (0x303)

  Content Type = ChangeCipherSpec (20)

  Length = 1

ssl/record/ssl3_record.c:465

ssl/record/ssl3_record.c:493

ssl/record/rec_layer_s3.c:1312

ssl/record/rec_layer_s3.c:1318

ssl/record/rec_layer_s3.c:1320

ssl/record/rec_layer_s3.c:1329

ssl/record/rec_layer_s3.c:1335

ssl/record/rec_layer_s3.c:1341

ssl/record/rec_layer_s3.c:1310 calling ssl3_get_record

ssl/record/ssl3_record.c:197 ssl3_get_record called

Received Record

Header:

  Version = TLS 1.2 (0x303)

  Content Type = ApplicationData (23)

  Length = 4658

ssl/record/ssl3_record.c:465

ssl/record/ssl3_record.c:497

ssl/record/ssl3_record.c:531

ssl/record/ssl3_record.c:535 ssl version 0x0304 method 0x0304

ssl/record/ssl3_record_tls13.c:37

ssl/record/ssl3_record_tls13.c:48

crypto/evp/e_aes.c:3195 aes_gcm_cipher

crypto/evp/e_aes.c:3203 aes_gcm_cipher

crypto/evp/e_aes.c:3210 aes_gcm_cipher

crypto/evp/e_aes.c:3216 aes_gcm_cipher

crypto/evp/e_aes.c:3221 aes_gcm_cipher

crypto/evp/e_aes.c:3347 aes_gcm_cipher

crypto/evp/e_aes.c:3195 aes_gcm_cipher

crypto/evp/e_aes.c:3203 aes_gcm_cipher

crypto/evp/e_aes.c:3210 aes_gcm_cipher

crypto/evp/e_aes.c:3216 aes_gcm_cipher

crypto/evp/e_aes.c:3290 aes_gcm_cipher

crypto/evp/e_aes.c:3320 aes_gcm_cipher

crypto/evp/e_aes.c:3336 aes_gcm_cipher

crypto/evp/e_aes.c:3343 aes_gcm_cipher

crypto/evp/e_aes.c:3345 aes_gcm_cipher

crypto/evp/e_aes.c:3347 aes_gcm_cipher

crypto/evp/evp_enc.c:228

crypto/evp/evp_enc.c:576

crypto/evp/evp_enc.c:587

crypto/evp/evp_enc.c:590 cipher nid 901

crypto/evp/e_aes.c:3195 aes_gcm_cipher

crypto/evp/e_aes.c:3203 aes_gcm_cipher

crypto/evp/e_aes.c:3210 aes_gcm_cipher

crypto/evp/e_aes.c:3216 aes_gcm_cipher

crypto/evp/e_aes.c:3350 aes_gcm_cipher

crypto/evp/e_aes.c:3352 aes_gcm_cipher

crypto/evp/e_aes.c:3358 aes_gcm_cipher

crypto/modes/gcm128.c:1838

crypto/modes/gcm128.c:1843

crypto/modes/gcm128.c:1887

crypto/modes/gcm128.c:1890

crypto/modes/gcm128.c:1896

crypto/modes/gcm128.c:1905

crypto/modes/gcm128.c:1906 ctx->EK0.u[0]=feb43481e257b3

crypto/modes/gcm128.c:1907 ctx->EK0.u[1]=3318fafcfb9e16ff

crypto/modes/gcm128.c:1908 ctx->Xi.u[0]=f8f7981d11c157e0

crypto/modes/gcm128.c:1909 ctx->Xi.u[1]=724b8338c6785f7b

crypto/modes/gcm128.c:1912 after xor:

crypto/modes/gcm128.c:1913 ctx->Xi.u[0]=f8092c2990230053

crypto/modes/gcm128.c:1914 ctx->Xi.u[1]=415379c43de64984

crypto/modes/gcm128.c:1916

crypto/modes/gcm128.c:1806 CRYPTO_gcm128_memcmp

        len=16

f8^2c

09^7e

2c^a9

29^77

90^80

23^c4

00^72

53^98

41^3b

53^e0

79^0a

c4^08

3d^5e

e6^89

49^c9

84^f9

crypto/modes/gcm128.c:1814 CRYPTO_gcm128_memcmp

crypto/modes/gcm128.c:1932 ret = 255

crypto/evp/e_aes.c:3361 aes_gcm_cipher

crypto/evp/evp_enc.c:592

ssl/record/ssl3_record_tls13.c:202

ssl/record/ssl3_record.c:537 enc_err=-1

ssl/record/ssl3_record.c:575

ssl/record/ssl3_record.c:586

ssl/record/ssl3_record.c:655

ssl/record/ssl3_record.c:661

ssl/record/ssl3_record.c:696

ssl/record/ssl3_record_tls13.c:37

ssl/record/ssl3_record_tls13.c:48

ssl/record/rec_layer_s3.c:1056

ssl/record/rec_layer_s3.c:1059

ssl/record/rec_layer_s3.c:1062

Sent Record

Header:

  Version = TLS 1.2 (0x303)

  Content Type = Alert (21)

  Length = 2

ssl/record/rec_layer_s3.c:1067 SSL_TREAT_AS_TLS13(s)=1
s->enc_write_ctx=0x00000000

ssl/record/rec_layer_s3.c:1076

ssl/record/rec_layer_s3.c:1079

    Level=fatal(2), description=bad record mac(20)


ssl/record/rec_layer_s3.c:1312

ssl/record/rec_layer_s3.c:1315

0:error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad
record mac:ssl/record/ssl3_record.c:698:

---

no peer certificate available

---

No client certificate CA names sent

Server Temp Key: X25519, 253 bits

---

SSL handshake has read 4796 bytes and written 241 bytes

Verification: OK

---

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384

Secure Renegotiation IS NOT supported

Compression: NONE

Expansion: NONE

No ALPN negotiated

Early data was not sent

Verify return code: 0 (ok)

-

Le mar. 29 juin 2021 ? 18:06, Jan Just Keijser <janjust at nikhef.nl> a ?crit :

> On 29/06/21 11:58, david raingeard wrote:
> > Hello,
> >
> > Technically, why prevents openssl 1.1.1g from compiling correctly on some
> > operating systems like Solaris 2.6, CentOS 7.8,... ?
> >
> >
> you will have to provide more details - openssl 1.1.1g compiles just
> fine on CentOS 7 (7.9 in my case).
>
> Can't talk about Solaris 2.6 , other than that it has been out of
> support since July 2006.
>
> HTH,
>
> JJK
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210629/dd37bd5a/attachment-0001.html>

From sage at sagegerard.com  Tue Jun 29 21:02:10 2021
From: sage at sagegerard.com (Sage Gerard)
Date: Tue, 29 Jun 2021 21:02:10 +0000
Subject: How did I break this signature library?
In-Reply-To: <3843ab11-9bb9-68ab-93fa-b69157805ab2@sagegerard.com>
References: <3843ab11-9bb9-68ab-93fa-b69157805ab2@sagegerard.com>
Message-ID: <308d5364-9569-3af6-b8cc-08982a10ee7a@sagegerard.com>

Hello,

I recently resubscribed so I'm unsure if this post was emailed back out
to members.

If you saw it and the question was bad, please let me know what I can
simplify or clarify.

Thank you.

On 6/27/21 11:44 PM, Sage Gerard wrote:
> Hi all,
>
> Context: https://github.com/zyrolasting/xiden/blob/master/crypto/crypto.c
>
> I compile this small EVP program into a dynamic library, in which
> libcrypto is statically linked. A nearby Racket program needs this
> dynamic library for a foreign function interface. I do things in an odd
> order, but I am able to create and verify signatures with this setup.
>
> Let's say the library's output signature is in file.sha1.sig, and the
> signature was created using the unencoded SHA-1 digest in file.sha1. I
> would compare verification output using my host 1.1.1f binary using:
>
> $ <file.sha1 openssl pkeyutl -sign -verify -pubin -inkey public.pem
> -sigfile file.sha1.sig
>
> Signature verification fails, so I made a mistake. I'm confused because
> the program still (broadly) follows the wiki, and it verifies its own
> valid-looking signatures successfully.
>
> Can the library and binary disagree because of different OpenSSL
> versions? If not, what did I do to make them produce different output
> for the same CHF and keypair?
>
> --
> ~slg
>
--
~slg



From ppjjvvww at gmail.com  Tue Jun 29 22:23:21 2021
From: ppjjvvww at gmail.com (Paulo Wollny)
Date: Tue, 29 Jun 2021 19:23:21 -0300
Subject: client certificate error
Message-ID: <432b4907-744b-58f0-de50-4a67b4c4bace@gmail.com>

Dear @ll

My environment:

OpenSSL 1.1.1f  31 Mar 2020

Ubuntu 20.04

Server version: Apache/2.4.41 (Ubuntu)
Server built:   2021-06-17T18:27:53

My problem:

connecting to a secure server requiring client certificate, i get the 
following error when presenting my certificate:

ERR_BAD_SSL_CLIENT_AUTH_CERT

It started to fail after the previous one voided and i issued a new one.

CA, the same, server cert, renewed after previous voided.

My server conf:

<VirtualHost *:443>
                 ServerAdmin webmaster at localhost

                 DocumentRoot /home/www/

                 # Available loglevels: trace8, ..., trace1, debug, 
info, notice, warn,
                 # error, crit, alert, emerg.
                 # It is also possible to configure the loglevel for 
particular
                 # modules, e.g.
                 #LogLevel info ssl:warn

                 ErrorLog /var/log/apache2/ssl_engine.log
                 LogLevel debug

                 #ErrorLog ${APACHE_LOG_DIR}/error.log
                 CustomLog ${APACHE_LOG_DIR}/access.log combined

                 # For most configuration files from conf-available/, 
which are
                 # enabled or disabled at a global level, it is possible to
                 # include a line for only one particular virtual host. 
For example the
                 # following line enables the CGI configuration for this 
host only
                 # after it has been globally disabled with "a2disconf".
                 #Include conf-available/serve-cgi-bin.conf

                 #   SSL Engine Switch:
                 #   Enable/Disable SSL for this virtual host.
                 SSLEngine on

                 SSLProtocol all -SSLv3 -TLSv1.3
                 #SSLProtocol all
                 #SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.3
                 SSLHonorCipherOrder on
                 SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM 
EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 
EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW 
!3DES !MD5 !EXP !PSK !SRP !DSS"

                 #   A self-signed (snakeoil) certificate can be created 
by installing
                 #   the ssl-cert package. See
                 #   /usr/share/doc/apache2/README.Debian.gz for more info.
                 #   If both key and certificate are stored in the same 
file, only the
                 #   SSLCertificateFile directive is needed.
                 SSLCertificateFile /etc/ssl/private/server.crt
                 SSLCertificateKeyFile /etc/ssl/private/server.key
                 SSLCACertificatePath /etc/ssl/certs/
                 #SSLCACertificateFile 
/etc/ssl/certs/PSign_TrustCenter_Root_CA-I.pem
                 SSLCACertificateFile /etc/ssl/private/fullchain.crt


                 #   Server Certificate Chain:
                 #   Point SSLCertificateChainFile at a file containing the
                 #   concatenation of PEM encoded CA certificates which 
form the
                 #   certificate chain for the server certificate. 
Alternatively
                 #   the referenced file can be the same as 
SSLCertificateFile
                 #   when the CA certificates are directly appended to 
the server
                 #   certificate for convinience.
                 #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt

                 #   Certificate Authority (CA):
                 #   Set the CA certificate verification path where to 
find CA
                 #   certificates for client authentication or 
alternatively one
                 #   huge file containing all of them (file must be PEM 
encoded)
                 #   Note: Inside SSLCACertificatePath you need hash 
symlinks
                 #                to point to the certificate files. Use 
the provided
                 #                Makefile to update the hash symlinks 
after changes.
                 #SSLCACertificatePath /etc/ssl/certs/
                 #SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt

                 #   Certificate Revocation Lists (CRL):
                 #   Set the CA revocation path where to find CA CRLs 
for client
                 #   authentication or alternatively one huge file 
containing all
                 #   of them (file must be PEM encoded)
                 #   Note: Inside SSLCARevocationPath you need hash symlinks
                 #                to point to the certificate files. Use 
the provided
                 #                Makefile to update the hash symlinks 
after changes.
                 #SSLCARevocationPath /etc/apache2/ssl.crl/
                 #SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl

                 #   Client Authentication (Type):
                 #   Client certificate verification type and depth. 
Types are
                 #   none, optional, require and optional_no_ca.  Depth is a
                 #   number which specifies how deeply to verify the 
certificate
                 #   issuer chain before deciding the certificate is not 
valid.
                 #SSLVerifyClient require
                 #SSLVerifyDepth  10

                 #   SSL Engine Options:
                 #   Set various options for the SSL engine.
                 #   o FakeBasicAuth:
                 #        Translate the client X.509 into a Basic 
Authorisation.  This means that
                 #        the standard Auth/DBMAuth methods can be used 
for access control.  The
                 #        user name is the `one line' version of the 
client's X.509 certificate.
                 #        Note that no password is obtained from the 
user. Every entry in the user
                 #        file needs this password: `xxj31ZMTZzkVA'.
                 #   o ExportCertData:
                 #        This exports two additional environment 
variables: SSL_CLIENT_CERT and
                 #        SSL_SERVER_CERT. These contain the PEM-encoded 
certificates of the
                 #        server (always existing) and the client (only 
existing when client
                 #        authentication is used). This can be used to 
import the certificates
                 #        into CGI scripts.
                 #   o StdEnvVars:
                 #        This exports the standard SSL/TLS related 
`SSL_*' environment variables.
                 #        Per default this exportation is switched off 
for performance reasons,
                 #        because the extraction step is an expensive 
operation and is usually
                 #        useless for serving static content. So one 
usually enables the
                 #        exportation for CGI and SSI requests only.
                 #   o OptRenegotiate:
                 #        This enables optimized SSL connection 
renegotiation handling when SSL
                 #        directives are used in per-directory context.
                 #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
                 <FilesMatch "\.(cgi|shtml|phtml|php)$">
                                 SSLOptions +StdEnvVars
                 </FilesMatch>
                 <Directory /usr/lib/cgi-bin>
                                 SSLOptions +StdEnvVars
                 </Directory>

                 #   SSL Protocol Adjustments:
                 #   The safe and default but still SSL/TLS standard 
compliant shutdown
                 #   approach is that mod_ssl sends the close notify 
alert but doesn't wait for
                 #   the close notify alert from client. When you need a 
different shutdown
                 #   approach you can use one of the following variables:
                 #   o ssl-unclean-shutdown:
                 #        This forces an unclean shutdown when the 
connection is closed, i.e. no
                 #        SSL close notify alert is send or allowed to 
received.  This violates
                 #        the SSL/TLS standard but is needed for some 
brain-dead browsers. Use
                 #        this when you receive I/O errors because of 
the standard approach where
                 #        mod_ssl sends the close notify alert.
                 #   o ssl-accurate-shutdown:
                 #        This forces an accurate shutdown when the 
connection is closed, i.e. a
                 #        SSL close notify alert is send and mod_ssl 
waits for the close notify
                 #        alert of the client. This is 100% SSL/TLS 
standard compliant, but in
                 #        practice often causes hanging connections with 
brain-dead browsers. Use
                 #        this only for browsers where you know that 
their SSL implementation
                 #        works correctly.
                 #   Notice: Most problems of broken clients are also 
related to the HTTP
                 #   keep-alive facility, so you usually additionally 
want to disable
                 #   keep-alive for those clients, too. Use variable 
"nokeepalive" for this.
                 #   Similarly, one has to force some clients to use 
HTTP/1.0 to workaround
                 #   their broken HTTP/1.1 implementation. Use variables 
"downgrade-1.0" and
                 #   "force-response-1.0" for this.
                 # BrowserMatch "MSIE [2-6]" \
                 #               nokeepalive ssl-unclean-shutdown \
                 #               downgrade-1.0 force-response-1.0


# private
        Alias /ssl/ /home/www/html-ssl-certs/
        <location /ssl/>
              SSLVerifyClient require
              SSLVerifyDepth       5
              SSLOptions +StdEnvVars +ExportCertData
              AuthType Basic
              AuthName "Protected User access required"
              AuthUserFile /etc/apache2/.htpasswd
              Require valid-user
              DirectoryIndex phpinfo.php
              DirectoryIndexRedirect permanent
              Order deny,allow
              Allow from all
       </location>



</VirtualHost>



log shows:

[Tue Jun 29 19:15:43.024571 2021] [socache_shmcb:debug] [pid 241359] 
mod_socache_shmcb.c(530): AH00835: socache_shmcb_retrieve (0xae -> 
subcache 14)
[Tue Jun 29 19:15:43.024597 2021] [socache_shmcb:debug] [pid 241359] 
mod_socache_shmcb.c(916): AH00851: shmcb_subcache_retrieve found no match
[Tue Jun 29 19:15:43.024605 2021] [socache_shmcb:debug] [pid 241359] 
mod_socache_shmcb.c(541): AH00836: leaving socache_shmcb_retrieve 
successfully
[Tue Jun 29 19:15:43.024632 2021] [ssl:debug] [pid 241359] 
ssl_engine_kernel.c(2387): [client 127.0.0.1:57022] AH02044: No matching 
SSL virtual host for servername localhost found (using default/first 
virtual host)
[Tue Jun 29 19:15:43.024700 2021] [ssl:debug] [pid 241359] 
ssl_engine_kernel.c(2387): [client 127.0.0.1:57022] AH02044: No matching 
SSL virtual host for servername localhost found (using default/first 
virtual host)
[Tue Jun 29 19:15:43.024711 2021] [core:debug] [pid 241359] 
protocol.c(2313): [client 127.0.0.1:57022] AH03155: select protocol from 
, choices=h2,http/1.1 for server hp15pw
[Tue Jun 29 19:15:43.026143 2021] [ssl:info] [pid 241355] [client 
127.0.0.1:57024] AH01964: Connection to child 0 established (server 
hp15pw:443)
[Tue Jun 29 19:15:43.026407 2021] [socache_shmcb:debug] [pid 241355] 
mod_socache_shmcb.c(530): AH00835: socache_shmcb_retrieve (0x07 -> 
subcache 7)
[Tue Jun 29 19:15:43.026424 2021] [socache_shmcb:debug] [pid 241355] 
mod_socache_shmcb.c(916): AH00851: shmcb_subcache_retrieve found no match
[Tue Jun 29 19:15:43.026429 2021] [socache_shmcb:debug] [pid 241355] 
mod_socache_shmcb.c(541): AH00836: leaving socache_shmcb_retrieve 
successfully
[Tue Jun 29 19:15:43.026449 2021] [ssl:debug] [pid 241355] 
ssl_engine_kernel.c(2387): [client 127.0.0.1:57024] AH02044: No matching 
SSL virtual host for servername localhost found (using default/first 
virtual host)
[Tue Jun 29 19:15:43.026489 2021] [ssl:debug] [pid 241355] 
ssl_engine_kernel.c(2387): [client 127.0.0.1:57024] AH02044: No matching 
SSL virtual host for servername localhost found (using default/first 
virtual host)
[Tue Jun 29 19:15:43.026497 2021] [core:debug] [pid 241355] 
protocol.c(2313): [client 127.0.0.1:57024] AH03155: select protocol from 
, choices=h2,http/1.1 for server hp15pw
[Tue Jun 29 19:15:43.321198 2021] [ssl:debug] [pid 241359] 
ssl_engine_kernel.c(2254): [client 127.0.0.1:57022] AH02041: Protocol: 
TLSv1.2, Cipher: ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)
[Tue Jun 29 19:15:43.323322 2021] [ssl:debug] [pid 241359] 
ssl_engine_kernel.c(415): [client 127.0.0.1:57022] AH02034: Initial 
(No.1) HTTPS request received for child 4 (server hp15pw:443)
[Tue Jun 29 19:15:43.323413 2021] [ssl:debug] [pid 241355] 
ssl_engine_kernel.c(2254): [client 127.0.0.1:57024] AH02041: Protocol: 
TLSv1.2, Cipher: ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)
[Tue Jun 29 19:15:43.323733 2021] [ssl:debug] [pid 241359] 
ssl_engine_kernel.c(782): [client 127.0.0.1:57022] AH02255: Changed 
client verification type will force renegotiation
[Tue Jun 29 19:15:43.323837 2021] [ssl:info] [pid 241359] [client 
127.0.0.1:57022] AH02221: Requesting connection re-negotiation
[Tue Jun 29 19:15:43.323893 2021] [ssl:debug] [pid 241359] 
ssl_engine_kernel.c(984): [client 127.0.0.1:57022] AH02260: Performing 
full renegotiation: complete handshake protocol (client does support 
secure renegotiation)
[Tue Jun 29 19:15:43.324148 2021] [ssl:debug] [pid 241359] 
ssl_engine_kernel.c(2254): [client 127.0.0.1:57022] AH02041: Protocol: 
TLSv1.2, Cipher: ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)
[Tue Jun 29 19:15:43.324265 2021] [ssl:info] [pid 241359] [client 
127.0.0.1:57022] AH02226: Awaiting re-negotiation handshake
[Tue Jun 29 19:15:43.324869 2021] [ssl:debug] [pid 241359] 
ssl_engine_kernel.c(2387): [client 127.0.0.1:57022] AH02044: No matching 
SSL virtual host for servername localhost found (using default/first 
virtual host)
[Tue Jun 29 19:15:43.331104 2021] [ssl:error] [pid 241359] [client 
127.0.0.1:57022] AH02261: Re-negotiation handshake failed
[Tue Jun 29 19:15:43.331256 2021] [ssl:debug] [pid 241359] 
ssl_engine_io.c(1368): (70014)End of file found: [client 
127.0.0.1:57022] AH02007: SSL handshake interrupted by system [Hint: 
Stop button pressed in browser?!]
[Tue Jun 29 19:15:43.331328 2021] [ssl:info] [pid 241359] [client 
127.0.0.1:57022] AH01998: Connection closed to child 4 with abortive 
shutdown (server hp15pw:443)
[Tue Jun 29 19:15:45.526753 2021] [ssl:info] [pid 241355] (70014)End of 
file found: [client 127.0.0.1:57024] AH01991: SSL input filter read failed.
[Tue Jun 29 19:15:45.527179 2021] [ssl:debug] [pid 241355] 
ssl_engine_io.c(1102): [client 127.0.0.1:57024] AH02001: Connection 
closed to child 0 with standard shutdown (server hp15pw:443)
[Tue Jun 29 19:15:45.537952 2021] [ssl:info] [pid 241357] [client 
127.0.0.1:57026] AH01964: Connection to child 2 established (server 
hp15pw:443)
[Tue Jun 29 19:15:45.538859 2021] [socache_shmcb:debug] [pid 241357] 
mod_socache_shmcb.c(530): AH00835: socache_shmcb_retrieve (0x68 -> 
subcache 8)
[Tue Jun 29 19:15:45.538910 2021] [socache_shmcb:debug] [pid 241357] 
mod_socache_shmcb.c(916): AH00851: shmcb_subcache_retrieve found no match
[Tue Jun 29 19:15:45.538929 2021] [socache_shmcb:debug] [pid 241357] 
mod_socache_shmcb.c(541): AH00836: leaving socache_shmcb_retrieve 
successfully
[Tue Jun 29 19:15:45.538994 2021] [ssl:debug] [pid 241357] 
ssl_engine_kernel.c(2387): [client 127.0.0.1:57026] AH02044: No matching 
SSL virtual host for servername localhost found (using default/first 
virtual host)
[Tue Jun 29 19:15:45.539162 2021] [ssl:debug] [pid 241357] 
ssl_engine_kernel.c(2387): [client 127.0.0.1:57026] AH02044: No matching 
SSL virtual host for servername localhost found (using default/first 
virtual host)
[Tue Jun 29 19:15:45.539188 2021] [core:debug] [pid 241357] 
protocol.c(2313): [client 127.0.0.1:57026] AH03155: select protocol from 
, choices=h2,http/1.1 for server hp15pw
[Tue Jun 29 19:15:45.574552 2021] [ssl:debug] [pid 241357] 
ssl_engine_kernel.c(2254): [client 127.0.0.1:57026] AH02041: Protocol: 
TLSv1.2, Cipher: ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)
[Tue Jun 29 19:15:45.589868 2021] [ssl:debug] [pid 241357] 
ssl_engine_kernel.c(415): [client 127.0.0.1:57026] AH02034: Initial 
(No.1) HTTPS request received for child 2 (server hp15pw:443)
[Tue Jun 29 19:15:45.590043 2021] [ssl:debug] [pid 241357] 
ssl_engine_kernel.c(782): [client 127.0.0.1:57026] AH02255: Changed 
client verification type will force renegotiation
[Tue Jun 29 19:15:45.590051 2021] [ssl:info] [pid 241357] [client 
127.0.0.1:57026] AH02221: Requesting connection re-negotiation
[Tue Jun 29 19:15:45.590124 2021] [ssl:debug] [pid 241357] 
ssl_engine_kernel.c(984): [client 127.0.0.1:57026] AH02260: Performing 
full renegotiation: complete handshake protocol (client does support 
secure renegotiation)
[Tue Jun 29 19:15:45.590251 2021] [ssl:debug] [pid 241357] 
ssl_engine_kernel.c(2254): [client 127.0.0.1:57026] AH02041: Protocol: 
TLSv1.2, Cipher: ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)
[Tue Jun 29 19:15:45.590261 2021] [ssl:info] [pid 241357] [client 
127.0.0.1:57026] AH02226: Awaiting re-negotiation handshake
[Tue Jun 29 19:15:45.590535 2021] [ssl:debug] [pid 241357] 
ssl_engine_kernel.c(2387): [client 127.0.0.1:57026] AH02044: No matching 
SSL virtual host for servername localhost found (using default/first 
virtual host)
[Tue Jun 29 19:15:45.592237 2021] [socache_shmcb:debug] [pid 241357] 
mod_socache_shmcb.c(555): AH00837: socache_shmcb_remove (0x4c -> 
subcache 12)
[Tue Jun 29 19:15:45.592290 2021] [socache_shmcb:debug] [pid 241357] 
mod_socache_shmcb.c(570): AH00839: leaving socache_shmcb_remove successfully
[Tue Jun 29 19:15:45.592363 2021] [ssl:error] [pid 241357] [client 
127.0.0.1:57026] AH02261: Re-negotiation handshake failed
[Tue Jun 29 19:15:45.592456 2021] [ssl:error] [pid 241357] SSL Library 
Error: error:1417C0C7:SSL routines:tls_process_client_certificate:peer 
did not return a certificate -- No CAs known to server for verification?
[Tue Jun 29 19:15:45.592643 2021] [ssl:debug] [pid 241357] 
ssl_engine_io.c(1368): [client 127.0.0.1:57026] AH02007: SSL handshake 
interrupted by system [Hint: Stop button pressed in browser?!]
[Tue Jun 29 19:15:45.592662 2021] [ssl:info] [pid 241357] [client 
127.0.0.1:57026] AH01998: Connection closed to child 2 with abortive 
shutdown (server hp15pw:443)
root at hp15pw:/var/log/apache2#

Any cue? I'm not being able to find out what is wrong.

Thx in advance.




From jeansfirefox741 at icloud.com  Wed Jun 30 02:41:01 2021
From: jeansfirefox741 at icloud.com (Jean Sweeny)
Date: Tue, 29 Jun 2021 22:41:01 -0400
Subject: Hi
Message-ID: <DE08F767-FF08-4486-991C-FAEF16C43B69@icloud.com>


From janjust at nikhef.nl  Wed Jun 30 08:32:58 2021
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Wed, 30 Jun 2021 10:32:58 +0200
Subject: client certificate error
In-Reply-To: <432b4907-744b-58f0-de50-4a67b4c4bace@gmail.com>
References: <432b4907-744b-58f0-de50-4a67b4c4bace@gmail.com>
Message-ID: <4f3662a8-6ffb-6040-9779-1fddb30bcaff@nikhef.nl>

Hi,

On 30/06/21 00:23, Paulo Wollny wrote:
> Dear @ll
>
> My environment:
>
> OpenSSL 1.1.1f? 31 Mar 2020
>
> Ubuntu 20.04
>
> Server version: Apache/2.4.41 (Ubuntu)
> Server built:?? 2021-06-17T18:27:53
>
> My problem:
>
> connecting to a secure server requiring client certificate, i get the 
> following error when presenting my certificate:
>
> ERR_BAD_SSL_CLIENT_AUTH_CERT
>
> It started to fail after the previous one voided and i issued a new one.
>
> CA, the same, server cert, renewed after previous voided.
>

this is an apache/mod_ssl issue and has little to do with openssl; from 
reading the logs the lines

[Tue Jun 29 19:15:45.592363 2021] [ssl:error] [pid 241357] [client 
127.0.0.1:57026] AH02261: Re-negotiation handshake failed

look suspicious - it means your client is connecting from 127.0.0.1 and 
your server is also listening on 127.0.0.1 ; is this really what you 
have in mind?

But again, this is an apache httpd/mod_sssl issue and does not belong on 
this list.

JJK

> My server conf:
>
> <VirtualHost *:443>
> ??????????????? ServerAdmin webmaster at localhost
>
> ??????????????? DocumentRoot /home/www/
>
> ??????????????? # Available loglevels: trace8, ..., trace1, debug, 
> info, notice, warn,
> ??????????????? # error, crit, alert, emerg.
> ??????????????? # It is also possible to configure the loglevel for 
> particular
> ??????????????? # modules, e.g.
> ??????????????? #LogLevel info ssl:warn
>
> ??????????????? ErrorLog /var/log/apache2/ssl_engine.log
> ??????????????? LogLevel debug
>
> ??????????????? #ErrorLog ${APACHE_LOG_DIR}/error.log
> ??????????????? CustomLog ${APACHE_LOG_DIR}/access.log combined
>
> ??????????????? # For most configuration files from conf-available/, 
> which are
> ??????????????? # enabled or disabled at a global level, it is 
> possible to
> ??????????????? # include a line for only one particular virtual host. 
> For example the
> ??????????????? # following line enables the CGI configuration for 
> this host only
> ??????????????? # after it has been globally disabled with "a2disconf".
> ??????????????? #Include conf-available/serve-cgi-bin.conf
>
> ??????????????? #?? SSL Engine Switch:
> ??????????????? #?? Enable/Disable SSL for this virtual host.
> ??????????????? SSLEngine on
>
> ??????????????? SSLProtocol all -SSLv3 -TLSv1.3
> ??????????????? #SSLProtocol all
> ??????????????? #SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.3
> ??????????????? SSLHonorCipherOrder on
> ??????????????? SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM 
> EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 
> EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW 
> !3DES !MD5 !EXP !PSK !SRP !DSS"
>
> ??????????????? #?? A self-signed (snakeoil) certificate can be 
> created by installing
> ??????????????? #?? the ssl-cert package. See
> ??????????????? #?? /usr/share/doc/apache2/README.Debian.gz for more 
> info.
> ??????????????? #?? If both key and certificate are stored in the same 
> file, only the
> ??????????????? #?? SSLCertificateFile directive is needed.
> ??????????????? SSLCertificateFile /etc/ssl/private/server.crt
> ??????????????? SSLCertificateKeyFile /etc/ssl/private/server.key
> ??????????????? SSLCACertificatePath /etc/ssl/certs/
> ??????????????? #SSLCACertificateFile 
> /etc/ssl/certs/PSign_TrustCenter_Root_CA-I.pem
> ??????????????? SSLCACertificateFile /etc/ssl/private/fullchain.crt
>
>
> ??????????????? #?? Server Certificate Chain:
> ??????????????? #?? Point SSLCertificateChainFile at a file containing 
> the
> ??????????????? #?? concatenation of PEM encoded CA certificates which 
> form the
> ??????????????? #?? certificate chain for the server certificate. 
> Alternatively
> ??????????????? #?? the referenced file can be the same as 
> SSLCertificateFile
> ??????????????? #?? when the CA certificates are directly appended to 
> the server
> ??????????????? #?? certificate for convinience.
> ??????????????? #SSLCertificateChainFile 
> /etc/apache2/ssl.crt/server-ca.crt
>
> ??????????????? #?? Certificate Authority (CA):
> ??????????????? #?? Set the CA certificate verification path where to 
> find CA
> ??????????????? #?? certificates for client authentication or 
> alternatively one
> ??????????????? #?? huge file containing all of them (file must be PEM 
> encoded)
> ??????????????? #?? Note: Inside SSLCACertificatePath you need hash 
> symlinks
> ??????????????? #??????????????? to point to the certificate files. 
> Use the provided
> ??????????????? #??????????????? Makefile to update the hash symlinks 
> after changes.
> ??????????????? #SSLCACertificatePath /etc/ssl/certs/
> ??????????????? #SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt
>
> ??????????????? #?? Certificate Revocation Lists (CRL):
> ??????????????? #?? Set the CA revocation path where to find CA CRLs 
> for client
> ??????????????? #?? authentication or alternatively one huge file 
> containing all
> ??????????????? #?? of them (file must be PEM encoded)
> ??????????????? #?? Note: Inside SSLCARevocationPath you need hash 
> symlinks
> ??????????????? #??????????????? to point to the certificate files. 
> Use the provided
> ??????????????? #??????????????? Makefile to update the hash symlinks 
> after changes.
> ??????????????? #SSLCARevocationPath /etc/apache2/ssl.crl/
> ??????????????? #SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl
>
> ??????????????? #?? Client Authentication (Type):
> ??????????????? #?? Client certificate verification type and depth. 
> Types are
> ??????????????? #?? none, optional, require and optional_no_ca. Depth 
> is a
> ??????????????? #?? number which specifies how deeply to verify the 
> certificate
> ??????????????? #?? issuer chain before deciding the certificate is 
> not valid.
> ??????????????? #SSLVerifyClient require
> ??????????????? #SSLVerifyDepth? 10
>
> ??????????????? #?? SSL Engine Options:
> ??????????????? #?? Set various options for the SSL engine.
> ??????????????? #?? o FakeBasicAuth:
> ??????????????? #??????? Translate the client X.509 into a Basic 
> Authorisation.? This means that
> ??????????????? #??????? the standard Auth/DBMAuth methods can be used 
> for access control.? The
> ??????????????? #??????? user name is the `one line' version of the 
> client's X.509 certificate.
> ??????????????? #??????? Note that no password is obtained from the 
> user. Every entry in the user
> ??????????????? #??????? file needs this password: `xxj31ZMTZzkVA'.
> ??????????????? #?? o ExportCertData:
> ??????????????? #??????? This exports two additional environment 
> variables: SSL_CLIENT_CERT and
> ??????????????? #??????? SSL_SERVER_CERT. These contain the 
> PEM-encoded certificates of the
> ??????????????? #??????? server (always existing) and the client (only 
> existing when client
> ??????????????? #??????? authentication is used). This can be used to 
> import the certificates
> ??????????????? #??????? into CGI scripts.
> ??????????????? #?? o StdEnvVars:
> ??????????????? #??????? This exports the standard SSL/TLS related 
> `SSL_*' environment variables.
> ??????????????? #??????? Per default this exportation is switched off 
> for performance reasons,
> ??????????????? #??????? because the extraction step is an expensive 
> operation and is usually
> ??????????????? #??????? useless for serving static content. So one 
> usually enables the
> ??????????????? #??????? exportation for CGI and SSI requests only.
> ??????????????? #?? o OptRenegotiate:
> ??????????????? #??????? This enables optimized SSL connection 
> renegotiation handling when SSL
> ??????????????? #??????? directives are used in per-directory context.
> ??????????????? #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
> ??????????????? <FilesMatch "\.(cgi|shtml|phtml|php)$">
> ??????????????????????????????? SSLOptions +StdEnvVars
> ??????????????? </FilesMatch>
> ??????????????? <Directory /usr/lib/cgi-bin>
> ??????????????????????????????? SSLOptions +StdEnvVars
> ??????????????? </Directory>
>
> ??????????????? #?? SSL Protocol Adjustments:
> ??????????????? #?? The safe and default but still SSL/TLS standard 
> compliant shutdown
> ??????????????? #?? approach is that mod_ssl sends the close notify 
> alert but doesn't wait for
> ??????????????? #?? the close notify alert from client. When you need 
> a different shutdown
> ??????????????? #?? approach you can use one of the following variables:
> ??????????????? #?? o ssl-unclean-shutdown:
> ??????????????? #??????? This forces an unclean shutdown when the 
> connection is closed, i.e. no
> ??????????????? #??????? SSL close notify alert is send or allowed to 
> received.? This violates
> ??????????????? #??????? the SSL/TLS standard but is needed for some 
> brain-dead browsers. Use
> ??????????????? #??????? this when you receive I/O errors because of 
> the standard approach where
> ??????????????? #??????? mod_ssl sends the close notify alert.
> ??????????????? #?? o ssl-accurate-shutdown:
> ??????????????? #??????? This forces an accurate shutdown when the 
> connection is closed, i.e. a
> ??????????????? #??????? SSL close notify alert is send and mod_ssl 
> waits for the close notify
> ??????????????? #??????? alert of the client. This is 100% SSL/TLS 
> standard compliant, but in
> ??????????????? #??????? practice often causes hanging connections 
> with brain-dead browsers. Use
> ??????????????? #??????? this only for browsers where you know that 
> their SSL implementation
> ??????????????? #??????? works correctly.
> ??????????????? #?? Notice: Most problems of broken clients are also 
> related to the HTTP
> ??????????????? #?? keep-alive facility, so you usually additionally 
> want to disable
> ??????????????? #?? keep-alive for those clients, too. Use variable 
> "nokeepalive" for this.
> ??????????????? #?? Similarly, one has to force some clients to use 
> HTTP/1.0 to workaround
> ??????????????? #?? their broken HTTP/1.1 implementation. Use 
> variables "downgrade-1.0" and
> ??????????????? #?? "force-response-1.0" for this.
> ??????????????? # BrowserMatch "MSIE [2-6]" \
> ??????????????? #?????????????? nokeepalive ssl-unclean-shutdown \
> ??????????????? #?????????????? downgrade-1.0 force-response-1.0
>
>
> # private
> ?????? Alias /ssl/ /home/www/html-ssl-certs/
> ?????? <location /ssl/>
> ???????????? SSLVerifyClient require
> ???????????? SSLVerifyDepth?????? 5
> ???????????? SSLOptions +StdEnvVars +ExportCertData
> ???????????? AuthType Basic
> ???????????? AuthName "Protected User access required"
> ???????????? AuthUserFile /etc/apache2/.htpasswd
> ???????????? Require valid-user
> ???????????? DirectoryIndex phpinfo.php
> ???????????? DirectoryIndexRedirect permanent
> ???????????? Order deny,allow
> ???????????? Allow from all
> ????? </location>
>
>
>
> </VirtualHost>
>
>
>
> log shows:
>
> [Tue Jun 29 19:15:43.024571 2021] [socache_shmcb:debug] [pid 241359] 
> mod_socache_shmcb.c(530): AH00835: socache_shmcb_retrieve (0xae -> 
> subcache 14)
> [Tue Jun 29 19:15:43.024597 2021] [socache_shmcb:debug] [pid 241359] 
> mod_socache_shmcb.c(916): AH00851: shmcb_subcache_retrieve found no match
> [Tue Jun 29 19:15:43.024605 2021] [socache_shmcb:debug] [pid 241359] 
> mod_socache_shmcb.c(541): AH00836: leaving socache_shmcb_retrieve 
> successfully
> [Tue Jun 29 19:15:43.024632 2021] [ssl:debug] [pid 241359] 
> ssl_engine_kernel.c(2387): [client 127.0.0.1:57022] AH02044: No 
> matching SSL virtual host for servername localhost found (using 
> default/first virtual host)
> [Tue Jun 29 19:15:43.024700 2021] [ssl:debug] [pid 241359] 
> ssl_engine_kernel.c(2387): [client 127.0.0.1:57022] AH02044: No 
> matching SSL virtual host for servername localhost found (using 
> default/first virtual host)
> [Tue Jun 29 19:15:43.024711 2021] [core:debug] [pid 241359] 
> protocol.c(2313): [client 127.0.0.1:57022] AH03155: select protocol 
> from , choices=h2,http/1.1 for server hp15pw
> [Tue Jun 29 19:15:43.026143 2021] [ssl:info] [pid 241355] [client 
> 127.0.0.1:57024] AH01964: Connection to child 0 established (server 
> hp15pw:443)
> [Tue Jun 29 19:15:43.026407 2021] [socache_shmcb:debug] [pid 241355] 
> mod_socache_shmcb.c(530): AH00835: socache_shmcb_retrieve (0x07 -> 
> subcache 7)
> [Tue Jun 29 19:15:43.026424 2021] [socache_shmcb:debug] [pid 241355] 
> mod_socache_shmcb.c(916): AH00851: shmcb_subcache_retrieve found no match
> [Tue Jun 29 19:15:43.026429 2021] [socache_shmcb:debug] [pid 241355] 
> mod_socache_shmcb.c(541): AH00836: leaving socache_shmcb_retrieve 
> successfully
> [Tue Jun 29 19:15:43.026449 2021] [ssl:debug] [pid 241355] 
> ssl_engine_kernel.c(2387): [client 127.0.0.1:57024] AH02044: No 
> matching SSL virtual host for servername localhost found (using 
> default/first virtual host)
> [Tue Jun 29 19:15:43.026489 2021] [ssl:debug] [pid 241355] 
> ssl_engine_kernel.c(2387): [client 127.0.0.1:57024] AH02044: No 
> matching SSL virtual host for servername localhost found (using 
> default/first virtual host)
> [Tue Jun 29 19:15:43.026497 2021] [core:debug] [pid 241355] 
> protocol.c(2313): [client 127.0.0.1:57024] AH03155: select protocol 
> from , choices=h2,http/1.1 for server hp15pw
> [Tue Jun 29 19:15:43.321198 2021] [ssl:debug] [pid 241359] 
> ssl_engine_kernel.c(2254): [client 127.0.0.1:57022] AH02041: Protocol: 
> TLSv1.2, Cipher: ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)
> [Tue Jun 29 19:15:43.323322 2021] [ssl:debug] [pid 241359] 
> ssl_engine_kernel.c(415): [client 127.0.0.1:57022] AH02034: Initial 
> (No.1) HTTPS request received for child 4 (server hp15pw:443)
> [Tue Jun 29 19:15:43.323413 2021] [ssl:debug] [pid 241355] 
> ssl_engine_kernel.c(2254): [client 127.0.0.1:57024] AH02041: Protocol: 
> TLSv1.2, Cipher: ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)
> [Tue Jun 29 19:15:43.323733 2021] [ssl:debug] [pid 241359] 
> ssl_engine_kernel.c(782): [client 127.0.0.1:57022] AH02255: Changed 
> client verification type will force renegotiation
> [Tue Jun 29 19:15:43.323837 2021] [ssl:info] [pid 241359] [client 
> 127.0.0.1:57022] AH02221: Requesting connection re-negotiation
> [Tue Jun 29 19:15:43.323893 2021] [ssl:debug] [pid 241359] 
> ssl_engine_kernel.c(984): [client 127.0.0.1:57022] AH02260: Performing 
> full renegotiation: complete handshake protocol (client does support 
> secure renegotiation)
> [Tue Jun 29 19:15:43.324148 2021] [ssl:debug] [pid 241359] 
> ssl_engine_kernel.c(2254): [client 127.0.0.1:57022] AH02041: Protocol: 
> TLSv1.2, Cipher: ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)
> [Tue Jun 29 19:15:43.324265 2021] [ssl:info] [pid 241359] [client 
> 127.0.0.1:57022] AH02226: Awaiting re-negotiation handshake
> [Tue Jun 29 19:15:43.324869 2021] [ssl:debug] [pid 241359] 
> ssl_engine_kernel.c(2387): [client 127.0.0.1:57022] AH02044: No 
> matching SSL virtual host for servername localhost found (using 
> default/first virtual host)
> [Tue Jun 29 19:15:43.331104 2021] [ssl:error] [pid 241359] [client 
> 127.0.0.1:57022] AH02261: Re-negotiation handshake failed
> [Tue Jun 29 19:15:43.331256 2021] [ssl:debug] [pid 241359] 
> ssl_engine_io.c(1368): (70014)End of file found: [client 
> 127.0.0.1:57022] AH02007: SSL handshake interrupted by system [Hint: 
> Stop button pressed in browser?!]
> [Tue Jun 29 19:15:43.331328 2021] [ssl:info] [pid 241359] [client 
> 127.0.0.1:57022] AH01998: Connection closed to child 4 with abortive 
> shutdown (server hp15pw:443)
> [Tue Jun 29 19:15:45.526753 2021] [ssl:info] [pid 241355] (70014)End 
> of file found: [client 127.0.0.1:57024] AH01991: SSL input filter read 
> failed.
> [Tue Jun 29 19:15:45.527179 2021] [ssl:debug] [pid 241355] 
> ssl_engine_io.c(1102): [client 127.0.0.1:57024] AH02001: Connection 
> closed to child 0 with standard shutdown (server hp15pw:443)
> [Tue Jun 29 19:15:45.537952 2021] [ssl:info] [pid 241357] [client 
> 127.0.0.1:57026] AH01964: Connection to child 2 established (server 
> hp15pw:443)
> [Tue Jun 29 19:15:45.538859 2021] [socache_shmcb:debug] [pid 241357] 
> mod_socache_shmcb.c(530): AH00835: socache_shmcb_retrieve (0x68 -> 
> subcache 8)
> [Tue Jun 29 19:15:45.538910 2021] [socache_shmcb:debug] [pid 241357] 
> mod_socache_shmcb.c(916): AH00851: shmcb_subcache_retrieve found no match
> [Tue Jun 29 19:15:45.538929 2021] [socache_shmcb:debug] [pid 241357] 
> mod_socache_shmcb.c(541): AH00836: leaving socache_shmcb_retrieve 
> successfully
> [Tue Jun 29 19:15:45.538994 2021] [ssl:debug] [pid 241357] 
> ssl_engine_kernel.c(2387): [client 127.0.0.1:57026] AH02044: No 
> matching SSL virtual host for servername localhost found (using 
> default/first virtual host)
> [Tue Jun 29 19:15:45.539162 2021] [ssl:debug] [pid 241357] 
> ssl_engine_kernel.c(2387): [client 127.0.0.1:57026] AH02044: No 
> matching SSL virtual host for servername localhost found (using 
> default/first virtual host)
> [Tue Jun 29 19:15:45.539188 2021] [core:debug] [pid 241357] 
> protocol.c(2313): [client 127.0.0.1:57026] AH03155: select protocol 
> from , choices=h2,http/1.1 for server hp15pw
> [Tue Jun 29 19:15:45.574552 2021] [ssl:debug] [pid 241357] 
> ssl_engine_kernel.c(2254): [client 127.0.0.1:57026] AH02041: Protocol: 
> TLSv1.2, Cipher: ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)
> [Tue Jun 29 19:15:45.589868 2021] [ssl:debug] [pid 241357] 
> ssl_engine_kernel.c(415): [client 127.0.0.1:57026] AH02034: Initial 
> (No.1) HTTPS request received for child 2 (server hp15pw:443)
> [Tue Jun 29 19:15:45.590043 2021] [ssl:debug] [pid 241357] 
> ssl_engine_kernel.c(782): [client 127.0.0.1:57026] AH02255: Changed 
> client verification type will force renegotiation
> [Tue Jun 29 19:15:45.590051 2021] [ssl:info] [pid 241357] [client 
> 127.0.0.1:57026] AH02221: Requesting connection re-negotiation
> [Tue Jun 29 19:15:45.590124 2021] [ssl:debug] [pid 241357] 
> ssl_engine_kernel.c(984): [client 127.0.0.1:57026] AH02260: Performing 
> full renegotiation: complete handshake protocol (client does support 
> secure renegotiation)
> [Tue Jun 29 19:15:45.590251 2021] [ssl:debug] [pid 241357] 
> ssl_engine_kernel.c(2254): [client 127.0.0.1:57026] AH02041: Protocol: 
> TLSv1.2, Cipher: ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)
> [Tue Jun 29 19:15:45.590261 2021] [ssl:info] [pid 241357] [client 
> 127.0.0.1:57026] AH02226: Awaiting re-negotiation handshake
> [Tue Jun 29 19:15:45.590535 2021] [ssl:debug] [pid 241357] 
> ssl_engine_kernel.c(2387): [client 127.0.0.1:57026] AH02044: No 
> matching SSL virtual host for servername localhost found (using 
> default/first virtual host)
> [Tue Jun 29 19:15:45.592237 2021] [socache_shmcb:debug] [pid 241357] 
> mod_socache_shmcb.c(555): AH00837: socache_shmcb_remove (0x4c -> 
> subcache 12)
> [Tue Jun 29 19:15:45.592290 2021] [socache_shmcb:debug] [pid 241357] 
> mod_socache_shmcb.c(570): AH00839: leaving socache_shmcb_remove 
> successfully
> [Tue Jun 29 19:15:45.592363 2021] [ssl:error] [pid 241357] [client 
> 127.0.0.1:57026] AH02261: Re-negotiation handshake failed
> [Tue Jun 29 19:15:45.592456 2021] [ssl:error] [pid 241357] SSL Library 
> Error: error:1417C0C7:SSL routines:tls_process_client_certificate:peer 
> did not return a certificate -- No CAs known to server for verification?
> [Tue Jun 29 19:15:45.592643 2021] [ssl:debug] [pid 241357] 
> ssl_engine_io.c(1368): [client 127.0.0.1:57026] AH02007: SSL handshake 
> interrupted by system [Hint: Stop button pressed in browser?!]
> [Tue Jun 29 19:15:45.592662 2021] [ssl:info] [pid 241357] [client 
> 127.0.0.1:57026] AH01998: Connection closed to child 2 with abortive 
> shutdown (server hp15pw:443)
> root at hp15pw:/var/log/apache2#
>
> Any cue? I'm not being able to find out what is wrong.
>
> Thx in advance.
>
>
>


From janjust at nikhef.nl  Wed Jun 30 08:42:32 2021
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Wed, 30 Jun 2021 10:42:32 +0200
Subject: Compilation issues
In-Reply-To: <CAFvDS1RomHYxqO-UWe1v6K9ZBYsY2hch2d5Gj7oZ1kzzt2VO=g@mail.gmail.com>
References: <CAFvDS1Sg-dEj-KvdFNYaNKvbp1C_TGNC5uTeSZKxASmE4HNqEQ@mail.gmail.com>
 <0a649e12-4094-08e5-22a6-39796e35467f@nikhef.nl>
 <CAFvDS1RomHYxqO-UWe1v6K9ZBYsY2hch2d5Gj7oZ1kzzt2VO=g@mail.gmail.com>
Message-ID: <f41d4c26-fce9-33b3-5f6f-b57cf8d9dca9@nikhef.nl>

Hi,

On 29/06/21 18:31, david raingeard wrote:
> Ok, here it is. It compiled mostly ok (some fixes for solaris 2.6, 
> like inttypes.h instead of stdint).
> The test suite fails (dubious error).
>
> *Tls 1.2 works* just fine (*openssl s_client -connect google.com:443 
> <http://google.com:443> -tls1_2 -trace*)
>
> but *Tls 1.3 fails* starting when the *ApplicationData *record is 
> received.
>
I'd say this is a local build issue; I just unpacked 1.1.1g on my CentOS 
7.9 box, did a
 ? ./config no-shared
 ? make
 ? make test
then
 ? ./apps/openssl s_client -CAfile /etc/pki/tls/cert.pem -connect 
google.com:443

and got this:

./apps/openssl s_client -CAfile /etc/pki/tls/cert.pem -connect 
google.com:443
CONNECTED(00000003)
depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1
verify return:1
depth=1 C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
verify return:1
depth=0 CN = *.google.com
verify return:1
---
Certificate chain
 ?0 s:CN = *.google.com
 ?? i:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
 ?1 s:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
 ?? i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
 ?2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
 ?? i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
subject=CN = *.google.com

issuer=C = US, O = Google Trust Services LLC, CN = GTS CA 1C3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 6449 bytes and written 392 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---


So no errors, no warnings and it is using TLS 1.3 to connect.
Check your local environment and especially check that
 ? make test
does not give any errors.

HTH,

JJK

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210630/8fcd98ff/attachment-0001.html>

From ppjjvvww at gmail.com  Wed Jun 30 13:22:25 2021
From: ppjjvvww at gmail.com (Paulo Wollny)
Date: Wed, 30 Jun 2021 10:22:25 -0300
Subject: client certificate error
In-Reply-To: <4f3662a8-6ffb-6040-9779-1fddb30bcaff@nikhef.nl>
References: <432b4907-744b-58f0-de50-4a67b4c4bace@gmail.com>
 <4f3662a8-6ffb-6040-9779-1fddb30bcaff@nikhef.nl>
Message-ID: <b7296407-4b84-5818-e0bb-2a07db2e1662@gmail.com>

Hi,

thank you for the answer.

can you please point the right direction for solution, please?

Regarding the "look suspicious - it means your client is connecting from 
127.0.0.1 and your server is also listening on 127.0.0.1 ; is this 
really what you have in mind? "  i'm testin on my local system, having 
apache server and browser (chrome) on the same system.

And yes, the server cetificate have localhost as DNS alias.

Again, thank you so much.

PW

Am 30.06.21 um 05:32 schrieb Jan Just Keijser:
> Hi,
> 
> On 30/06/21 00:23, Paulo Wollny wrote:
>> Dear @ll
>>
>> My environment:
>>
>> OpenSSL 1.1.1f? 31 Mar 2020
>>
>> Ubuntu 20.04
>>
>> Server version: Apache/2.4.41 (Ubuntu)
>> Server built:?? 2021-06-17T18:27:53
>>
>> My problem:
>>
>> connecting to a secure server requiring client certificate, i get the 
>> following error when presenting my certificate:
>>
>> ERR_BAD_SSL_CLIENT_AUTH_CERT
>>
>> It started to fail after the previous one voided and i issued a new one.
>>
>> CA, the same, server cert, renewed after previous voided.
>>
> 
> this is an apache/mod_ssl issue and has little to do with openssl; from 
> reading the logs the lines
> 
> [Tue Jun 29 19:15:45.592363 2021] [ssl:error] [pid 241357] [client 
> 127.0.0.1:57026] AH02261: Re-negotiation handshake failed
> 
> look suspicious - it means your client is connecting from 127.0.0.1 and 
> your server is also listening on 127.0.0.1 ; is this really what you 
> have in mind?
> 
> But again, this is an apache httpd/mod_sssl issue and does not belong on 
> this list.
> 
> JJK
> 
>> My server conf:
>>
>> <VirtualHost *:443>
>> ??????????????? ServerAdmin webmaster at localhost
>>
>> ??????????????? DocumentRoot /home/www/
>>
>> ??????????????? # Available loglevels: trace8, ..., trace1, debug, 
>> info, notice, warn,
>> ??????????????? # error, crit, alert, emerg.
>> ??????????????? # It is also possible to configure the loglevel for 
>> particular
>> ??????????????? # modules, e.g.
>> ??????????????? #LogLevel info ssl:warn
>>
>> ??????????????? ErrorLog /var/log/apache2/ssl_engine.log
>> ??????????????? LogLevel debug
>>
>> ??????????????? #ErrorLog ${APACHE_LOG_DIR}/error.log
>> ??????????????? CustomLog ${APACHE_LOG_DIR}/access.log combined
>>
>> ??????????????? # For most configuration files from conf-available/, 
>> which are
>> ??????????????? # enabled or disabled at a global level, it is 
>> possible to
>> ??????????????? # include a line for only one particular virtual host. 
>> For example the
>> ??????????????? # following line enables the CGI configuration for 
>> this host only
>> ??????????????? # after it has been globally disabled with "a2disconf".
>> ??????????????? #Include conf-available/serve-cgi-bin.conf
>>
>> ??????????????? #?? SSL Engine Switch:
>> ??????????????? #?? Enable/Disable SSL for this virtual host.
>> ??????????????? SSLEngine on
>>
>> ??????????????? SSLProtocol all -SSLv3 -TLSv1.3
>> ??????????????? #SSLProtocol all
>> ??????????????? #SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.3
>> ??????????????? SSLHonorCipherOrder on
>> ??????????????? SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM 
>> EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 
>> EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW 
>> !3DES !MD5 !EXP !PSK !SRP !DSS"
>>
>> ??????????????? #?? A self-signed (snakeoil) certificate can be 
>> created by installing
>> ??????????????? #?? the ssl-cert package. See
>> ??????????????? #?? /usr/share/doc/apache2/README.Debian.gz for more 
>> info.
>> ??????????????? #?? If both key and certificate are stored in the same 
>> file, only the
>> ??????????????? #?? SSLCertificateFile directive is needed.
>> ??????????????? SSLCertificateFile /etc/ssl/private/server.crt
>> ??????????????? SSLCertificateKeyFile /etc/ssl/private/server.key
>> ??????????????? SSLCACertificatePath /etc/ssl/certs/
>> ??????????????? #SSLCACertificateFile 
>> /etc/ssl/certs/PSign_TrustCenter_Root_CA-I.pem
>> ??????????????? SSLCACertificateFile /etc/ssl/private/fullchain.crt
>>
>>
>> ??????????????? #?? Server Certificate Chain:
>> ??????????????? #?? Point SSLCertificateChainFile at a file containing 
>> the
>> ??????????????? #?? concatenation of PEM encoded CA certificates which 
>> form the
>> ??????????????? #?? certificate chain for the server certificate. 
>> Alternatively
>> ??????????????? #?? the referenced file can be the same as 
>> SSLCertificateFile
>> ??????????????? #?? when the CA certificates are directly appended to 
>> the server
>> ??????????????? #?? certificate for convinience.
>> ??????????????? #SSLCertificateChainFile 
>> /etc/apache2/ssl.crt/server-ca.crt
>>
>> ??????????????? #?? Certificate Authority (CA):
>> ??????????????? #?? Set the CA certificate verification path where to 
>> find CA
>> ??????????????? #?? certificates for client authentication or 
>> alternatively one
>> ??????????????? #?? huge file containing all of them (file must be PEM 
>> encoded)
>> ??????????????? #?? Note: Inside SSLCACertificatePath you need hash 
>> symlinks
>> ??????????????? #??????????????? to point to the certificate files. 
>> Use the provided
>> ??????????????? #??????????????? Makefile to update the hash symlinks 
>> after changes.
>> ??????????????? #SSLCACertificatePath /etc/ssl/certs/
>> ??????????????? #SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt
>>
>> ??????????????? #?? Certificate Revocation Lists (CRL):
>> ??????????????? #?? Set the CA revocation path where to find CA CRLs 
>> for client
>> ??????????????? #?? authentication or alternatively one huge file 
>> containing all
>> ??????????????? #?? of them (file must be PEM encoded)
>> ??????????????? #?? Note: Inside SSLCARevocationPath you need hash 
>> symlinks
>> ??????????????? #??????????????? to point to the certificate files. 
>> Use the provided
>> ??????????????? #??????????????? Makefile to update the hash symlinks 
>> after changes.
>> ??????????????? #SSLCARevocationPath /etc/apache2/ssl.crl/
>> ??????????????? #SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl
>>
>> ??????????????? #?? Client Authentication (Type):
>> ??????????????? #?? Client certificate verification type and depth. 
>> Types are
>> ??????????????? #?? none, optional, require and optional_no_ca. Depth 
>> is a
>> ??????????????? #?? number which specifies how deeply to verify the 
>> certificate
>> ??????????????? #?? issuer chain before deciding the certificate is 
>> not valid.
>> ??????????????? #SSLVerifyClient require
>> ??????????????? #SSLVerifyDepth? 10
>>
>> ??????????????? #?? SSL Engine Options:
>> ??????????????? #?? Set various options for the SSL engine.
>> ??????????????? #?? o FakeBasicAuth:
>> ??????????????? #??????? Translate the client X.509 into a Basic 
>> Authorisation.? This means that
>> ??????????????? #??????? the standard Auth/DBMAuth methods can be used 
>> for access control.? The
>> ??????????????? #??????? user name is the `one line' version of the 
>> client's X.509 certificate.
>> ??????????????? #??????? Note that no password is obtained from the 
>> user. Every entry in the user
>> ??????????????? #??????? file needs this password: `xxj31ZMTZzkVA'.
>> ??????????????? #?? o ExportCertData:
>> ??????????????? #??????? This exports two additional environment 
>> variables: SSL_CLIENT_CERT and
>> ??????????????? #??????? SSL_SERVER_CERT. These contain the 
>> PEM-encoded certificates of the
>> ??????????????? #??????? server (always existing) and the client (only 
>> existing when client
>> ??????????????? #??????? authentication is used). This can be used to 
>> import the certificates
>> ??????????????? #??????? into CGI scripts.
>> ??????????????? #?? o StdEnvVars:
>> ??????????????? #??????? This exports the standard SSL/TLS related 
>> `SSL_*' environment variables.
>> ??????????????? #??????? Per default this exportation is switched off 
>> for performance reasons,
>> ??????????????? #??????? because the extraction step is an expensive 
>> operation and is usually
>> ??????????????? #??????? useless for serving static content. So one 
>> usually enables the
>> ??????????????? #??????? exportation for CGI and SSI requests only.
>> ??????????????? #?? o OptRenegotiate:
>> ??????????????? #??????? This enables optimized SSL connection 
>> renegotiation handling when SSL
>> ??????????????? #??????? directives are used in per-directory context.
>> ??????????????? #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
>> ??????????????? <FilesMatch "\.(cgi|shtml|phtml|php)$">
>> ??????????????????????????????? SSLOptions +StdEnvVars
>> ??????????????? </FilesMatch>
>> ??????????????? <Directory /usr/lib/cgi-bin>
>> ??????????????????????????????? SSLOptions +StdEnvVars
>> ??????????????? </Directory>
>>
>> ??????????????? #?? SSL Protocol Adjustments:
>> ??????????????? #?? The safe and default but still SSL/TLS standard 
>> compliant shutdown
>> ??????????????? #?? approach is that mod_ssl sends the close notify 
>> alert but doesn't wait for
>> ??????????????? #?? the close notify alert from client. When you need 
>> a different shutdown
>> ??????????????? #?? approach you can use one of the following variables:
>> ??????????????? #?? o ssl-unclean-shutdown:
>> ??????????????? #??????? This forces an unclean shutdown when the 
>> connection is closed, i.e. no
>> ??????????????? #??????? SSL close notify alert is send or allowed to 
>> received.? This violates
>> ??????????????? #??????? the SSL/TLS standard but is needed for some 
>> brain-dead browsers. Use
>> ??????????????? #??????? this when you receive I/O errors because of 
>> the standard approach where
>> ??????????????? #??????? mod_ssl sends the close notify alert.
>> ??????????????? #?? o ssl-accurate-shutdown:
>> ??????????????? #??????? This forces an accurate shutdown when the 
>> connection is closed, i.e. a
>> ??????????????? #??????? SSL close notify alert is send and mod_ssl 
>> waits for the close notify
>> ??????????????? #??????? alert of the client. This is 100% SSL/TLS 
>> standard compliant, but in
>> ??????????????? #??????? practice often causes hanging connections 
>> with brain-dead browsers. Use
>> ??????????????? #??????? this only for browsers where you know that 
>> their SSL implementation
>> ??????????????? #??????? works correctly.
>> ??????????????? #?? Notice: Most problems of broken clients are also 
>> related to the HTTP
>> ??????????????? #?? keep-alive facility, so you usually additionally 
>> want to disable
>> ??????????????? #?? keep-alive for those clients, too. Use variable 
>> "nokeepalive" for this.
>> ??????????????? #?? Similarly, one has to force some clients to use 
>> HTTP/1.0 to workaround
>> ??????????????? #?? their broken HTTP/1.1 implementation. Use 
>> variables "downgrade-1.0" and
>> ??????????????? #?? "force-response-1.0" for this.
>> ??????????????? # BrowserMatch "MSIE [2-6]" \
>> ??????????????? #?????????????? nokeepalive ssl-unclean-shutdown \
>> ??????????????? #?????????????? downgrade-1.0 force-response-1.0
>>
>>
>> # private
>> ?????? Alias /ssl/ /home/www/html-ssl-certs/
>> ?????? <location /ssl/>
>> ???????????? SSLVerifyClient require
>> ???????????? SSLVerifyDepth?????? 5
>> ???????????? SSLOptions +StdEnvVars +ExportCertData
>> ???????????? AuthType Basic
>> ???????????? AuthName "Protected User access required"
>> ???????????? AuthUserFile /etc/apache2/.htpasswd
>> ???????????? Require valid-user
>> ???????????? DirectoryIndex phpinfo.php
>> ???????????? DirectoryIndexRedirect permanent
>> ???????????? Order deny,allow
>> ???????????? Allow from all
>> ????? </location>
>>
>>
>>
>> </VirtualHost>
>>
>>
>>
>> log shows:
>>
>> [Tue Jun 29 19:15:43.024571 2021] [socache_shmcb:debug] [pid 241359] 
>> mod_socache_shmcb.c(530): AH00835: socache_shmcb_retrieve (0xae -> 
>> subcache 14)
>> [Tue Jun 29 19:15:43.024597 2021] [socache_shmcb:debug] [pid 241359] 
>> mod_socache_shmcb.c(916): AH00851: shmcb_subcache_retrieve found no match
>> [Tue Jun 29 19:15:43.024605 2021] [socache_shmcb:debug] [pid 241359] 
>> mod_socache_shmcb.c(541): AH00836: leaving socache_shmcb_retrieve 
>> successfully
>> [Tue Jun 29 19:15:43.024632 2021] [ssl:debug] [pid 241359] 
>> ssl_engine_kernel.c(2387): [client 127.0.0.1:57022] AH02044: No 
>> matching SSL virtual host for servername localhost found (using 
>> default/first virtual host)
>> [Tue Jun 29 19:15:43.024700 2021] [ssl:debug] [pid 241359] 
>> ssl_engine_kernel.c(2387): [client 127.0.0.1:57022] AH02044: No 
>> matching SSL virtual host for servername localhost found (using 
>> default/first virtual host)
>> [Tue Jun 29 19:15:43.024711 2021] [core:debug] [pid 241359] 
>> protocol.c(2313): [client 127.0.0.1:57022] AH03155: select protocol 
>> from , choices=h2,http/1.1 for server hp15pw
>> [Tue Jun 29 19:15:43.026143 2021] [ssl:info] [pid 241355] [client 
>> 127.0.0.1:57024] AH01964: Connection to child 0 established (server 
>> hp15pw:443)
>> [Tue Jun 29 19:15:43.026407 2021] [socache_shmcb:debug] [pid 241355] 
>> mod_socache_shmcb.c(530): AH00835: socache_shmcb_retrieve (0x07 -> 
>> subcache 7)
>> [Tue Jun 29 19:15:43.026424 2021] [socache_shmcb:debug] [pid 241355] 
>> mod_socache_shmcb.c(916): AH00851: shmcb_subcache_retrieve found no match
>> [Tue Jun 29 19:15:43.026429 2021] [socache_shmcb:debug] [pid 241355] 
>> mod_socache_shmcb.c(541): AH00836: leaving socache_shmcb_retrieve 
>> successfully
>> [Tue Jun 29 19:15:43.026449 2021] [ssl:debug] [pid 241355] 
>> ssl_engine_kernel.c(2387): [client 127.0.0.1:57024] AH02044: No 
>> matching SSL virtual host for servername localhost found (using 
>> default/first virtual host)
>> [Tue Jun 29 19:15:43.026489 2021] [ssl:debug] [pid 241355] 
>> ssl_engine_kernel.c(2387): [client 127.0.0.1:57024] AH02044: No 
>> matching SSL virtual host for servername localhost found (using 
>> default/first virtual host)
>> [Tue Jun 29 19:15:43.026497 2021] [core:debug] [pid 241355] 
>> protocol.c(2313): [client 127.0.0.1:57024] AH03155: select protocol 
>> from , choices=h2,http/1.1 for server hp15pw
>> [Tue Jun 29 19:15:43.321198 2021] [ssl:debug] [pid 241359] 
>> ssl_engine_kernel.c(2254): [client 127.0.0.1:57022] AH02041: Protocol: 
>> TLSv1.2, Cipher: ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)
>> [Tue Jun 29 19:15:43.323322 2021] [ssl:debug] [pid 241359] 
>> ssl_engine_kernel.c(415): [client 127.0.0.1:57022] AH02034: Initial 
>> (No.1) HTTPS request received for child 4 (server hp15pw:443)
>> [Tue Jun 29 19:15:43.323413 2021] [ssl:debug] [pid 241355] 
>> ssl_engine_kernel.c(2254): [client 127.0.0.1:57024] AH02041: Protocol: 
>> TLSv1.2, Cipher: ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)
>> [Tue Jun 29 19:15:43.323733 2021] [ssl:debug] [pid 241359] 
>> ssl_engine_kernel.c(782): [client 127.0.0.1:57022] AH02255: Changed 
>> client verification type will force renegotiation
>> [Tue Jun 29 19:15:43.323837 2021] [ssl:info] [pid 241359] [client 
>> 127.0.0.1:57022] AH02221: Requesting connection re-negotiation
>> [Tue Jun 29 19:15:43.323893 2021] [ssl:debug] [pid 241359] 
>> ssl_engine_kernel.c(984): [client 127.0.0.1:57022] AH02260: Performing 
>> full renegotiation: complete handshake protocol (client does support 
>> secure renegotiation)
>> [Tue Jun 29 19:15:43.324148 2021] [ssl:debug] [pid 241359] 
>> ssl_engine_kernel.c(2254): [client 127.0.0.1:57022] AH02041: Protocol: 
>> TLSv1.2, Cipher: ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)
>> [Tue Jun 29 19:15:43.324265 2021] [ssl:info] [pid 241359] [client 
>> 127.0.0.1:57022] AH02226: Awaiting re-negotiation handshake
>> [Tue Jun 29 19:15:43.324869 2021] [ssl:debug] [pid 241359] 
>> ssl_engine_kernel.c(2387): [client 127.0.0.1:57022] AH02044: No 
>> matching SSL virtual host for servername localhost found (using 
>> default/first virtual host)
>> [Tue Jun 29 19:15:43.331104 2021] [ssl:error] [pid 241359] [client 
>> 127.0.0.1:57022] AH02261: Re-negotiation handshake failed
>> [Tue Jun 29 19:15:43.331256 2021] [ssl:debug] [pid 241359] 
>> ssl_engine_io.c(1368): (70014)End of file found: [client 
>> 127.0.0.1:57022] AH02007: SSL handshake interrupted by system [Hint: 
>> Stop button pressed in browser?!]
>> [Tue Jun 29 19:15:43.331328 2021] [ssl:info] [pid 241359] [client 
>> 127.0.0.1:57022] AH01998: Connection closed to child 4 with abortive 
>> shutdown (server hp15pw:443)
>> [Tue Jun 29 19:15:45.526753 2021] [ssl:info] [pid 241355] (70014)End 
>> of file found: [client 127.0.0.1:57024] AH01991: SSL input filter read 
>> failed.
>> [Tue Jun 29 19:15:45.527179 2021] [ssl:debug] [pid 241355] 
>> ssl_engine_io.c(1102): [client 127.0.0.1:57024] AH02001: Connection 
>> closed to child 0 with standard shutdown (server hp15pw:443)
>> [Tue Jun 29 19:15:45.537952 2021] [ssl:info] [pid 241357] [client 
>> 127.0.0.1:57026] AH01964: Connection to child 2 established (server 
>> hp15pw:443)
>> [Tue Jun 29 19:15:45.538859 2021] [socache_shmcb:debug] [pid 241357] 
>> mod_socache_shmcb.c(530): AH00835: socache_shmcb_retrieve (0x68 -> 
>> subcache 8)
>> [Tue Jun 29 19:15:45.538910 2021] [socache_shmcb:debug] [pid 241357] 
>> mod_socache_shmcb.c(916): AH00851: shmcb_subcache_retrieve found no match
>> [Tue Jun 29 19:15:45.538929 2021] [socache_shmcb:debug] [pid 241357] 
>> mod_socache_shmcb.c(541): AH00836: leaving socache_shmcb_retrieve 
>> successfully
>> [Tue Jun 29 19:15:45.538994 2021] [ssl:debug] [pid 241357] 
>> ssl_engine_kernel.c(2387): [client 127.0.0.1:57026] AH02044: No 
>> matching SSL virtual host for servername localhost found (using 
>> default/first virtual host)
>> [Tue Jun 29 19:15:45.539162 2021] [ssl:debug] [pid 241357] 
>> ssl_engine_kernel.c(2387): [client 127.0.0.1:57026] AH02044: No 
>> matching SSL virtual host for servername localhost found (using 
>> default/first virtual host)
>> [Tue Jun 29 19:15:45.539188 2021] [core:debug] [pid 241357] 
>> protocol.c(2313): [client 127.0.0.1:57026] AH03155: select protocol 
>> from , choices=h2,http/1.1 for server hp15pw
>> [Tue Jun 29 19:15:45.574552 2021] [ssl:debug] [pid 241357] 
>> ssl_engine_kernel.c(2254): [client 127.0.0.1:57026] AH02041: Protocol: 
>> TLSv1.2, Cipher: ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)
>> [Tue Jun 29 19:15:45.589868 2021] [ssl:debug] [pid 241357] 
>> ssl_engine_kernel.c(415): [client 127.0.0.1:57026] AH02034: Initial 
>> (No.1) HTTPS request received for child 2 (server hp15pw:443)
>> [Tue Jun 29 19:15:45.590043 2021] [ssl:debug] [pid 241357] 
>> ssl_engine_kernel.c(782): [client 127.0.0.1:57026] AH02255: Changed 
>> client verification type will force renegotiation
>> [Tue Jun 29 19:15:45.590051 2021] [ssl:info] [pid 241357] [client 
>> 127.0.0.1:57026] AH02221: Requesting connection re-negotiation
>> [Tue Jun 29 19:15:45.590124 2021] [ssl:debug] [pid 241357] 
>> ssl_engine_kernel.c(984): [client 127.0.0.1:57026] AH02260: Performing 
>> full renegotiation: complete handshake protocol (client does support 
>> secure renegotiation)
>> [Tue Jun 29 19:15:45.590251 2021] [ssl:debug] [pid 241357] 
>> ssl_engine_kernel.c(2254): [client 127.0.0.1:57026] AH02041: Protocol: 
>> TLSv1.2, Cipher: ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)
>> [Tue Jun 29 19:15:45.590261 2021] [ssl:info] [pid 241357] [client 
>> 127.0.0.1:57026] AH02226: Awaiting re-negotiation handshake
>> [Tue Jun 29 19:15:45.590535 2021] [ssl:debug] [pid 241357] 
>> ssl_engine_kernel.c(2387): [client 127.0.0.1:57026] AH02044: No 
>> matching SSL virtual host for servername localhost found (using 
>> default/first virtual host)
>> [Tue Jun 29 19:15:45.592237 2021] [socache_shmcb:debug] [pid 241357] 
>> mod_socache_shmcb.c(555): AH00837: socache_shmcb_remove (0x4c -> 
>> subcache 12)
>> [Tue Jun 29 19:15:45.592290 2021] [socache_shmcb:debug] [pid 241357] 
>> mod_socache_shmcb.c(570): AH00839: leaving socache_shmcb_remove 
>> successfully
>> [Tue Jun 29 19:15:45.592363 2021] [ssl:error] [pid 241357] [client 
>> 127.0.0.1:57026] AH02261: Re-negotiation handshake failed
>> [Tue Jun 29 19:15:45.592456 2021] [ssl:error] [pid 241357] SSL Library 
>> Error: error:1417C0C7:SSL routines:tls_process_client_certificate:peer 
>> did not return a certificate -- No CAs known to server for verification?
>> [Tue Jun 29 19:15:45.592643 2021] [ssl:debug] [pid 241357] 
>> ssl_engine_io.c(1368): [client 127.0.0.1:57026] AH02007: SSL handshake 
>> interrupted by system [Hint: Stop button pressed in browser?!]
>> [Tue Jun 29 19:15:45.592662 2021] [ssl:info] [pid 241357] [client 
>> 127.0.0.1:57026] AH01998: Connection closed to child 2 with abortive 
>> shutdown (server hp15pw:443)
>> root at hp15pw:/var/log/apache2#
>>
>> Any cue? I'm not being able to find out what is wrong.
>>
>> Thx in advance.
>>
>>
>>
> 

From bhat.jayalakshmi at gmail.com  Wed Jun 30 14:29:13 2021
From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat)
Date: Wed, 30 Jun 2021 19:59:13 +0530
Subject: Compilation error using OpenSSL 1.1.1i
Message-ID: <CALq8RvJX690JPd1Utgr+DRBR8D0nxZtV_H8LEkJhckWXcz-2hQ@mail.gmail.com>

Hi All,

We are trying to compile OpenSSL 1.1.1i on our system.  It is a hybrid
system. Compiler  is arm -gcc for WinCE 6.0 and the module that compiles
openssl is on Vxworks 5.0 abstraction.
I am getting the below error. Does anyone have inputs. Any help would be
appreciated.

openssl/safestack.h(159) : error C2054: expected '(' to follow '__inline__'
openssl/safestack.h(159) : error C2085: 'sk_OPENSSL_STRING_num' : not in
formal parameter list


Regards,
Jaya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210630/42a2f36a/attachment-0001.html>