From openssl at openssl.org  Thu Dec  1 14:00:02 2022
From: openssl at openssl.org (OpenSSL)
Date: Thu, 1 Dec 2022 14:00:02 +0000
Subject: OpenSSL version 3.1.0-alpha1 published
Message-ID: <Y4izYrt/Jg7XNIEB@openssl.org>

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


   OpenSSL version 3.1 alpha 1 released
   ====================================

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

   OpenSSL 3.1 is currently in alpha.

   OpenSSL 3.1 alpha 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.1 from previous versions are
   available in the OpenSSL Migration Guide, here:

        https://www.openssl.org/docs/man3.0/man7/migration_guide.html

   The alpha 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.1.0-alpha1.tar.gz
      Size: 15343477
      SHA1 checksum:  91a7cbcb761c4bb8a460899bccddcbd5d047d3c3
      SHA256 checksum:  ef10f70023f4e3f701c434db0b4b0c8cfea1e1e473a0eb3c9ccbc5c54f5f5566

   The checksums were calculated using the following commands:

    openssl sha1 openssl-3.1.0-alpha1.tar.gz
    openssl sha256 openssl-3.1.0-alpha1.tar.gz

   Please download and check this alpha 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-----

iQJGBAEBCAAwFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmOIqpASHHRvbWFzQG9w
ZW5zc2wub3JnAAoJEFJ0ZqIcp55tWrIQAJHT40JekEs3DacHjQrTmGLc56TmzaFD
oDp8Md2E0RpX/vuANdIVGB89zGQMag13TPa9CzT1yk7wFBilPoiuapolmo8N0nvF
OnMLIQjF+sbsQN0gqchuMKKD98omc1ZNNcijq/GlKM9wH6ey1uHnFAi2aXF4f6ai
2SviauJvHQDgDOe9tFfA5lDF1EdYZt20D46Yc+yJf/zr4MJZFcX2T2qmo+oew6VA
djZ+cRPeeNmRXrl5Banqpfcy2iH4N57wvEcM4dtGaGY+4Pwr0H9XN6MxfamGUbLv
oSySdFpTagPENPGDBPoRilPSXdapCD5m8Xd2FERM1HF5E1GaemqaQKUYiXbANqL/
SDBftayilhYf+tXg3/22xksZVEkEjFD79M0mj75dn+UgQilOTR/AOdup2imTB7PG
7Cgq2HGz93ppO3kG0iuTS5uc95Gfu9AfkjgfcydA2eZf+rmHAoocm8kpThdxD/a5
avpMudgklyXysmO+2MJ16806Sa27L8N52YTPzy4Zthx/SLR/RA//bXBnlSlguRGw
7+hIDPncmaCfegaI65yq/TgtU9z/OLhNTPmYaUQi3IFtsCrAahZNVYg8qZtnMtgC
iaVYQkNZsqE0wSDalgJANJkZUa8VHdh2O3sOBSYbZvHWEiYJJ+9ATgLSLDjiGq0e
l9cvtybysQsx
=upN5
-----END PGP SIGNATURE-----

From felipe at felipegasper.com  Thu Dec  1 14:40:45 2022
From: felipe at felipegasper.com (Felipe Gasper)
Date: Thu, 1 Dec 2022 09:40:45 -0500
Subject: OpenSSL version 3.1.0-alpha1 published
In-Reply-To: <Y4izYrt/Jg7XNIEB@openssl.org>
References: <Y4izYrt/Jg7XNIEB@openssl.org>
Message-ID: <2A1EC9C0-D10F-4163-9211-E39CE4BF423A@felipegasper.com>

AFAICT, the migration guide doesn?t actually seem to mention upgrades to 3.1.

-FG


> On Dec 1, 2022, at 09:00, OpenSSL <openssl at openssl.org> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> 
>   OpenSSL version 3.1 alpha 1 released
>   ====================================
> 
>   OpenSSL - The Open Source toolkit for SSL/TLS
>   https://www.openssl.org/
> 
>   OpenSSL 3.1 is currently in alpha.
> 
>   OpenSSL 3.1 alpha 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.1 from previous versions are
>   available in the OpenSSL Migration Guide, here:
> 
>        https://www.openssl.org/docs/man3.0/man7/migration_guide.html
> 
>   The alpha 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.1.0-alpha1.tar.gz
>      Size: 15343477
>      SHA1 checksum:  91a7cbcb761c4bb8a460899bccddcbd5d047d3c3
>      SHA256 checksum:  ef10f70023f4e3f701c434db0b4b0c8cfea1e1e473a0eb3c9ccbc5c54f5f5566
> 
>   The checksums were calculated using the following commands:
> 
>    openssl sha1 openssl-3.1.0-alpha1.tar.gz
>    openssl sha256 openssl-3.1.0-alpha1.tar.gz
> 
>   Please download and check this alpha 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-----
> 
> iQJGBAEBCAAwFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmOIqpASHHRvbWFzQG9w
> ZW5zc2wub3JnAAoJEFJ0ZqIcp55tWrIQAJHT40JekEs3DacHjQrTmGLc56TmzaFD
> oDp8Md2E0RpX/vuANdIVGB89zGQMag13TPa9CzT1yk7wFBilPoiuapolmo8N0nvF
> OnMLIQjF+sbsQN0gqchuMKKD98omc1ZNNcijq/GlKM9wH6ey1uHnFAi2aXF4f6ai
> 2SviauJvHQDgDOe9tFfA5lDF1EdYZt20D46Yc+yJf/zr4MJZFcX2T2qmo+oew6VA
> djZ+cRPeeNmRXrl5Banqpfcy2iH4N57wvEcM4dtGaGY+4Pwr0H9XN6MxfamGUbLv
> oSySdFpTagPENPGDBPoRilPSXdapCD5m8Xd2FERM1HF5E1GaemqaQKUYiXbANqL/
> SDBftayilhYf+tXg3/22xksZVEkEjFD79M0mj75dn+UgQilOTR/AOdup2imTB7PG
> 7Cgq2HGz93ppO3kG0iuTS5uc95Gfu9AfkjgfcydA2eZf+rmHAoocm8kpThdxD/a5
> avpMudgklyXysmO+2MJ16806Sa27L8N52YTPzy4Zthx/SLR/RA//bXBnlSlguRGw
> 7+hIDPncmaCfegaI65yq/TgtU9z/OLhNTPmYaUQi3IFtsCrAahZNVYg8qZtnMtgC
> iaVYQkNZsqE0wSDalgJANJkZUa8VHdh2O3sOBSYbZvHWEiYJJ+9ATgLSLDjiGq0e
> l9cvtybysQsx
> =upN5
> -----END PGP SIGNATURE-----



From tomas at openssl.org  Thu Dec  1 14:43:27 2022
From: tomas at openssl.org (Tomas Mraz)
Date: Thu, 01 Dec 2022 15:43:27 +0100
Subject: OpenSSL version 3.1.0-alpha1 published
In-Reply-To: <2A1EC9C0-D10F-4163-9211-E39CE4BF423A@felipegasper.com>
References: <Y4izYrt/Jg7XNIEB@openssl.org>
 <2A1EC9C0-D10F-4163-9211-E39CE4BF423A@felipegasper.com>
Message-ID: <73355d44c8f399e68d7eda7fed4b8b8b39e0217b.camel@openssl.org>

Hmm, good point.

Though when migrating from 1.1.1 the 3.0 guide still applies and
migration from 3.0 to 3.1 should be just seamless.

Tomas


On Thu, 2022-12-01 at 09:40 -0500, Felipe Gasper wrote:
> AFAICT, the migration guide doesn?t actually seem to mention upgrades
> to 3.1.
> 
> -FG
> 
> 
> > On Dec 1, 2022, at 09:00, OpenSSL <openssl at openssl.org> wrote:
> > 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> > 
> > 
> > ? OpenSSL version 3.1 alpha 1 released
> > ? ====================================
> > 
> > ? OpenSSL - The Open Source toolkit for SSL/TLS
> > ? https://www.openssl.org/
> > 
> > ? OpenSSL 3.1 is currently in alpha.
> > 
> > ? OpenSSL 3.1 alpha 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.1 from previous versions
> > are
> > ? available in the OpenSSL Migration Guide, here:
> > 
> > ??????
> > https://www.openssl.org/docs/man3.0/man7/migration_guide.html
> > 
> > ? The alpha 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.1.0-alpha1.tar.gz
> > ???? Size: 15343477
> > ???? SHA1 checksum:? 91a7cbcb761c4bb8a460899bccddcbd5d047d3c3
> > ???? SHA256 checksum:?
> > ef10f70023f4e3f701c434db0b4b0c8cfea1e1e473a0eb3c9ccbc5c54f5f5566
> > 
> > ? The checksums were calculated using the following commands:
> > 
> > ?? openssl sha1 openssl-3.1.0-alpha1.tar.gz
> > ?? openssl sha256 openssl-3.1.0-alpha1.tar.gz
> > 
> > ? Please download and check this alpha 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-----
> > 
> > iQJGBAEBCAAwFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmOIqpASHHRvbWFzQG9w
> > ZW5zc2wub3JnAAoJEFJ0ZqIcp55tWrIQAJHT40JekEs3DacHjQrTmGLc56TmzaFD
> > oDp8Md2E0RpX/vuANdIVGB89zGQMag13TPa9CzT1yk7wFBilPoiuapolmo8N0nvF
> > OnMLIQjF+sbsQN0gqchuMKKD98omc1ZNNcijq/GlKM9wH6ey1uHnFAi2aXF4f6ai
> > 2SviauJvHQDgDOe9tFfA5lDF1EdYZt20D46Yc+yJf/zr4MJZFcX2T2qmo+oew6VA
> > djZ+cRPeeNmRXrl5Banqpfcy2iH4N57wvEcM4dtGaGY+4Pwr0H9XN6MxfamGUbLv
> > oSySdFpTagPENPGDBPoRilPSXdapCD5m8Xd2FERM1HF5E1GaemqaQKUYiXbANqL/
> > SDBftayilhYf+tXg3/22xksZVEkEjFD79M0mj75dn+UgQilOTR/AOdup2imTB7PG
> > 7Cgq2HGz93ppO3kG0iuTS5uc95Gfu9AfkjgfcydA2eZf+rmHAoocm8kpThdxD/a5
> > avpMudgklyXysmO+2MJ16806Sa27L8N52YTPzy4Zthx/SLR/RA//bXBnlSlguRGw
> > 7+hIDPncmaCfegaI65yq/TgtU9z/OLhNTPmYaUQi3IFtsCrAahZNVYg8qZtnMtgC
> > iaVYQkNZsqE0wSDalgJANJkZUa8VHdh2O3sOBSYbZvHWEiYJJ+9ATgLSLDjiGq0e
> > l9cvtybysQsx
> > =upN5
> > -----END PGP SIGNATURE-----
> 
> 

-- 
Tom?? Mr?z, OpenSSL


From felipe at felipegasper.com  Thu Dec  1 15:10:46 2022
From: felipe at felipegasper.com (Felipe Gasper)
Date: Thu, 1 Dec 2022 10:10:46 -0500
Subject: OpenSSL version 3.1.0-alpha1 published
In-Reply-To: <73355d44c8f399e68d7eda7fed4b8b8b39e0217b.camel@openssl.org>
References: <Y4izYrt/Jg7XNIEB@openssl.org>
 <2A1EC9C0-D10F-4163-9211-E39CE4BF423A@felipegasper.com>
 <73355d44c8f399e68d7eda7fed4b8b8b39e0217b.camel@openssl.org>
Message-ID: <67FA2D3D-695D-46A1-83FC-4B2F7392A0F6@felipegasper.com>

All the same, it would be good to mention, or to link to, new features that might allow reconsideration of technical constraints, etc.

Anyhow, thank you!

-FG

> On Dec 1, 2022, at 09:43, Tomas Mraz <tomas at openssl.org> wrote:
> 
> Hmm, good point.
> 
> Though when migrating from 1.1.1 the 3.0 guide still applies and
> migration from 3.0 to 3.1 should be just seamless.
> 
> Tomas
> 
> 
> On Thu, 2022-12-01 at 09:40 -0500, Felipe Gasper wrote:
>> AFAICT, the migration guide doesn?t actually seem to mention upgrades
>> to 3.1.
>> 
>> -FG
>> 
>> 
>>> On Dec 1, 2022, at 09:00, OpenSSL <openssl at openssl.org> wrote:
>>> 
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>> 
>>> 
>>>   OpenSSL version 3.1 alpha 1 released
>>>   ====================================
>>> 
>>>   OpenSSL - The Open Source toolkit for SSL/TLS
>>>   https://www.openssl.org/
>>> 
>>>   OpenSSL 3.1 is currently in alpha.
>>> 
>>>   OpenSSL 3.1 alpha 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.1 from previous versions
>>> are
>>>   available in the OpenSSL Migration Guide, here:
>>> 
>>>       
>>> https://www.openssl.org/docs/man3.0/man7/migration_guide.html
>>> 
>>>   The alpha 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.1.0-alpha1.tar.gz
>>>      Size: 15343477
>>>      SHA1 checksum:  91a7cbcb761c4bb8a460899bccddcbd5d047d3c3
>>>      SHA256 checksum: 
>>> ef10f70023f4e3f701c434db0b4b0c8cfea1e1e473a0eb3c9ccbc5c54f5f5566
>>> 
>>>   The checksums were calculated using the following commands:
>>> 
>>>    openssl sha1 openssl-3.1.0-alpha1.tar.gz
>>>    openssl sha256 openssl-3.1.0-alpha1.tar.gz
>>> 
>>>   Please download and check this alpha 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-----
>>> 
>>> iQJGBAEBCAAwFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmOIqpASHHRvbWFzQG9w
>>> ZW5zc2wub3JnAAoJEFJ0ZqIcp55tWrIQAJHT40JekEs3DacHjQrTmGLc56TmzaFD
>>> oDp8Md2E0RpX/vuANdIVGB89zGQMag13TPa9CzT1yk7wFBilPoiuapolmo8N0nvF
>>> OnMLIQjF+sbsQN0gqchuMKKD98omc1ZNNcijq/GlKM9wH6ey1uHnFAi2aXF4f6ai
>>> 2SviauJvHQDgDOe9tFfA5lDF1EdYZt20D46Yc+yJf/zr4MJZFcX2T2qmo+oew6VA
>>> djZ+cRPeeNmRXrl5Banqpfcy2iH4N57wvEcM4dtGaGY+4Pwr0H9XN6MxfamGUbLv
>>> oSySdFpTagPENPGDBPoRilPSXdapCD5m8Xd2FERM1HF5E1GaemqaQKUYiXbANqL/
>>> SDBftayilhYf+tXg3/22xksZVEkEjFD79M0mj75dn+UgQilOTR/AOdup2imTB7PG
>>> 7Cgq2HGz93ppO3kG0iuTS5uc95Gfu9AfkjgfcydA2eZf+rmHAoocm8kpThdxD/a5
>>> avpMudgklyXysmO+2MJ16806Sa27L8N52YTPzy4Zthx/SLR/RA//bXBnlSlguRGw
>>> 7+hIDPncmaCfegaI65yq/TgtU9z/OLhNTPmYaUQi3IFtsCrAahZNVYg8qZtnMtgC
>>> iaVYQkNZsqE0wSDalgJANJkZUa8VHdh2O3sOBSYbZvHWEiYJJ+9ATgLSLDjiGq0e
>>> l9cvtybysQsx
>>> =upN5
>>> -----END PGP SIGNATURE-----
>> 
>> 
> 
> -- 
> Tom?? Mr?z, OpenSSL
> 



From kgoldman at us.ibm.com  Thu Dec  1 15:15:46 2022
From: kgoldman at us.ibm.com (Kenneth Goldman)
Date: Thu, 1 Dec 2022 15:15:46 +0000
Subject: OpenSSL version 3.1.0-alpha1 published
In-Reply-To: <Y4izYrt/Jg7XNIEB@openssl.org>
References: <Y4izYrt/Jg7XNIEB@openssl.org>
Message-ID: <BN8PR15MB275337F71A6C2E068366D6DEF2149@BN8PR15MB2753.namprd15.prod.outlook.com>

The changes show a jump from 3.0 to 3.2

https://github.com/openssl/openssl/blob/master/CHANGES.md

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5357 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221201/a2a918de/attachment.p7s>

From tomas at openssl.org  Thu Dec  1 15:19:29 2022
From: tomas at openssl.org (Tomas Mraz)
Date: Thu, 01 Dec 2022 16:19:29 +0100
Subject: OpenSSL version 3.1.0-alpha1 published
In-Reply-To: <BN8PR15MB275337F71A6C2E068366D6DEF2149@BN8PR15MB2753.namprd15.prod.outlook.com>
References: <Y4izYrt/Jg7XNIEB@openssl.org>
 <BN8PR15MB275337F71A6C2E068366D6DEF2149@BN8PR15MB2753.namprd15.prod.outlook.com>
Message-ID: <3695e0b3a111f437771f304fcf032fe99428642e.camel@openssl.org>

That is the master branch CHANGES.md. It will be synced later.

For the 3.1 changes please look at the CHANGES.md in the openssl-3.1
branch and/or inside the alpha tarball.

Tomas

On Thu, 2022-12-01 at 15:15 +0000, Kenneth Goldman wrote:
> The changes show a jump from 3.0 to 3.2
> 
> https://github.com/openssl/openssl/blob/master/CHANGES.md
> 

-- 
Tom?? Mr?z, OpenSSL


From zwang2 at rocketsoftware.com  Mon Dec  5 08:45:37 2022
From: zwang2 at rocketsoftware.com (Zhongyan Wang)
Date: Mon, 5 Dec 2022 08:45:37 +0000
Subject: BIO_read() crash
Message-ID: <SN7PR07MB9577571C8070AF8DC6B268F8E9189@SN7PR07MB9577.namprd07.prod.outlook.com>

Hi team,
I find a segment fault in BIO_read() on openssl 3.0 about calculate digest with BIO using md4 algorithm.
This is my test code, put it in a.c, build & run, it will crash.
If don't load legacy provider:

  1.  Set dgst  = "md4", EVP_get_digestbyname(dgst) won't return NULL, but a non-NULL object. If use EVP_MD_fetch(NULL, dgst, NULL) instead, it will return NULL.
  2.  When call BIO_read(), this program crashes.
If load legacy provider, this program works ok.


------------------------------------------------------------------------
#include <openssl/provider.h>
#include <openssl/err.h>
#include <openssl/types.h>
#include <openssl/evp.h>
#include <openssl/bn.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main() {
    EVP_MD *md = NULL;
    const char *datain = "a.c";
    const int BUF_SIZE = 8192;
    char *buff = NULL;
    char *ptr = NULL;
    const char *dgst = "md4";
    int ret = 0, len = 0, i = 0;
    BIO *in = NULL, *out = NULL, *bmd = NULL, *rbio = NULL, *err;

    if ((err = BIO_new(BIO_s_file())) != NULL)
        BIO_set_fp(err, stderr, BIO_NOCLOSE|BIO_FP_TEXT);

    md = EVP_get_digestbyname(dgst);
    if (!md) {
        printf("Error EVP_get_digestbyname %s\n", dgst);
        goto err_exit;
    }

    in = BIO_new_file(datain, "rb");
    if (!in) {
        printf("Error BIO_new_file %s\n", datain);
        goto err_exit;
    }

    out = BIO_new(BIO_s_mem());
    if (!out) {
        printf("Error BIO_new out\n");
        goto err_exit;
    }

    rbio = in;

    bmd = BIO_new(BIO_f_md());
    if (!bmd){
        printf("Error BIO_new bmd\n");
        goto err_exit;
    }

    BIO_set_md(bmd, md);

    rbio = BIO_push(bmd, rbio);

    buff = (char *)malloc(BUF_SIZE);
    if (!buff) {
        printf("Error malloc\n");
        goto err_exit;
    }

    for (;;) {
        ret = BIO_read(rbio, buff, BUF_SIZE); /* this call will segment fault */
        if (ret <= 0) break;
    }

    len = BIO_gets(rbio, buff, BUF_SIZE);

    len = BIO_write(out, buff, len);

    if (!BIO_flush(out)) {
        printf("Error BIO_flush\n");
        goto err_exit;
    }

    len = BIO_get_mem_data(out, &ptr);
    printf("digest success, len=%d\n", len);
    for (i = 0; i < len; i++)
        printf("%d ", ptr[i]);
    printf("\n");

err_exit:
    ERR_print_errors(err);
    if (in)
        BIO_free(in);
    if (out)
        BIO_free_all(out);
    if (err)
        BIO_free(err);
    if (bmd)
        BIO_free(bmd);
    if (buff)
        free(buff);
    if (md)
        EVP_MD_free(md);
    ERR_clear_error();
    return 0;
}
---------------------------------------------------------------------------------

================================
Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
================================

This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221205/116975fc/attachment.htm>

From tomas at openssl.org  Mon Dec  5 10:24:23 2022
From: tomas at openssl.org (Tomas Mraz)
Date: Mon, 05 Dec 2022 11:24:23 +0100
Subject: BIO_read() crash
In-Reply-To: <SN7PR07MB9577571C8070AF8DC6B268F8E9189@SN7PR07MB9577.namprd07.prod.outlook.com>
References: <SN7PR07MB9577571C8070AF8DC6B268F8E9189@SN7PR07MB9577.namprd07.prod.outlook.com>
Message-ID: <bc4577e870d4dee66aba872144c6ae20d8b2b0b0.camel@openssl.org>

Hi,

there is an error in your code - see my comment below.


On Mon, 2022-12-05 at 08:45 +0000, Zhongyan Wang wrote:
...
> ??? md = EVP_get_digestbyname(dgst);
> ??? if (!md) {
> ??????? printf("Error EVP_get_digestbyname %s\n", dgst);
> ??????? goto err_exit;
> ??? }
> ?
> ??? in = BIO_new_file(datain, "rb");
> ??? if (!in) {
> ??????? printf("Error BIO_new_file %s\n", datain);
> ??????? goto err_exit;
> ??? }
> ?
> ??? out = BIO_new(BIO_s_mem());
> ??? if (!out) {
> ??????? printf("Error BIO_new out\n");
> ??????? goto err_exit;
> ??? }
> ?
> ??? rbio = in;
> ?
> ??? bmd = BIO_new(BIO_f_md());
> ??? if (!bmd){
> ??????? printf("Error BIO_new bmd\n");
> ??????? goto err_exit;
> ??? }
> ?
> ??? BIO_set_md(bmd, md);

You do not check the return value here. This call will return <= 0
return value in case the legacy provider is not loaded.



-- 
Tom?? Mr?z, OpenSSL


From thomas.dwyer at oracle.com  Mon Dec  5 19:31:18 2022
From: thomas.dwyer at oracle.com (Thomas Dwyer III)
Date: Mon, 5 Dec 2022 11:31:18 -0800
Subject: [External] : Re: BIO_read() crash
In-Reply-To: <bc4577e870d4dee66aba872144c6ae20d8b2b0b0.camel@openssl.org>
References: <SN7PR07MB9577571C8070AF8DC6B268F8E9189@SN7PR07MB9577.namprd07.prod.outlook.com>
 <bc4577e870d4dee66aba872144c6ae20d8b2b0b0.camel@openssl.org>
Message-ID: <cb43443b-e452-3567-1006-3c01b0fab62b@oracle.com>

Why does EVP_get_digestbyname("md4") return non-NULL if the legacy 
provider isn't loaded? Similarly, why does it return non-NULL for "md5" 
after doing EVP_set_default_properties(NULL, "fips=yes")? This seems 
unintuitive. Legacy code that does not know about EVP_MD_fetch() checks 
the return value of EVP_get_digestbyname(). Isn't that where the error 
should be detected? Why let it get all the way to BIO_set_md() (or 
EVP_DigestInit() or whatever) before the error is detected?


Tom.III


||
On 12/5/22 02:24, Tomas Mraz wrote:
> Hi,
>
> there is an error in your code - see my comment below.
>
>
> On Mon, 2022-12-05 at 08:45 +0000, Zhongyan Wang wrote:
> ...
>>  ??? md = EVP_get_digestbyname(dgst);
>>  ??? if (!md) {
>>  ??????? printf("Error EVP_get_digestbyname %s\n", dgst);
>>  ??????? goto err_exit;
>>  ??? }
>>   
>>  ??? in = BIO_new_file(datain, "rb");
>>  ??? if (!in) {
>>  ??????? printf("Error BIO_new_file %s\n", datain);
>>  ??????? goto err_exit;
>>  ??? }
>>   
>>  ??? out = BIO_new(BIO_s_mem());
>>  ??? if (!out) {
>>  ??????? printf("Error BIO_new out\n");
>>  ??????? goto err_exit;
>>  ??? }
>>   
>>  ??? rbio = in;
>>   
>>  ??? bmd = BIO_new(BIO_f_md());
>>  ??? if (!bmd){
>>  ??????? printf("Error BIO_new bmd\n");
>>  ??????? goto err_exit;
>>  ??? }
>>   
>>  ??? BIO_set_md(bmd, md);
> You do not check the return value here. This call will return <= 0
> return value in case the legacy provider is not loaded.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221205/3f6a9e52/attachment.htm>

From bkaduk at akamai.com  Tue Dec  6 00:14:02 2022
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Mon, 5 Dec 2022 16:14:02 -0800
Subject: [External] : Re: BIO_read() crash
In-Reply-To: <cb43443b-e452-3567-1006-3c01b0fab62b@oracle.com>
References: <SN7PR07MB9577571C8070AF8DC6B268F8E9189@SN7PR07MB9577.namprd07.prod.outlook.com>
 <bc4577e870d4dee66aba872144c6ae20d8b2b0b0.camel@openssl.org>
 <cb43443b-e452-3567-1006-3c01b0fab62b@oracle.com>
Message-ID: <20221206001402.GQ4895@akamai.com>

On Mon, Dec 05, 2022 at 11:31:18AM -0800, Thomas Dwyer III wrote:
> Why does EVP_get_digestbyname("md4") return non-NULL if the legacy provider
> isn't loaded? Similarly, why does it return non-NULL for "md5" after doing
> EVP_set_default_properties(NULL, "fips=yes")? This seems unintuitive. Legacy
> code that does not know about EVP_MD_fetch() checks the return value of
> EVP_get_digestbyname(). Isn't that where the error should be detected? Why
> let it get all the way to BIO_set_md() (or EVP_DigestInit() or whatever)
> before the error is detected?

To do so would introduce a time-of-check/time-of-use race, as the set of
providers available may change in the intervening period.

-Ben

From tomas at openssl.org  Tue Dec  6 08:02:52 2022
From: tomas at openssl.org (Tomas Mraz)
Date: Tue, 06 Dec 2022 09:02:52 +0100
Subject: [External] : Re: BIO_read() crash
In-Reply-To: <20221206001402.GQ4895@akamai.com>
References: <SN7PR07MB9577571C8070AF8DC6B268F8E9189@SN7PR07MB9577.namprd07.prod.outlook.com>
 <bc4577e870d4dee66aba872144c6ae20d8b2b0b0.camel@openssl.org>
 <cb43443b-e452-3567-1006-3c01b0fab62b@oracle.com>
 <20221206001402.GQ4895@akamai.com>
Message-ID: <4fd8f915d1974c2136e39057d49b5050406fc58b.camel@openssl.org>

On Mon, 2022-12-05 at 16:14 -0800, Benjamin Kaduk via openssl-users
wrote:
> On Mon, Dec 05, 2022 at 11:31:18AM -0800, Thomas Dwyer III wrote:
> > Why does EVP_get_digestbyname("md4") return non-NULL if the legacy
> > provider
> > isn't loaded? Similarly, why does it return non-NULL for "md5"
> > after doing
> > EVP_set_default_properties(NULL, "fips=yes")? This seems
> > unintuitive. Legacy
> > code that does not know about EVP_MD_fetch() checks the return
> > value of
> > EVP_get_digestbyname(). Isn't that where the error should be
> > detected? Why
> > let it get all the way to BIO_set_md() (or EVP_DigestInit() or
> > whatever)
> > before the error is detected?
> 
> To do so would introduce a time-of-check/time-of-use race, as the set
> of
> providers available may change in the intervening period.

Not just that. IMO the primary motivation was to keep the digests (and
similarly ciphers) returned by the EVP_md4() (and similar) or
EVP_get_digestbyname() calls still constant. I.e., they would not
change based on the providers involved, etc. This implied the implicit
fetching done inside the EVP_DigestInit() and similar init routines.

As any correct code required checking result of EVP_DigestInit() and
thus also the result of BIO_set_md(), it was the least of all evils in
how to implement these legacy EVP_MD functions returning constant
EVP_MDs.
-- 
Tom?? Mr?z, OpenSSL


From hareesh.ulleri at ovt.com  Tue Dec 13 09:13:50 2022
From: hareesh.ulleri at ovt.com (Hareesh Das Ulleri)
Date: Tue, 13 Dec 2022 09:13:50 +0000
Subject: Custom Provider - EVP_CIPHER_fetch fails
Message-ID: <839a0daa09fc4da4b87ad844564ddec1@ovtmail3.ovt.com>

Hello OpenSSL users,

  I am in preparation of a provider (for a custom crypto) by referring OpenSSL 3 design doc (I use Linux 5.10 + OpenSSL 3.0.7). I believe, the custom provider has all required call backs implemented for the cipher functionalities in its dispatch table.

  I have another test application (for encryption and decryption of a text message). At the starting of the app, it calls OSSL_PROVIDER_load and EVP_CIPHER_fetch functions to the custom provider. But unfortunately custom provider fetch function fails...

What could be the missing or how to make sure that the custom provider is loaded correctly before calling the fetch function?

cipher = EVP_CIPHER_fetch(NULL, "AES-256-CBC-CTS", NULL);  -> This will work, default provider
cipher = EVP_CIPHER_fetch(NULL, "CUSTOM_ALGO", NULL);  -> returns NULL, custom provider

Confg file:
openssl_conf = openssl_init

[openssl_init]
providers = provider_section

[provider_section]
customProv = customProv_section
default = default_sect

[customProv_section]
provider_id = customProv
module_path = /userfs/lib/customProv.so
algorithms = CUSTOM_ALGO
activate = 1

[default_sect]
algorithms = AES-256-CBC-CTS
activate = 1

Thank you,
Hareesh


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221213/fc94dcde/attachment.htm>

From matt at openssl.org  Tue Dec 13 11:48:52 2022
From: matt at openssl.org (Matt Caswell)
Date: Tue, 13 Dec 2022 11:48:52 +0000
Subject: Custom Provider - EVP_CIPHER_fetch fails
In-Reply-To: <839a0daa09fc4da4b87ad844564ddec1@ovtmail3.ovt.com>
References: <839a0daa09fc4da4b87ad844564ddec1@ovtmail3.ovt.com>
Message-ID: <6e87e68c-9fa0-9873-3e66-2289a36020cd@openssl.org>



On 13/12/2022 09:13, Hareesh Das Ulleri wrote:
> Hello OpenSSL users,
> 
>  ? I am in preparation of a provider (for a custom crypto) by referring 
> OpenSSL 3 design doc

Don't refer to the design doc. It has not been maintained with all the 
latest tweaks and updates to what was originally envisaged.

> (I use Linux 5.10 + OpenSSL 3.0.7). I believe, the 
> custom provider has all required call backs implemented for the cipher 
> functionalities in its dispatch table.
> 

You should refer to the man page for what is required to implement a 
custom cipher. See:

https://www.openssl.org/docs/man3.0/man7/provider-cipher.html

Note in particular this comment in the man page:

"A cipher algorithm implementation may not implement all of these 
functions. In order to be a consistent set of functions there must at 
least be a complete set of "encrypt" functions, or a complete set of 
"decrypt" functions, or a single "cipher" function. In all cases both 
the OSSL_FUNC_cipher_newctx and OSSL_FUNC_cipher_freectx functions must 
be present. All other functions are optional."

So, in other words, you must as a minimum implement 
OSSL_FUNC_cipher_encrypt_init (or OSSL_FUNC_cipher_decrypt_init), 
OSSL_FUNC_cipher_update, OSSL_FUNC_cipher_final, OSSL_FUNC_cipher_newctx 
and OSSL_FUNC_cipher_freectx.

You should probably also read the following pages for general 
information on writing a provider:

https://www.openssl.org/docs/man3.0/man7/provider.html
https://www.openssl.org/docs/man3.0/man7/provider-base.html

You might also want to refer to Richard Levitte's implementation of the 
toy Vigen?re cipher as a provider here:

https://github.com/provider-corner/vigenere

>  ? I have another test application (for encryption and decryption of a 
> text message). At the starting of the app, it calls OSSL_PROVIDER_load 
> and EVP_CIPHER_fetch functions to the custom provider. But unfortunately 
> custom provider fetch function fails?


I suggest calling the OSSL_PROVIDER_available() function to determine 
whether your custom provider has been successfully loaded:

https://www.openssl.org/docs/man3.0/man3/OSSL_PROVIDER_available.html

> 
> What could be the missing or how to make sure that the custom provider 
> is loaded correctly before calling the fetch function?
> 
> cipher = EVP_CIPHER_fetch(NULL, "AES-256-CBC-CTS", NULL);? -> This will 
> work, default provider
> 
> cipher = EVP_CIPHER_fetch(NULL, "CUSTOM_ALGO", NULL);? -> returns NULL, 
> custom provider
> 
> _Confg file:_
> 
> openssl_conf = openssl_init
> 
> [openssl_init]
> 
> providers = provider_section
> 
> [provider_section]
> 
> customProv = customProv_section
> 
> default = default_sect
> 
> [customProv_section]
> 
> provider_id = customProv
> 
> module_path = /userfs/lib/customProv.so
> 
> algorithms = CUSTOM_ALGO
> 
> activate = 1
> 
> [default_sect]
> 
> algorithms = AES-256-CBC-CTS
> 
> activate = 1

This config file does not look correct. I guess you based it on some of 
the examples in the design doc which are out of date.

The man page for config file formats is here:

https://www.openssl.org/docs/man3.0/man5/config.html

See the "Provider Configuration" section on that page in particular.

Also worth looking at are some of the test config files used in the 
OpenSSL code base for loading providers, e.g.

https://github.com/openssl/openssl/blob/openssl-3.0/test/default-and-legacy.cnf

Matt


> 
> Thank you,
> 
> Hareesh
> 

From tomas at openssl.org  Tue Dec 13 13:24:56 2022
From: tomas at openssl.org (Tomas Mraz)
Date: Tue, 13 Dec 2022 13:24:56 +0000
Subject: OpenSSL Security Advisory
Message-ID: <Y5h9KBZ93EWQqHMB@dev.openssl.org>

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

OpenSSL Security Advisory [13 December 2022]
============================================

X.509 Policy Constraints Double Locking (CVE-2022-3996)
=======================================================

Severity: Low

If an X.509 certificate contains a malformed policy constraint and
policy processing is enabled, then a write lock will be taken twice
recursively.  On some operating systems (most widely: Windows) this
results in a denial of service when the affected process hangs.  Policy
processing being enabled on a publicly facing server is not considered
to be a common setup.

Policy processing is enabled by passing the `-policy'
argument to the command line utilities or by calling either
`X509_VERIFY_PARAM_add0_policy()' or `X509_VERIFY_PARAM_set1_policies()'
functions.

OpenSSL versions 3.0.0 to 3.0.7 are vulnerable to this issue.  However due
to the low severity of this issue we are not creating a new release at
this time.  The mitigation for this issue can be found in commit 7725e7bfe.

OpenSSL 3.0 users should upgrade to OpenSSL 3.0.8 once it is released.

OpenSSL 1.1.1 and 1.0.2 are not affected by this issue.

This issue was discovered on 7th November 2022 by Polar Bear.
The fix was developed by Dr Paul Dale.

We have no evidence of this issue being exploited as of the time of
release of this advisory (December 13th 2022).

References
==========

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20221213.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
-----BEGIN PGP SIGNATURE-----

iQJGBAEBCAAwFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmOYehASHHRvbWFzQG9w
ZW5zc2wub3JnAAoJEFJ0ZqIcp55tRVsQAIW6PehuBCAjLZLWRlx85qIkGSKSuQoR
K+Fl9C3zT2DOg0kldhE4rHRDoAOKhle9dOh4J46NVQ8TCPZYN9D0CTHpyY4YEOye
CEyrozcaHnO9TwnWoFMhx76Vo9IMujogK+A/0pO7qACTJNsSlix/zWAkkzoD5Esi
BJdlQMlLSi92cHISzY3YoY3td0BlR3b8/SQBeUj8O4n80c6P89U7cti9WyN+KSep
gkB36n4k4cPQXTCB/K8OUC1F8az3PmndOKgxmo19cMWgElW06rFyYvhyWcv1ObjR
dZxXbq8CV4pv4WexsFF8y0f8xplPi5kcdOe8mJMoPGCC0aRvhVDMxmE4r9/Xq8LL
aZD6nYx4LBHBsdMsVuCLwds+BIhMYqs9KmjjxRRJDdMXpSCQT6LH2YfkevhIITfa
bSb0TyX+1dSVieFr70pFDP/Fd1add7ktS+lu54i0oH8f1hQDmh7s+SXjcM3ULcXE
REie5EZWALZX4T7gXNMeWIcNn7UL6xg7EU8Fq7aWy9bIyyy7d5GmFamLPLLzQc4s
gs2DBkYiwpW/KuCksfGro1FQVMVxanVaFvqnYpl/W092F/JbN7XC2MLP7L6eGMKz
RTvLpZ46c+nGfZ5Cx/dvv1efLfcAg1KX+182ITSjL7v/7XW4i1TOfzBmyZm6Vd9g
37jOuJ7uCQWG
=r/+J
-----END PGP SIGNATURE-----

From fernando.elena.benavente at gmv.com  Wed Dec 14 10:47:35 2022
From: fernando.elena.benavente at gmv.com (Fernando Elena Benavente)
Date: Wed, 14 Dec 2022 10:47:35 +0000
Subject: Im triying to find the FIPS self-test source code for HMAC and ECDSA
Message-ID: <AS8PR07MB75106A62CE0B05E8E9FC0439D5E09@AS8PR07MB7510.eurprd07.prod.outlook.com>

Good morning everyone, I'm trying to find the source code of the Known Answer FIPS Test for the HMAC and ECDSA algorithms on the GitHub project, but I'm not able to find them. Any tips of where they are?.

Also is there any example of how to call the HMAC and ECDSA FIPS certified self-tests with the OpenSSL C library?

Yours sincerely, Fernando.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221214/bc583967/attachment.htm>

From wiktor at metacode.biz  Thu Dec 15 16:57:50 2022
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Thu, 15 Dec 2022 17:57:50 +0100
Subject: "num" parameter and expected output buffer size in EVP_CipherUpdate
Message-ID: <b2637d67-bf28-9894-639b-014db13adf87@metacode.biz>

Hello,

I've got a question about the "num" parameter of the cipher context 
(EVP_CIPHER_CTX_get_num [0]). The documentation states:

> Gets or sets the cipher specific "num" parameter for the associated ctx. Built-in ciphers typically use this to track how much of the current underlying block has been "used" already.

I'd like to use this parameter to check in advance how big should the 
output buffer passed to EVP_CipherUpdate be. My understanding of it was 
that "num" would be incremented if I feed partial block to 
EVP_CipherUpdate but I've failed to observe any other values of "num" 
than 0.

My two questions:

   - what is the "num" parameter used for? is it only for internal use?

and, more importantly,

   - given EVP_CIPHER_CTX object and the length of the input buffer, is 
it possible to calculate the needed output buffer size without 
explicitly keeping external state?

The manual algorithm on how it is handled has been excellently described 
by Matt here [1]. I'm wondering if it's possible to calculate that in 
code (from OpenSSL client's perspective).

Thank you in advance for your time!

Kind regards,
Wiktor

[0]: https://www.openssl.org/docs/man3.0/man3/EVP_CIPHER_CTX_get_num.html

[1]: 
https://mta.openssl.org/pipermail/openssl-users/2022-November/015623.html

Below you will find sample code that reproduces the behavior of "num" 
I've seen. (Please beware that C is not my native language :))

#include <string.h>
#include <openssl/evp.h>

int main()
{
     unsigned char outbuf[1024];
     int outlen, tmplen;
     unsigned char key[] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
     unsigned char iv[] = {1,2,3,4,5,6,7,8};
     char intext[] = "1234567"; // half of block size
     EVP_CIPHER_CTX *ctx;
     FILE *out;
     int num;
     unsigned int block_size;

     ctx = EVP_CIPHER_CTX_new();
     EVP_EncryptInit_ex2(ctx, EVP_aes_128_cbc(), key, iv, NULL);

     block_size = EVP_CIPHER_CTX_block_size(ctx);
     printf("Block size: %d\n", block_size); // 16- block cipher

     num = EVP_CIPHER_CTX_num(ctx);
     printf("Num is: %d\n", num); // num is 0

     if (!EVP_CipherUpdate(ctx, outbuf, &outlen, intext, strlen(intext))) {
         EVP_CIPHER_CTX_free(ctx);
         return 1;
     }
     printf("Out len: %d\n", outlen); // 0 - no block produced, OK

     num = EVP_CIPHER_CTX_num(ctx);
     printf("Num is: %d\n", num); // num is still 0

     // I want to know the exact size of output buffer needed here
     if (!EVP_CipherFinal(ctx, outbuf + outlen, &tmplen)) {
         EVP_CIPHER_CTX_free(ctx);
         return 1;
     }
     outlen += tmplen;
     EVP_CIPHER_CTX_free(ctx);
     out = fopen("outfile", "wb");
     if (out == NULL) {
         return 1;
     }
     fwrite(outbuf, 1, outlen, out);
     fclose(out);
     return 0;
}

From michel.sales at online.fr  Thu Dec 15 18:17:13 2022
From: michel.sales at online.fr (Michel)
Date: Thu, 15 Dec 2022 19:17:13 +0100
Subject: "num" parameter and expected output buffer size in
 EVP_CipherUpdate
In-Reply-To: <b2637d67-bf28-9894-639b-014db13adf87@metacode.biz>
References: <b2637d67-bf28-9894-639b-014db13adf87@metacode.biz>
Message-ID: <000601d910b1$75927a90$60b76fb0$@sales@online.fr>

Hi Wiktor,

> and, more importantly,
> - given EVP_CIPHER_CTX object and the length of the input buffer, is 
> it possible to calculate the needed output buffer size without 
> explicitly keeping external state?

I may not have understood your question, but, as stated in [1], isn't :
"the amount of data written can be anything from zero bytes to (inl + cipher_block_size) bytes" (at a maximum)
what you are asking for ?

Resulting in cipher_block_size bytes needed (at max, may be 0) when calling EVP_CipherFinal() ?

>From : https://www.openssl.org/docs/manmaster/man3/EVP_EncryptUpdate.html
?The encrypted final data is written to out which should have sufficient space for one cipher block?.

Hope this helps,

Regards,

Michel.

[1]: https://mta.openssl.org/pipermail/openssl-users/2022-November/015623.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221215/6b1081e2/attachment.htm>

From wiktor at metacode.biz  Thu Dec 15 19:44:05 2022
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Thu, 15 Dec 2022 20:44:05 +0100
Subject: "num" parameter and expected output buffer size in
 EVP_CipherUpdate
In-Reply-To: <000601d910b1$75927a90$60b76fb0$@sales@online.fr>
References: <b2637d67-bf28-9894-639b-014db13adf87@metacode.biz>
 <000601d910b1$75927a90$60b76fb0$@sales@online.fr>
Message-ID: <1f6fa488-1c8b-b953-9c91-7b96dd7f0c23@metacode.biz>

Hi Michel,

On 15.12.2022 19:17, Michel wrote:
> ///"the amount of data written can be anything from zero bytes to (inl + 
> cipher_block_size) bytes"/(at a maximum)
> 
> what you are asking for ?
> 
> Resulting in///cipher_block_size/bytesneeded (at max, may be 0) when 
> callingEVP_CipherFinal() ?
> 
> ?///The encrypted final data is written to////out////which should have 
> sufficient space for one cipher block/?.

This gives a range and I'm looking for exact value. That value can be 
calculated using Matt's description [0]. I'm wondering if that can be 
done without keeping external state, just using cipher API.

The "num" parameter looked like exactly what I was looking for but 
either I'm holding it wrong or I misunderstood its purpose.

The use case I have in mind is to provide safe API that checks if the 
client provided buffer big enough for next call to CipherUpdate. In some 
cases, for example when encrypting data block by block by the client, 
the output buffer of one block is sufficient.

I hope that clarifies the use case I have in mind.

Have a nice day!

Kind regards,
Wiktor

[0]: 
https://mta.openssl.org/pipermail/openssl-users/2022-November/015623.html

From michel.sales at online.fr  Thu Dec 15 20:19:27 2022
From: michel.sales at online.fr (Michel)
Date: Thu, 15 Dec 2022 21:19:27 +0100
Subject: "num" parameter and expected output buffer size in
 EVP_CipherUpdate
In-Reply-To: <1f6fa488-1c8b-b953-9c91-7b96dd7f0c23@metacode.biz>
References: <b2637d67-bf28-9894-639b-014db13adf87@metacode.biz>
 <000601d910b1$75927a90$60b76fb0$@sales@online.fr>
 <1f6fa488-1c8b-b953-9c91-7b96dd7f0c23@metacode.biz>
Message-ID: <001101d910c2$890905b0$9b1b1110$@sales@online.fr>

> This gives a range and I'm looking for exact value. 

Ha, OK. I missed that.
But don't you think that an exact value smaller than the 
cipher block size might look like an hazardous 'optimization', 
for a very hypothetical gain ?

I don't know much about EVP_CIPHER_CTX_num() use case, 
looks new to me (OpenSSL version > 3 ?),
sorry.

Regards,

Michel.

-----Message d'origine-----

This gives a range and I'm looking for exact value. That value can be 
calculated using Matt's description [0]. I'm wondering if that can be 
done without keeping external state, just using cipher API.

The "num" parameter looked like exactly what I was looking for but 
either I'm holding it wrong or I misunderstood its purpose.

The use case I have in mind is to provide safe API that checks if the 
client provided buffer big enough for next call to CipherUpdate. In some 
cases, for example when encrypting data block by block by the client, 
the output buffer of one block is sufficient.

I hope that clarifies the use case I have in mind.

Have a nice day!

Kind regards,
Wiktor

[0]: 
https://mta.openssl.org/pipermail/openssl-users/2022-November/015623.html


From wiktor at metacode.biz  Fri Dec 16 09:51:23 2022
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Fri, 16 Dec 2022 10:51:23 +0100
Subject: "num" parameter and expected output buffer size in
 EVP_CipherUpdate
In-Reply-To: <001101d910c2$890905b0$9b1b1110$@sales@online.fr>
References: <b2637d67-bf28-9894-639b-014db13adf87@metacode.biz>
 <000601d910b1$75927a90$60b76fb0$@sales@online.fr>
 <1f6fa488-1c8b-b953-9c91-7b96dd7f0c23@metacode.biz>
 <001101d910c2$890905b0$9b1b1110$@sales@online.fr>
Message-ID: <2c7cc277-8186-0b47-8092-3ad755ce2f5d@metacode.biz>

Hi Michel,

On 15.12.2022 21:19, Michel wrote:
> But don't you think that an exact value smaller than the
> cipher block size might look like an hazardous 'optimization',
> for a very hypothetical gain ?

The maximum possible output buffer size is *twice* the block size (due 
to any partial blocks that may have been updated previously). As I'm 
updating the cipher block by block output buffer size equal to block 
size should be sufficient.

> I don't know much about EVP_CIPHER_CTX_num() use case,
> looks new to me (OpenSSL version > 3 ?),
> sorry.

It was introduced in 1.1.0 in this commit:

> commit 83b06347023a573433b6aa23c8042f89df869f9e
> Author: Richard Levitte <levitte at openssl.org>
> Date:   Sun Dec 13 21:25:42 2015 +0100
> 
>     Add accessors and writers for EVP_CIPHER_CTX
>     
>     New functions:
>     
>     - EVP_CIPHER_CTX_encrypting()
>     - EVP_CIPHER_CTX_iv()
>     - EVP_CIPHER_CTX_iv_noconst()
>     - EVP_CIPHER_CTX_original_iv()
>     - EVP_CIPHER_CTX_buf_noconst()
>     - EVP_CIPHER_CTX_num()
>     - EVP_CIPHER_CTX_set_num()
>     - EVP_CIPHER_CTX_cipher_data()

but it appears it's not widely used outside of OpenSSL's internals (at 
least I didn't get any meaningful search results).

Thanks for your time!

Kind regards,
Wiktor

From tomas at openssl.org  Fri Dec 16 10:53:46 2022
From: tomas at openssl.org (Tomas Mraz)
Date: Fri, 16 Dec 2022 11:53:46 +0100
Subject: "num" parameter and expected output buffer size in
 EVP_CipherUpdate
In-Reply-To: <1f6fa488-1c8b-b953-9c91-7b96dd7f0c23@metacode.biz>
References: <b2637d67-bf28-9894-639b-014db13adf87@metacode.biz>
 <000601d910b1$75927a90$60b76fb0$@sales@online.fr>
 <1f6fa488-1c8b-b953-9c91-7b96dd7f0c23@metacode.biz>
Message-ID: <e4605631627e759e853c9fb47e77f2292110631d.camel@openssl.org>

On Thu, 2022-12-15 at 20:44 +0100, Wiktor Kwapisiewicz via openssl-
users wrote:
> Hi Michel,
> 
> On 15.12.2022 19:17, Michel wrote:
> > ///"the amount of data written can be anything from zero bytes to
> > (inl + 
> > cipher_block_size) bytes"/(at a maximum)
> > 
> > what you are asking for ?
> > 
> > Resulting in///cipher_block_size/bytesneeded (at max, may be 0)
> > when 
> > callingEVP_CipherFinal() ?
> > 
> > ?///The encrypted final data is written to////out////which should
> > have 
> > sufficient space for one cipher block/?.
> 
> This gives a range and I'm looking for exact value. That value can be
> calculated using Matt's description [0]. I'm wondering if that can be
> done without keeping external state, just using cipher API.
> 
> The "num" parameter looked like exactly what I was looking for but 
> either I'm holding it wrong or I misunderstood its purpose.
> 
> The use case I have in mind is to provide safe API that checks if the
> client provided buffer big enough for next call to CipherUpdate. In
> some 
> cases, for example when encrypting data block by block by the client,
> the output buffer of one block is sufficient.
> 
> I hope that clarifies the use case I have in mind.

There is no way to get the exact output buffer size needed than by
knowing the cipher an the provider. If you know that the cipher used is
producing the ciphertext with the same length as the plaintext (at
least in the circumstances you follow - for example the length is a
multiple of the block size), then you know that if for every previous
call to EncryptUpdate (if there was any) the output ciphertext size was
the same as the plaintext size, then the next EncryptUpdate call cannot
produce any more ciphertext bytes than plaintext size.

Of course once you feed the data to EncryptUpdate by chunks sized
smaller than block size, there logically has to be some caching
involved as a block cipher must encrypt only full blocks unless there
is some padding involved but that applies only to the last block.

In case of AEAD modes this is also different as there must be some
additional space in the ciphertext for the tag.

-- 
Tom?? Mr?z, OpenSSL


From wiktor at metacode.biz  Fri Dec 16 11:08:24 2022
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Fri, 16 Dec 2022 12:08:24 +0100
Subject: "num" parameter and expected output buffer size in
 EVP_CipherUpdate
In-Reply-To: <e4605631627e759e853c9fb47e77f2292110631d.camel@openssl.org>
References: <b2637d67-bf28-9894-639b-014db13adf87@metacode.biz>
 <000601d910b1$75927a90$60b76fb0$@sales@online.fr>
 <1f6fa488-1c8b-b953-9c91-7b96dd7f0c23@metacode.biz>
 <e4605631627e759e853c9fb47e77f2292110631d.camel@openssl.org>
Message-ID: <a84af70e-11f4-fe7c-4593-2d52f5874b78@metacode.biz>

Hi Tom??,

On 16.12.2022 11:53, Tomas Mraz wrote:
> Of course once you feed the data to EncryptUpdate by chunks sized
> smaller than block size, there logically has to be some caching
> involved as a block cipher must encrypt only full blocks unless there
> is some padding involved but that applies only to the last block.

Okay, if I understood you correctly there's no API to ask an already 
intitialized EVP_CIPHER_CTX object about the cache as this is 
implementation detail?

(I thought EVP_CIPHER_CTX_get_num would do that but apparently not...)

> In case of AEAD modes this is also different as there must be some
> additional space in the ciphertext for the tag.

Yes, understood.

Thank you for answers!

Kind regards,
Wiktor

From tomas at openssl.org  Fri Dec 16 14:26:28 2022
From: tomas at openssl.org (Tomas Mraz)
Date: Fri, 16 Dec 2022 15:26:28 +0100
Subject: "num" parameter and expected output buffer size in
 EVP_CipherUpdate
In-Reply-To: <a84af70e-11f4-fe7c-4593-2d52f5874b78@metacode.biz>
References: <b2637d67-bf28-9894-639b-014db13adf87@metacode.biz>
 <000601d910b1$75927a90$60b76fb0$@sales@online.fr>
 <1f6fa488-1c8b-b953-9c91-7b96dd7f0c23@metacode.biz>
 <e4605631627e759e853c9fb47e77f2292110631d.camel@openssl.org>
 <a84af70e-11f4-fe7c-4593-2d52f5874b78@metacode.biz>
Message-ID: <2d13f647de629f59eea75d9b04b34352fde90703.camel@openssl.org>

On Fri, 2022-12-16 at 12:08 +0100, Wiktor Kwapisiewicz wrote:
> Hi Tom??,
> 
> On 16.12.2022 11:53, Tomas Mraz wrote:
> > Of course once you feed the data to EncryptUpdate by chunks sized
> > smaller than block size, there logically has to be some caching
> > involved as a block cipher must encrypt only full blocks unless
> > there
> > is some padding involved but that applies only to the last block.
> 
> Okay, if I understood you correctly there's no API to ask an already 
> intitialized EVP_CIPHER_CTX object about the cache as this is 
> implementation detail?
> 
> (I thought EVP_CIPHER_CTX_get_num would do that but apparently
> not...)

Yep, there is no such API. Especially the provider interface does not
provide any such call.

-- 
Tom?? Mr?z, OpenSSL


From arielrm at outlook.com  Fri Dec 16 15:09:43 2022
From: arielrm at outlook.com (Ariel R.)
Date: Fri, 16 Dec 2022 15:09:43 +0000
Subject: Openssl 3.0.7 in Centos 7.9
In-Reply-To: <SA1P223MB0607F74B63C9DBCAC134C4DBB0E69@SA1P223MB0607.NAMP223.PROD.OUTLOOK.COM>
References: <SA1P223MB0607F74B63C9DBCAC134C4DBB0E69@SA1P223MB0607.NAMP223.PROD.OUTLOOK.COM>
Message-ID: <SA1P223MB06071A05F22C375CF0C1B891B0E69@SA1P223MB0607.NAMP223.PROD.OUTLOOK.COM>

FYI

From: Ariel R.
Sent: Friday, December 16, 2022 11:04 AM
To: openssl-users at openssl.org
Subject: Openssl 3.0.7 in Centos 7.9

Hello,
I have installed OpenSSL 3.0.7 in a server running CentOS 7.9.2009

#About the installation
These are the commands used for the installation:
sudo yum install perl-IPC-Cmd perl-Test-Simple
cd /usr/src
wget https://www.openssl.org/source/openssl-3.0.7.tar.gz
tar -zxf openssl-3.0.7.tar.gz
rm openssl-3.0.7.tar.gz
cd /usr/src/openssl-3.0.7
./config
make
make test
make install
ln -s /usr/local/lib64/libssl.so.3 /usr/lib64/libssl.so.3
ln -s /usr/local/lib64/libcrypto.so.3 /usr/lib64/libcrypto.so.3
openssl version


#About the problem
In the console, if I run "openssl version", I can see the version installed is indeed 3.0.7, which is ok.
The problem is that Apache is still referencing the old version:
Server Version: Apache/2.4.54 (cPanel) OpenSSL/1.1.1s


#My question:
How can I change it to the 3.0.7 version?


Thanks in advance for your kind support.

Regards,


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221216/307e5cca/attachment.htm>

From arielrm at outlook.com  Fri Dec 16 15:11:45 2022
From: arielrm at outlook.com (Ariel R.)
Date: Fri, 16 Dec 2022 15:11:45 +0000
Subject: Openssl 3.0.7 in Centos 7.9
In-Reply-To: <SA1P223MB0607F74B63C9DBCAC134C4DBB0E69@SA1P223MB0607.NAMP223.PROD.OUTLOOK.COM>
References: <SA1P223MB0607F74B63C9DBCAC134C4DBB0E69@SA1P223MB0607.NAMP223.PROD.OUTLOOK.COM>
Message-ID: <SA1P223MB0607A3912566FBE6A2CED750B0E69@SA1P223MB0607.NAMP223.PROD.OUTLOOK.COM>

Hello,
I have installed OpenSSL 3.0.7 in a server running CentOS 7.9.2009

#About the installation
These are the commands used for the installation:
sudo yum install perl-IPC-Cmd perl-Test-Simple
cd /usr/src
wget https://www.openssl.org/source/openssl-3.0.7.tar.gz
tar -zxf openssl-3.0.7.tar.gz
rm openssl-3.0.7.tar.gz
cd /usr/src/openssl-3.0.7
./config
make
make test
make install
ln -s /usr/local/lib64/libssl.so.3 /usr/lib64/libssl.so.3
ln -s /usr/local/lib64/libcrypto.so.3 /usr/lib64/libcrypto.so.3
openssl version


#About the problem
In the console, if I run "openssl version", I can see the version installed is indeed 3.0.7, which is ok.
The problem is that Apache is still referencing the old version:
Server Version: Apache/2.4.54 (cPanel) OpenSSL/1.1.1s


#My question:
How can I change it to the 3.0.7 version?


Thanks in advance for your kind support.

Regards,


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221216/13b6cc8f/attachment-0001.htm>

From Jochen.Bern at binect.de  Fri Dec 16 15:31:07 2022
From: Jochen.Bern at binect.de (Jochen Bern)
Date: Fri, 16 Dec 2022 16:31:07 +0100
Subject: openssl-users Digest, Vol 97, Issue 9
Message-ID: <6cfd8ea6-0413-de1c-6c33-e15e06878dc8@binect.de>

On 16.12.22 16:11, openssl-users-request at openssl.org digested:
> I have installed OpenSSL 3.0.7 in a server running CentOS 7.9.2009
[...]
> The problem is that Apache is still referencing the old version:
> Server Version: Apache/2.4.54 (cPanel) OpenSSL/1.1.1s
[...]
> How can I change it to the 3.0.7 version?

No idea whether that's the *only* place that you'll need to tweak, but 
CentOS 7's mod_ssl package installs a module
	/usr/lib64/httpd/modules/mod_ssl.so
that is explicitly linked against

>         libssl.so.10 => /lib64/libssl.so.10 (...)
>         libcrypto.so.10 => /lib64/libcrypto.so.10 (...)

instead of ...so.3 or the agnostic ...so, so you'll need to build 
(against the .3 libs) and use a custom mod_ssl as well.

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221216/592d4283/attachment.p7s>

From arielrm at outlook.com  Fri Dec 16 15:48:05 2022
From: arielrm at outlook.com (Ariel R.)
Date: Fri, 16 Dec 2022 15:48:05 +0000
Subject: openssl-users Digest, Vol 97, Issue 9
In-Reply-To: <6cfd8ea6-0413-de1c-6c33-e15e06878dc8@binect.de>
References: <6cfd8ea6-0413-de1c-6c33-e15e06878dc8@binect.de>
Message-ID: <SA1P223MB06075CFD5CF4F79C9B26A104B0E69@SA1P223MB0607.NAMP223.PROD.OUTLOOK.COM>

Thanks for your response Jochen

I have created a feature request to make it easier for other users:
https://github.com/openssl/openssl/issues/19928 

Regards,

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jochen Bern
Sent: Friday, December 16, 2022 11:31 AM
To: openssl-users at openssl.org
Subject: Re: openssl-users Digest, Vol 97, Issue 9

On 16.12.22 16:11, openssl-users-request at openssl.org digested:
> I have installed OpenSSL 3.0.7 in a server running CentOS 7.9.2009
[...]
> The problem is that Apache is still referencing the old version:
> Server Version: Apache/2.4.54 (cPanel) OpenSSL/1.1.1s
[...]
> How can I change it to the 3.0.7 version?

No idea whether that's the *only* place that you'll need to tweak, but 
CentOS 7's mod_ssl package installs a module
	/usr/lib64/httpd/modules/mod_ssl.so
that is explicitly linked against

>         libssl.so.10 => /lib64/libssl.so.10 (...)
>         libcrypto.so.10 => /lib64/libcrypto.so.10 (...)

instead of ...so.3 or the agnostic ...so, so you'll need to build 
(against the .3 libs) and use a custom mod_ssl as well.

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH

From pierreluc.boily at gmail.com  Fri Dec 16 22:07:51 2022
From: pierreluc.boily at gmail.com (Pierre-Luc Boily)
Date: Fri, 16 Dec 2022 17:07:51 -0500
Subject: How to fix "OpenSSL failed - error:0A000086:SSL routines::certificate
 verify failed"
Message-ID: <CACTRa=sS8mxStmq_-N9HBdgsKZFiozheyOm44F5md5Vqnqgdcw@mail.gmail.com>

Hello,

*Details*
OS : WIndows 10
Arch : x64
Compiler : VisualStudio 2017

I have a *c++ wss IXWebSocket
<https://github.com/machinezone/IXWebSocket> client* that tries to connect
to a *nodejs https/websocket server* but the client refuses to connect and
returns the error : *OpenSSL failed - error:0A000086:SSL
routines::certificate verify failed*
*What I tried*

   1. I have a React front end using wss to communicate to my https nodejs
   server. *It works ->* *This confirms that my key and certificate are
   valid.*
   2. I also tried the same c++ client above, not secured (no wss)
   connecting to my same nodejs server, but http/websocket (non secure). *It
   works*.

So, I had to dig into the OpenSSL code and I found where the error is
triggered, see code below.  In my case *s->verify_mode* is equal to
*SSL_VERIFY_PEER* and *i* equal to *0* and I don't know if those values are
OK or not.

While I was digging into the code, I also realized that *SSL_OP_NO_TLSv1_3*
is automagically defined for my code.  I feel that it is incorrect.

*From statem_clnt.c line 1888*:
    if (s->verify_mode != SSL_VERIFY_NONE && i <= 0) {
        SSLfatal(s, ssl_x509err2alert(s->verify_result),
                 SSL_R_CERTIFICATE_VERIFY_FAILED);
        return WORK_ERROR;
    }

*Stacktrace*:
> libssl-3-x64.dll!tls_post_process_server_certificate(ssl_st
  libssl-3-x64.dll!ossl_statem_client_post_process_message(ss
  libssl-3-x64.dll!read_state_machine(ssl_st * s) Line 675
  libssl-3-x64.dll!state_machine(ssl_st * s, int server) Line
  libssl-3-x64.dll!ossl_statem_connect(ssl_st * s) Line 266
  libssl-3-x64.dll!SSL_do_handshake(ssl_st * s) Line 3937 C
  libssl-3-x64.dll!SSL_connect(ssl_st * s) Line 1760 C
  testWSClient.exe!ix::SocketOpenSSL::openSSLClientHandshake(
  testWSClient.exe!ix::SocketOpenSSL::connect(const std::basi
  testWSClient.exe!ix::WebSocketHandshake::clientHandshake(co
  testWSClient.exe!ix::WebSocketTransport::connectToUrl(const
  testWSClient.exe!ix::WebSocket::connect(int timeoutSecs) Li
  testWSClient.exe!ix::WebSocket::checkConnection(bool firstC
  testWSClient.exe!ix::WebSocket::run() Line 367 C++

*IXWebClient, how key/cert are set :*
    ix::SocketTLSOptions tlsOptions;
    tlsOptions.certFile = "WebRTC.test.crt";
    tlsOptions.keyFile = "WebRTC.test.key";
    tlsOptions.caFile = "WebRTC-CA.pem";
    webSocket.setTLSOptions(tlsOptions);
    std::string url("wss://localhost:8080");
    webSocket.setUrl(url);

No matter if the path of the key/certificate exists or not, I have the same
error message from OpenSSL, which is weird...

*So :*
1. Any idea why I have *certificate verify failed*?
2. Is it normal that *s->verify_mode* is equal to *SSL_VERIFY_PEER*
and *i* equal
to *0*
3. Is it normal that *SSL_OP_NO_TLSv1_3* is enabled in the code?

Thanks a lot for any help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221216/11778b0f/attachment-0001.htm>

From psv_sridhar at yahoo.com  Fri Dec 16 22:14:06 2022
From: psv_sridhar at yahoo.com (psv sridhar)
Date: Fri, 16 Dec 2022 22:14:06 +0000 (UTC)
Subject: How to fix "OpenSSL failed - error:0A000086:SSL
 routines::certificate verify failed"
In-Reply-To: <CACTRa=sS8mxStmq_-N9HBdgsKZFiozheyOm44F5md5Vqnqgdcw@mail.gmail.com>
References: <CACTRa=sS8mxStmq_-N9HBdgsKZFiozheyOm44F5md5Vqnqgdcw@mail.gmail.com>
Message-ID: <1030394545.643155.1671228846622@mail.yahoo.com>

you are sending flooded emails wrongly. stop it.
?Thanks and Regards
Sridhar PSVPhone 571 244-5862 

    On Friday, December 16, 2022 at 04:08:38 PM CST, Pierre-Luc Boily <pierreluc.boily at gmail.com> wrote:  
 
 Hello,

Details
OS : WIndows 10Arch : x64Compiler : VisualStudio 2017
I have a?c++ wss?IXWebSocket?client?that tries to connect to a?nodejs https/websocket server?but the client refuses to connect and returns the error :?OpenSSL failed - error:0A000086:SSL routines::certificate verify failed
What I tried
   
   - I have a React front end using wss to communicate to my https nodejs server.?It works ->?This confirms that my key and certificate?are valid.
   - I also tried the same c++ client above, not secured (no wss) connecting to my same nodejs server, but http/websocket (non secure).?It works.
So, I had to dig into the OpenSSL code and I found where the error is triggered, see code below.? In my case?s->verify_mode?is equal to?SSL_VERIFY_PEER?and?i?equal to?0?and I don't know if those values are OK or not.
While I was?digging into the code, I also realized that?SSL_OP_NO_TLSv1_3 is automagically defined for my code.? I feel that it is incorrect.
>From statem_clnt.c line 1888:? ? if (s->verify_mode != SSL_VERIFY_NONE && i <= 0) {
? ? ? ? SSLfatal(s, ssl_x509err2alert(s->verify_result),
? ? ? ? ? ? ? ? ?SSL_R_CERTIFICATE_VERIFY_FAILED);
? ? ? ? return WORK_ERROR;
? ? }

Stacktrace:> libssl-3-x64.dll!tls_post_process_server_certificate(ssl_st
? libssl-3-x64.dll!ossl_statem_client_post_process_message(ss
? libssl-3-x64.dll!read_state_machine(ssl_st * s) Line 675 
? libssl-3-x64.dll!state_machine(ssl_st * s, int server) Line
? libssl-3-x64.dll!ossl_statem_connect(ssl_st * s) Line 266 
? libssl-3-x64.dll!SSL_do_handshake(ssl_st * s) Line 3937 C ?
? libssl-3-x64.dll!SSL_connect(ssl_st * s) Line 1760 C ? ? ?
? testWSClient.exe!ix::SocketOpenSSL::openSSLClientHandshake(
? testWSClient.exe!ix::SocketOpenSSL::connect(const std::basi
? testWSClient.exe!ix::WebSocketHandshake::clientHandshake(co
? testWSClient.exe!ix::WebSocketTransport::connectToUrl(const
? testWSClient.exe!ix::WebSocket::connect(int timeoutSecs) Li
? testWSClient.exe!ix::WebSocket::checkConnection(bool firstC
? testWSClient.exe!ix::WebSocket::run() Line 367 C++? ? ? ??

IXWebClient, how key/cert are set :? ? ix::SocketTLSOptions tlsOptions;
? ? tlsOptions.certFile = "WebRTC.test.crt";
? ? tlsOptions.keyFile = "WebRTC.test.key";
? ? tlsOptions.caFile = "WebRTC-CA.pem";
? ? webSocket.setTLSOptions(tlsOptions);
? ? std::string url("wss://localhost:8080");
? ? webSocket.setUrl(url);

No matter if the?path of the key/certificate exists or not, I have the same error message from OpenSSL, which is weird...
So :?1. Any idea why I?have?certificate verify failed?2. Is it normal that?s->verify_mode?is equal to?SSL_VERIFY_PEER?and?i?equal to?03. Is it normal that?SSL_OP_NO_TLSv1_3 is enabled in the code?
Thanks a lot for any help.  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221216/6f785cda/attachment.htm>

From pierreluc.boily at gmail.com  Fri Dec 16 22:20:02 2022
From: pierreluc.boily at gmail.com (Pierre-Luc Boily)
Date: Fri, 16 Dec 2022 17:20:02 -0500
Subject: How to fix "OpenSSL failed - error:0A000086:SSL
 routines::certificate verify failed"
In-Reply-To: <1030394545.643155.1671228846622@mail.yahoo.com>
References: <CACTRa=sS8mxStmq_-N9HBdgsKZFiozheyOm44F5md5Vqnqgdcw@mail.gmail.com>
 <1030394545.643155.1671228846622@mail.yahoo.com>
Message-ID: <CACTRa=uMmeg3TeJT9Z2WwK0ZQ4eQDesKo=+3sEpSpxAjFbT9MQ@mail.gmail.com>

I am asking a question regarding OpenSSL.  I thought the mailing list was
the place.  I read this on the github page of OpenSSL







*    If you have questions about how to use OpenSSL for specific tasks
or how to solve certain problems you have when using it, you might    want
to ask them on the openssl-users at openssl.org <openssl-users at openssl.org>
mailing list.    There you can get help from a great community of OpenSSL
users,    not only (but including) the OpenSSL developers. For more
information    about our mailing lists, see
https://www.openssl.org/community/mailinglists.html
<https://www.openssl.org/community/mailinglists.html>.*



Le ven. 16 d?c. 2022, ? 17 h 14, psv sridhar <psv_sridhar at yahoo.com> a
?crit :

> you are sending flooded emails wrongly. stop it.
>
>
>
> *Thanks and Regards**Sridhar PSV*
> *Phone 571 244-5862*
>
>
> On Friday, December 16, 2022 at 04:08:38 PM CST, Pierre-Luc Boily <
> pierreluc.boily at gmail.com> wrote:
>
>
> Hello,
>
> *Details*
> OS : WIndows 10
> Arch : x64
> Compiler : VisualStudio 2017
>
> I have a *c++ wss IXWebSocket
> <https://github.com/machinezone/IXWebSocket> client* that tries to
> connect to a *nodejs https/websocket server* but the client refuses to
> connect and returns the error : *OpenSSL failed - error:0A000086:SSL
> routines::certificate verify failed*
> *What I tried*
>
>    1. I have a React front end using wss to communicate to my https
>    nodejs server. *It works ->* *This confirms that my key and
>    certificate are valid.*
>    2. I also tried the same c++ client above, not secured (no wss)
>    connecting to my same nodejs server, but http/websocket (non secure). *It
>    works*.
>
> So, I had to dig into the OpenSSL code and I found where the error is
> triggered, see code below.  In my case *s->verify_mode* is equal to
> *SSL_VERIFY_PEER* and *i* equal to *0* and I don't know if those values
> are OK or not.
>
> While I was digging into the code, I also realized that
> *SSL_OP_NO_TLSv1_3* is automagically defined for my code.  I feel that it
> is incorrect.
>
> *From statem_clnt.c line 1888*:
>     if (s->verify_mode != SSL_VERIFY_NONE && i <= 0) {
>         SSLfatal(s, ssl_x509err2alert(s->verify_result),
>                  SSL_R_CERTIFICATE_VERIFY_FAILED);
>         return WORK_ERROR;
>     }
>
> *Stacktrace*:
> > libssl-3-x64.dll!tls_post_process_server_certificate(ssl_st
>   libssl-3-x64.dll!ossl_statem_client_post_process_message(ss
>   libssl-3-x64.dll!read_state_machine(ssl_st * s) Line 675
>   libssl-3-x64.dll!state_machine(ssl_st * s, int server) Line
>   libssl-3-x64.dll!ossl_statem_connect(ssl_st * s) Line 266
>   libssl-3-x64.dll!SSL_do_handshake(ssl_st * s) Line 3937 C
>   libssl-3-x64.dll!SSL_connect(ssl_st * s) Line 1760 C
>   testWSClient.exe!ix::SocketOpenSSL::openSSLClientHandshake(
>   testWSClient.exe!ix::SocketOpenSSL::connect(const std::basi
>   testWSClient.exe!ix::WebSocketHandshake::clientHandshake(co
>   testWSClient.exe!ix::WebSocketTransport::connectToUrl(const
>   testWSClient.exe!ix::WebSocket::connect(int timeoutSecs) Li
>   testWSClient.exe!ix::WebSocket::checkConnection(bool firstC
>   testWSClient.exe!ix::WebSocket::run() Line 367 C++
>
> *IXWebClient, how key/cert are set :*
>     ix::SocketTLSOptions tlsOptions;
>     tlsOptions.certFile = "WebRTC.test.crt";
>     tlsOptions.keyFile = "WebRTC.test.key";
>     tlsOptions.caFile = "WebRTC-CA.pem";
>     webSocket.setTLSOptions(tlsOptions);
>     std::string url("wss://localhost:8080");
>     webSocket.setUrl(url);
>
> No matter if the path of the key/certificate exists or not, I have the
> same error message from OpenSSL, which is weird...
>
> *So :*
> 1. Any idea why I have *certificate verify failed*?
> 2. Is it normal that *s->verify_mode* is equal to *SSL_VERIFY_PEER* and
> *i* equal to *0*
> 3. Is it normal that *SSL_OP_NO_TLSv1_3* is enabled in the code?
>
> Thanks a lot for any help.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221216/0af4beae/attachment-0001.htm>

From Michael.Wojcik at microfocus.com  Fri Dec 16 23:05:45 2022
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 16 Dec 2022 23:05:45 +0000
Subject: How to fix "OpenSSL failed - error:0A000086:SSL
 routines::certificate verify failed"
In-Reply-To: <CACTRa=uMmeg3TeJT9Z2WwK0ZQ4eQDesKo=+3sEpSpxAjFbT9MQ@mail.gmail.com>
References: <CACTRa=sS8mxStmq_-N9HBdgsKZFiozheyOm44F5md5Vqnqgdcw@mail.gmail.com>
 <1030394545.643155.1671228846622@mail.yahoo.com>
 <CACTRa=uMmeg3TeJT9Z2WwK0ZQ4eQDesKo=+3sEpSpxAjFbT9MQ@mail.gmail.com>
Message-ID: <DM6PR18MB27003D96DF332C2598BFB26CF9E69@DM6PR18MB2700.namprd18.prod.outlook.com>

[Apologies to the list for top-posting and HTML email. I'm in a hurry and don't have time to reformat.]

No idea who "psv sridhar" is ? I don't recall ever seeing that name here on openssl-users before ? but I don't see anything inappropriate about your message. Ignore him/her.

OpenSSL is telling you that it wasn't able to verify the peer's certificate. That's probably because you haven't loaded the correct collection of trust anchors (root certificates, and possibly intermediate certificates as well).

You ask whether SSL_VERIFY_PEER should be set. Yes, it *must* be set, except in unusual circumstances (e.g. you're using a pre-shared key); otherwise you're vulnerable to MITM interception and have no security under any reasonable threat model.

Your questions suggest you're not a TLS expert. TLS is extremely easy to get wrong (which is why a huge number of applications, particularly in the mobile space, get it wrong), so I would strongly recommend you do some research before proceeding. There are any number of introductions to SSL/TLS online, though personally if one of my teams were starting with TLS I'd require at least one of them read a more substantial introduction, such as Rescorla's /SSL and TLS/ or Ristic's /Bulletproof TLS/.


From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Pierre-Luc Boily
Sent: Friday, 16 December, 2022 16:20
To: psv sridhar <psv_sridhar at yahoo.com>
Cc: openssl-users at openssl.org
Subject: Re: How to fix "OpenSSL failed - error:0A000086:SSL routines::certificate verify failed"

I am asking a question regarding OpenSSL.  I thought the mailing list was the place.  I read this on the github page of OpenSSL

    If you have questions about how to use OpenSSL for specific tasks
    or how to solve certain problems you have when using it, you might
    want to ask them on the openssl-users at openssl.org<mailto:openssl-users at openssl.org> mailing list.
    There you can get help from a great community of OpenSSL users,
    not only (but including) the OpenSSL developers. For more information
    about our mailing lists, see
    https://www.openssl.org/community/mailinglists.html.



Le ven. 16 d?c. 2022, ? 17 h 14, psv sridhar <psv_sridhar at yahoo.com<mailto:psv_sridhar at yahoo.com>> a ?crit :
you are sending flooded emails wrongly. stop it.


Thanks and Regards
Sridhar PSV
Phone 571 244-5862


On Friday, December 16, 2022 at 04:08:38 PM CST, Pierre-Luc Boily <pierreluc.boily at gmail.com<mailto:pierreluc.boily at gmail.com>> wrote:


Hello,

Details
OS : WIndows 10
Arch : x64
Compiler : VisualStudio 2017

I have a c++ wss IXWebSocket<https://github.com/machinezone/IXWebSocket> client that tries to connect to a nodejs https/websocket server but the client refuses to connect and returns the error : OpenSSL failed - error:0A000086:SSL routines::certificate verify failed
What I tried
1.       I have a React front end using wss to communicate to my https nodejs server. It works -> This confirms that my key and certificate are valid.
2.       I also tried the same c++ client above, not secured (no wss) connecting to my same nodejs server, but http/websocket (non secure). It works.
So, I had to dig into the OpenSSL code and I found where the error is triggered, see code below.  In my case s->verify_mode is equal to SSL_VERIFY_PEER and i equal to 0 and I don't know if those values are OK or not.

While I was digging into the code, I also realized that SSL_OP_NO_TLSv1_3 is automagically defined for my code.  I feel that it is incorrect.

From statem_clnt.c line 1888:
    if (s->verify_mode != SSL_VERIFY_NONE && i <= 0) {
        SSLfatal(s, ssl_x509err2alert(s->verify_result),
                 SSL_R_CERTIFICATE_VERIFY_FAILED);
        return WORK_ERROR;
    }

Stacktrace:
> libssl-3-x64.dll!tls_post_process_server_certificate(ssl_st
  libssl-3-x64.dll!ossl_statem_client_post_process_message(ss
  libssl-3-x64.dll!read_state_machine(ssl_st * s) Line 675
  libssl-3-x64.dll!state_machine(ssl_st * s, int server) Line
  libssl-3-x64.dll!ossl_statem_connect(ssl_st * s) Line 266
  libssl-3-x64.dll!SSL_do_handshake(ssl_st * s) Line 3937 C
  libssl-3-x64.dll!SSL_connect(ssl_st * s) Line 1760 C
  testWSClient.exe!ix::SocketOpenSSL::openSSLClientHandshake(
  testWSClient.exe!ix::SocketOpenSSL::connect(const std::basi
  testWSClient.exe!ix::WebSocketHandshake::clientHandshake(co
  testWSClient.exe!ix::WebSocketTransport::connectToUrl(const
  testWSClient.exe!ix::WebSocket::connect(int timeoutSecs) Li
  testWSClient.exe!ix::WebSocket::checkConnection(bool firstC
  testWSClient.exe!ix::WebSocket::run() Line 367 C++

IXWebClient, how key/cert are set :
    ix::SocketTLSOptions tlsOptions;
    tlsOptions.certFile = "WebRTC.test.crt";
    tlsOptions.keyFile = "WebRTC.test.key";
    tlsOptions.caFile = "WebRTC-CA.pem";
    webSocket.setTLSOptions(tlsOptions);
    std::string url("wss://localhost:8080");
    webSocket.setUrl(url);

No matter if the path of the key/certificate exists or not, I have the same error message from OpenSSL, which is weird...

So :
1. Any idea why I have certificate verify failed?
2. Is it normal that s->verify_mode is equal to SSL_VERIFY_PEER and i equal to 0
3. Is it normal that SSL_OP_NO_TLSv1_3 is enabled in the code?

Thanks a lot for any help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221216/fcad1720/attachment-0001.htm>

From openssl-users at dukhovni.org  Fri Dec 16 23:38:10 2022
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 16 Dec 2022 18:38:10 -0500
Subject: How to fix "OpenSSL failed - error:0A000086:SSL
 routines::certificate verify failed"
In-Reply-To: <CACTRa=sS8mxStmq_-N9HBdgsKZFiozheyOm44F5md5Vqnqgdcw@mail.gmail.com>
References: <CACTRa=sS8mxStmq_-N9HBdgsKZFiozheyOm44F5md5Vqnqgdcw@mail.gmail.com>
Message-ID: <Y50BYt6lEZjc9/LR@straasha.imrryr.org>

On Fri, Dec 16, 2022 at 05:07:51PM -0500, Pierre-Luc Boily wrote:

>    1. I have a React front end using wss to communicate to my https nodejs
>    server. *It works ->* *This confirms that my key and certificate are
>    valid.*

But it does not confirm that the server sent a "full" certificate chain,
with all the required intermediate certificates.  It also does not
confirm that you've set the correct peer hostname in the OpenSSL case
(if you don't set the hostname at all, your connection is insecure).

> So, I had to dig into the OpenSSL code and I found where the error is
> triggered, see code below.  In my case *s->verify_mode* is equal to
> *SSL_VERIFY_PEER* and *i* equal to *0* and I don't know if those values are
> OK or not.

OpenSSL failed to validat the certificate chain, it could be missing
intermediate certificates (from the server), or the wrong expected peer
hostname specified on the client end.  It could also be related to SNI,
some servers return different certificates depending on what SNI name
is signalled by the client.

So double-check that the server certificate chain is complete (includes
all intermediate CA certificates) optionally apart from a root CA (trust
anchor) configured on the client.

Then ensure that the client application correctly sets the SNI extension
and the expected peer hostname to check in the server certificate.

-- 
    Viktor.

From openssl at elyograg.org  Sat Dec 17 22:43:20 2022
From: openssl at elyograg.org (Shawn Heisey)
Date: Sat, 17 Dec 2022 15:43:20 -0700
Subject: Openssl 3.0.7 in Centos 7.9
In-Reply-To: <SA1P223MB0607A3912566FBE6A2CED750B0E69@SA1P223MB0607.NAMP223.PROD.OUTLOOK.COM>
References: <SA1P223MB0607F74B63C9DBCAC134C4DBB0E69@SA1P223MB0607.NAMP223.PROD.OUTLOOK.COM>
 <SA1P223MB0607A3912566FBE6A2CED750B0E69@SA1P223MB0607.NAMP223.PROD.OUTLOOK.COM>
Message-ID: <7a467631-18d6-3068-5159-a96c157bc45d@elyograg.org>

On 12/16/22 08:11, Ariel R. wrote:
> ln -s /usr/local/lib64/libssl.so.3 /usr/lib64/libssl.so.3
> ln -s /usr/local/lib64/libcrypto.so.3 /usr/lib64/libcrypto.so.3

<snip>

> *#About the problem*
> 
> In the console, if I run ?openssl version?, I can see the version 
> installed is indeed 3.0.7, which is ok.
> 
> The problem is that Apache is still referencing the old version:
> 
> Server Version: Apache/2.4.54 (cPanel) OpenSSL/1.1.1s

The symlinks you created put copies of the openssl 3 libraries into the 
general OS library path.

Apache wasn't compiled against openssl 3, though ... so it is going to 
be looking for a very different library files.

This is a generic CentOS 7 install on a VM:

[sheisey at centos7 ~]$ locate libssl
/usr/lib64/.libssl.so.1.0.2k.hmac
/usr/lib64/.libssl.so.10.hmac
/usr/lib64/libssl.so.1.0.2k
/usr/lib64/libssl.so.10
/usr/lib64/libssl3.so
[sheisey at centos7 ~]$ cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)

The library filenames for the system openssl are very different than the 
library filenames for the 3.0.7 version you installed.

I don't think you can replace the system's 1.1.1s libraries with the 
3.0.7 version, I expect that would break things.  You will probably need 
to compile Apache yourself and have it use the openssl that you 
installed into /usr/local.

I installed mod_ssl on that vm and checked what library files it is 
looking for:

[sheisey at centos7 ~]$ ldd /usr/lib64/httpd/modules/mod_ssl.so
	linux-vdso.so.1 =>  (0x00007ffd0bda5000)
	libssl.so.10 => /lib64/libssl.so.10 (0x00007f309ddd7000)
	libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f309d974000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f309d758000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f309d554000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f309d186000)
	libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f309cf39000)
	libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f309cc50000)
	libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f309ca4c000)
	libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f309c819000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f309c603000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f309e280000)
	libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f309c3f3000)
	libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f309c1ef000)
	libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f309bfd5000)
	libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f309bdae000)
	libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f309bb4c000)

The openssl library filenames that it is looking for are libssl.so.10 
and libcrypto.so.10, so it would not pick up the openssl version 3 symlinks.

I'm curious how you ended up with 1.1.1s on CentOS 7.  My VM is up to 
date and it has 1.0.2k.

Thanks,
Shawn

From pierreluc.boily at gmail.com  Sun Dec 18 01:47:43 2022
From: pierreluc.boily at gmail.com (Pierre-Luc Boily)
Date: Sat, 17 Dec 2022 20:47:43 -0500
Subject: openssl-users Digest, Vol 97, Issue 13
In-Reply-To: <mailman.1.1671278402.1512292.openssl-users@openssl.org>
References: <mailman.1.1671278402.1512292.openssl-users@openssl.org>
Message-ID: <CACTRa=sWNL_pj+yPf8uf-EyLkaoeMcZb_Rw2P5OAbSPFw2NkUA@mail.gmail.com>

Hello M.Dukhovni,

Thank you for your reply.  FYI, you missed an email I sent earlier
yesterday,  I mistakenly replied only to M. Wojcik instead of the openssl
mailing list.  I re-sent the email to the group. In the mail, I dug deeper
in the code and added more information.

In your email, you told me

*But it does not confirm that the server sent a "full" certificate chain*


The screenshot below shows the chrome address bar of my React front end web
page.  The server is https, and I added the CA on the Trusted Root
Certification Authorities store.  It says that my connection is secured.
Does it sound OK ?

[image: image.png]

*It also does not confirm that you've set the correct peer hostname in the
> OpenSSL case*


I created a CA-Signed certificate for my dev sites and I used a SAN :

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment,
dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = localhost
IP.1 = 192.168.230.138
IP.2 = 127.0.0.1




 By the way, all of this is for demo/prototype purposes.  I am fully aware
that when we will be ready to go on production, we will have to have a
better understanding of SSL.  Our first prototype iteration is to
demonstrate the feasibility to have a web page communicate with our speech
system on Windows platform using WebRTC.  And WebRTC is available only with
secure connection.

Thank you for reading all of this and thank you for your patience, it is
really appreciated.

Pierre-Luc Boily

Le sam. 17 d?c. 2022, ? 07 h 00, <openssl-users-request at openssl.org> a
?crit :

> Send openssl-users mailing list submissions to
>         openssl-users at openssl.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mta.openssl.org/mailman/listinfo/openssl-users
> or, via email, send a message with subject or body 'help' to
>         openssl-users-request at openssl.org
>
> You can reach the person managing the list at
>         openssl-users-owner at openssl.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openssl-users digest..."
>
>
> Today's Topics:
>
>    1. Re: How to fix "OpenSSL failed - error:0A000086:SSL
>       routines::certificate verify failed" (Viktor Dukhovni)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 16 Dec 2022 18:38:10 -0500
> From: Viktor Dukhovni <openssl-users at dukhovni.org>
> To: openssl-users at openssl.org
> Subject: Re: How to fix "OpenSSL failed - error:0A000086:SSL
>         routines::certificate verify failed"
> Message-ID: <Y50BYt6lEZjc9/LR at straasha.imrryr.org>
> Content-Type: text/plain; charset=us-ascii
>
> On Fri, Dec 16, 2022 at 05:07:51PM -0500, Pierre-Luc Boily wrote:
>
> >    1. I have a React front end using wss to communicate to my https
> nodejs
> >    server. *It works ->* *This confirms that my key and certificate are
> >    valid.*
>
> But it does not confirm that the server sent a "full" certificate chain,
> with all the required intermediate certificates.  It also does not
> confirm that you've set the correct peer hostname in the OpenSSL case
> (if you don't set the hostname at all, your connection is insecure).
>
> > So, I had to dig into the OpenSSL code and I found where the error is
> > triggered, see code below.  In my case *s->verify_mode* is equal to
> > *SSL_VERIFY_PEER* and *i* equal to *0* and I don't know if those values
> are
> > OK or not.
>
> OpenSSL failed to validat the certificate chain, it could be missing
> intermediate certificates (from the server), or the wrong expected peer
> hostname specified on the client end.  It could also be related to SNI,
> some servers return different certificates depending on what SNI name
> is signalled by the client.
>
> So double-check that the server certificate chain is complete (includes
> all intermediate CA certificates) optionally apart from a root CA (trust
> anchor) configured on the client.
>
> Then ensure that the client application correctly sets the SNI extension
> and the expected peer hostname to check in the server certificate.
>
> --
>     Viktor.
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> openssl-users mailing list
> openssl-users at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
> ------------------------------
>
> End of openssl-users Digest, Vol 97, Issue 13
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221217/68131cfd/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 5000 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221217/68131cfd/attachment.png>

From Michael.Wojcik at microfocus.com  Sun Dec 18 19:46:51 2022
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Sun, 18 Dec 2022 19:46:51 +0000
Subject: How to fix "OpenSSL failed - error:0A000086:SSL
 routines::certificate verify failed"
In-Reply-To: <CACTRa=tCr74rjSSaGfAHjq24ivZM6CqpdiBg+zJeiTDh6-OJcw@mail.gmail.com>
References: <CACTRa=sS8mxStmq_-N9HBdgsKZFiozheyOm44F5md5Vqnqgdcw@mail.gmail.com>
 <1030394545.643155.1671228846622@mail.yahoo.com>
 <CACTRa=uMmeg3TeJT9Z2WwK0ZQ4eQDesKo=+3sEpSpxAjFbT9MQ@mail.gmail.com>
 <DM6PR18MB27003D96DF332C2598BFB26CF9E69@DM6PR18MB2700.namprd18.prod.outlook.com>
 <CACTRa=tCr74rjSSaGfAHjq24ivZM6CqpdiBg+zJeiTDh6-OJcw@mail.gmail.com>
Message-ID: <DM6PR18MB2700C219E4ACA7C14164A37AF9E49@DM6PR18MB2700.namprd18.prod.outlook.com>

Please send replies to the list, not to me directly, as a courtesy to other people reading the thread and to allow them to reply to your questions.

> From: Pierre-Luc Boily <pierreluc.boily at gmail.com> 
> Sent: Friday, 16 December, 2022 21:10

> > Your questions suggest you're not a TLS expert.

> I humbly confess that I am a total beginner!.? Reading the books you proposed is absolutely
> something we will do.? But before becoming an expert on this topic (this will take some time
> I guess), I'd like to have my c++ client working well with openSSL for demo purposes

I understand, but it may be faster to at least gain more understanding of how TLS works in common cases than spend a lot of time trying to get your demonstration working.

> Our project needs a key/certificate because it uses WebRTC on browsers?such as chrome and
> edge and? WebRTC is not available on a non-secure browser. We also need a https/websocket
> server.

Is this also the server for the WebRTC connection? If not, do you have control of that server, or is it a third-party server?

> As a first step, I quickly created an https/websocket server with nodejs, and a React front end.?
> I created my own SSL Certificate Authority ...  I have a .key, a .crt and a .pem(my root certificate).

Note that ".key" and ".crt" are generic file extensions which doesn't tell us anything about the file format. A ".key" file might be PKCS#8, possibly PEM-encoded, or various other things. Most often a .crt is a DER-encoded certificate in PEM format (so a Base64-encoded representation of the DER data, with PEM header/footer lines, and possibly other text which will be ignored by decoders), but it could be binary DER or something else.

Presumably you have a key for the root certificate you created, and a key for your entity (server) certificate. Are there any intermediate certificates for your CA? Viktor mentioned this in his reply but it may not be clear to you. Conventional CAs do not sign entity certificates with their root certificates. They sign an intermediate certificate, which may be used to sign entity certificates or other intermediates.

The "certificate chain" that an entity sends should usually be its entity certificates plus any required intermediates, and optionally the root. (Sending the root doesn't help the peer validate the certificate, because the peer has to already trust the root certificate; but it can help with problem investigation and resolution.)

>? I added the .pem into windows, and .key and .crt are used in my nodejs server and on my html server as well.

An entity certificate identifies the entity. Do you know your two servers can both use that certificate? Are they running on the same host? Or is it a wildcard certificate?

> The second step is that we have a c++ webrtc client and this client has to talk with the nodejs
> https/websocket server.? I thought that using the same key/crt would do the trick.? But I have
> the error mentioned in my first email.

Without seeing the certificate chain and knowing how the client is trying to connect, we can't do much to diagnose this. Viktor mentioned some common problems. Since you control the servers, my guess is that SNI is not at issue, but telling OpenSSL what you're connecting to and ensuring that matches what the certificate identifies is a common problem.

The client has to receive a certificate that matches the name it tells OpenSSL it expects for the server. That means the certificate needs to have a Subject Alternative Name extension that matches what the client tells OpenSSL. (If the certificate lacks Subject Alternative Names, the CN of the Subject DN is used, but that's deprecated.)

Then there are quite a number of other checks which are performed, including building the chain to a trust anchor (root). Your application tells OpenSSL what roots it trusts, and OpenSSL needs to be able to create a chain of valid certificates from the server's entity certificate to one of those roots. Each certificate along the chain has to be not only the appropriate certificate (i.e. sign the one before and be signed by the one after, as determined by subject/issuer names or key IDs *and* by a valid signature), but also be valid and have the required key-usage values and so on. The full set of rules is large.

> I have 4 things I am wondering :?
> 1. The interface I use, IXWebSockect, has?SSL_OP_NO_TLSv1_3?defined.? If I understand, it means
> OpenSSL TLS1.3.? Is this correct?? I am suspicious...

TLSv1.3 is not an OpenSSL thing; it's a public standard. I'm not sure what you mean by "defined". SSL_OP_NO_TLSv1_3 is an object-type macro defined by the OpenSSL API, which a caller can use to disable TLSv1.3 support for a connection. Is the API you're calling actually passing that to OpenSSL (e.g. with SSL_CTX_set_options)?

In any case, it's unlikely your server only supports TLSv1.3, and the error you're getting doesn't indicate a lack of matching TLS protocol versions, so this doesn't appear to be an issue.

> 2. No matter the path of the key/crt I give to OpenSSL, I have the same error message.? If the path doesn't exist,
> should I expect an error message like "file not found"?? If yes, my problem could be elsewhere...

This is the server certificate and key? Why are you specifying those to OpenSSL at all? The client does not programmatically set anything regarding the server's certificate (which it normally doesn't know until the server sends it), and should not have a copy of the server's key.

> 3. You used the terminology "collection of trust anchors".? Is this the .pem, .key and .crt???

In your case, it's just what's in the .pem file: the root for your test CA. Trust anchors are the roots you trust to "anchor" (terminate) a chain, and possibly some intermediates that chain to some of those roots so you can verify certificates that aren't sent with their complete chains.

> 4. If SSL_VERIFY_PEER is the value expected, I guess "i" shall be 1.? So, I decided to check why i == 0,
> and I found this in x509_vfy.c line 206:

In my opinion, debugging into the OpenSSL implementation is very much the wrong way to go. The OpenSSL implementation is not particularly easy to understand, and you really want a thorough understanding of TLS, PKIX, and related matters before trying to figure out what it's doing and why.

...

> And build_chain(ctx) bring me there (line 3166, x509_vfy.c) :?

Have you confirmed (in the debugger) that this is the point at which OpenSSL decides to reject the peer certificate? Guessing at causes by looking at the code is going to be extremely inefficient.

> "Untrust mimic" sounds suspicious!

"Suspicious" describes essentially every failed certificate check. That's pretty much the entire point of TLS, and indeed all security mechanisms: to be suspicious.

-- 
Michael Wojcik

From david.von.oheimb at siemens.com  Mon Dec 19 08:00:16 2022
From: david.von.oheimb at siemens.com (von Oheimb, David)
Date: Mon, 19 Dec 2022 08:00:16 +0000
Subject: How to fix "OpenSSL failed - error:0A000086:SSL
 routines::certificate verify failed"
In-Reply-To: <DM6PR18MB2700C219E4ACA7C14164A37AF9E49@DM6PR18MB2700.namprd18.prod.outlook.com>
References: <CACTRa=sS8mxStmq_-N9HBdgsKZFiozheyOm44F5md5Vqnqgdcw@mail.gmail.com>
 <1030394545.643155.1671228846622@mail.yahoo.com>
 <CACTRa=uMmeg3TeJT9Z2WwK0ZQ4eQDesKo=+3sEpSpxAjFbT9MQ@mail.gmail.com>
 <DM6PR18MB27003D96DF332C2598BFB26CF9E69@DM6PR18MB2700.namprd18.prod.outlook.com>
 <CACTRa=tCr74rjSSaGfAHjq24ivZM6CqpdiBg+zJeiTDh6-OJcw@mail.gmail.com>
 <DM6PR18MB2700C219E4ACA7C14164A37AF9E49@DM6PR18MB2700.namprd18.prod.outlook.com>
Message-ID: <39346621914932292ce26ff0d2ea7cfff9a49b5d.camel@siemens.com>

Certificate chain building, which is part of cert chain validation, is notoriously hard to debug and get right because there are so many implicit things that may go wrong.
This holds in particular for TLS connection setup, but also for most other use cases like checking at application level the signature on a document or message received.
Unfortunately, the error messages by OpenSSL and similar libraries when the chain construction fails are typically not very helpful to find out where the problem(s) is/are.

For this reason, I proposed a chain building trace feature for OpenSSL at https://github.com/openssl/openssl/pull/18761 about half a year ago.
It shows which candidate certificates are tried at which points in which order, and at which points which candidate gets ruled out for which reasons.
Yet the further handling got stuck because it requires some code refactoring, and the respective PR https://github.com/openssl/openssl/pull/18762 is still awaiting review.
Nevertheless, those who are able to compile OpenSSL themselves from a specific branch, namely the branch given in PR 18761<https://github.com/siemens/openssl/tree/x509_trace_chain_building>, may already make use of this.

David

On Sun, 2022-12-18 at 19:46 +0000, Michael Wojcik via openssl-users wrote:
Please send replies to the list, not to me directly, as a courtesy to other people reading the thread and to allow them to reply to your questions.

From: Pierre-Luc Boily <pierreluc.boily at gmail.com<mailto:pierreluc.boily at gmail.com>>
Sent: Friday, 16 December, 2022 21:10

Your questions suggest you're not a TLS expert.

I humbly confess that I am a total beginner!.  Reading the books you proposed is absolutely
something we will do.  But before becoming an expert on this topic (this will take some time
I guess), I'd like to have my c++ client working well with openSSL for demo purposes

I understand, but it may be faster to at least gain more understanding of how TLS works in common cases than spend a lot of time trying to get your demonstration working.

Our project needs a key/certificate because it uses WebRTC on browsers such as chrome and
edge and  WebRTC is not available on a non-secure browser. We also need a https/websocket
server.

Is this also the server for the WebRTC connection? If not, do you have control of that server, or is it a third-party server?

As a first step, I quickly created an https/websocket server with nodejs, and a React front end.
I created my own SSL Certificate Authority ...  I have a .key, a .crt and a .pem(my root certificate).

Note that ".key" and ".crt" are generic file extensions which doesn't tell us anything about the file format. A ".key" file might be PKCS#8, possibly PEM-encoded, or various other things. Most often a .crt is a DER-encoded certificate in PEM format (so a Base64-encoded representation of the DER data, with PEM header/footer lines, and possibly other text which will be ignored by decoders), but it could be binary DER or something else.

Presumably you have a key for the root certificate you created, and a key for your entity (server) certificate. Are there any intermediate certificates for your CA? Viktor mentioned this in his reply but it may not be clear to you. Conventional CAs do not sign entity certificates with their root certificates. They sign an intermediate certificate, which may be used to sign entity certificates or other intermediates.

The "certificate chain" that an entity sends should usually be its entity certificates plus any required intermediates, and optionally the root. (Sending the root doesn't help the peer validate the certificate, because the peer has to already trust the root certificate; but it can help with problem investigation and resolution.)

  I added the .pem into windows, and .key and .crt are used in my nodejs server and on my html server as well.

An entity certificate identifies the entity. Do you know your two servers can both use that certificate? Are they running on the same host? Or is it a wildcard certificate?

The second step is that we have a c++ webrtc client and this client has to talk with the nodejs
https/websocket server.  I thought that using the same key/crt would do the trick.  But I have
the error mentioned in my first email.

Without seeing the certificate chain and knowing how the client is trying to connect, we can't do much to diagnose this. Viktor mentioned some common problems. Since you control the servers, my guess is that SNI is not at issue, but telling OpenSSL what you're connecting to and ensuring that matches what the certificate identifies is a common problem.

The client has to receive a certificate that matches the name it tells OpenSSL it expects for the server. That means the certificate needs to have a Subject Alternative Name extension that matches what the client tells OpenSSL. (If the certificate lacks Subject Alternative Names, the CN of the Subject DN is used, but that's deprecated.)

Then there are quite a number of other checks which are performed, including building the chain to a trust anchor (root). Your application tells OpenSSL what roots it trusts, and OpenSSL needs to be able to create a chain of valid certificates from the server's entity certificate to one of those roots. Each certificate along the chain has to be not only the appropriate certificate (i.e. sign the one before and be signed by the one after, as determined by subject/issuer names or key IDs *and* by a valid signature), but also be valid and have the required key-usage values and so on. The full set of rules is large.

I have 4 things I am wondering :
1. The interface I use, IXWebSockect, has SSL_OP_NO_TLSv1_3 defined.  If I understand, it means
OpenSSL TLS1.3.  Is this correct?  I am suspicious...

TLSv1.3 is not an OpenSSL thing; it's a public standard. I'm not sure what you mean by "defined". SSL_OP_NO_TLSv1_3 is an object-type macro defined by the OpenSSL API, which a caller can use to disable TLSv1.3 support for a connection. Is the API you're calling actually passing that to OpenSSL (e.g. with SSL_CTX_set_options)?

In any case, it's unlikely your server only supports TLSv1.3, and the error you're getting doesn't indicate a lack of matching TLS protocol versions, so this doesn't appear to be an issue.

2. No matter the path of the key/crt I give to OpenSSL, I have the same error message.  If the path doesn't exist,
should I expect an error message like "file not found"?  If yes, my problem could be elsewhere...

This is the server certificate and key? Why are you specifying those to OpenSSL at all? The client does not programmatically set anything regarding the server's certificate (which it normally doesn't know until the server sends it), and should not have a copy of the server's key.

3. You used the terminology "collection of trust anchors".  Is this the .pem, .key and .crt?

In your case, it's just what's in the .pem file: the root for your test CA. Trust anchors are the roots you trust to "anchor" (terminate) a chain, and possibly some intermediates that chain to some of those roots so you can verify certificates that aren't sent with their complete chains.

4. If SSL_VERIFY_PEER is the value expected, I guess "i" shall be 1.  So, I decided to check why i == 0,
and I found this in x509_vfy.c line 206:

In my opinion, debugging into the OpenSSL implementation is very much the wrong way to go. The OpenSSL implementation is not particularly easy to understand, and you really want a thorough understanding of TLS, PKIX, and related matters before trying to figure out what it's doing and why.

...

And build_chain(ctx) bring me there (line 3166, x509_vfy.c) :

Have you confirmed (in the debugger) that this is the point at which OpenSSL decides to reject the peer certificate? Guessing at causes by looking at the code is going to be extremely inefficient.

"Untrust mimic" sounds suspicious!

"Suspicious" describes essentially every failed certificate check. That's pretty much the entire point of TLS, and indeed all security mechanisms: to be suspicious.

--
Michael Wojcik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221219/978d73ee/attachment-0001.htm>

From samiya.khanum at broadcom.com  Tue Dec 20 13:11:36 2022
From: samiya.khanum at broadcom.com (Samiya Khanum)
Date: Tue, 20 Dec 2022 18:41:36 +0530
Subject: undefined reference to `__atomic_is_lock_free'
Message-ID: <CADmX34pX4pRFragnM=AbsbTjJyLnxbfBDxkp47S6JKVZGDm64A@mail.gmail.com>

Hi,

After upgrading openssl to 3.0.7 from 1.1.1 , I see below errors.

libcrypto.so: undefined reference to `__atomic_is_lock_free'
libcrypto.so: undefined reference to `__atomic_fetch_or_8'
libcrypto.so: undefined reference to `__atomic_load_8'
libcrypto.so: undefined reference to `__atomic_fetch_add_8'
I tried  this patch, still seeing the same errors .
Prevent Clang from emitting atomic libcalls by xtkoba ? Pull Request #16584
? openssl/openssl ? GitHub
<https://github.com/openssl/openssl/pull/16584/files>

If we define "-DBROKEN_CLANG_ATOMICS" , it works. What is the impact If we
define "BROKEN_CLANG_ATOMICS".

Can someone please suggest the correct way?

Thanks & Regards,
Samiya khanum

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221220/5c147074/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4212 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221220/5c147074/attachment.p7s>

From pierreluc.boily at gmail.com  Tue Dec 20 14:06:58 2022
From: pierreluc.boily at gmail.com (Pierre-Luc Boily)
Date: Tue, 20 Dec 2022 09:06:58 -0500
Subject: openssl-users Digest, Vol 97, Issue 15
In-Reply-To: <mailman.896.1671436825.2095.openssl-users@openssl.org>
References: <mailman.896.1671436825.2095.openssl-users@openssl.org>
Message-ID: <CACTRa=sZdRR9bGHesCpt=ALcg-UC6TMqDHtTWovjkA6Q5QMn7A@mail.gmail.com>

Hello Micheal,

Thank you very much for answering all my questions.  I clearly need to go
back one step and learn more about TLS/SSL.  I quickly followed a guide to
create my key/crt/pem, while not understanding what I did..  We got the
book from Ivan Ristic at my work.  If I still have questions in a couple of
weeks, I'll come here! :)

Regards,

Pierre-Luc

Le lun. 19 d?c. 2022, ? 03 h 01, <openssl-users-request at openssl.org> a
?crit :

> Send openssl-users mailing list submissions to
>         openssl-users at openssl.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mta.openssl.org/mailman/listinfo/openssl-users
> or, via email, send a message with subject or body 'help' to
>         openssl-users-request at openssl.org
>
> You can reach the person managing the list at
>         openssl-users-owner at openssl.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openssl-users digest..."
>
>
> Today's Topics:
>
>    1. RE: How to fix "OpenSSL failed - error:0A000086:SSL
>       routines::certificate verify failed" (Michael Wojcik)
>    2. Re: How to fix "OpenSSL failed - error:0A000086:SSL
>       routines::certificate verify failed" (von Oheimb, David)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 18 Dec 2022 19:46:51 +0000
> From: Michael Wojcik <Michael.Wojcik at microfocus.com>
> To: "openssl-users at openssl.org" <openssl-users at openssl.org>
> Cc: Pierre-Luc Boily <pierreluc.boily at gmail.com>
> Subject: RE: How to fix "OpenSSL failed - error:0A000086:SSL
>         routines::certificate verify failed"
> Message-ID:
>         <
> DM6PR18MB2700C219E4ACA7C14164A37AF9E49 at DM6PR18MB2700.namprd18.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> Please send replies to the list, not to me directly, as a courtesy to
> other people reading the thread and to allow them to reply to your
> questions.
>
> > From: Pierre-Luc Boily <pierreluc.boily at gmail.com>
> > Sent: Friday, 16 December, 2022 21:10
>
> > > Your questions suggest you're not a TLS expert.
>
> > I humbly confess that I am a total beginner!.? Reading the books you
> proposed is absolutely
> > something we will do.? But before becoming an expert on this topic (this
> will take some time
> > I guess), I'd like to have my c++ client working well with openSSL for
> demo purposes
>
> I understand, but it may be faster to at least gain more understanding of
> how TLS works in common cases than spend a lot of time trying to get your
> demonstration working.
>
> > Our project needs a key/certificate because it uses WebRTC on
> browsers?such as chrome and
> > edge and? WebRTC is not available on a non-secure browser. We also need
> a https/websocket
> > server.
>
> Is this also the server for the WebRTC connection? If not, do you have
> control of that server, or is it a third-party server?
>
> > As a first step, I quickly created an https/websocket server with
> nodejs, and a React front end.?
> > I created my own SSL Certificate Authority ...  I have a .key, a .crt
> and a .pem(my root certificate).
>
> Note that ".key" and ".crt" are generic file extensions which doesn't tell
> us anything about the file format. A ".key" file might be PKCS#8, possibly
> PEM-encoded, or various other things. Most often a .crt is a DER-encoded
> certificate in PEM format (so a Base64-encoded representation of the DER
> data, with PEM header/footer lines, and possibly other text which will be
> ignored by decoders), but it could be binary DER or something else.
>
> Presumably you have a key for the root certificate you created, and a key
> for your entity (server) certificate. Are there any intermediate
> certificates for your CA? Viktor mentioned this in his reply but it may not
> be clear to you. Conventional CAs do not sign entity certificates with
> their root certificates. They sign an intermediate certificate, which may
> be used to sign entity certificates or other intermediates.
>
> The "certificate chain" that an entity sends should usually be its entity
> certificates plus any required intermediates, and optionally the root.
> (Sending the root doesn't help the peer validate the certificate, because
> the peer has to already trust the root certificate; but it can help with
> problem investigation and resolution.)
>
> >? I added the .pem into windows, and .key and .crt are used in my nodejs
> server and on my html server as well.
>
> An entity certificate identifies the entity. Do you know your two servers
> can both use that certificate? Are they running on the same host? Or is it
> a wildcard certificate?
>
> > The second step is that we have a c++ webrtc client and this client has
> to talk with the nodejs
> > https/websocket server.? I thought that using the same key/crt would do
> the trick.? But I have
> > the error mentioned in my first email.
>
> Without seeing the certificate chain and knowing how the client is trying
> to connect, we can't do much to diagnose this. Viktor mentioned some common
> problems. Since you control the servers, my guess is that SNI is not at
> issue, but telling OpenSSL what you're connecting to and ensuring that
> matches what the certificate identifies is a common problem.
>
> The client has to receive a certificate that matches the name it tells
> OpenSSL it expects for the server. That means the certificate needs to have
> a Subject Alternative Name extension that matches what the client tells
> OpenSSL. (If the certificate lacks Subject Alternative Names, the CN of the
> Subject DN is used, but that's deprecated.)
>
> Then there are quite a number of other checks which are performed,
> including building the chain to a trust anchor (root). Your application
> tells OpenSSL what roots it trusts, and OpenSSL needs to be able to create
> a chain of valid certificates from the server's entity certificate to one
> of those roots. Each certificate along the chain has to be not only the
> appropriate certificate (i.e. sign the one before and be signed by the one
> after, as determined by subject/issuer names or key IDs *and* by a valid
> signature), but also be valid and have the required key-usage values and so
> on. The full set of rules is large.
>
> > I have 4 things I am wondering :?
> > 1. The interface I use, IXWebSockect, has?SSL_OP_NO_TLSv1_3?defined.? If
> I understand, it means
> > OpenSSL TLS1.3.? Is this correct?? I am suspicious...
>
> TLSv1.3 is not an OpenSSL thing; it's a public standard. I'm not sure what
> you mean by "defined". SSL_OP_NO_TLSv1_3 is an object-type macro defined by
> the OpenSSL API, which a caller can use to disable TLSv1.3 support for a
> connection. Is the API you're calling actually passing that to OpenSSL
> (e.g. with SSL_CTX_set_options)?
>
> In any case, it's unlikely your server only supports TLSv1.3, and the
> error you're getting doesn't indicate a lack of matching TLS protocol
> versions, so this doesn't appear to be an issue.
>
> > 2. No matter the path of the key/crt I give to OpenSSL, I have the same
> error message.? If the path doesn't exist,
> > should I expect an error message like "file not found"?? If yes, my
> problem could be elsewhere...
>
> This is the server certificate and key? Why are you specifying those to
> OpenSSL at all? The client does not programmatically set anything regarding
> the server's certificate (which it normally doesn't know until the server
> sends it), and should not have a copy of the server's key.
>
> > 3. You used the terminology "collection of trust anchors".? Is this the
> .pem, .key and .crt???
>
> In your case, it's just what's in the .pem file: the root for your test
> CA. Trust anchors are the roots you trust to "anchor" (terminate) a chain,
> and possibly some intermediates that chain to some of those roots so you
> can verify certificates that aren't sent with their complete chains.
>
> > 4. If SSL_VERIFY_PEER is the value expected, I guess "i" shall be 1.?
> So, I decided to check why i == 0,
> > and I found this in x509_vfy.c line 206:
>
> In my opinion, debugging into the OpenSSL implementation is very much the
> wrong way to go. The OpenSSL implementation is not particularly easy to
> understand, and you really want a thorough understanding of TLS, PKIX, and
> related matters before trying to figure out what it's doing and why.
>
> ...
>
> > And build_chain(ctx) bring me there (line 3166, x509_vfy.c) :?
>
> Have you confirmed (in the debugger) that this is the point at which
> OpenSSL decides to reject the peer certificate? Guessing at causes by
> looking at the code is going to be extremely inefficient.
>
> > "Untrust mimic" sounds suspicious!
>
> "Suspicious" describes essentially every failed certificate check. That's
> pretty much the entire point of TLS, and indeed all security mechanisms: to
> be suspicious.
>
> --
> Michael Wojcik
>
> ------------------------------
>
> Message: 2
> Date: Mon, 19 Dec 2022 08:00:16 +0000
> From: "von Oheimb, David" <david.von.oheimb at siemens.com>
> To: "openssl-users at openssl.org" <openssl-users at openssl.org>,
>         "Michael.Wojcik at microfocus.com" <Michael.Wojcik at microfocus.com>,
>         "pierreluc.boily at gmail.com" <pierreluc.boily at gmail.com>
> Subject: Re: How to fix "OpenSSL failed - error:0A000086:SSL
>         routines::certificate verify failed"
> Message-ID:
>         <39346621914932292ce26ff0d2ea7cfff9a49b5d.camel at siemens.com>
> Content-Type: text/plain; charset="utf-8"
>
> Certificate chain building, which is part of cert chain validation, is
> notoriously hard to debug and get right because there are so many implicit
> things that may go wrong.
> This holds in particular for TLS connection setup, but also for most other
> use cases like checking at application level the signature on a document or
> message received.
> Unfortunately, the error messages by OpenSSL and similar libraries when
> the chain construction fails are typically not very helpful to find out
> where the problem(s) is/are.
>
> For this reason, I proposed a chain building trace feature for OpenSSL at
> https://github.com/openssl/openssl/pull/18761 about half a year ago.
> It shows which candidate certificates are tried at which points in which
> order, and at which points which candidate gets ruled out for which reasons.
> Yet the further handling got stuck because it requires some code
> refactoring, and the respective PR
> https://github.com/openssl/openssl/pull/18762 is still awaiting review.
> Nevertheless, those who are able to compile OpenSSL themselves from a
> specific branch, namely the branch given in PR 18761<
> https://github.com/siemens/openssl/tree/x509_trace_chain_building>, may
> already make use of this.
>
> David
>
> On Sun, 2022-12-18 at 19:46 +0000, Michael Wojcik via openssl-users wrote:
> Please send replies to the list, not to me directly, as a courtesy to
> other people reading the thread and to allow them to reply to your
> questions.
>
> From: Pierre-Luc Boily <pierreluc.boily at gmail.com<mailto:
> pierreluc.boily at gmail.com>>
> Sent: Friday, 16 December, 2022 21:10
>
> Your questions suggest you're not a TLS expert.
>
> I humbly confess that I am a total beginner!.  Reading the books you
> proposed is absolutely
> something we will do.  But before becoming an expert on this topic (this
> will take some time
> I guess), I'd like to have my c++ client working well with openSSL for
> demo purposes
>
> I understand, but it may be faster to at least gain more understanding of
> how TLS works in common cases than spend a lot of time trying to get your
> demonstration working.
>
> Our project needs a key/certificate because it uses WebRTC on browsers
> such as chrome and
> edge and  WebRTC is not available on a non-secure browser. We also need a
> https/websocket
> server.
>
> Is this also the server for the WebRTC connection? If not, do you have
> control of that server, or is it a third-party server?
>
> As a first step, I quickly created an https/websocket server with nodejs,
> and a React front end.
> I created my own SSL Certificate Authority ...  I have a .key, a .crt and
> a .pem(my root certificate).
>
> Note that ".key" and ".crt" are generic file extensions which doesn't tell
> us anything about the file format. A ".key" file might be PKCS#8, possibly
> PEM-encoded, or various other things. Most often a .crt is a DER-encoded
> certificate in PEM format (so a Base64-encoded representation of the DER
> data, with PEM header/footer lines, and possibly other text which will be
> ignored by decoders), but it could be binary DER or something else.
>
> Presumably you have a key for the root certificate you created, and a key
> for your entity (server) certificate. Are there any intermediate
> certificates for your CA? Viktor mentioned this in his reply but it may not
> be clear to you. Conventional CAs do not sign entity certificates with
> their root certificates. They sign an intermediate certificate, which may
> be used to sign entity certificates or other intermediates.
>
> The "certificate chain" that an entity sends should usually be its entity
> certificates plus any required intermediates, and optionally the root.
> (Sending the root doesn't help the peer validate the certificate, because
> the peer has to already trust the root certificate; but it can help with
> problem investigation and resolution.)
>
>   I added the .pem into windows, and .key and .crt are used in my nodejs
> server and on my html server as well.
>
> An entity certificate identifies the entity. Do you know your two servers
> can both use that certificate? Are they running on the same host? Or is it
> a wildcard certificate?
>
> The second step is that we have a c++ webrtc client and this client has to
> talk with the nodejs
> https/websocket server.  I thought that using the same key/crt would do
> the trick.  But I have
> the error mentioned in my first email.
>
> Without seeing the certificate chain and knowing how the client is trying
> to connect, we can't do much to diagnose this. Viktor mentioned some common
> problems. Since you control the servers, my guess is that SNI is not at
> issue, but telling OpenSSL what you're connecting to and ensuring that
> matches what the certificate identifies is a common problem.
>
> The client has to receive a certificate that matches the name it tells
> OpenSSL it expects for the server. That means the certificate needs to have
> a Subject Alternative Name extension that matches what the client tells
> OpenSSL. (If the certificate lacks Subject Alternative Names, the CN of the
> Subject DN is used, but that's deprecated.)
>
> Then there are quite a number of other checks which are performed,
> including building the chain to a trust anchor (root). Your application
> tells OpenSSL what roots it trusts, and OpenSSL needs to be able to create
> a chain of valid certificates from the server's entity certificate to one
> of those roots. Each certificate along the chain has to be not only the
> appropriate certificate (i.e. sign the one before and be signed by the one
> after, as determined by subject/issuer names or key IDs *and* by a valid
> signature), but also be valid and have the required key-usage values and so
> on. The full set of rules is large.
>
> I have 4 things I am wondering :
> 1. The interface I use, IXWebSockect, has SSL_OP_NO_TLSv1_3 defined.  If I
> understand, it means
> OpenSSL TLS1.3.  Is this correct?  I am suspicious...
>
> TLSv1.3 is not an OpenSSL thing; it's a public standard. I'm not sure what
> you mean by "defined". SSL_OP_NO_TLSv1_3 is an object-type macro defined by
> the OpenSSL API, which a caller can use to disable TLSv1.3 support for a
> connection. Is the API you're calling actually passing that to OpenSSL
> (e.g. with SSL_CTX_set_options)?
>
> In any case, it's unlikely your server only supports TLSv1.3, and the
> error you're getting doesn't indicate a lack of matching TLS protocol
> versions, so this doesn't appear to be an issue.
>
> 2. No matter the path of the key/crt I give to OpenSSL, I have the same
> error message.  If the path doesn't exist,
> should I expect an error message like "file not found"?  If yes, my
> problem could be elsewhere...
>
> This is the server certificate and key? Why are you specifying those to
> OpenSSL at all? The client does not programmatically set anything regarding
> the server's certificate (which it normally doesn't know until the server
> sends it), and should not have a copy of the server's key.
>
> 3. You used the terminology "collection of trust anchors".  Is this the
> .pem, .key and .crt?
>
> In your case, it's just what's in the .pem file: the root for your test
> CA. Trust anchors are the roots you trust to "anchor" (terminate) a chain,
> and possibly some intermediates that chain to some of those roots so you
> can verify certificates that aren't sent with their complete chains.
>
> 4. If SSL_VERIFY_PEER is the value expected, I guess "i" shall be 1.  So,
> I decided to check why i == 0,
> and I found this in x509_vfy.c line 206:
>
> In my opinion, debugging into the OpenSSL implementation is very much the
> wrong way to go. The OpenSSL implementation is not particularly easy to
> understand, and you really want a thorough understanding of TLS, PKIX, and
> related matters before trying to figure out what it's doing and why.
>
> ...
>
> And build_chain(ctx) bring me there (line 3166, x509_vfy.c) :
>
> Have you confirmed (in the debugger) that this is the point at which
> OpenSSL decides to reject the peer certificate? Guessing at causes by
> looking at the code is going to be extremely inefficient.
>
> "Untrust mimic" sounds suspicious!
>
> "Suspicious" describes essentially every failed certificate check. That's
> pretty much the entire point of TLS, and indeed all security mechanisms: to
> be suspicious.
>
> --
> Michael Wojcik
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mta.openssl.org/pipermail/openssl-users/attachments/20221219/978d73ee/attachment.htm
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> openssl-users mailing list
> openssl-users at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
> ------------------------------
>
> End of openssl-users Digest, Vol 97, Issue 15
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221220/4e68cb28/attachment-0001.htm>

From jhb at FreeBSD.org  Tue Dec 20 18:50:54 2022
From: jhb at FreeBSD.org (John Baldwin)
Date: Tue, 20 Dec 2022 10:50:54 -0800
Subject: Using OpenSSL with Kernel TLS
In-Reply-To: <CAFN_Zgmh29Lp5e2ODP3rXFiegC8ruw6jyWBihweZgzY-Kg3bvg@mail.gmail.com>
References: <CAFN_Zgmh29Lp5e2ODP3rXFiegC8ruw6jyWBihweZgzY-Kg3bvg@mail.gmail.com>
Message-ID: <a856d992-7214-9e72-3dd1-f50607235205@FreeBSD.org>

On 11/4/22 5:20 PM, Michael Elf wrote:
> I'd like to use OpenSSL with KTLS for websocket protocol, mainly for
> receiving but also transmit. I'm using the latest version of OpenSSL from
> source, with Ubuntu 20.04 and 22.04.
> 
> I currently use the regular SSL_read() and SSL_write() functions to receive
> and transmit bytes. I have not used BIO interfaces before and do not
> currently have one.
> 
> I saw an Issue on the Github page discussing KTLS:
> 
> https://github.com/openssl/openssl/issues/14595
> 
> In particular:
> 
> -   -   -   -    -   -   -   -    -   -   -   -    -   -   -   -    -   -
>   -   -    -   -   -   -    -   -   -   -    -   -   -   -    -   -   -   -
>    -   -   -   -    -   -   -   -    -
> 
> *KTLS will be used if................You are using a suitable KTLS aware
> BIO (BIO_s_connect(), or BIO_s_socket())You don't need to do anything
> special in your code. SSL_write will just do the right thing if the above
> conditions are met. *
> -   -   -   -    -   -   -   -    -   -   -   -    -   -   -   -    -   -
>   -   -    -   -   -   -    -   -   -   -    -   -   -   -    -   -   -   -
>    -   -   -   -    -   -   -   -    -
> 
> The last part suggests SSL_write() will work out-of-the-box, so long as we
> have a BIO interface.
> 
> 1) Will SSL_read() work with KTLS too?

It can.  It depeneds on your kernel/OS version and what capabilities you have.
I'm more familiar with FreeBSD than Linux, and in FreeBSD's case KTLS for
sending landed in the kernel before KTLS for receiving.  The same thing was
also repeated when TLS 1.3 support was added (sending before receiving) on
both Linux and FreeBSD I believe.  Some NICs can also do TLS offload, though
whether or not you can do both send and receive can depend on things like the
specific NIC, kernel/driver version, and TLS protocol version.

> 2) If we can still call SSL_read() and SSL_write() with KTLS, what is the
> purpose/requirement for the BIO interface?

You still need to read/write on a socket and BIO is used to deal with that.
KTLS allows SSL_read/write to take shorter paths that get to the BIO interface
to do I/O directly on the socket sooner.  While you could just call read
and write directly, I don't think it would really save you much time.

> 3) If we cannot use SSL_read() and SSL_write() I assume we have to use
> BIO_read() and BIO_write(). I read somewhere to receive a packet I must
> read bytes from the BIO and pass to the SSL layer. For KTLS this seems odd,
> the whole idea is we want all processing performed in the kernel. Have I
> misunderstood this?

Yes, you can just use SSL_read.

> 4) Are there any significant performance differences (between Linux
> distributions) for KTLS + OpenSSL?

I think any performance differences (if any) would be due to kernel versions
and not really OpenSSL.

-- 
John Baldwin


From tomas at openssl.org  Wed Dec 21 10:58:12 2022
From: tomas at openssl.org (Tomas Mraz)
Date: Wed, 21 Dec 2022 10:58:12 +0000
Subject: OpenSSL version 3.1.0-beta1 published
Message-ID: <Y6LmxIf8zaQYGmnN@dev.openssl.org>

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


   OpenSSL version 3.1 beta 1 released
   ===================================

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

   OpenSSL 3.1 is currently in beta.

   OpenSSL 3.1 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.1 from previous versions are
   available in the OpenSSL Migration Guide, here:

        https://www.openssl.org/docs/man3.0/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.1.0-beta1.tar.gz
      Size: 15477820
      SHA1 checksum:  8b1e5150c8148fb2a4c115e0c8641b8cfc339877
      SHA256 checksum:  e0d4bb52f7f9a745127b533be1c42bd4743467b180e7bc28a3d6ed40410c86d0

   The checksums were calculated using the following commands:

    openssl sha1 openssl-3.1.0-beta1.tar.gz
    openssl sha256 openssl-3.1.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-----

iQJGBAEBCAAwFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmOi3rYSHHRvbWFzQG9w
ZW5zc2wub3JnAAoJEFJ0ZqIcp55t+SYP/iAe1G/sOzc19X3RgmhGwkMTWICGAmX9
GMhVQYo7+LMDuH1yrxklsRDqdMsGjN73omw1oiye+Wl74xsinV8MefNb/AdWX7uz
u+7mI+fBwg3el7UquZWKIRo8XPXdOZUAVYdnpyCRCewGNFIqnkwSQfNBXPV2brY4
gzom+JaVG4riHaAAOB5FI/GG7zgaZ9y25PHd34aD+M/RcRbH0NQ+z21gSzxehFRL
eHVO4ErNFswhDRyzsfq8BeJ2OAxS79Ue3UyV05cwEnEnv/eJq/Vy3ISthMx9Rl6v
ALKJRmzo2lUUk1rwIVobOo6x4RKVNGbv9jnZpzVL6zmgozrv5/s0EzMTbkUMe69i
G2REaZS26iQO99r1BD+cNNYDg85/inn8sjN2UxzYmFkLItea5XdK8Wths40DLzYz
ozua4jkGQBqfb4xPFM2Ueq73Z2JMUype0HxNS/BgAYtyyV8E0jplf1oaacKB33k6
8ZLlWhh+tx9eAuMc59xthcaIxRC7S0TMOxRuFPQ7v/bWl90iJHac86s5QHm7Xfha
2NN5FhFRPYz4zbkQBX8WAiC76nZGBIxJAqhYV1UbX583kEXVgCxf42YV55bPWkIe
HChMhr0saY/hQ8BlYSkNlFrzN50zGBINKwRXBhQuofrCmlwhky9eiw09h2sne4FE
LJvNDpUY98tL
=gT0X
-----END PGP SIGNATURE-----

From b_duvvuri at yahoo.com  Wed Dec 21 17:26:18 2022
From: b_duvvuri at yahoo.com (Bala Duvvuri)
Date: Wed, 21 Dec 2022 17:26:18 +0000 (UTC)
Subject: openssl verify with concatenated CA
References: <1198059248.2020913.1671643578278.ref@mail.yahoo.com>
Message-ID: <1198059248.2020913.1671643578278@mail.yahoo.com>

I have a concatenated file containing root CA and intermediate CA (say concat.pem, having the 2 CA certificates) copied to a directory say "ca"

I have a entity certificate (cert1) signed by above intermediate CA (say inter.pem)

The observation is 

This command works : openssl verify -CAfile ca/concat.pem cert1

This command does not work: openssl verify -CApath ca cert1  ((ca directory has concat.pem in hash.0 format))
But if we copy the intermediate CA as well to the ca/ directory, the above command works

If verification with -CAfile with a concatenated CA file works, when the same file is present in the "ca" directory and is specified as option to -CApath directory, why verification fails?

Thanks
Bala

From pierreluc.boily at gmail.com  Thu Dec 22 02:41:55 2022
From: pierreluc.boily at gmail.com (Pierre-Luc Boily)
Date: Wed, 21 Dec 2022 21:41:55 -0500
Subject: Error with ciphers -V 'ALL:COMPLEMENTOFALL'
Message-ID: <CACTRa=vYt9tM91+6KcWNeLtO9GfxwPsqPsydutg1DfDBgyrjsg@mail.gmail.com>

Hello,

I am playing with the book of Ivan Ristic.  At some point, he talks about
the list of cipher.  This command gives me an error message :

C:\Program Files\OpenSSL\bin>openssl version -a
OpenSSL 3.0.7 1 Nov 2022 (Library: OpenSSL 3.0.7 1 Nov 2022)
built on: Wed Dec 21 19:51:29 2022 UTC
platform: VC-WIN64A
options:  bn(64,64)
compiler: cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo
/O2 -DL_ENDIAN -DOPENSSL_PIC
OPENSSLDIR: "C:\Program Files\Common Files\SSL"
ENGINESDIR: "C:\Program Files\OpenSSL\lib\engines-3"
MODULESDIR: "C:\Program Files\OpenSSL\lib\ossl-modules"
Seeding source: os-specific
CPUINFO: OPENSSL_ia32cap=0x7ffaf3ffffebffff:0x29c6fbf


C:\Program Files\OpenSSL\bin>openssl ciphers -V 'ALL:COMPLEMENTOFALL'
Error in cipher list
DC0E0000:error:0A000118:SSL routines:ssl_cipher_process_rulestr:invalid
command:ssl\ssl_ciph.c:1065:


Should I worry that something is wrong with my OpenSSL build.  This is a
version that I compiled myself with the instructions given there :
https://github.com/openssl/openssl/blob/master/NOTES-WINDOWS.md

Other commands such as genpkey and req are working well.

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221221/5bfd2714/attachment.htm>

From openssl-users at dukhovni.org  Thu Dec 22 05:50:25 2022
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 22 Dec 2022 00:50:25 -0500
Subject: Error with ciphers -V 'ALL:COMPLEMENTOFALL'
In-Reply-To: <CACTRa=vYt9tM91+6KcWNeLtO9GfxwPsqPsydutg1DfDBgyrjsg@mail.gmail.com>
References: <CACTRa=vYt9tM91+6KcWNeLtO9GfxwPsqPsydutg1DfDBgyrjsg@mail.gmail.com>
Message-ID: <Y6PwIT2pKHNproeB@straasha.imrryr.org>

On Wed, Dec 21, 2022 at 09:41:55PM -0500, Pierre-Luc Boily wrote:

> C:\Program Files\OpenSSL\bin>openssl ciphers -V 'ALL:COMPLEMENTOFALL'

Could it be something as simple the Windows shell passing the "'"
charaxcters as part of the value?  Do double-quotes, or no quotes work
better?

On a Unix system:

    $ openssl ciphers -V "'ALL:COMPLEMENTOFALL'"
    Error in cipher list
    34371141632:error:140E6118:SSL routines:ssl_cipher_process_rulestr:invalid command:/usr/src/crypto/openssl/ssl/ssl_ciph.c:1028:
    34371141632:error:140E6118:SSL routines:ssl_cipher_process_rulestr:invalid command:/usr/src/crypto/openssl/ssl/ssl_ciph.c:1028:

-- 
    Viktor.

From tomas at openssl.org  Thu Dec 22 07:25:52 2022
From: tomas at openssl.org (Tomas Mraz)
Date: Thu, 22 Dec 2022 08:25:52 +0100
Subject: openssl verify with concatenated CA
In-Reply-To: <1198059248.2020913.1671643578278@mail.yahoo.com>
References: <1198059248.2020913.1671643578278.ref@mail.yahoo.com>
 <1198059248.2020913.1671643578278@mail.yahoo.com>
Message-ID: <6b16ec116a83f15c05c1ea2dd52752edf132abd7.camel@openssl.org>

On Wed, 2022-12-21 at 17:26 +0000, Bala Duvvuri via openssl-users
wrote:
> I have a concatenated file containing root CA and intermediate CA
> (say concat.pem, having the 2 CA certificates) copied to a directory
> say "ca"
> 
> I have a entity certificate (cert1) signed by above intermediate CA
> (say inter.pem)
> 
> The observation is 
> 
> This command works : openssl verify -CAfile ca/concat.pem cert1
> 
> This command does not work: openssl verify -CApath ca cert1? ((ca
> directory has concat.pem in hash.0 format))
> But if we copy the intermediate CA as well to the ca/ directory, the
> above command works

Because the -CApath option expects each of the CA certificates to be
placed in the ca directory in a separate file with the hash.x symlink.
Basically the second certificate in the concat.pem file is ignored if
placed in -CApath directory.

-- 
Tom?? Mr?z, OpenSSL


From b_duvvuri at yahoo.com  Thu Dec 22 07:34:14 2022
From: b_duvvuri at yahoo.com (Bala Duvvuri)
Date: Thu, 22 Dec 2022 07:34:14 +0000 (UTC)
Subject: openssl verify with concatenated CA
In-Reply-To: <6b16ec116a83f15c05c1ea2dd52752edf132abd7.camel@openssl.org>
References: <1198059248.2020913.1671643578278.ref@mail.yahoo.com>
 <1198059248.2020913.1671643578278@mail.yahoo.com>
 <6b16ec116a83f15c05c1ea2dd52752edf132abd7.camel@openssl.org>
Message-ID: <580185068.2234974.1671694454449@mail.yahoo.com>

 Thank you Tomas for the clarification.

Thanks
Bala     On Thursday, 22 December, 2022, 12:55:56 pm IST, Tomas Mraz <tomas at openssl.org> wrote:  
 
 On Wed, 2022-12-21 at 17:26 +0000, Bala Duvvuri via openssl-users
wrote:
> I have a concatenated file containing root CA and intermediate CA
> (say concat.pem, having the 2 CA certificates) copied to a directory
> say "ca"
> 
> I have a entity certificate (cert1) signed by above intermediate CA
> (say inter.pem)
> 
> The observation is 
> 
> This command works : openssl verify -CAfile ca/concat.pem cert1
> 
> This command does not work: openssl verify -CApath ca cert1? ((ca
> directory has concat.pem in hash.0 format))
> But if we copy the intermediate CA as well to the ca/ directory, the
> above command works

Because the -CApath option expects each of the CA certificates to be
placed in the ca directory in a separate file with the hash.x symlink.
Basically the second certificate in the concat.pem file is ignored if
placed in -CApath directory.

-- 
Tom?? Mr?z, OpenSSL

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221222/66069c58/attachment-0001.htm>

From Michael.Wojcik at microfocus.com  Thu Dec 22 15:21:57 2022
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 22 Dec 2022 15:21:57 +0000
Subject: Error with ciphers -V 'ALL:COMPLEMENTOFALL'
In-Reply-To: <Y6PwIT2pKHNproeB@straasha.imrryr.org>
References: <CACTRa=vYt9tM91+6KcWNeLtO9GfxwPsqPsydutg1DfDBgyrjsg@mail.gmail.com>
 <Y6PwIT2pKHNproeB@straasha.imrryr.org>
Message-ID: <DM6PR18MB27000B3C3653E5BB5F3B9786F9E89@DM6PR18MB2700.namprd18.prod.outlook.com>

> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of
> Viktor Dukhovni
> Sent: Wednesday, 21 December, 2022 23:50
> 
> On Wed, Dec 21, 2022 at 09:41:55PM -0500, Pierre-Luc Boily wrote:
> 
> > C:\Program Files\OpenSSL\bin>openssl ciphers -V
> 'ALL:COMPLEMENTOFALL'
> 
> Could it be something as simple the Windows shell passing the "'"
> charaxcters as part of the value?  Do double-quotes, or no quotes work
> better?

Exactly. Windows cmd.exe has different quoting conventions than the popular UNIX shells (as does Powershell). The example commands given in /Bulletproof TLS/ need to be adapted to the OS and shell you're using.

There are, of course, various ways to run bash and other UNIX shells under Windows, but the simplest thing in this case is to use cmd.exe's quoting conventions, which are documented by Microsoft. Specifically, as Viktor suggests, use double quotes.

-- 
Michael Wojcik

From pierreluc.boily at gmail.com  Thu Dec 22 15:49:01 2022
From: pierreluc.boily at gmail.com (Pierre-Luc Boily)
Date: Thu, 22 Dec 2022 10:49:01 -0500
Subject: openssl-users Digest, Vol 97, Issue 18
In-Reply-To: <mailman.1065.1671694466.2095.openssl-users@openssl.org>
References: <mailman.1065.1671694466.2095.openssl-users@openssl.org>
Message-ID: <CACTRa=u4AvPiAp3zb=af0Ycfu7BQN8CXCApeh5=K5-ezwZa3tg@mail.gmail.com>

Hello Viktor,

Thank you, this was indeed as simple as that.  I removed the quote and the
command worked on windows.


> On Wed, Dec 21, 2022 at 09:41:55PM -0500, Pierre-Luc Boily wrote:
>
> > C:\Program Files\OpenSSL\bin>openssl ciphers -V 'ALL:COMPLEMENTOFALL'
>
> Could it be something as simple the Windows shell passing the "'"
> charaxcters as part of the value?  Do double-quotes, or no quotes work
> better?
>
> On a Unix system:
>
>     $ openssl ciphers -V "'ALL:COMPLEMENTOFALL'"
>     Error in cipher list
>     34371141632:error:140E6118:SSL
> routines:ssl_cipher_process_rulestr:invalid
> command:/usr/src/crypto/openssl/ssl/ssl_ciph.c:1028:
>     34371141632:error:140E6118:SSL
> routines:ssl_cipher_process_rulestr:invalid
> command:/usr/src/crypto/openssl/ssl/ssl_ciph.c:1028:
>
> --
>     Viktor.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221222/9c393f9a/attachment.htm>

From psv_sridhar at yahoo.com  Thu Dec 22 17:28:57 2022
From: psv_sridhar at yahoo.com (Sridhar)
Date: Thu, 22 Dec 2022 09:28:57 -0800
Subject: Error with ciphers -V 'ALL:COMPLEMENTOFALL'
In-Reply-To: <Y6PwIT2pKHNproeB@straasha.imrryr.org>
References: <Y6PwIT2pKHNproeB@straasha.imrryr.org>
Message-ID: <3C808E06-8A04-48C2-BC65-89BA7C91B006@yahoo.com>

You idiots 

Thanks 
Sridhar 

Sent from my iPhone

> On Dec 21, 2022, at 9:56 PM, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
> 
> ?On Wed, Dec 21, 2022 at 09:41:55PM -0500, Pierre-Luc Boily wrote:
> 
>> C:\Program Files\OpenSSL\bin>openssl ciphers -V 'ALL:COMPLEMENTOFALL'
> 
> Could it be something as simple the Windows shell passing the "'"
> charaxcters as part of the value?  Do double-quotes, or no quotes work
> better?
> 
> On a Unix system:
> 
>    $ openssl ciphers -V "'ALL:COMPLEMENTOFALL'"
>    Error in cipher list
>    34371141632:error:140E6118:SSL routines:ssl_cipher_process_rulestr:invalid command:/usr/src/crypto/openssl/ssl/ssl_ciph.c:1028:
>    34371141632:error:140E6118:SSL routines:ssl_cipher_process_rulestr:invalid command:/usr/src/crypto/openssl/ssl/ssl_ciph.c:1028:
> 
> -- 
>    Viktor.


From guru at unixarea.de  Thu Dec 22 18:29:19 2022
From: guru at unixarea.de (Matthias Apitz)
Date: Thu, 22 Dec 2022 19:29:19 +0100
Subject: Error with ciphers -V 'ALL:COMPLEMENTOFALL'
In-Reply-To: <3C808E06-8A04-48C2-BC65-89BA7C91B006@yahoo.com>
References: <Y6PwIT2pKHNproeB@straasha.imrryr.org>
 <3C808E06-8A04-48C2-BC65-89BA7C91B006@yahoo.com>
Message-ID: <Y6Sh/zKbsFUWndNN@c720-r368166>

El d?a jueves, diciembre 22, 2022 a las 09:28:57a. m. -0800, Sridhar via openssl-users escribi?:

> You idiots 
> 
> Thanks 
> Sridhar 

Sridhar,

Please be so kind and explain to me why you name me an "idiot".
Thanks in advance

	matthias

> > On Dec 21, 2022, at 9:56 PM, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
> > 
> > ?On Wed, Dec 21, 2022 at 09:41:55PM -0500, Pierre-Luc Boily wrote:
> > 
> >> C:\Program Files\OpenSSL\bin>openssl ciphers -V 'ALL:COMPLEMENTOFALL'
> > 
> > Could it be something as simple the Windows shell passing the "'"
> > charaxcters as part of the value?  Do double-quotes, or no quotes work
> > better?
> > 
> > On a Unix system:
> > 
> >    $ openssl ciphers -V "'ALL:COMPLEMENTOFALL'"
> >    Error in cipher list
> >    34371141632:error:140E6118:SSL routines:ssl_cipher_process_rulestr:invalid command:/usr/src/crypto/openssl/ssl/ssl_ciph.c:1028:
> >    34371141632:error:140E6118:SSL routines:ssl_cipher_process_rulestr:invalid command:/usr/src/crypto/openssl/ssl/ssl_ciph.c:1028:
> > 
> > -- 
> >    Viktor.
> 

-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Schlu? mit dem (Wirtschafts-) Krieg gegen Ru?land! Schlu? mit den Sanktionen!
Schlu? mit der Unterst?tzung der faschistoiden Regierungskr?fte in der Ukraine!
Ru?land ist nicht unser Feind, die Regierung der Kriegstreiber ist unser Feind!
Druschba / ?????? mit Ru?land statt NATO-Krieg gegen Ru?land!

From fernando.elena.benavente at gmv.com  Fri Dec 23 10:30:36 2022
From: fernando.elena.benavente at gmv.com (Fernando Elena Benavente)
Date: Fri, 23 Dec 2022 10:30:36 +0000
Subject: ECDSA_SIG not works
Message-ID: <AS8PR07MB751035684E3C80FEEEDF522BD5E99@AS8PR07MB7510.eurprd07.prod.outlook.com>

Good morning everyone,

I have problems with the OpenSSL ECDSA ,specifically with the EDSA_SIG struct. When I initialize the struct and I access to its params (r and s) I get the following error: "error: invalid use of incomplete typedef 'ECDSA_SIG' {aka 'struct ECDSA_SIG_st'}". I am using the latest version of OpenSSL (3.0.7)

https://gyazo.com/375f2fe6a04352f2ee3f3ab4915e27c9

https://gyazo.com/b0817f5e81f86b0b6dcbd405c6cde18b

any tips of why it could happen?

Thanks a lot, Fernando.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221223/99fb8b5c/attachment-0001.htm>

From halmurray+openssl at sonic.net  Sat Dec 24 01:02:44 2022
From: halmurray+openssl at sonic.net (Hal Murray)
Date: Fri, 23 Dec 2022 17:02:44 -0800
Subject: 3.1.0-beta1: util/shlib_wrap.sh
Message-ID: <20221224010244.087FB28C206@107-137-68-211.lightspeed.sntcca.sbcglobal.net>


My notes from 3.0 beta include this step to verify that I got --openssldir 
configured correctly.

$ util/shlib_wrap.sh ./apps/openssl version -d

Now it says:
FATAL: Startup failure (dev note: apps_startup()) for ./apps/openssl
40772751647F0000:error:030000A9:digital envelope routines:alg_module_init:unkno
wn option:crypto/evp/evp_cnf.c:61:name=rh-allow-sha1-signatures, value=yes
40772751647F0000:error:0700006D:configuration file routines:module_run:module 
initialization error:crypto/conf/conf_mod.c:270:module=alg_section, 
value=evp_properties retcode=-1


Did this area change from 3.0 to 3.1?

-- 
These are my opinions.  I hate spam.




From tomiii at tomiii.com  Mon Dec 26 20:04:08 2022
From: tomiii at tomiii.com (Thomas Dwyer III)
Date: Mon, 26 Dec 2022 12:04:08 -0800
Subject: ECDSA_SIG not works
In-Reply-To: <AS8PR07MB751035684E3C80FEEEDF522BD5E99@AS8PR07MB7510.eurprd07.prod.outlook.com>
References: <AS8PR07MB751035684E3C80FEEEDF522BD5E99@AS8PR07MB7510.eurprd07.prod.outlook.com>
Message-ID: <CADqc48RAk4Y18e6iJ5q585wQebhaDmZd4qskKCYWrxvD2QAvOA@mail.gmail.com>

Most (all?) of the OpenSSL data structures are opaque now and require
accessor functions to get/set the member fields. In your case, see the man
page for ECDSA_SIG_set0():

       The r and s values can be set by calling ECDSA_SIG_set0() and passing
       the new values for r and s as parameters to the function. Calling
this
       function transfers the memory management of the values to the
ECDSA_SIG
       object, and therefore the values that have been passed in should not
be
       freed directly after this function has been called.


Regards,
Tom.III


On Fri, Dec 23, 2022 at 2:31 AM Fernando Elena Benavente <
fernando.elena.benavente at gmv.com> wrote:

> Good morning everyone,
>
>
>
> I have problems with the OpenSSL ECDSA ,specifically with the EDSA_SIG
> struct. When I initialize the struct and I access to its params (r and s) I
> get the following error: ?error: invalid use of incomplete typedef
> ?ECDSA_SIG? {aka ?struct ECDSA_SIG_st?}?. I am using the latest version of
> OpenSSL (3.0.7)
>
>
>
> https://gyazo.com/375f2fe6a04352f2ee3f3ab4915e27c9
>
>
>
> https://gyazo.com/b0817f5e81f86b0b6dcbd405c6cde18b
>
>
>
> any tips of why it could happen?
>
>
>
> Thanks a lot, Fernando.
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221226/646699c7/attachment.htm>

From jeremy at saklad5.com  Tue Dec 27 01:46:29 2022
From: jeremy at saklad5.com (Jeremy Saklad)
Date: Mon, 26 Dec 2022 19:46:29 -0600
Subject: Creating an indefinitely-valid self-signed x509 certificate
Message-ID: <4924B2F8-0832-479D-851C-B6D3148AC76C@saklad5.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I find myself regularly creating self-signed certificates that are verified out-of-band, through DANE, pinning the file, or other means. Since the out-of-band verification determines validity, there is no reason to set an expiration date on the certificate itself.

Section 4.1.2.5 of RFC 5280 states that an x509 certificate without a well-defined expiration date SHOULD have a notAfter value of 99991231235959Z. However, I see no practical way to achieve this using the openssl command-line options. In fact, I see no way to set an explicit expiration date at all. Am I missing something?

The following is the sort of command I am using (with OpenSSL 3.0.7) to produce self-signed certificates. How could I set an absolute time like the RFC recommends?

openssl req -x509 -key host.example.key -addext keyUsage=digitalSignature -addext extendedKeyUsage=serverAuth -subj "/CN=host.example/" -out ~/host.example.crt
-----BEGIN PGP SIGNATURE-----

iMwEARYKAHQWIQST9JhYTT2FVNyHHwCUsC6j0LZIGwUCY6pKc1YYJ2h0dHBzOi8v
b3BlbnBncGtleS5zYWtsYWQ1LmNvbS9maW5nZXJwcmludC9GRERGQzRBNEE2N0Qw
NEVGRkVCOEU0MjQ5Q0EyMTQ5NTgzRURCRjg0JwAKCRCUsC6j0LZIGy30AQCVvn0t
9oe111vtIPI8AxWOc0xfIuWA8TMKrhzJEaeGYwD/c0qemFs1Ou5s4nB/gdhBIfWm
vFNQa2Pz3zhm3JVwyQk=
=fEvX
-----END PGP SIGNATURE-----

From openssl-users at dukhovni.org  Tue Dec 27 01:55:19 2022
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 26 Dec 2022 20:55:19 -0500
Subject: Creating an indefinitely-valid self-signed x509 certificate
In-Reply-To: <4924B2F8-0832-479D-851C-B6D3148AC76C@saklad5.com>
References: <4924B2F8-0832-479D-851C-B6D3148AC76C@saklad5.com>
Message-ID: <Y6pQhyCP24SeIptP@straasha.imrryr.org>

On Mon, Dec 26, 2022 at 07:46:29PM -0600, Jeremy Saklad via openssl-users wrote:

> I find myself regularly creating self-signed certificates that are
> verified out-of-band, through DANE, pinning the file, or other means.
> Since the out-of-band verification determines validity, there is no
> reason to set an expiration date on the certificate itself.
> 
> Section 4.1.2.5 of RFC 5280 states that an x509 certificate without a
> well-defined expiration date SHOULD have a notAfter value of
> 99991231235959Z. However, I see no practical way to achieve this using
> the openssl command-line options. In fact, I see no way to set an
> explicit expiration date at all. Am I missing something?
> 
> The following is the sort of command I am using (with OpenSSL 3.0.7)
> to produce self-signed certificates. How could I set an absolute time
> like the RFC recommends?

The "-days" option of "openssl req -new -x509" lets you set an
expiration date far into the future.  This is used in, e.g.:

    https://raw.githubusercontent.com/openssl/openssl/master/test/certs/mkcert.sh

I frankly wouldn't bother with the year 9999 date, it is more likely to
run into issues than something that is say good for 100 years.  If RSA
is still in use by then, I'd be surprised (if I were still alive, so
perhaps more suprised by that, than by RSA being in use, so see you in
2122! :-) Happy New Year!

-- 
    Viktor.

From felipe at felipegasper.com  Tue Dec 27 02:09:39 2022
From: felipe at felipegasper.com (Felipe Gasper)
Date: Mon, 26 Dec 2022 21:09:39 -0500
Subject: Creating an indefinitely-valid self-signed x509 certificate
In-Reply-To: <4924B2F8-0832-479D-851C-B6D3148AC76C@saklad5.com>
References: <4924B2F8-0832-479D-851C-B6D3148AC76C@saklad5.com>
Message-ID: <12E9013E-30E4-4C0C-8519-1867740FA7D1@felipegasper.com>

If all else fails, this should be possible in Perl with Crypt::Perl.

-FG

> On Dec 26, 2022, at 20:46, Jeremy Saklad via openssl-users <openssl-users at openssl.org> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> I find myself regularly creating self-signed certificates that are verified out-of-band, through DANE, pinning the file, or other means. Since the out-of-band verification determines validity, there is no reason to set an expiration date on the certificate itself.
> 
> Section 4.1.2.5 of RFC 5280 states that an x509 certificate without a well-defined expiration date SHOULD have a notAfter value of 99991231235959Z. However, I see no practical way to achieve this using the openssl command-line options. In fact, I see no way to set an explicit expiration date at all. Am I missing something?
> 
> The following is the sort of command I am using (with OpenSSL 3.0.7) to produce self-signed certificates. How could I set an absolute time like the RFC recommends?
> 
> openssl req -x509 -key host.example.key -addext keyUsage=digitalSignature -addext extendedKeyUsage=serverAuth -subj "/CN=host.example/" -out ~/host.example.crt
> -----BEGIN PGP SIGNATURE-----
> 
> iMwEARYKAHQWIQST9JhYTT2FVNyHHwCUsC6j0LZIGwUCY6pKc1YYJ2h0dHBzOi8v
> b3BlbnBncGtleS5zYWtsYWQ1LmNvbS9maW5nZXJwcmludC9GRERGQzRBNEE2N0Qw
> NEVGRkVCOEU0MjQ5Q0EyMTQ5NTgzRURCRjg0JwAKCRCUsC6j0LZIGy30AQCVvn0t
> 9oe111vtIPI8AxWOc0xfIuWA8TMKrhzJEaeGYwD/c0qemFs1Ou5s4nB/gdhBIfWm
> vFNQa2Pz3zhm3JVwyQk=
> =fEvX
> -----END PGP SIGNATURE-----




From tomas at openssl.org  Tue Dec 27 08:39:17 2022
From: tomas at openssl.org (Tomas Mraz)
Date: Tue, 27 Dec 2022 09:39:17 +0100
Subject: 3.1.0-beta1: util/shlib_wrap.sh
In-Reply-To: <20221224010244.087FB28C206@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
References: <20221224010244.087FB28C206@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
Message-ID: <de120197a6cc5972517195f1b41a74cb57d3c8d7.camel@openssl.org>

This is indication that you're using Red Hat specific configuration
file with the OpenSSL-3.1.0-beta1 build. Red Hat adds some patches to
their OpenSSL builds to support additional configuration options in the
config file. These options won't be recognized by upstream build and
cause such errors.

That basically means that you cannot use the same openssldir for the
Red Hat build of OpenSSL and regular upstream OpenSSL builds.

Tomas Mraz, OpenSSL

On Fri, 2022-12-23 at 17:02 -0800, Hal Murray wrote:
> 
> My notes from 3.0 beta include this step to verify that I got --
> openssldir 
> configured correctly.
> 
> $ util/shlib_wrap.sh ./apps/openssl version -d
> 
> Now it says:
> FATAL: Startup failure (dev note: apps_startup()) for ./apps/openssl
> 40772751647F0000:error:030000A9:digital envelope
> routines:alg_module_init:unkno
> wn option:crypto/evp/evp_cnf.c:61:name=rh-allow-sha1-signatures,
> value=yes
> 40772751647F0000:error:0700006D:configuration file
> routines:module_run:module 
> initialization error:crypto/conf/conf_mod.c:270:module=alg_section, 
> value=evp_properties retcode=-1
> 
> 
> Did this area change from 3.0 to 3.1?
> 

-- 
Tom?? Mr?z, OpenSSL


From hareesh.ulleri at ovt.com  Wed Dec 28 10:49:01 2022
From: hareesh.ulleri at ovt.com (Hareesh Das Ulleri)
Date: Wed, 28 Dec 2022 10:49:01 +0000
Subject: Custom Provider - EVP_CIPHER_fetch fails
In-Reply-To: <6e87e68c-9fa0-9873-3e66-2289a36020cd@openssl.org>
References: <839a0daa09fc4da4b87ad844564ddec1@ovtmail3.ovt.com>
 <6e87e68c-9fa0-9873-3e66-2289a36020cd@openssl.org>
Message-ID: <4ee418854527491fbb3733fd10786d6c@ovtmail2.ovt.com>

Hello Matt / Hello all,
   Thanks for the support. After some changes, able to do the encryption and decryption.

In test application, fetch is like...
cipher = EVP_CIPHER_fetch(NULL, "ALGO-CUSTOM", NULL);

and the config file looks below (hope this is the expected way):
openssl_conf = openssl_init

[openssl_init]
providers = provider_section
alg_section = evp_properties

[provider_section]
Custom-Prov = Custom-Prov_section
default = default_section

[Custom-Prov_section]
identity = Custom-Prov
module = /userfs/lib/ Custom-Prov.so
activate = 1

[default_section]
activate = 1

However when I want to change the algorithm name to " AES-256-CBC-CTS " (This is the actual implementation), not able to fetch from the custom provider (taking default one). Even I tried to give along with an algo property string in test application and in provider, fetch is failing.

cipher = EVP_CIPHER_fetch(NULL, "AES-256-CBC-CTS", "Custom-Prov=yes");

How can I fetch an cipher algorithm implementation even a default implementation exists ("default" provider may need to co-exist for other operations). Please suggest.

Thank you,
Hareesh

-----Original Message-----
From: Matt Caswell <matt at openssl.org> 
Sent: Tuesday, December 13, 2022 7:49 PM
To: Hareesh Das Ulleri <hareesh.ulleri at ovt.com>; openssl-users at openssl.org
Subject: Re: Custom Provider - EVP_CIPHER_fetch fails

[CAUTION]: EXTERNAL EMAIL


On 13/12/2022 09:13, Hareesh Das Ulleri wrote:
> Hello OpenSSL users,
>
>    I am in preparation of a provider (for a custom crypto) by 
> referring OpenSSL 3 design doc

Don't refer to the design doc. It has not been maintained with all the latest tweaks and updates to what was originally envisaged.

> (I use Linux 5.10 + OpenSSL 3.0.7). I believe, the custom provider has 
> all required call backs implemented for the cipher functionalities in 
> its dispatch table.
>

You should refer to the man page for what is required to implement a custom cipher. See:

https://urldefense.com/v3/__https://www.openssl.org/docs/man3.0/man7/provider-cipher.html__;!!AYUVhIwY!6U5m1Q3RFPFx8ih3X6UUd7d2rGn85M_2O1G29O1jiYnm8L3aX9Q8HpvSCrZsJGZIRglgUjpEScuW0w$

Note in particular this comment in the man page:

"A cipher algorithm implementation may not implement all of these functions. In order to be a consistent set of functions there must at least be a complete set of "encrypt" functions, or a complete set of "decrypt" functions, or a single "cipher" function. In all cases both the OSSL_FUNC_cipher_newctx and OSSL_FUNC_cipher_freectx functions must be present. All other functions are optional."

So, in other words, you must as a minimum implement OSSL_FUNC_cipher_encrypt_init (or OSSL_FUNC_cipher_decrypt_init), OSSL_FUNC_cipher_update, OSSL_FUNC_cipher_final, OSSL_FUNC_cipher_newctx and OSSL_FUNC_cipher_freectx.

You should probably also read the following pages for general information on writing a provider:

https://urldefense.com/v3/__https://www.openssl.org/docs/man3.0/man7/provider.html__;!!AYUVhIwY!6U5m1Q3RFPFx8ih3X6UUd7d2rGn85M_2O1G29O1jiYnm8L3aX9Q8HpvSCrZsJGZIRglgUjr2VgFhFA$
https://urldefense.com/v3/__https://www.openssl.org/docs/man3.0/man7/provider-base.html__;!!AYUVhIwY!6U5m1Q3RFPFx8ih3X6UUd7d2rGn85M_2O1G29O1jiYnm8L3aX9Q8HpvSCrZsJGZIRglgUjqmYHiAcQ$

You might also want to refer to Richard Levitte's implementation of the toy Vigen?re cipher as a provider here:

https://urldefense.com/v3/__https://github.com/provider-corner/vigenere__;!!AYUVhIwY!6U5m1Q3RFPFx8ih3X6UUd7d2rGn85M_2O1G29O1jiYnm8L3aX9Q8HpvSCrZsJGZIRglgUjoTNn-vCA$

>    I have another test application (for encryption and decryption of a 
> text message). At the starting of the app, it calls OSSL_PROVIDER_load 
> and EVP_CIPHER_fetch functions to the custom provider. But 
> unfortunately custom provider fetch function fails?


I suggest calling the OSSL_PROVIDER_available() function to determine whether your custom provider has been successfully loaded:

https://urldefense.com/v3/__https://www.openssl.org/docs/man3.0/man3/OSSL_PROVIDER_available.html__;!!AYUVhIwY!6U5m1Q3RFPFx8ih3X6UUd7d2rGn85M_2O1G29O1jiYnm8L3aX9Q8HpvSCrZsJGZIRglgUjqQex0Yvg$

>
> What could be the missing or how to make sure that the custom provider 
> is loaded correctly before calling the fetch function?
>
> cipher = EVP_CIPHER_fetch(NULL, "AES-256-CBC-CTS", NULL);  -> This 
> will work, default provider
>
> cipher = EVP_CIPHER_fetch(NULL, "CUSTOM_ALGO", NULL);  -> returns 
> NULL, custom provider
>
> _Confg file:_
>
> openssl_conf = openssl_init
>
> [openssl_init]
>
> providers = provider_section
>
> [provider_section]
>
> customProv = customProv_section
>
> default = default_sect
>
> [customProv_section]
>
> provider_id = customProv
>
> module_path = /userfs/lib/customProv.so
>
> algorithms = CUSTOM_ALGO
>
> activate = 1
>
> [default_sect]
>
> algorithms = AES-256-CBC-CTS
>
> activate = 1

This config file does not look correct. I guess you based it on some of the examples in the design doc which are out of date.

The man page for config file formats is here:

https://urldefense.com/v3/__https://www.openssl.org/docs/man3.0/man5/config.html__;!!AYUVhIwY!6U5m1Q3RFPFx8ih3X6UUd7d2rGn85M_2O1G29O1jiYnm8L3aX9Q8HpvSCrZsJGZIRglgUjooudQYNw$

See the "Provider Configuration" section on that page in particular.

Also worth looking at are some of the test config files used in the OpenSSL code base for loading providers, e.g.

https://urldefense.com/v3/__https://github.com/openssl/openssl/blob/openssl-3.0/test/default-and-legacy.cnf__;!!AYUVhIwY!6U5m1Q3RFPFx8ih3X6UUd7d2rGn85M_2O1G29O1jiYnm8L3aX9Q8HpvSCrZsJGZIRglgUjqOGgUZbA$

Matt


>
> Thank you,
>
> Hareesh
>