From lists at boyandin.info Thu Jul 1 00:36:10 2021 From: lists at boyandin.info (Konstantin Boyandin) Date: Thu, 01 Jul 2021 00:36:10 +0000 Subject: openssl 1.1.1k: missing d2i_X509 function prototype Message-ID: <0a76731c-04de-462e-bfb3-5f88f8a9a813@mtasv.net> Hello, OpenSSL version: 1.1.1k. I noticed that X509 *d2i_X509(X509 **px, const unsigned char **in, long len); function is no longer defined in openssl/x509.h available in 1.0.x versions, the only one available is now X509 *d2i_X509_AUX(X509 **a, const unsigned char **pp, long length); Do I understand correctly that I should rewrite corresponding code of my application so that it would only use d2i_X509_AUX ? Note: d2i_X509() is still mentioned in https://www.openssl.org/docs/man1.1.1/man3/d2i_X509.html -- Sincerely, Konstantin Boyandin From openssl-users at dukhovni.org Thu Jul 1 01:04:22 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 30 Jun 2021 21:04:22 -0400 Subject: openssl 1.1.1k: missing d2i_X509 function prototype In-Reply-To: <0a76731c-04de-462e-bfb3-5f88f8a9a813@mtasv.net> References: <0a76731c-04de-462e-bfb3-5f88f8a9a813@mtasv.net> Message-ID: On Thu, Jul 01, 2021 at 12:36:10AM +0000, Konstantin Boyandin via openssl-users wrote: > OpenSSL version: 1.1.1k. > > I noticed that > > X509 *d2i_X509(X509 **px, const unsigned char **in, long len); > > function is no longer defined in openssl/x509.h available in 1.0.x > versions, the only one available is now Actually it is still declared, via: DECLARE_ASN1_FUNCTIONS(X509) -- Viktor. From lists at boyandin.info Thu Jul 1 01:37:14 2021 From: lists at boyandin.info (Konstantin Boyandin) Date: Thu, 01 Jul 2021 01:37:14 +0000 Subject: openssl 1.1.1k: missing d2i_X509 function prototype In-Reply-To: References: <0a76731c-04de-462e-bfb3-5f88f8a9a813@mtasv.net> Message-ID: On 01.07.2021 08:04, Viktor Dukhovni wrote: > On Thu, Jul 01, 2021 at 12:36:10AM +0000, Konstantin Boyandin via openssl-users wrote: > >> OpenSSL version: 1.1.1k. >> >> I noticed that >> >> X509 *d2i_X509(X509 **px, const unsigned char **in, long len); >> >> function is no longer defined in openssl/x509.h available in 1.0.x >> versions, the only one available is now > > Actually it is still declared, via: > > DECLARE_ASN1_FUNCTIONS(X509) But I can't find the function implementation anywhere in code! After I build .dll version of OpenSSL 1.1.1k, I get a fatal error when an application tries to call d2i_X509() - it's not present in the library. What are my options in such a situation? -- Sincerely, Konstantin Boyandin From openssl-users at dukhovni.org Thu Jul 1 01:49:16 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 30 Jun 2021 21:49:16 -0400 Subject: openssl 1.1.1k: missing d2i_X509 function prototype In-Reply-To: References: <0a76731c-04de-462e-bfb3-5f88f8a9a813@mtasv.net> Message-ID: On Thu, Jul 01, 2021 at 01:37:14AM +0000, Konstantin Boyandin via openssl-users wrote: > > Actually it is still declared, via: > > > > DECLARE_ASN1_FUNCTIONS(X509) > > But I can't find the function implementation anywhere in code! > > After I build .dll version of OpenSSL 1.1.1k, I get a fatal error when > an application tries to call d2i_X509() - it's not present in the library. Build the library correctly: * On a Fedora system: $ objdump -T /usr/lib64/libcrypto.so.1.1 | grep -w d2i_X509 000000000020c490 g DF .text 0000000000000010 OPENSSL_1_1_0 d2i_X509 * On a FreeBSD system: $ nm /usr/local/lib/libcrypto.so.11 | grep -w d2i_X509 00000000003189a0 T d2i_X509 The list of exported symbols for libcrypto has: util/libcrypto.num:d2i_X509 574 1_1_0 EXIST::FUNCTION: a correct build will result in a libcrypto with this function exported. -- Viktor. From vinod9987 at gmail.com Thu Jul 1 06:21:08 2021 From: vinod9987 at gmail.com (vinod mg) Date: Thu, 1 Jul 2021 11:51:08 +0530 Subject: Need help in removing secp521r1 from openssl-1.1.1g and adding TLS_GREASE_BA cipher. In-Reply-To: References: Message-ID: Hi All, Please let know if my ask is even possible. Thanks, Vinod On Tue, Jun 29, 2021 at 4:42 PM vinod mg wrote: > Hi All, > > I am bit a newbie and need some assistance in couple of things - > > 1) Supress or a way to remove secp521r1 from the currenlty installed > openssl. > 2) Add the cipher - "0xbaba TLS_GREASE_BA GREASE" like we see in > chrome. > > I am ok with custom install as well, if above cannot be done with already > installed openssl package. Please share any wiki I can follow to > impliment the same. > > ~]# openssl ecparam -list_curves > > secp224r1 : NIST/SECG curve over a 224 bit prime field > > secp256k1 : SECG curve over a 256 bit prime field > > secp384r1 : NIST/SECG curve over a 384 bit prime field > > *secp521r1 : NIST/SECG curve over a 521 bit prime field* > > prime256v1: X9.62/SECG curve over a 256 bit prime field > > I am using below OS and version- > > # cat /etc/redhat-release > > Red Hat Enterprise Linux release 8.3 (Ootpa) > > # openssl version -a > > OpenSSL 1.1.1g FIPS 21 Apr 2020 > > built on: Thu Mar 25 16:46:53 2021 UTC > > platform: linux-x86_64 > > options: bn(64,64) md2(char) rc4(16x,int) des(int) idea(int) > blowfish(ptr) > > compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -O2 -g -pipe > -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 > -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong > -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic > -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection > -Wa,--noexecstack -Wa,--generate-missing-build-notes=yes > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -DOPENSSL_USE_NODELETE > -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM > -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM > -DPOLY1305_ASM -DZLIB -DNDEBUG -DPURIFY -DDEVRANDOM="\"/dev/urandom\"" > -DSYSTEM_CIPHERS_FILE="/etc/crypto-policies/back-ends/openssl.config" > > OPENSSLDIR: "/etc/pki/tls" > > ENGINESDIR: "/usr/lib64/engines-1.1" > > Seeding source: os-specific > > engines: rdrand dynamic > > Really appriciate your time and help, thanks in advance. > > Thanks, > Vinod > -------------- next part -------------- An HTML attachment was scrubbed... URL: From janjust at nikhef.nl Thu Jul 1 06:59:58 2021 From: janjust at nikhef.nl (Jan Just Keijser) Date: Thu, 1 Jul 2021 08:59:58 +0200 Subject: client certificate error In-Reply-To: References: <432b4907-744b-58f0-de50-4a67b4c4bace@gmail.com> <4f3662a8-6ffb-6040-9779-1fddb30bcaff@nikhef.nl> Message-ID: <679a67d8-7ec2-b06e-5ac7-5d28ed7a8dc8@nikhef.nl> Hi, On 30/06/21 15:22, Paulo Wollny wrote: > Hi, > > thank you for the answer. > > can you please point the right direction for solution, please? > try ?http://httpd.apache.org/userslist.html > Regarding the "look suspicious - it means your client is connecting > from 127.0.0.1 and your server is also listening on 127.0.0.1 ; is > this really what you have in mind? "? i'm testin on my local system, > having apache server and browser (chrome) on the same system. > > And yes, the server cetificate have localhost as DNS alias. > > The apache mailing list is a better place to ask ; as for using a certificate with localhost alias - I would not recommend doing that. It is better to use a FDQN and then add that FQDN to the /etc/hosts file using ? 127.0.0.1??? HTH, JJK From joe.carroll.hrg2 at statefarm.com Thu Jul 1 13:22:46 2021 From: joe.carroll.hrg2 at statefarm.com (Joe Carroll) Date: Thu, 1 Jul 2021 13:22:46 +0000 Subject: GNU Make erroring on makefile Message-ID: <9b2db2eb94f64a5a8f1258f1792c142a@statefarm.com> Has anyone successfully used GNU Make as part of the install process for version 1.1.1k or later? I'm getting a "missing separator" error on line 56. I do not have access to nmake.exe. !IF "$(DESTDIR)" != "" -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Thu Jul 1 13:24:39 2021 From: levitte at openssl.org (Richard Levitte) Date: Thu, 01 Jul 2021 15:24:39 +0200 Subject: GNU Make erroring on makefile In-Reply-To: <9b2db2eb94f64a5a8f1258f1792c142a@statefarm.com> References: <9b2db2eb94f64a5a8f1258f1792c142a@statefarm.com> Message-ID: <87tulep3oo.wl-levitte@openssl.org> How did you configure, and on what platform? On Thu, 01 Jul 2021 15:22:46 +0200, Joe Carroll wrote: > > Has anyone successfully used GNU Make as part of the install process for version 1.1.1k or later? > I?m getting a ?missing separator? error on line 56. I do not have access to nmake.exe. > > !IF "$(DESTDIR)" != "" > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From joe.carroll.hrg2 at statefarm.com Thu Jul 1 14:06:49 2021 From: joe.carroll.hrg2 at statefarm.com (Joe Carroll) Date: Thu, 1 Jul 2021 14:06:49 +0000 Subject: [EXTERNAL] Re: GNU Make erroring on makefile In-Reply-To: <87tulep3oo.wl-levitte@openssl.org> References: <9b2db2eb94f64a5a8f1258f1792c142a@statefarm.com> <87tulep3oo.wl-levitte@openssl.org> Message-ID: <25d2ddf580954554b348f1d6a193ccb5@statefarm.com> Windows 10 perl Configure VC-WIN64A -----Original Message----- From: Richard Levitte [mailto:levitte at openssl.org] Sent: Thursday, July 1, 2021 8:25 AM To: Joe Carroll Cc: openssl-users at openssl.org Subject: [EXTERNAL] Re: GNU Make erroring on makefile How did you configure, and on what platform? On Thu, 01 Jul 2021 15:22:46 +0200, Joe Carroll wrote: > > Has anyone successfully used GNU Make as part of the install process for version 1.1.1k or later? > I'm getting a "missing separator" error on line 56. I do not have access to nmake.exe. > > !IF "$(DESTDIR)" != "" > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Thu Jul 1 14:40:14 2021 From: matt at openssl.org (Matt Caswell) Date: Thu, 1 Jul 2021 15:40:14 +0100 Subject: [EXTERNAL] Re: GNU Make erroring on makefile In-Reply-To: <25d2ddf580954554b348f1d6a193ccb5@statefarm.com> References: <9b2db2eb94f64a5a8f1258f1792c142a@statefarm.com> <87tulep3oo.wl-levitte@openssl.org> <25d2ddf580954554b348f1d6a193ccb5@statefarm.com> Message-ID: On 01/07/2021 15:06, Joe Carroll wrote: > Windows 10 > perl Configure VC-WIN64A The VC-WIN64A target generates a Makefile suitable for consumption by nmake. Hence its not possible to use GNU make with it. It *is* possible to build for Windows using GNU make with a different target however. To do this you must first install MSYS2 with the mingw compiler packages and associated toolchain, as well as the MSYS2 version of perl (*not* other versions of perl). Then you can configure and build as normal: perl Configure mingw64 make make test make install See the section "mingw and mingw64" in NOTES.WIN. Matt > > > -----Original Message----- > From: Richard Levitte [mailto:levitte at openssl.org] > Sent: Thursday, July 1, 2021 8:25 AM > To: Joe Carroll > Cc: openssl-users at openssl.org > Subject: [EXTERNAL] Re: GNU Make erroring on makefile > > How did you configure, and on what platform? > > On Thu, 01 Jul 2021 15:22:46 +0200, > Joe Carroll wrote: >> >> Has anyone successfully used GNU Make as part of the install process for version 1.1.1k or later? >> I'm getting a "missing separator" error on line 56. I do not have access to nmake.exe. >> >> !IF "$(DESTDIR)" != "" >> >> From joe.carroll.hrg2 at statefarm.com Thu Jul 1 14:55:05 2021 From: joe.carroll.hrg2 at statefarm.com (Joe Carroll) Date: Thu, 1 Jul 2021 14:55:05 +0000 Subject: [EXTERNAL] Re: GNU Make erroring on makefile In-Reply-To: References: <9b2db2eb94f64a5a8f1258f1792c142a@statefarm.com> <87tulep3oo.wl-levitte@openssl.org> <25d2ddf580954554b348f1d6a193ccb5@statefarm.com> Message-ID: <1eb5797b70464409bbac853690a4523a@statefarm.com> Thanks Matt. That clears it up. -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matt Caswell Sent: Thursday, July 1, 2021 9:40 AM To: openssl-users at openssl.org Subject: Re: [EXTERNAL] Re: GNU Make erroring on makefile On 01/07/2021 15:06, Joe Carroll wrote: > Windows 10 > perl Configure VC-WIN64A The VC-WIN64A target generates a Makefile suitable for consumption by nmake. Hence its not possible to use GNU make with it. It *is* possible to build for Windows using GNU make with a different target however. To do this you must first install MSYS2 with the mingw compiler packages and associated toolchain, as well as the MSYS2 version of perl (*not* other versions of perl). Then you can configure and build as normal: perl Configure mingw64 make make test make install See the section "mingw and mingw64" in NOTES.WIN. Matt > > > -----Original Message----- > From: Richard Levitte [mailto:levitte at openssl.org] > Sent: Thursday, July 1, 2021 8:25 AM > To: Joe Carroll > Cc: openssl-users at openssl.org > Subject: [EXTERNAL] Re: GNU Make erroring on makefile > > How did you configure, and on what platform? > > On Thu, 01 Jul 2021 15:22:46 +0200, > Joe Carroll wrote: >> >> Has anyone successfully used GNU Make as part of the install process for version 1.1.1k or later? >> I'm getting a "missing separator" error on line 56. I do not have access to nmake.exe. >> >> !IF "$(DESTDIR)" != "" >> >> From Michael.Wojcik at microfocus.com Thu Jul 1 17:21:15 2021 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 1 Jul 2021 17:21:15 +0000 Subject: Compilation error using OpenSSL 1.1.1i In-Reply-To: References: Message-ID: > From: openssl-users On Behalf Of Jayalakshmi bhat > Sent: Wednesday, 30 June, 2021 08:29 > I am getting the below error. Does anyone have inputs. Any help would be appreciated. > openssl/safestack.h(159) : error C2054: expected '(' to follow '__inline__' [I don't think I've seen a reply to this. If it's already been answered, my apologies for the noise.] With OpenSSL build questions, please always supply the Configure command line. Offhand, it looks like your compiler doesn't recognize __inline__ as a decoration on a function declaration, and the pp-token "ossl_inline" is defined to expand to "__inline__". Without digging through the configuration mechanism I can't say exactly how ossl_inline is defined, but presumably it's set by configuration based on what C implementation it believes you're using. So you may be using the wrong Configure target, or that target may assume a different C compiler, or a newer version of it. -- Michael Wojcik From reinier.torenbeek at gmail.com Thu Jul 1 17:49:00 2021 From: reinier.torenbeek at gmail.com (Reinier Torenbeek) Date: Thu, 1 Jul 2021 14:49:00 -0300 Subject: CNG engine on GitHub Message-ID: Hi, For anyone interested in leveraging Windows CNG with OpenSSL 1.1.1, you may want to check out this new OpenSSL CNG Engine project on GitHub: https://github.com/rticommunity/openssl-cng-engine . The associated User's Manual is on ReadTheDocs: https://openssl-cng-engine.readthedocs.io/en/latest/index.html . The project implements the majority of the EVP interface, to leverage the BCrypt crypto implementations, as well as a subset of the STORE interface, for integration with the Windows Certificate and Keystore(s), via the NCrypt and Cert APIs. It has been tested with 1.1.1k on Windows 10, with Visual Studio 2017 and 2019. It is released under the Apache-2.0 license. Any feedback is welcome, please send it to me or open an issue on GitHub. Best regards, Reinier -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Jul 1 19:40:41 2021 From: matt at openssl.org (Matt Caswell) Date: Thu, 1 Jul 2021 20:40:41 +0100 Subject: CNG engine on GitHub In-Reply-To: References: Message-ID: Nice! Are there any thoughts to support providers? The engine interface is deprecated in 3.0. Matt On 01/07/2021 18:49, Reinier Torenbeek wrote: > Hi, > > For anyone interested in leveraging Windows CNG with OpenSSL 1.1.1, you > may want to check out this new OpenSSL CNG Engine project on GitHub: > https://github.com/rticommunity/openssl-cng-engine > . The associated > User's Manual is on ReadTheDocs: > https://openssl-cng-engine.readthedocs.io/en/latest/index.html > . > > The project implements the majority of the EVP interface, to leverage > the BCrypt crypto implementations, as well as a subset of the STORE > interface, for integration with the Windows?Certificate and Keystore(s), > via the NCrypt and Cert APIs. It has been tested with 1.1.1k on Windows > 10, with Visual Studio 2017 and 2019. It is released under the > Apache-2.0 license. > > Any feedback is welcome, please send it to me or open an issue on GitHub. > > Best regards, > Reinier From jb-openssl at wisemo.com Thu Jul 1 22:35:27 2021 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 2 Jul 2021 00:35:27 +0200 Subject: email notice [was: Not getting some macros for FIPS] In-Reply-To: <871r8pr8qb.wl-levitte@openssl.org> References: <871r8pr8qb.wl-levitte@openssl.org> Message-ID: <853f53ff-da00-6ee5-7c97-c8da4fd6a1a7@wisemo.com> On 2021-06-25 22:26, Richard Levitte wrote: > On Wed, 23 Jun 2021 10:51:05 +0200, > Tomas Mraz wrote: >> On Wed, 2021-06-23 at 08:12 +0000, Kumar Mishra, Sanjeev wrote: >> >>> Notice: This e-mail together with any attachments may contain >>> information of Ribbon Communications Inc. and its Affiliates that is >>> confidential and/or proprietary for the sole use of the intended >>> recipient. Any review, disclosure, reliance or distribution by others >>> or forwarding without express permission is strictly prohibited. If >>> you are not the intended recipient, please notify the sender >>> immediately and then delete all copies, including any attachments. >> It's a little bit strange to send e-mails with such notices to public >> mailing lists where the intented recipient is _anyone_. > Those notices are a bit amusing, yeah. Of course, Sanjeev can't be > blamed for this, as we can probably assume that it's a corporate > filter that automagically adds those. > > And oh boy! openssl-users having almost 3000 subscribers, that's > quite a lot of people to chase down and ensure they have destroyed all > copies, I tell ya! "Good luck" is probably an appropriate response > ;-) > > Which is why I have set up dedicated e-mail identities for posting to such public lists, using a different disclaimer in the sig-block. I hope this can inspire other sysadmins to set up something similar. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From reinier.torenbeek at gmail.com Fri Jul 2 03:25:17 2021 From: reinier.torenbeek at gmail.com (Reinier Torenbeek) Date: Fri, 2 Jul 2021 00:25:17 -0300 Subject: CNG engine on GitHub In-Reply-To: References: Message-ID: Hi Matt, I am aware of the deprecation of the engine interface with 3.0 but have not looked into the details of support providers yet. I expect converting an engine to a support provider could be done with quite a bit of code reuse, correct? Would you say the interface and design of support providers is stable at this point? Thanks, Reinier > On Jul 1, 2021, at 4:41 PM, Matt Caswell wrote: > > ?Nice! Are there any thoughts to support providers? The engine interface is deprecated in 3.0. > > Matt > > >> On 01/07/2021 18:49, Reinier Torenbeek wrote: >> Hi, >> For anyone interested in leveraging Windows CNG with OpenSSL 1.1.1, you may want to check out this new OpenSSL CNG Engine project on GitHub: https://github.com/rticommunity/openssl-cng-engine . The associated User's Manual is on ReadTheDocs: https://openssl-cng-engine.readthedocs.io/en/latest/index.html . >> The project implements the majority of the EVP interface, to leverage the BCrypt crypto implementations, as well as a subset of the STORE interface, for integration with the Windows Certificate and Keystore(s), via the NCrypt and Cert APIs. It has been tested with 1.1.1k on Windows 10, with Visual Studio 2017 and 2019. It is released under the Apache-2.0 license. >> Any feedback is welcome, please send it to me or open an issue on GitHub. >> Best regards, >> Reinier From dev at ddvo.net Fri Jul 2 05:57:24 2021 From: dev at ddvo.net (David von Oheimb) Date: Fri, 2 Jul 2021 07:57:24 +0200 Subject: [EXTERNAL] Re: GNU Make erroring on makefile In-Reply-To: <1eb5797b70464409bbac853690a4523a@statefarm.com> References: <9b2db2eb94f64a5a8f1258f1792c142a@statefarm.com> <87tulep3oo.wl-levitte@openssl.org> <25d2ddf580954554b348f1d6a193ccb5@statefarm.com> <1eb5797b70464409bbac853690a4523a@statefarm.com> Message-ID: On Thu, 01 Jul 2021 15:22:46 +0200, Joe Carroll wrote: > I'm getting a "missing separator" error on line 56. Would be good to add a note to the top of both Makefile and makefile for which flavor of make they are intended, and maybe we can add some check to them that gives a more to-the-point hint if an unsuitable one is used. > I do not have access to nmake.exe. Everyone who uses a VC-* configuration should have access to cl.exe and nmake.exe. ??? David On 01.07.21 16:55, Joe Carroll wrote: > Thanks Matt. That clears it up. > > > > -----Original Message----- > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matt Caswell > Sent: Thursday, July 1, 2021 9:40 AM > To: openssl-users at openssl.org > Subject: Re: [EXTERNAL] Re: GNU Make erroring on makefile > > > On 01/07/2021 15:06, Joe Carroll wrote: >> Windows 10 >> perl Configure VC-WIN64A > The VC-WIN64A target generates a Makefile suitable for consumption by > nmake. Hence its not possible to use GNU make with it. > > [...] > > > Matt > > > > >> -----Original Message----- >> From: Richard Levitte [mailto:levitte at openssl.org] >> Sent: Thursday, July 1, 2021 8:25 AM >> To: Joe Carroll >> Cc: openssl-users at openssl.org >> Subject: [EXTERNAL] Re: GNU Make erroring on makefile >> >> How did you configure, and on what platform? >> >> On Thu, 01 Jul 2021 15:22:46 +0200, >> Joe Carroll wrote: >>> Has anyone successfully used GNU Make as part of the install process for version 1.1.1k or later? >>> I'm getting a "missing separator" error on line 56. I do not have access to nmake.exe. >>> >>> !IF "$(DESTDIR)" != "" >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Jul 2 07:21:35 2021 From: matt at openssl.org (Matt Caswell) Date: Fri, 2 Jul 2021 08:21:35 +0100 Subject: CNG engine on GitHub In-Reply-To: References: Message-ID: On 02/07/2021 04:25, Reinier Torenbeek wrote: > Hi Matt, > > I am aware of the deprecation of the engine interface with 3.0 but have not looked into the details of support providers yet. I expect converting an engine to a support provider could be done with quite a bit of code reuse, correct? Would you say the interface and design of support providers is stable at this point? The engine and provider interfaces are quite different - but since the underlying operations are the same I imagine there will be quite a bit of reuse. Yes, we consider the provider interface to be stable now. Matt > > Thanks, > Reinier > >> On Jul 1, 2021, at 4:41 PM, Matt Caswell wrote: >> >> ?Nice! Are there any thoughts to support providers? The engine interface is deprecated in 3.0. >> >> Matt >> >> >>> On 01/07/2021 18:49, Reinier Torenbeek wrote: >>> Hi, >>> For anyone interested in leveraging Windows CNG with OpenSSL 1.1.1, you may want to check out this new OpenSSL CNG Engine project on GitHub: https://github.com/rticommunity/openssl-cng-engine . The associated User's Manual is on ReadTheDocs: https://openssl-cng-engine.readthedocs.io/en/latest/index.html . >>> The project implements the majority of the EVP interface, to leverage the BCrypt crypto implementations, as well as a subset of the STORE interface, for integration with the Windows Certificate and Keystore(s), via the NCrypt and Cert APIs. It has been tested with 1.1.1k on Windows 10, with Visual Studio 2017 and 2019. It is released under the Apache-2.0 license. >>> Any feedback is welcome, please send it to me or open an issue on GitHub. >>> Best regards, >>> Reinier > From xiaonan830818 at gmail.com Fri Jul 2 09:09:20 2021 From: xiaonan830818 at gmail.com (Nan Xiao) Date: Fri, 2 Jul 2021 17:09:20 +0800 Subject: How to simulate "TLS 1.3 Session Resumption" through OpenSSL tools? Message-ID: Hi OpenSSL users, Greetings from me! From this article (https://www.qacafe.com/resources/examples-of-tls-1-3/) and pcap file (https://www.cloudshark.org/captures/64d433b1585a), I know we can use s_server and s_client to simulate "TLS 1.3 Session Resumption". I tried following command: echo | openssl s_client -tls1_3 -connect tls13.cloudflare.com:443 -reconnect But it seems not to work since there is no "pre_shared_key" extension, and every time s_client just initiated a new connection instead of resumption. Could anybody advise how to simulate "TLS 1.3 Session Resumption" through OpenSSL tools? Thanks very much in advance! Best Regards Nan Xiao From matt at openssl.org Fri Jul 2 09:45:59 2021 From: matt at openssl.org (Matt Caswell) Date: Fri, 2 Jul 2021 10:45:59 +0100 Subject: How to simulate "TLS 1.3 Session Resumption" through OpenSSL tools? In-Reply-To: References: Message-ID: <31ce8d9c-c670-2bb4-7bdc-641cbcaf4654@openssl.org> On 02/07/2021 10:09, Nan Xiao wrote: > Hi OpenSSL users, > > Greetings from me! From this article > (https://www.qacafe.com/resources/examples-of-tls-1-3/) and pcap file > (https://www.cloudshark.org/captures/64d433b1585a), I know we can use > s_server and s_client to simulate "TLS 1.3 Session Resumption". I > tried following command: > > echo | openssl s_client -tls1_3 -connect tls13.cloudflare.com:443 -reconnect > That looks like you've stumbled across an s_client bug. This should work, but it doesn't appear to. I just raised an issue for it: https://github.com/openssl/openssl/issues/15979 > But it seems not to work since there is no "pre_shared_key" extension, > and every time s_client just initiated a new connection instead of > resumption. > > Could anybody advise how to simulate "TLS 1.3 Session Resumption" > through OpenSSL tools? Thanks very much in advance! You can do this another way. Create an initial connection (add "-connect" option as appropriate): openssl s_client -tls1_3 -sess_out sess.pem And then resume like this: openssl s_client -tls1_3 -sess_in sess.pem However, note that with TLSv1.3 the session data doesn't arrive until post-handshake. In the case of the cloudflare server it doesn't send any session tickets until it has received some application data from the client. So in order to get a valid resumable session you will have to type some HTTP command into s_client once it has created its initial connection. This should cause the cloudflare server to respond with a session ticket, which will get saved to the sess.pem file. You can then use that in the subsequent resumption attempt. Matt From dev at ddvo.net Fri Jul 2 09:56:05 2021 From: dev at ddvo.net (David von Oheimb) Date: Fri, 2 Jul 2021 11:56:05 +0200 Subject: OpenSSL CNG engine on GitHub In-Reply-To: References: Message-ID: <40c4f8f4-e0fc-8a5a-37d1-5799dc053f54@ddvo.net> Hello Reinier, around five years back I was looking for such an implementation as an alternative to the rather limited CAPI engine, mostly because the C(rypto )API does not support ECC. The only thing I found at that time was https://mta.openssl.org/pipermail/openssl-dev/2016-June/007362.html and I do not know how it evolved since them. So I am very pleased to see that meanwhile there is a way of using core features of Windows CAPI Next Generation (CNG) from OpenSSL. Many thanks to RTI for providing this as open-source development under the Apache license. I currently do not have the time for a closer look or even trying it out, but this looks very good and well documented. In particular, https://openssl-cng-engine.readthedocs.io/en/latest/using/openssl_commands.html gives a nice example how to use the Windows cert & key store. Porting this to the new OpenSSL crypto provider interface will likely lift the limitation regarding RSA-PSS support, which lacks just due to the engine interface. Cheers, ??? David On 01.07.21 19:49, Reinier Torenbeek wrote: > Hi, > > For anyone interested in leveraging Windows CNG with OpenSSL 1.1.1, > you may want to check out this new OpenSSL CNG Engine project on > GitHub: https://github.com/rticommunity/openssl-cng-engine . The > associated User's Manual is on > ReadTheDocs:?https://openssl-cng-engine.readthedocs.io/en/latest/index.html > . > > The project implements the majority of the EVP interface, to leverage > the BCrypt crypto implementations, as well as a subset of the STORE > interface, for integration with the Windows?Certificate and > Keystore(s), via the NCrypt and Cert APIs. It has been tested with > 1.1.1k on Windows 10, with Visual Studio 2017 and 2019. It is released > under the Apache-2.0 license. > > Any feedback is welcome, please send it to me or open an issue on GitHub. > > Best regards, > Reinier -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Jul 2 11:02:48 2021 From: matt at openssl.org (Matt Caswell) Date: Fri, 2 Jul 2021 12:02:48 +0100 Subject: Need help in removing secp521r1 from openssl-1.1.1g and adding TLS_GREASE_BA cipher. In-Reply-To: References: Message-ID: On 01/07/2021 07:21, vinod mg wrote: > 1) Supress?or a way to remove?secp521r1 from the currenlty installed > openssl. You can specify the list of groups by calling SSL_CTX_set1_groups_list (or SSL_set1_groups_list) from your application. See: https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set1_groups_list.html > 2) Add the cipher - "0xbaba ? TLS_GREASE_BA ? GREASE" like we see in > chrome. This is not a real cipher. It does nothing and is always ignored. OpenSSL does not support sending this value. Matt > > I am ok with custom install as well, if above cannot be done with > already installed openssl package. Please share any wiki I can > follow to impliment?the same. > > ~]# openssl ecparam -list_curves > > secp224r1 : NIST/SECG curve over a 224 bit prime field > > secp256k1 : SECG curve over a 256 bit prime field > > secp384r1 : NIST/SECG curve over a 384 bit prime field > > /secp521r1 : NIST/SECG curve over a 521 bit prime field/ > > prime256v1: X9.62/SECG curve over a 256 bit prime field > > > I am using below OS and version- > > # cat /etc/redhat-release > > Red Hat Enterprise Linux release 8.3 (Ootpa) > > > # opensslversion -a > > OpenSSL 1.1.1g FIPS21 Apr 2020 > > built on: Thu Mar 25 16:46:53 2021 UTC > > platform: linux-x86_64 > > options:bn(64,64) md2(char) rc4(16x,int) des(int) idea(int) > blowfish(ptr) > > compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -O2 -g > -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 > -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong > -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic > -fasynchronous-unwind-tables -fstack-clash-protection > -fcf-protection -Wa,--noexecstack > -Wa,--generate-missing-build-notes=yes > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -DOPENSSL_USE_NODELETE > -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM > -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM > -DX25519_ASM -DPOLY1305_ASM -DZLIB -DNDEBUG -DPURIFY > -DDEVRANDOM="\"/dev/urandom\"" > -DSYSTEM_CIPHERS_FILE="/etc/crypto-policies/back-ends/openssl.config" > > OPENSSLDIR: "/etc/pki/tls" > > ENGINESDIR: "/usr/lib64/engines-1.1" > > Seeding source: os-specific > > engines:rdrand dynamic > > > Really appriciate your time and help, thanks in advance. > > Thanks, > Vinod > From levitte at openssl.org Fri Jul 2 12:03:31 2021 From: levitte at openssl.org (Richard Levitte) Date: Fri, 02 Jul 2021 14:03:31 +0200 Subject: CNG engine on GitHub In-Reply-To: References: Message-ID: <87pmw0q5ws.wl-levitte@openssl.org> This is cool! I had some kind of skeleton of a start to make something similar, but time was never on my side. I'm really glad to see this got picked up! This also answered a question I never got the answer for, what scheme to use for the STORE. I know next to nothing about PowerShell, so hadn't discovered the 'cert:' "scheme". That answers quite a lot :-) Time for me to throw away my skeleton then ;-) Cheers, Richard On Thu, 01 Jul 2021 19:49:00 +0200, Reinier Torenbeek wrote: > > Hi, > > For anyone interested in leveraging Windows CNG with OpenSSL 1.1.1, you may want to check out this > new OpenSSL CNG Engine project on GitHub: https://github.com/rticommunity/openssl-cng-engine . The > associated User's Manual is on ReadTheDocs:? > https://openssl-cng-engine.readthedocs.io/en/latest/index.html . > > The project implements the majority of the EVP interface, to leverage the BCrypt crypto > implementations, as well as a subset of the STORE interface, for integration with the > Windows?Certificate and Keystore(s), via the NCrypt and Cert APIs. It has been tested with 1.1.1k > on Windows 10, with Visual Studio 2017 and 2019. It is released under the Apache-2.0 license. > > Any feedback is welcome, please send it to me or open an issue on GitHub. > > Best regards, > Reinier > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From reinier.torenbeek at gmail.com Fri Jul 2 12:54:46 2021 From: reinier.torenbeek at gmail.com (Reinier Torenbeek) Date: Fri, 2 Jul 2021 09:54:46 -0300 Subject: CNG engine on GitHub In-Reply-To: References: Message-ID: Thanks Matt. >From your response, it seems that this would be a good moment to start looking into the provider interface. I will check it out (and may get back with questions after that...) Reinier On Fri, Jul 2, 2021 at 4:21 AM Matt Caswell wrote: > > > On 02/07/2021 04:25, Reinier Torenbeek wrote: > > Hi Matt, > > > > I am aware of the deprecation of the engine interface with 3.0 but have > not looked into the details of support providers yet. I expect converting > an engine to a support provider could be done with quite a bit of code > reuse, correct? Would you say the interface and design of support providers > is stable at this point? > > The engine and provider interfaces are quite different - but since the > underlying operations are the same I imagine there will be quite a bit > of reuse. > > Yes, we consider the provider interface to be stable now. > > Matt > > > > > > Thanks, > > Reinier > > > >> On Jul 1, 2021, at 4:41 PM, Matt Caswell wrote: > >> > >> ?Nice! Are there any thoughts to support providers? The engine > interface is deprecated in 3.0. > >> > >> Matt > >> > >> > >>> On 01/07/2021 18:49, Reinier Torenbeek wrote: > >>> Hi, > >>> For anyone interested in leveraging Windows CNG with OpenSSL 1.1.1, > you may want to check out this new OpenSSL CNG Engine project on GitHub: > https://github.com/rticommunity/openssl-cng-engine < > https://github.com/rticommunity/openssl-cng-engine> . The associated > User's Manual is on ReadTheDocs: > https://openssl-cng-engine.readthedocs.io/en/latest/index.html < > https://openssl-cng-engine.readthedocs.io/en/latest/index.html> . > >>> The project implements the majority of the EVP interface, to leverage > the BCrypt crypto implementations, as well as a subset of the STORE > interface, for integration with the Windows Certificate and Keystore(s), > via the NCrypt and Cert APIs. It has been tested with 1.1.1k on Windows 10, > with Visual Studio 2017 and 2019. It is released under the Apache-2.0 > license. > >>> Any feedback is welcome, please send it to me or open an issue on > GitHub. > >>> Best regards, > >>> Reinier > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From reinier.torenbeek at gmail.com Fri Jul 2 12:59:30 2021 From: reinier.torenbeek at gmail.com (Reinier Torenbeek) Date: Fri, 2 Jul 2021 09:59:30 -0300 Subject: OpenSSL CNG engine on GitHub In-Reply-To: <40c4f8f4-e0fc-8a5a-37d1-5799dc053f54@ddvo.net> References: <40c4f8f4-e0fc-8a5a-37d1-5799dc053f54@ddvo.net> Message-ID: Hello David, Thanks for checking this out and your positive feedback. I was not able to find any substantial solution for this either. I do wonder why that is? Possibly, Windows users are not as interested in a cross platform solution like OpenSSL provides and they are fine with using the Windows APIs directly -- that is just speculation though. Best regards, Reinier On Fri, Jul 2, 2021 at 6:56 AM David von Oheimb wrote: > Hello Reinier, > > around five years back I was looking for such an implementation as an > alternative to the rather limited CAPI engine, mostly because the C(rypto > )API does not support ECC. > The only thing I found at that time was > https://mta.openssl.org/pipermail/openssl-dev/2016-June/007362.html and I > do not know how it evolved since them. > So I am very pleased to see that meanwhile there is a way of using core > features of Windows CAPI Next Generation (CNG) from OpenSSL. > > Many thanks to RTI for providing this as open-source development under the > Apache license. > I currently do not have the time for a closer look or even trying it out, > but this looks very good and well documented. > In particular, > https://openssl-cng-engine.readthedocs.io/en/latest/using/openssl_commands.html > gives a nice example how to use the Windows cert & key store. > Porting this to the new OpenSSL crypto provider interface will likely lift > the limitation regarding RSA-PSS support, which lacks just due to the > engine interface. > > Cheers, > > David > > > On 01.07.21 19:49, Reinier Torenbeek wrote: > > Hi, > > For anyone interested in leveraging Windows CNG with OpenSSL 1.1.1, you > may want to check out this new OpenSSL CNG Engine project on GitHub: > https://github.com/rticommunity/openssl-cng-engine . The associated > User's Manual is on ReadTheDocs: > https://openssl-cng-engine.readthedocs.io/en/latest/index.html . > > The project implements the majority of the EVP interface, to leverage the > BCrypt crypto implementations, as well as a subset of the STORE interface, > for integration with the Windows Certificate and Keystore(s), via the > NCrypt and Cert APIs. It has been tested with 1.1.1k on Windows 10, with > Visual Studio 2017 and 2019. It is released under the Apache-2.0 license. > > Any feedback is welcome, please send it to me or open an issue on GitHub. > > Best regards, > Reinier > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinod9987 at gmail.com Fri Jul 2 13:02:44 2021 From: vinod9987 at gmail.com (vinod mg) Date: Fri, 2 Jul 2021 18:32:44 +0530 Subject: Need help in removing secp521r1 from openssl-1.1.1g and adding TLS_GREASE_BA cipher. In-Reply-To: References: Message-ID: Hi Matt, Thanks for response. > 1) Supress or a way to remove secp521r1 from the currenlty installed > openssl. You can specify the list of groups by calling SSL_CTX_set1_groups_list (or SSL_set1_groups_list) from your application. See: https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set1_groups_list.html --> Is there a way I can compile openssl itself to exclude 'secp521r1' and install? The reason I ask is because application I am testing is squid( squid-cache.org) for ssl bumping purposes and it has limited configurability . Thanks, Vinod On Fri, Jul 2, 2021 at 4:32 PM Matt Caswell wrote: > > > On 01/07/2021 07:21, vinod mg wrote: > > 1) Supress or a way to remove secp521r1 from the currenlty installed > > openssl. > > You can specify the list of groups by calling SSL_CTX_set1_groups_list > (or SSL_set1_groups_list) from your application. See: > > https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set1_groups_list.html > > > 2) Add the cipher - "0xbaba TLS_GREASE_BA GREASE" like we see in > > chrome. > > This is not a real cipher. It does nothing and is always ignored. > OpenSSL does not support sending this value. > > Matt > > > > > > I am ok with custom install as well, if above cannot be done with > > already installed openssl package. Please share any wiki I can > > follow to impliment the same. > > > > ~]# openssl ecparam -list_curves > > > > secp224r1 : NIST/SECG curve over a 224 bit prime field > > > > secp256k1 : SECG curve over a 256 bit prime field > > > > secp384r1 : NIST/SECG curve over a 384 bit prime field > > > > /secp521r1 : NIST/SECG curve over a 521 bit prime field/ > > > > prime256v1: X9.62/SECG curve over a 256 bit prime field > > > > > > I am using below OS and version- > > > > # cat /etc/redhat-release > > > > Red Hat Enterprise Linux release 8.3 (Ootpa) > > > > > > # opensslversion -a > > > > OpenSSL 1.1.1g FIPS21 Apr 2020 > > > > built on: Thu Mar 25 16:46:53 2021 UTC > > > > platform: linux-x86_64 > > > > options:bn(64,64) md2(char) rc4(16x,int) des(int) idea(int) > > blowfish(ptr) > > > > compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -O2 -g > > -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 > > -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong > > -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic > > -fasynchronous-unwind-tables -fstack-clash-protection > > -fcf-protection -Wa,--noexecstack > > -Wa,--generate-missing-build-notes=yes > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -DOPENSSL_USE_NODELETE > > -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 > > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m > > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM > > -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM > > -DX25519_ASM -DPOLY1305_ASM -DZLIB -DNDEBUG -DPURIFY > > -DDEVRANDOM="\"/dev/urandom\"" > > -DSYSTEM_CIPHERS_FILE="/etc/crypto-policies/back-ends/openssl.config" > > > > OPENSSLDIR: "/etc/pki/tls" > > > > ENGINESDIR: "/usr/lib64/engines-1.1" > > > > Seeding source: os-specific > > > > engines:rdrand dynamic > > > > > > Really appriciate your time and help, thanks in advance. > > > > Thanks, > > Vinod > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From selva.nair at gmail.com Fri Jul 2 13:48:21 2021 From: selva.nair at gmail.com (Selva Nair) Date: Fri, 2 Jul 2021 09:48:21 -0400 Subject: CNG engine on GitHub In-Reply-To: References: Message-ID: Hi, On Thu, Jul 1, 2021 at 1:49 PM Reinier Torenbeek < reinier.torenbeek at gmail.com> wrote: > Hi, > > For anyone interested in leveraging Windows CNG with OpenSSL 1.1.1, you > may want to check out this new OpenSSL CNG Engine project on GitHub: > https://github.com/rticommunity/openssl-cng-engine . The associated > User's Manual is on ReadTheDocs: > https://openssl-cng-engine.readthedocs.io/en/latest/index.html . > > The project implements the majority of the EVP interface, to leverage the > BCrypt crypto implementations, as well as a subset of the STORE interface, > for integration with the Windows Certificate and Keystore(s), via the > NCrypt and Cert APIs. It has been tested with 1.1.1k on Windows 10, with > Visual Studio 2017 and 2019. It is released under the Apache-2.0 license. > > Any feedback is welcome, please send it to me or open an issue on GitHub. > This is great, but limiting RSA signature to RSA-PKCS#1 v 1.5 is a major limitation. It doesn't have to be that way as the OpenSSL engine interface does allow using EVP_PKEY_METHOD callbacks instead of rsa_priv_dec etc. Selva > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doctor at doctor.nl2k.ab.ca Fri Jul 2 13:53:01 2021 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Fri, 2 Jul 2021 07:53:01 -0600 Subject: OPenssl 3 Beta 1 Message-ID: So far working better with openssh 8.6 . Ruby 2.7 and rust is of concern. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b Muscle, brain, will... all must be exercised if they will be strong. -unknown Beware https://mindspring.com From reinier.torenbeek at gmail.com Fri Jul 2 14:11:01 2021 From: reinier.torenbeek at gmail.com (Reinier Torenbeek) Date: Fri, 2 Jul 2021 11:11:01 -0300 Subject: CNG engine on GitHub In-Reply-To: <87pmw0q5ws.wl-levitte@openssl.org> References: <87pmw0q5ws.wl-levitte@openssl.org> Message-ID: Hi Richard, Glad you like it. The cert: scheme is a little inconvenient and I do not know how extensively it is used in practice. But it seemed appropriate to leverage it since it was around already and seemed to fit the bill. Microsoft's documentation is not too extensive, but for anybody interested, here is a starting point: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.security/about/about_certificate_provider?view=powershell-7.1 Best regards, Reinier On Fri, Jul 2, 2021 at 9:03 AM Richard Levitte wrote: > This is cool! > > I had some kind of skeleton of a start to make something similar, but > time was never on my side. I'm really glad to see this got picked up! > > This also answered a question I never got the answer for, what scheme > to use for the STORE. I know next to nothing about PowerShell, so > hadn't discovered the 'cert:' "scheme". That answers quite a lot :-) > > Time for me to throw away my skeleton then ;-) > > Cheers, > Richard > > On Thu, 01 Jul 2021 19:49:00 +0200, > Reinier Torenbeek wrote: > > > > Hi, > > > > For anyone interested in leveraging Windows CNG with OpenSSL 1.1.1, you > may want to check out this > > new OpenSSL CNG Engine project on GitHub: > https://github.com/rticommunity/openssl-cng-engine . The > > associated User's Manual is on ReadTheDocs: > > https://openssl-cng-engine.readthedocs.io/en/latest/index.html . > > > > The project implements the majority of the EVP interface, to leverage > the BCrypt crypto > > implementations, as well as a subset of the STORE interface, for > integration with the > > Windows Certificate and Keystore(s), via the NCrypt and Cert APIs. It > has been tested with 1.1.1k > > on Windows 10, with Visual Studio 2017 and 2019. It is released under > the Apache-2.0 license. > > > > Any feedback is welcome, please send it to me or open an issue on GitHub. > > > > Best regards, > > Reinier > > > > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas at openssl.org Fri Jul 2 14:12:29 2021 From: tomas at openssl.org (Tomas Mraz) Date: Fri, 02 Jul 2021 16:12:29 +0200 Subject: OPenssl 3 Beta 1 In-Reply-To: References: Message-ID: <10d233d99f865404e156c5e5dc5515e96aae601d.camel@openssl.org> On Fri, 2021-07-02 at 07:53 -0600, The Doctor wrote: > So far working better with openssh 8.6 . > > Ruby 2.7 and rust is of concern. Language bindings are expected to require some minor changes to be able to properly work with OpenSSL 3.0. Hopefully the maintainers of these language bindings follow the alpha/beta releases and are working on fixes. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From doctor at doctor.nl2k.ab.ca Fri Jul 2 14:33:00 2021 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Fri, 2 Jul 2021 08:33:00 -0600 Subject: OPenssl 3 Beta 1 In-Reply-To: <10d233d99f865404e156c5e5dc5515e96aae601d.camel@openssl.org> References: <10d233d99f865404e156c5e5dc5515e96aae601d.camel@openssl.org> Message-ID: On Fri, Jul 02, 2021 at 04:12:29PM +0200, Tomas Mraz wrote: > On Fri, 2021-07-02 at 07:53 -0600, The Doctor wrote: > > So far working better with openssh 8.6 . > > > > Ruby 2.7 and rust is of concern. > > Language bindings are expected to require some minor changes to be able > to properly work with OpenSSL 3.0. Hopefully the maintainers of these > language bindings follow the alpha/beta releases and are working on > fixes. > Hopefully they are doing it now! > -- > Tom???? Mr??z > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > [You'll know whether the road is wrong if you carefully listen to your > conscience.] > > -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b Muscle, brain, will... all must be exercised if they will be strong. -unknown Beware https://mindspring.com From matt at openssl.org Fri Jul 2 14:53:39 2021 From: matt at openssl.org (Matt Caswell) Date: Fri, 2 Jul 2021 15:53:39 +0100 Subject: Need help in removing secp521r1 from openssl-1.1.1g and adding TLS_GREASE_BA cipher. In-Reply-To: References: Message-ID: On 02/07/2021 14:02, vinod mg wrote: > --> Is there a way I can compile openssl itself to exclude 'secp521r1' > and install? The reason I ask is because application I am testing is > squid(squid-cache.org ) for ssl bumping purposes > and it has limited configurability. Only by disabling *all* ec groups (via the "no-ec" configure option) but that is no solution at all really. I would not recommend that! You might try starting squid with the OPENSSL_CONF environment variable pointing to a custom OpenSSL config file. Assuming squid doesn't suppress loading the config file then you can do the same thing as SSL_CTX_set1_groups_list via the "Groups" SSL_CONF setting. See the info here on configuring OpenSSL SSL/TLS settings via config file (see the section "SSL Configuration Module"): https://www.openssl.org/docs/man1.1.1/man5/config.html And see the documentation on "Groups" on this page: https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html Matt > > Thanks, > Vinod > > > On Fri, Jul 2, 2021 at 4:32 PM Matt Caswell > wrote: > > > > On 01/07/2021 07:21, vinod mg wrote: > >? ? ?1) Supress?or a way to remove?secp521r1 from the currenlty > installed > >? ? ?openssl. > > You can specify the list of groups by calling SSL_CTX_set1_groups_list > (or SSL_set1_groups_list) from your application. See: > > https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set1_groups_list.html > > > >? ? ?2) Add the cipher - "0xbaba ? TLS_GREASE_BA ? GREASE" like we > see in > >? ? ?chrome. > > This is not a real cipher. It does nothing and is always ignored. > OpenSSL does not support sending this value. > > Matt > > > > > >? ? ?I am ok with custom install as well, if above cannot be done with > >? ? ?already installed openssl package. Please share any wiki I can > >? ? ?follow to impliment?the same. > > > >? ? ?~]# openssl ecparam -list_curves > > > >? ? ?secp224r1 : NIST/SECG curve over a 224 bit prime field > > > >? ? ?secp256k1 : SECG curve over a 256 bit prime field > > > >? ? ?secp384r1 : NIST/SECG curve over a 384 bit prime field > > > >? ? ?/secp521r1 : NIST/SECG curve over a 521 bit prime field/ > > > >? ? ?prime256v1: X9.62/SECG curve over a 256 bit prime field > > > > > >? ? ?I am using below OS and version- > > > >? ? ?# cat /etc/redhat-release > > > >? ? ?Red Hat Enterprise Linux release 8.3 (Ootpa) > > > > > >? ? ?# opensslversion -a > > > >? ? ?OpenSSL 1.1.1g FIPS21 Apr 2020 > > > >? ? ?built on: Thu Mar 25 16:46:53 2021 UTC > > > >? ? ?platform: linux-x86_64 > > > >? ? ?options:bn(64,64) md2(char) rc4(16x,int) des(int) idea(int) > >? ? ?blowfish(ptr) > > > >? ? ?compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 > -O2 -g > >? ? ?-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 > >? ? ?-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong > >? ? ?-grecord-gcc-switches > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > >? ? ?-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic > >? ? ?-fasynchronous-unwind-tables -fstack-clash-protection > >? ? ?-fcf-protection -Wa,--noexecstack > >? ? ?-Wa,--generate-missing-build-notes=yes > >? ? ?-specs=/usr/lib/rpm/redhat/redhat-hardened-ld > -DOPENSSL_USE_NODELETE > >? ? ?-DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 > >? ? ?-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 > -DOPENSSL_BN_ASM_GF2m > >? ? ?-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM > >? ? ?-DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM > >? ? ?-DX25519_ASM -DPOLY1305_ASM -DZLIB -DNDEBUG -DPURIFY > >? ? ?-DDEVRANDOM="\"/dev/urandom\"" > > > ?-DSYSTEM_CIPHERS_FILE="/etc/crypto-policies/back-ends/openssl.config" > > > >? ? ?OPENSSLDIR: "/etc/pki/tls" > > > >? ? ?ENGINESDIR: "/usr/lib64/engines-1.1" > > > >? ? ?Seeding source: os-specific > > > >? ? ?engines:rdrand dynamic > > > > > >? ? ?Really appriciate your time and help, thanks in advance. > > > >? ? ?Thanks, > >? ? ?Vinod > > > From reinier.torenbeek at gmail.com Fri Jul 2 15:18:05 2021 From: reinier.torenbeek at gmail.com (Reinier Torenbeek) Date: Fri, 2 Jul 2021 12:18:05 -0300 Subject: CNG engine on GitHub In-Reply-To: References: Message-ID: Hi Selva, On Fri, Jul 2, 2021 at 10:49 AM Selva Nair wrote: > Hi, > > On Thu, Jul 1, 2021 at 1:49 PM Reinier Torenbeek < > reinier.torenbeek at gmail.com> wrote: > >> Hi, >> >> For anyone interested in leveraging Windows CNG with OpenSSL 1.1.1, you >> may want to check out this new OpenSSL CNG Engine project on GitHub: >> https://github.com/rticommunity/openssl-cng-engine . The associated >> User's Manual is on ReadTheDocs: >> https://openssl-cng-engine.readthedocs.io/en/latest/index.html . >> >> The project implements the majority of the EVP interface, to leverage the >> BCrypt crypto implementations, as well as a subset of the STORE interface, >> for integration with the Windows Certificate and Keystore(s), via the >> NCrypt and Cert APIs. It has been tested with 1.1.1k on Windows 10, with >> Visual Studio 2017 and 2019. It is released under the Apache-2.0 license. >> >> Any feedback is welcome, please send it to me or open an issue on GitHub. >> > > This is great, but limiting RSA signature to RSA-PKCS#1 v 1.5 is a major > limitation. It doesn't have to be that way as the OpenSSL engine interface > does allow using EVP_PKEY_METHOD callbacks instead of rsa_priv_dec etc. > Yes I agree the lack of support for RSA-PSS is significant. There is a discussion (which includes you, I see ) around the root cause of that here: https://github.com/openssl/openssl/issues/7341 , among other places. It is not clear to me what you mean with "the OpenSSL engine interface does allow using EVP_PKEY_METHOD callbacks instead of rsa_priv_dec etc.". Can you elaborate (here or on the GitHub issue)? Thanks, Reinier > Selva > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Jul 2 15:33:50 2021 From: matt at openssl.org (Matt Caswell) Date: Fri, 2 Jul 2021 16:33:50 +0100 Subject: CNG engine on GitHub In-Reply-To: References: Message-ID: <9388a230-829a-5045-e1df-12d51843aa57@openssl.org> On 02/07/2021 16:18, Reinier Torenbeek wrote: > It is not clear to me what you mean with "the OpenSSL engine interface > does allow using EVP_PKEY_METHOD callbacks instead of rsa_priv_dec > etc.". Can you elaborate (here or on the GitHub issue)? You can hook the RSA calls at different abstraction levels. You can provide a custom RSA_METHOD in an enigne, which means calls to the various RSA_*() functions go via the custom RSA_METHOD. However these RSA_*() functions are considered the "low level" functions, and it is preferred that applications use the "high level" EVP API instead (in fact the "low level" functions are all deprecated in 3.0). RSA PSS padding is *only* available via the EVP API. Algorithm specific EVP functionality is implemented via an EVP_PKEY_METHOD. The built-in RSA EVP_PKEY_METHOD mostly just calls the low level RSA_*() functions in the right places. However it implements PSS padding directly. Since padding has already been added via the RSA_PKEY_METHOD, when it actually calls the lower level RSA_*() functions it does so with RSA_NO_PADDING. So this means that the RSA_METHOD has no opportunity to influence the PSS padding. However, an alternative is to implement a custom EVP_PKEY_METHOD. By doing this you get the opportunity to hook the PSS padding. Not sure I explained that too well. I hope it makes sense. Matt From matt at openssl.org Fri Jul 2 15:35:07 2021 From: matt at openssl.org (Matt Caswell) Date: Fri, 2 Jul 2021 16:35:07 +0100 Subject: CNG engine on GitHub In-Reply-To: <9388a230-829a-5045-e1df-12d51843aa57@openssl.org> References: <9388a230-829a-5045-e1df-12d51843aa57@openssl.org> Message-ID: On 02/07/2021 16:33, Matt Caswell wrote: > via the RSA_PKEY_METHOD I meant RSA EVP_PKEY_METHOD. Matt From selva.nair at gmail.com Fri Jul 2 16:34:19 2021 From: selva.nair at gmail.com (Selva Nair) Date: Fri, 2 Jul 2021 12:34:19 -0400 Subject: CNG engine on GitHub In-Reply-To: References: Message-ID: Hi > >> >> This is great, but limiting RSA signature to RSA-PKCS#1 v 1.5 is a major >> limitation. It doesn't have to be that way as the OpenSSL engine interface >> does allow using EVP_PKEY_METHOD callbacks instead of rsa_priv_dec etc. >> > > Yes I agree the lack of support for RSA-PSS is significant. There is a > discussion (which includes you, I see ) around the root cause of that here: > https://github.com/openssl/openssl/issues/7341 , among other places. > That discussion is valid only if you insist on using "legacy" rsa_sign or other rsa_priv_dec which have no mechanism for providing context info like padding and hash type. > It is not clear to me what you mean with "the OpenSSL engine interface > does allow using EVP_PKEY_METHOD callbacks instead of rsa_priv_dec etc.". > Can you elaborate (here or on the GitHub issue)? > To add to what Matt wrote: As an example, see my PR for pkcs11-helper: https://github.com/OpenSC/pkcs11-helper/pull/31 This uses a dummy engine and passes the singing operation to the pkcs11 device, but the idea is the same. Selva > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaonan830818 at gmail.com Sun Jul 4 11:01:25 2021 From: xiaonan830818 at gmail.com (Nan Xiao) Date: Sun, 4 Jul 2021 19:01:25 +0800 Subject: How to simulate "TLS 1.3 Session Resumption" through OpenSSL tools? In-Reply-To: <31ce8d9c-c670-2bb4-7bdc-641cbcaf4654@openssl.org> References: <31ce8d9c-c670-2bb4-7bdc-641cbcaf4654@openssl.org> Message-ID: Hi Matt, Got it! Thanks very much for your reply! Best Regards Nan Xiao On Fri, Jul 2, 2021 at 5:46 PM Matt Caswell wrote: > > > > On 02/07/2021 10:09, Nan Xiao wrote: > > Hi OpenSSL users, > > > > Greetings from me! From this article > > (https://www.qacafe.com/resources/examples-of-tls-1-3/) and pcap file > > (https://www.cloudshark.org/captures/64d433b1585a), I know we can use > > s_server and s_client to simulate "TLS 1.3 Session Resumption". I > > tried following command: > > > > echo | openssl s_client -tls1_3 -connect tls13.cloudflare.com:443 -reconnect > > > > That looks like you've stumbled across an s_client bug. This should > work, but it doesn't appear to. I just raised an issue for it: > > https://github.com/openssl/openssl/issues/15979 > > > > > But it seems not to work since there is no "pre_shared_key" extension, > > and every time s_client just initiated a new connection instead of > > resumption. > > > > Could anybody advise how to simulate "TLS 1.3 Session Resumption" > > through OpenSSL tools? Thanks very much in advance! > > You can do this another way. Create an initial connection (add > "-connect" option as appropriate): > > openssl s_client -tls1_3 -sess_out sess.pem > > And then resume like this: > > openssl s_client -tls1_3 -sess_in sess.pem > > However, note that with TLSv1.3 the session data doesn't arrive until > post-handshake. In the case of the cloudflare server it doesn't send any > session tickets until it has received some application data from the > client. So in order to get a valid resumable session you will have to > type some HTTP command into s_client once it has created its initial > connection. This should cause the cloudflare server to respond with a > session ticket, which will get saved to the sess.pem file. You can then > use that in the subsequent resumption attempt. > > Matt > From markhack at markhack.com Wed Jul 7 07:01:16 2021 From: markhack at markhack.com (Mark Hack) Date: Wed, 07 Jul 2021 02:01:16 -0500 Subject: Need help in removing secp521r1 from openssl-1.1.1g and adding TLS_GREASE_BA cipher. In-Reply-To: References: Message-ID: <9014bea2ca0dd94891b82d36c16c9f366f9b9b82.camel@markhack.com> The docs are not the easiest to follow so here is what I did to order curves from strongest to weakest.The file is /etc/pki/tls/openssl.conf and should be close to your settings. Set the curves to what you want as I did in the Curve line openssl_conf = default_modules [ default_modules ] ssl_conf = ssl_module [ ssl_module ] system_default = crypto_policy [ crypto_policy ] Curves = P-521:P-384:P-256 On Fri, 2021-07-02 at 15:53 +0100, Matt Caswell wrote: > > On 02/07/2021 14:02, vinod mg wrote: > > --> Is there a way I can compile openssl itself to exclude > > 'secp521r1' > > and install? The reason I ask is because application I am testing > > is > > squid(squid-cache.org ) for ssl bumping > > purposes > > and it has limited configurability. > > Only by disabling *all* ec groups (via the "no-ec" configure option) > but > that is no solution at all really. I would not recommend that! > > You might try starting squid with the OPENSSL_CONF environment > variable > pointing to a custom OpenSSL config file. Assuming squid doesn't > suppress loading the config file then you can do the same thing as > SSL_CTX_set1_groups_list via the "Groups" SSL_CONF setting. See the > info > here on configuring OpenSSL SSL/TLS settings via config file (see > the > section "SSL Configuration Module"): > > https://www.openssl.org/docs/man1.1.1/man5/config.html > > And see the documentation on "Groups" on this page: > > https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html > > Matt > > > > > Thanks, > > Vinod > > > > > > On Fri, Jul 2, 2021 at 4:32 PM Matt Caswell > > wrote: > > > > > > > > On 01/07/2021 07:21, vinod mg wrote: > > > 1) Supress or a way to remove secp521r1 from the > > currenlty > > installed > > > openssl. > > > > You can specify the list of groups by calling > > SSL_CTX_set1_groups_list > > (or SSL_set1_groups_list) from your application. See: > > > > > > https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set1_groups_list.html > > < > > https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set1_groups_list.html > > > > > > > > 2) Add the cipher - "0xbaba TLS_GREASE_BA GREASE" > > like we > > see in > > > chrome. > > > > This is not a real cipher. It does nothing and is always > > ignored. > > OpenSSL does not support sending this value. > > > > Matt > > > > > > > > > > I am ok with custom install as well, if above cannot be > > done with > > > already installed openssl package. Please share any wiki > > I can > > > follow to impliment the same. > > > > > > ~]# openssl ecparam -list_curves > > > > > > secp224r1 : NIST/SECG curve over a 224 bit prime field > > > > > > secp256k1 : SECG curve over a 256 bit prime field > > > > > > secp384r1 : NIST/SECG curve over a 384 bit prime field > > > > > > /secp521r1 : NIST/SECG curve over a 521 bit prime field/ > > > > > > prime256v1: X9.62/SECG curve over a 256 bit prime field > > > > > > > > > I am using below OS and version- > > > > > > # cat /etc/redhat-release > > > > > > Red Hat Enterprise Linux release 8.3 (Ootpa) > > > > > > > > > # opensslversion -a > > > > > > OpenSSL 1.1.1g FIPS21 Apr 2020 > > > > > > built on: Thu Mar 25 16:46:53 2021 UTC > > > > > > platform: linux-x86_64 > > > > > > options:bn(64,64) md2(char) rc4(16x,int) des(int) > > idea(int) > > > blowfish(ptr) > > > > > > compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack > > -Wall -O3 > > -O2 -g > > > -pipe -Wall -Werror=format-security -Wp,- > > D_FORTIFY_SOURCE=2 > > > -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack- > > protector-strong > > > -grecord-gcc-switches > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > > > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 > > -mtune=generic > > > -fasynchronous-unwind-tables -fstack-clash-protection > > > -fcf-protection -Wa,--noexecstack > > > -Wa,--generate-missing-build-notes=yes > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld > > -DOPENSSL_USE_NODELETE > > > -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ > > -DOPENSSL_IA32_SSE2 > > > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 > > -DOPENSSL_BN_ASM_GF2m > > > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM > > -DRC4_ASM > > > -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM > > -DECP_NISTZ256_ASM > > > -DX25519_ASM -DPOLY1305_ASM -DZLIB -DNDEBUG -DPURIFY > > > -DDEVRANDOM="\"/dev/urandom\"" > > > > > -DSYSTEM_CIPHERS_FILE="/etc/crypto-policies/back- > > ends/openssl.config" > > > > > > OPENSSLDIR: "/etc/pki/tls" > > > > > > ENGINESDIR: "/usr/lib64/engines-1.1" > > > > > > Seeding source: os-specific > > > > > > engines:rdrand dynamic > > > > > > > > > Really appriciate your time and help, thanks in advance. > > > > > > Thanks, > > > Vinod > > > > > From tshort at akamai.com Wed Jul 7 18:23:00 2021 From: tshort at akamai.com (Short, Todd) Date: Wed, 7 Jul 2021 18:23:00 +0000 Subject: Time for OpenSSL 1.1.1l? Message-ID: The cadence of 1.1.1 release is supposed to be quarterly (I seem to recall reading that somewhere, but I can't find it)? It has been almost 4 months since 1.1.1k (25-March-2021) was released. Are there any plans for 1.1.1l (ell)? -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet." -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From reinier.torenbeek at gmail.com Thu Jul 8 02:18:05 2021 From: reinier.torenbeek at gmail.com (Reinier Torenbeek) Date: Wed, 7 Jul 2021 23:18:05 -0300 Subject: CNG engine on GitHub In-Reply-To: References: Message-ID: Hello Selva and Matt, Thanks for the pointers. Following the suggested approach, I have added (in a branch of a fork) initial support of RSA-PSS for the BCrypt engine and the few first tests look promising. Next, I will do the same thing for NCrypt. After that I will probably add support for OAEP as well. Best regards, Reinier On Fri, Jul 2, 2021 at 1:35 PM Selva Nair wrote: > Hi > >> >>> >>> This is great, but limiting RSA signature to RSA-PKCS#1 v 1.5 is a >>> major limitation. It doesn't have to be that way as the OpenSSL engine >>> interface does allow using EVP_PKEY_METHOD callbacks instead of >>> rsa_priv_dec etc. >>> >> >> Yes I agree the lack of support for RSA-PSS is significant. There is a >> discussion (which includes you, I see ) around the root cause of that here: >> https://github.com/openssl/openssl/issues/7341 , among other places. >> > > That discussion is valid only if you insist on using "legacy" rsa_sign or > other rsa_priv_dec which have no mechanism for providing context info like > padding and hash type. > > >> It is not clear to me what you mean with "the OpenSSL engine interface >> does allow using EVP_PKEY_METHOD callbacks instead of rsa_priv_dec etc.". >> Can you elaborate (here or on the GitHub issue)? >> > > To add to what Matt wrote: > > As an example, see my PR for pkcs11-helper: > https://github.com/OpenSC/pkcs11-helper/pull/31 This uses a dummy engine > and passes the singing operation to the pkcs11 device, but the idea is the > same. > > Selva > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.gotthard at advantech.cz Thu Jul 8 11:17:57 2021 From: petr.gotthard at advantech.cz (Petr Gotthard) Date: Thu, 8 Jul 2021 11:17:57 +0000 Subject: CMP mock server OldCertID check behavior Message-ID: Hello, I am trying to renew a certificate via CMP and authenticate the request using the same cert. I start the mock server: openssl cmp -port 8080 -srv_trusted test-ca-cert.pem \ -srv_key test-server-key.pem -srv_cert test-server-cert.pem \ -rsp_cert test-client-cert2.pem -rsp_capubs test-ca-cert.pem & And run the client: openssl cmp -cmd kur -server localhost:8080/pkix/ -srvcert test-server-cert.pem \ -key test-client-key.pem -cert test-my-cert.pem \ -newkey test-client-key2.pem -certout test-my-cert2.pem However, the CMP server(?) compares the serial number of the old client certificate with the serial of the new (enrolled) certificate and fails. (I can make the enrollment succeed if I force the old and the new certificate to have the same serial.) CMP error: received error:PKIStatus: rejection; PKIFailureInfo: badRequest; StatusString: "wrong certid"; errorCode: 1D0000BD; errorDetails: CMP routines, wrong certid What am I doing wrong, please? It is quite obvious the new certificate will have a different certid, isn't it? Kind Regards, Petr -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.j.culhane at gmail.com Thu Jul 8 16:55:42 2021 From: tim.j.culhane at gmail.com (Tim Culhane) Date: Thu, 8 Jul 2021 17:55:42 +0100 Subject: installing OpenSSL 1.1.1 on RedHat 6.x Message-ID: <001f01d7741a$18ff5f80$4afe1e80$@gmail.com> Hi, We have a customer who is running our product on a RedHat 6.x server. Our product uses OpenSSL 1.1.1 to handle secure connections. Initial testing by the customer is showing segmentation faults in OpenSSL during the handshake process. We have successfully tested our product on CentOS 7.x servers. I know that RedHat certainly doesn't ship recent versions of OpenSSL for RedHat 6.x. However it is still possible to install later OpenSSL versions to run side-by-side the system installation. What I'm wondering is, would there be a technical reason why OpenSSL 1.1.1 would not work correctly on a RedHat 6.x system? For the record the customer has tried with OpenSSL 1.1.1g and 1.1.1k with similar results. Many thanks, Tim From thomas_floodeenjr at mentor.com Thu Jul 8 17:02:03 2021 From: thomas_floodeenjr at mentor.com (Floodeenjr, Thomas) Date: Thu, 8 Jul 2021 17:02:03 +0000 Subject: installing OpenSSL 1.1.1 on RedHat 6.x In-Reply-To: <001f01d7741a$18ff5f80$4afe1e80$@gmail.com> References: <001f01d7741a$18ff5f80$4afe1e80$@gmail.com> Message-ID: Is the OpenSSL version being used built on the platform that it is run on? You cannot use a version compiled on a newer platform in an older environment. -Tom -----Original Message----- From: openssl-users On Behalf Of Tim Culhane Sent: Thursday, July 8, 2021 10:56 AM To: openssl-users at openssl.org Subject: installing OpenSSL 1.1.1 on RedHat 6.x Hi, We have a customer who is running our product on a RedHat 6.x server. Our product uses OpenSSL 1.1.1 to handle secure connections. Initial testing by the customer is showing segmentation faults in OpenSSL during the handshake process. We have successfully tested our product on CentOS 7.x servers. I know that RedHat certainly doesn't ship recent versions of OpenSSL for RedHat 6.x. However it is still possible to install later OpenSSL versions to run side-by-side the system installation. What I'm wondering is, would there be a technical reason why OpenSSL 1.1.1 would not work correctly on a RedHat 6.x system? For the record the customer has tried with OpenSSL 1.1.1g and 1.1.1k with similar results. Many thanks, Tim From openssl-users at dukhovni.org Thu Jul 8 19:48:55 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 8 Jul 2021 15:48:55 -0400 Subject: installing OpenSSL 1.1.1 on RedHat 6.x In-Reply-To: <001f01d7741a$18ff5f80$4afe1e80$@gmail.com> References: <001f01d7741a$18ff5f80$4afe1e80$@gmail.com> Message-ID: On Thu, Jul 08, 2021 at 05:55:42PM +0100, Tim Culhane wrote: > We have a customer who is running our product on a RedHat 6.x server. > Our product uses OpenSSL 1.1.1 to handle secure connections. > > Initial testing by the customer is showing segmentation faults in OpenSSL > during the handshake process. You can build and bundle your own OpenSSL library (libssl and libcrypto), that is dynamically linked, has a custom "SONAME", and custom symbol version names. Such a dynamically linked SSL library can coexist in the same address space with another (e.g. platform-vendor provided) OpenSSL version, provided both use symbol versioning. > I know that RedHat certainly doesn't ship recent versions of OpenSSL for > RedHat 6.x. However it is still possible to install later OpenSSL versions > to run side-by-side the system installation. > > What I'm wondering is, would there be a technical reason why OpenSSL 1.1.1 > would not work correctly on a RedHat 6.x system? There are two potential problems: - Symbol name/version collisions. - Passing of incompatible SSL contexts/handles created in one library to an API linked with another incompatible library. The second issue is quite rare, but though the first is common, it can avoided by building the custom non-platform OpenSSL libraries with care. Look for "shlib_variant" in the Configuration profiles for OpenSSL 1.1.1x. -- Viktor. From tim.j.culhane at gmail.com Thu Jul 8 20:55:38 2021 From: tim.j.culhane at gmail.com (Tim Culhane) Date: Thu, 8 Jul 2021 21:55:38 +0100 Subject: installing OpenSSL 1.1.1 on RedHat 6.x In-Reply-To: References: <001f01d7741a$18ff5f80$4afe1e80$@gmail.com> Message-ID: <002801d7743b$9bb4f860$d31ee920$@gmail.com> Hi Tom, So from what you say, you can run an OpenSSL built on RedHat 6.6 on a RedHat 6.6 server. But you cannot run that build on RedHat 6.5? Thanks, Tim -----Original Message----- From: Floodeenjr, Thomas Sent: Thursday 8 July 2021 18:02 To: Tim Culhane ; openssl-users at openssl.org Subject: RE: installing OpenSSL 1.1.1 on RedHat 6.x Is the OpenSSL version being used built on the platform that it is run on? You cannot use a version compiled on a newer platform in an older environment. -Tom -----Original Message----- From: openssl-users On Behalf Of Tim Culhane Sent: Thursday, July 8, 2021 10:56 AM To: openssl-users at openssl.org Subject: installing OpenSSL 1.1.1 on RedHat 6.x Hi, We have a customer who is running our product on a RedHat 6.x server. Our product uses OpenSSL 1.1.1 to handle secure connections. Initial testing by the customer is showing segmentation faults in OpenSSL during the handshake process. We have successfully tested our product on CentOS 7.x servers. I know that RedHat certainly doesn't ship recent versions of OpenSSL for RedHat 6.x. However it is still possible to install later OpenSSL versions to run side-by-side the system installation. What I'm wondering is, would there be a technical reason why OpenSSL 1.1.1 would not work correctly on a RedHat 6.x system? For the record the customer has tried with OpenSSL 1.1.1g and 1.1.1k with similar results. Many thanks, Tim From thomas_floodeenjr at mentor.com Thu Jul 8 20:58:01 2021 From: thomas_floodeenjr at mentor.com (Floodeenjr, Thomas) Date: Thu, 8 Jul 2021 20:58:01 +0000 Subject: installing OpenSSL 1.1.1 on RedHat 6.x In-Reply-To: <002801d7743b$9bb4f860$d31ee920$@gmail.com> References: <001f01d7741a$18ff5f80$4afe1e80$@gmail.com> <002801d7743b$9bb4f860$d31ee920$@gmail.com> Message-ID: Tim, 6.6 - 6.5 may likely work. 7.x - 6.x will probably not work. -Tom -----Original Message----- From: Tim Culhane Sent: Thursday, July 8, 2021 2:56 PM To: Floodeenjr, Thomas ; openssl-users at openssl.org Subject: RE: installing OpenSSL 1.1.1 on RedHat 6.x Hi Tom, So from what you say, you can run an OpenSSL built on RedHat 6.6 on a RedHat 6.6 server. But you cannot run that build on RedHat 6.5? Thanks, Tim -----Original Message----- From: Floodeenjr, Thomas Sent: Thursday 8 July 2021 18:02 To: Tim Culhane ; openssl-users at openssl.org Subject: RE: installing OpenSSL 1.1.1 on RedHat 6.x Is the OpenSSL version being used built on the platform that it is run on? You cannot use a version compiled on a newer platform in an older environment. -Tom -----Original Message----- From: openssl-users On Behalf Of Tim Culhane Sent: Thursday, July 8, 2021 10:56 AM To: openssl-users at openssl.org Subject: installing OpenSSL 1.1.1 on RedHat 6.x Hi, We have a customer who is running our product on a RedHat 6.x server. Our product uses OpenSSL 1.1.1 to handle secure connections. Initial testing by the customer is showing segmentation faults in OpenSSL during the handshake process. We have successfully tested our product on CentOS 7.x servers. I know that RedHat certainly doesn't ship recent versions of OpenSSL for RedHat 6.x. However it is still possible to install later OpenSSL versions to run side-by-side the system installation. What I'm wondering is, would there be a technical reason why OpenSSL 1.1.1 would not work correctly on a RedHat 6.x system? For the record the customer has tried with OpenSSL 1.1.1g and 1.1.1k with similar results. Many thanks, Tim From tim.j.culhane at gmail.com Thu Jul 8 20:58:15 2021 From: tim.j.culhane at gmail.com (Tim Culhane) Date: Thu, 8 Jul 2021 21:58:15 +0100 Subject: installing OpenSSL 1.1.1 on RedHat 6.x In-Reply-To: References: <001f01d7741a$18ff5f80$4afe1e80$@gmail.com> Message-ID: <002901d7743b$f8d72220$ea856660$@gmail.com> Hi Victor, We used to ship OpenSSL with our product but decided to decouple OpenSSL so that customers had the flexibility to run with whatever versionof OpenSSL and could upgrade OpenSSL when they needed to rather than waiting for an update from us containing a new OpenSSL implementation. Tim -----Original Message----- From: openssl-users On Behalf Of Viktor Dukhovni Sent: Thursday 8 July 2021 20:49 To: openssl-users at openssl.org Subject: Re: installing OpenSSL 1.1.1 on RedHat 6.x On Thu, Jul 08, 2021 at 05:55:42PM +0100, Tim Culhane wrote: > We have a customer who is running our product on a RedHat 6.x server. > Our product uses OpenSSL 1.1.1 to handle secure connections. > > Initial testing by the customer is showing segmentation faults in > OpenSSL during the handshake process. You can build and bundle your own OpenSSL library (libssl and libcrypto), that is dynamically linked, has a custom "SONAME", and custom symbol version names. Such a dynamically linked SSL library can coexist in the same address space with another (e.g. platform-vendor provided) OpenSSL version, provided both use symbol versioning. > I know that RedHat certainly doesn't ship recent versions of OpenSSL > for RedHat 6.x. However it is still possible to install later OpenSSL > versions to run side-by-side the system installation. > > What I'm wondering is, would there be a technical reason why OpenSSL > 1.1.1 would not work correctly on a RedHat 6.x system? There are two potential problems: - Symbol name/version collisions. - Passing of incompatible SSL contexts/handles created in one library to an API linked with another incompatible library. The second issue is quite rare, but though the first is common, it can avoided by building the custom non-platform OpenSSL libraries with care. Look for "shlib_variant" in the Configuration profiles for OpenSSL 1.1.1x. -- Viktor. From openssl-users at dukhovni.org Thu Jul 8 21:03:39 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 8 Jul 2021 17:03:39 -0400 Subject: installing OpenSSL 1.1.1 on RedHat 6.x In-Reply-To: <002901d7743b$f8d72220$ea856660$@gmail.com> References: <001f01d7741a$18ff5f80$4afe1e80$@gmail.com> <002901d7743b$f8d72220$ea856660$@gmail.com> Message-ID: On Thu, Jul 08, 2021 at 09:58:15PM +0100, Tim Culhane wrote: > We used to ship OpenSSL with our product but decided to decouple OpenSSL so > that customers had the flexibility to run with whatever versionof OpenSSL > and could upgrade OpenSSL when they needed to rather than waiting for an > update from us containing a new OpenSSL implementation. That makes sense for customers on non-LTS (a.k.a. obsolete) platforms, but if a customer is sticking with an ~10 year platform that you're forced to support, then for *that* platform it may make sense to bundle a version of OpenSSL that has the requisite modern features. This can be done, and the OpenSSL build contains the necessary hooks to do this (sorry I never wrote a detailed tutorial on how to do that, I hope, if motivated, it should be possible to figure it out). Of course the custom OpenSSL build would have to be built for the platform in question (e.g. built on a sufficiently old RedHat 6.x system). -- VIktor. From tim.j.culhane at gmail.com Thu Jul 8 21:39:19 2021 From: tim.j.culhane at gmail.com (Tim Culhane) Date: Thu, 8 Jul 2021 22:39:19 +0100 Subject: installing OpenSSL 1.1.1 on RedHat 6.x In-Reply-To: References: <001f01d7741a$18ff5f80$4afe1e80$@gmail.com> <002901d7743b$f8d72220$ea856660$@gmail.com> Message-ID: <002b01d77441$b5b20cc0$21162640$@gmail.com> Well the product in question is pretty legacy so I don't think we will be investing time on that sort of implementation. I understand the customer can use a build of OpenSSL 1.1.1 built for RedHat 6.6 and that should work. Its possible they have used an installation built on a newer RedHat version. I need to find that out first. Tim -----Original Message----- From: openssl-users On Behalf Of Viktor Dukhovni Sent: Thursday 8 July 2021 22:04 To: openssl-users at openssl.org Subject: Re: installing OpenSSL 1.1.1 on RedHat 6.x On Thu, Jul 08, 2021 at 09:58:15PM +0100, Tim Culhane wrote: > We used to ship OpenSSL with our product but decided to decouple > OpenSSL so that customers had the flexibility to run with whatever > versionof OpenSSL and could upgrade OpenSSL when they needed to rather > than waiting for an update from us containing a new OpenSSL implementation. That makes sense for customers on non-LTS (a.k.a. obsolete) platforms, but if a customer is sticking with an ~10 year platform that you're forced to support, then for *that* platform it may make sense to bundle a version of OpenSSL that has the requisite modern features. This can be done, and the OpenSSL build contains the necessary hooks to do this (sorry I never wrote a detailed tutorial on how to do that, I hope, if motivated, it should be possible to figure it out). Of course the custom OpenSSL build would have to be built for the platform in question (e.g. built on a sufficiently old RedHat 6.x system). -- VIktor. From ylelkin1 at gmail.com Fri Jul 9 06:32:31 2021 From: ylelkin1 at gmail.com (Yaroslav Lelkin) Date: Fri, 9 Jul 2021 11:32:31 +0500 Subject: s_server: unexpected behavior when using "-brief" option Message-ID: Hello all. I'm trying to launch s_client and s_server like this: $ openssl s_server -cert test.crt -key test.key -tls1_3 $ openssl s_client -CAfile test.crt -connect localhost:4433 After typing Q in s_server's terminal, it finishes its execution so everything is OK. However, with "-brief" option set, i.e. $ openssl s_server -brief -cert test.crt -key test.key -tls1_3 it doesn't react to this command at all. From what I see this behavior is controlled by "if" condition at "apps/s_server.c:2541". s_server's manpage doesn't mention that "-brief" controls how user input is processed. So, can someone clarify, is this a bug, or missing documentation, or just my misunderstanding? -------------- next part -------------- An HTML attachment was scrubbed... URL: From janjust at nikhef.nl Fri Jul 9 07:27:12 2021 From: janjust at nikhef.nl (Jan Just Keijser) Date: Fri, 9 Jul 2021 09:27:12 +0200 Subject: installing OpenSSL 1.1.1 on RedHat 6.x In-Reply-To: <001f01d7741a$18ff5f80$4afe1e80$@gmail.com> References: <001f01d7741a$18ff5f80$4afe1e80$@gmail.com> Message-ID: <8893416e-dba7-9fe4-8c82-8131b126e612@nikhef.nl> On 08/07/21 18:55, Tim Culhane wrote: > Hi, > > We have a customer who is running our product on a RedHat 6.x server. > Our product uses OpenSSL 1.1.1 to handle secure connections. > > Initial testing by the customer is showing segmentation faults in OpenSSL > during the handshake process. > > We have successfully tested our product on CentOS 7.x servers. > > I know that RedHat certainly doesn't ship recent versions of OpenSSL for > RedHat 6.x. However it is still possible to install later OpenSSL versions > to run side-by-side the system installation. > > What I'm wondering is, would there be a technical reason why OpenSSL 1.1.1 > would not work correctly on a RedHat 6.x system? > > For the record the customer has tried with OpenSSL 1.1.1g and 1.1.1k with > similar results. Note that RH 6 is out of support and it will be hard to find support for it anywhere. It uses openssl 1.0.1e by default which is *not* API compatible with 1.1.1k; please ensure that the RH openssl header files and development libraries are NOT installed when compiling your application against 1.1.1k (try removing the RPM openssl-devel). I compiled and used OpenSSL up to version 1.1.1d on RH 6 without any issues; I just revived an old VM and built openssl 1.1.1k on it without problems. However, the command ? make test failed as I am missing certain dependencies. Without knowing how you build your appilcation it is impossible to tell where and how it is failing. A long shot, but one thing to try is to install a newer gcc compiler; you can find one in the "sclo" repositories, e.g ? https://vault.centos.org/6.10/sclo/x86_64/rh/Packages/d/ and install 'devtoolset-9' to get gcc 9 on RH 6. Perhaps a rebuild using a new compiler fixes the segfaults you are seeing.? Most likely, however, you are mixing headers files from different versions of OpenSSL. HTH, JJK From hkario at redhat.com Fri Jul 9 11:29:46 2021 From: hkario at redhat.com (Hubert Kario) Date: Fri, 09 Jul 2021 13:29:46 +0200 Subject: installing OpenSSL 1.1.1 on RedHat 6.x In-Reply-To: <8893416e-dba7-9fe4-8c82-8131b126e612@nikhef.nl> References: <001f01d7741a$18ff5f80$4afe1e80$@gmail.com> <8893416e-dba7-9fe4-8c82-8131b126e612@nikhef.nl> Message-ID: <206ab394-a416-4392-ac72-f6cc22b682b9@redhat.com> On Friday, 9 July 2021 09:27:12 CEST, Jan Just Keijser wrote: > On 08/07/21 18:55, Tim Culhane wrote: >> Hi, >> >> We have a customer who is running our product on a RedHat 6.x server. >> Our product uses OpenSSL 1.1.1 to handle secure connections. >> >> Initial testing by the customer is showing segmentation faults in OpenSSL >> during the handshake process. ... > > Note that RH 6 is out of support and it will be hard to find > support for it anywhere. There still is support for Red Hat Enterprise Linux 6. It's provided as part of the Extended Life-cycle Support, available till 30th of June 2024: https://access.redhat.com/support/policy/updates/errata and OpenSSL is part of the ELS Inclusion List: https://access.redhat.com/articles/4997301 -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic From matt at openssl.org Mon Jul 12 08:36:55 2021 From: matt at openssl.org (Matt Caswell) Date: Mon, 12 Jul 2021 09:36:55 +0100 Subject: Time for OpenSSL 1.1.1l? In-Reply-To: References: Message-ID: <0c82ee1e-5804-2dbe-a5e1-48cbdfabc3aa@openssl.org> Good question! I'll raise this at OTC tomorrow. Matt On 07/07/2021 19:23, Short, Todd via openssl-users wrote: > The cadence of 1.1.1 release is supposed to be quarterly (I seem to > recall reading that somewhere, but I can't find it)? > > It has been almost 4 months since 1.1.1k (25-March-2021) was released. > > Are there any plans for 1.1.1l (ell)? > > -- > -Todd Short > // tshort at akamai.com > // ?One if by land, two if by sea, three if by?the Internet." > From dev at ddvo.net Mon Jul 12 15:39:18 2021 From: dev at ddvo.net (David von Oheimb) Date: Mon, 12 Jul 2021 17:39:18 +0200 Subject: CMP mock server OldCertID check behavior In-Reply-To: References: Message-ID: <4b4e9a70-a914-f055-df25-b21158398ab2@ddvo.net> Hello Petr, thank you for your message and filing the related issue at https://github.com/openssl/openssl/issues/16041. I very much appreciate such feedback on the new CMP implementation and its tests. You are right that the behavior of the mock server appears pretty strange regarding the checks on the |oldCertID| in |kur| messages. This is because for the HTTP-based OpenSSL-internal CMP test cases the mock server deals, as you noticed, with just a single certificate. For this reason, the short-circuit comparison given in |cmp_mock_srv.c| is sufficient but at least would have deserved an explaining comment and documentation. In order to make the mock server more generally useful, I've extended it in https://github.com/openssl/openssl/pull/16050 by giving the option -ref_cert to specify an independent reference certificate to be used for the checks done for |kur| and |rr| messages. Kind regards, ??? David On 08.07.21 13:17, Petr Gotthard wrote: > > Hello, > > ? > > I am trying to renew a certificate via CMP and authenticate the > request using the same cert. > > ? > > I start the mock server: > > openssl cmp -port 8080 -srv_trusted test-ca-cert.pem \ > > ??????????? -srv_key test-server-key.pem -srv_cert test-server-cert.pem \ > > ??????????? -rsp_cert test-client-cert2.pem -rsp_capubs test-ca-cert.pem & > > ? > > And run the client: > > openssl cmp -cmd kur -server localhost:8080/pkix/ -srvcert > test-server-cert.pem \ > > ??????????? -key test-client-key.pem -cert test-my-cert.pem \ > > ??????????? -newkey test-client-key2.pem -certout test-my-cert2.pem > > ? > > However, the CMP server(?) compares the serial number of the old > client certificate with the serial of the new (enrolled) certificate > and fails. (I can make the enrollment succeed if I force the old and > the new certificate to have the same serial.) > > ? > > CMP error: received error:PKIStatus: rejection; PKIFailureInfo: > badRequest; StatusString: "wrong certid"; errorCode: 1D0000BD; > errorDetails: CMP routines, wrong certid > > ? > > What am I doing wrong, please? It is quite obvious the new certificate > will have a different certid, isn?t it? > > ? > > ? > > Kind Regards, > > Petr > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dev at ddvo.net Mon Jul 12 19:53:42 2021 From: dev at ddvo.net (David von Oheimb) Date: Mon, 12 Jul 2021 21:53:42 +0200 Subject: [openssl CMP with pkcs11 engine] In-Reply-To: <24f54f69-276f-2727-94b9-3d9304df8571@csgroup.eu> References: <24f54f69-276f-2727-94b9-3d9304df8571@csgroup.eu> Message-ID: Hi Marc, I just came across your below message of March, which arrived in a bit weird form (I removed duplicate text sections in the below quote) and appears unanswered - sorry for that. It has been a while since I last used engines, but the following variant ?? -newkey org.openssl.engine:pkcs11: should work, rather than ????? -engine pkcs11 -keyform engine because the latter pertains to all key options used, including -key, which is not what you want. HTH, ??? David On 25.03.21 18:56, mbalembo wrote: > > Hello all, > > > I'm trying to do a CMP request using openssl with a private key inside > a pkcs11 device (on linux). > So i'm using opsenssl 3.0.0 alpha 13. > > I did compile fine (./config --prefix=/opt/openssl enable-deprecated > --openssldir=/usr/local/ssl -Wl,-rpath=/opt/openssl/lib), > but i ran into trouble when compiling libp11 to get my pkcs11 engine. > (i had a similar issue while trying to use tpm2-tss-engine) > I can't find a way to build openssl with ERR_put_error() symbol. > I know it's deprecated so i changed the code in libp11 to use > ERR_raise() instead, but again the symbol is also missing. > I ended up removing the function call in the engine as a dirty fix, > but i'd like to have a better solution. > > > So, with everything compiled, I tried to use the engine only and > create a CSR first. > > # /opt/openssl/bin/openssl req -new -engine pkcs11 -keyform engine > -key > "pkcs11:model=SLB9670;manufacturer=Infineon;serial=0000000000000000;token=tpm2-token;id=%c1%b2%36%b2%eb%53%f0%4f%ea%24%1a%4d%01%ac%d1%9e%fe%11%19%6d;object=test;type=private;pin-value=000000" > -subj "" -out testpkcs11.csr > > > and, everything works so far ! > > but i get errors when trying to do a CMP request with the engine, > thing is, i'm not so sure of the command. > > # /opt/openssl/bin/openssl cmp -cmd ir -engine pkcs11 -server server>:8080 -path ejbca/publicweb/cmp/WKS-RA-Bootstrap_auth -cert > -key file: -keypass > file: -keyform engine -newkey > "pkcs11:model=SLB9670;manufacturer=Infineon;serial=0000000000000000;token=tpm2-token;id=%c1%b2%36%b2%eb%53%f0%4f%ea%24%1a%4d%01%ac%d1%9e%fe%11%19%6d;object=test;type=private;pin-value=000000" > -subject '' -certout testcmppkcs11.pem -trusted <> my > root CA> -reqexts san -config /opt/conf/openssl_reqext.cnf > > > i get the following error : > > cmp_main:apps/cmp.c:2728:CMP info: using section(s) 'cmp' of > OpenSSL configuration file '/opt/conf/openssl_reqext.cnf' > cmp_main:apps/cmp.c:2737:CMP info: no [cmp] section found in > config file '/opt/conf/openssl_reqext.cnf'; will thus use just > [default] and unnamed section if > present???????????????????????????????????????????? > ???????????????????????????????????????????????? > Engine "pkcs11" > set.???????????????????????????????????????????????????????????????????????????????????????????????????????????????? > Format not > recognized!?????????????????????????????????????????????????? > ???????????????????????????????????????????????????????????? > The key ID is not a valid PKCS#11 > URI??????????????????????????????????????????????????????????????????????????????????????????????? > The PKCS#11 URI format is defined by RFC7512???????????????? > ?????????????????????????????????????????????????????????????????????? > > The legacy ENGINE_pkcs11 ID format is also still accepted for > now????????????????????????????????????????????????????????????????? > Format not recognized!???????????????????????? > ?????????????????????????????????????????????????????????????????????????????????? > > The key ID is not a valid PKCS#11 > URI????????????????????????????????????????????????????????????????????????????????? > > The PKCS#11 URI format is defined by > RFC7512??????????????????????????????????????????????????????????????????????????? > > The legacy ENGINE_pkcs11 ID format is also still accepted for > now??????????????????????????????????????????? > PKCS11_get_private_key returned > NULL???????????????????????????????????????????????????????????????????????????????????????????????? > Could not read private key for CMP client certificate from > org.openssl.engine:pkcs11:file:/foo/usine.boot.key.pem??? > 00E01783A47F0000:error:13000080:engine > routines:ENGINE_load_private_key:failed loading private > key:crypto/engine/eng_pkey.c:78:????? > cmp_main:apps/cmp.c:2879:CMP error: cannot set up CMP context? > > > I'm quite confuse about the PKCS11 error since i know from the req > command that openssl rsa show that the passphrase for the CMP client > certificate is good. > my URI is good and openssl rsa show that the passphrase for the CMP > client certificate is good. > > I've tried various modification of the command, mostly removing the > "keyform engine" and using just 'newkey "pkcs11:(...)" ' with no succes. > > Maybe openssl is mixing engine format for everything and not just for > the newkey ? > > > Thanks, > Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgoldman at us.ibm.com Tue Jul 13 18:02:22 2021 From: kgoldman at us.ibm.com (Ken Goldman) Date: Tue, 13 Jul 2021 14:02:22 -0400 Subject: EVP_MAC_init - specify the hash algorithm Message-ID: Porting to 3.0 ... HMAC_Init_ex() had a place for the hash algorithm. EVP_MAC_init() does not, unless it's embedded in the 'params' parameter. Any advice? Or a sample for doing an HMAC with 3.0? From schmidt at digadd.de Tue Jul 13 18:44:11 2021 From: schmidt at digadd.de (Christian Schmidt) Date: Tue, 13 Jul 2021 20:44:11 +0200 Subject: SSL_connect with TLS 1.3 and client Certificates Message-ID: Hello all, I am currently trying to build both client and server of an application that uses TLS 1.3 and mutual authentication using certificates. The application works so far - I can establish connections, certificates are verified, data is successfully transmitted, etc. However, I have an issue, or maybe two. 1. SSL_connect returns successfully before the client certificate is sent from the client to the server. The client certificate is only sent on the first SSL_write_ex with > 0 bytes, and as such, at this point the server can generate SSL alerts like access denied, etc. 2. When trying to benchmark latency on the application, the first roundtrip is extended by the client certificate verification. Is there any way I can complete the handshake, and thus validate the full connection, without sending data? I must say that even after reading RFC8446 I am not sure if there is a positive confirmation after the client certificate is sent, so I am not sure if what I am asking for is even possible. Best regards, Chris From matt at openssl.org Tue Jul 13 18:50:41 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 13 Jul 2021 19:50:41 +0100 Subject: EVP_MAC_init - specify the hash algorithm In-Reply-To: References: Message-ID: On 13/07/2021 19:02, Ken Goldman wrote: > Porting to 3.0 ... HMAC_Init_ex() had a place for > the hash algorithm.? EVP_MAC_init() does not, > unless it's embedded in the 'params' parameter. > > Any advice?? Or a sample for doing an > HMAC with 3.0? > If its just a straight forward HMAC you want you can do it very simply with the one-shot EVP_Q_mac function: unsigned char *EVP_Q_mac(OSSL_LIB_CTX *libctx, const char *name, const char *propq, const char *subalg, const OSSL_PARAM *params, const void *key, size_t keylen, const unsigned char *data, size_t datalen, unsigned char *out, size_t outsize, size_t *outlen); Supply "HMAC" for the name param and "SHA256" (or whatever) for the subalg. Matt From kgoldman at us.ibm.com Tue Jul 13 20:44:07 2021 From: kgoldman at us.ibm.com (Ken Goldman) Date: Tue, 13 Jul 2021 16:44:07 -0400 Subject: EVP_MAC_init - specify the hash algorithm In-Reply-To: References: Message-ID: On 7/13/2021 2:50 PM, Matt Caswell wrote: > > > On 13/07/2021 19:02, Ken Goldman wrote: >> Porting to 3.0 ... HMAC_Init_ex() had a place for >> the hash algorithm.? EVP_MAC_init() does not, >> unless it's embedded in the 'params' parameter. >> >> Any advice?? Or a sample for doing an >> HMAC with 3.0? >> > > If its just a straight forward HMAC you want you can do it very simply with the one-shot EVP_Q_mac function: > > unsigned char *EVP_Q_mac(OSSL_LIB_CTX *libctx, const char *name, const char *propq, > ???????????????????????? const char *subalg, const OSSL_PARAM *params, > ???????????????????????? const void *key, size_t keylen, > ???????????????????????? const unsigned char *data, size_t datalen, > ???????????????????????? unsigned char *out, size_t outsize, size_t *outlen); > > Supply "HMAC" for the name param and "SHA256" (or whatever) for the subalg. It's not. It's the usual init/update/final pattern. From kgoldman at us.ibm.com Tue Jul 13 21:03:48 2021 From: kgoldman at us.ibm.com (Ken Goldman) Date: Tue, 13 Jul 2021 17:03:48 -0400 Subject: RSA_set0_key() equivalent for 3.0.0 Message-ID: What is the 3.0.0 equivalent to RSA_set0_key() when I want to create a key token from n and e. Meta question: Is there a porting guide for these type of questions - something that says, "If you used this before, use this now." From nic.tuv at gmail.com Tue Jul 13 21:08:09 2021 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Wed, 14 Jul 2021 00:08:09 +0300 Subject: RSA_set0_key() equivalent for 3.0.0 In-Reply-To: References: Message-ID: There is the migration guide: https://github.com/openssl/openssl/tree/master/doc/man7/migration_guide.pod Best regards, Nicola On Wed, Jul 14, 2021, 00:04 Ken Goldman wrote: > What is the 3.0.0 equivalent to RSA_set0_key() when I > want to create a key token from n and e. > > Meta question: Is there a porting guide for these > type of questions - something that says, "If you > used this before, use this now." > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sahana at redhat.com Tue Jul 13 21:08:24 2021 From: sahana at redhat.com (Sahana Prasad) Date: Tue, 13 Jul 2021 23:08:24 +0200 Subject: RSA_set0_key() equivalent for 3.0.0 In-Reply-To: References: Message-ID: On Tue, Jul 13, 2021 at 11:04 PM Ken Goldman wrote: > What is the 3.0.0 equivalent to RSA_set0_key() when I > want to create a key token from n and e. > > Meta question: Is there a porting guide for these > type of questions - something that says, "If you > used this before, use this now." > Hi Ken, you could have a look at the migration guide [1], if you haven't looked at it already. [1] https://github.com/openssl/openssl/blob/master/doc/man7/migration_guide.pod Thank you, Regards, Sahana Prasad -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.c.roberts at gmail.com Tue Jul 13 21:14:55 2021 From: bill.c.roberts at gmail.com (William Roberts) Date: Tue, 13 Jul 2021 16:14:55 -0500 Subject: RSA_set0_key() equivalent for 3.0.0 In-Reply-To: References: Message-ID: Outside of the migration guide others have pointed out, I think the functions you need are: https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_set1_RSA.html Use use EVP level now as pointed out in the guide. On Tue, Jul 13, 2021, 16:04 Ken Goldman wrote: > What is the 3.0.0 equivalent to RSA_set0_key() when I > want to create a key token from n and e. > > Meta question: Is there a porting guide for these > type of questions - something that says, "If you > used this before, use this now." > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Jul 13 22:11:49 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 13 Jul 2021 23:11:49 +0100 Subject: RSA_set0_key() equivalent for 3.0.0 In-Reply-To: References: Message-ID: <58dbb2dc-149b-f87e-1bbd-689df428b0ab@openssl.org> On 13/07/2021 22:14, William Roberts wrote: > Outside of the migration guide others have pointed out, I think the > functions you need are: > > https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_set1_RSA.html > Those functions are deprecated. Better would be EVP_PKEY_fromdata(): https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_fromdata.html Matt > > Use use EVP level now as pointed out in the guide. > > > > On Tue, Jul 13, 2021, 16:04 Ken Goldman > wrote: > > What is the 3.0.0 equivalent to RSA_set0_key() when I > want to create a key token from n and e. > > Meta question:? Is there a porting guide for these > type of questions - something that says, "If you > used this before, use this now." > From tomiii at tomiii.com Tue Jul 13 22:48:01 2021 From: tomiii at tomiii.com (Thomas Dwyer III) Date: Tue, 13 Jul 2021 15:48:01 -0700 Subject: EVP_MAC_init - specify the hash algorithm In-Reply-To: References: Message-ID: This seems to work for me in 3.0, passing the EVP_MD to EVP_DigestSignInit(): pkey = EVP_PKEY_new_mac_key() EVP_DigestSignInit() EVP_DigestSignUpdate() EVP_DigestSignUpdate() . . . EVP_DigestSignFinal() Regards, Tom.III On Tue, Jul 13, 2021 at 11:02 AM Ken Goldman wrote: > Porting to 3.0 ... HMAC_Init_ex() had a place for > the hash algorithm. EVP_MAC_init() does not, > unless it's embedded in the 'params' parameter. > > Any advice? Or a sample for doing an > HMAC with 3.0? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pauli at openssl.org Tue Jul 13 23:06:38 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Wed, 14 Jul 2021 09:06:38 +1000 Subject: EVP_MAC_init - specify the hash algorithm In-Reply-To: References: Message-ID: <1eaf59cc-8570-eae6-4882-67e60fb0f345@openssl.org> Please don't do it the PKEY way :) Your code should look more like: OSSL_PARAMS params[2]; EVP_MAC *mac = EVP_MAC_new(NULL, "HMAC", NULL); EVP_MAC_CTX *mac_ctx = EVP_MAC_CTX_new(mac); EVP_MAC_free(mac); /* Now or later is all good and depends on the app reusing it or not */ params[0] = OSSL_PARAMS_construct_utf8_string("digest", "SHA256", 0); params[1] = OSSL_PARAMS_construct_end(); EVP_MAC_init(mac_ctx, key, key_len, params); EVP_MAC_update(mac_ctx, data1, data1_len); EVP_MAC_update(mac_ctx, data2, data2_len); EVP_MAC_update(mac_ctx, data3, data3_len); EVP_MAC_final(mac_ctx, out, &out_size, out_len); EVP_MAC_CTX_free(mac_ctx); There are various other calls that tweak the flow but this is the basic idea. Pauli On 14/7/21 8:48 am, Thomas Dwyer III wrote: > This seems to work for me in 3.0, passing the EVP_MD to > EVP_DigestSignInit(): > > pkey = EVP_PKEY_new_mac_key() > EVP_DigestSignInit() > EVP_DigestSignUpdate() > EVP_DigestSignUpdate() > . > . > . > EVP_DigestSignFinal() > > > Regards, > Tom.III > > > > On Tue, Jul 13, 2021 at 11:02 AM Ken Goldman > wrote: > > Porting to 3.0 ... HMAC_Init_ex() had a place for > the hash algorithm.? EVP_MAC_init() does not, > unless it's embedded in the 'params' parameter. > > Any advice?? Or a sample for doing an > HMAC with 3.0? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomiii at tomiii.com Tue Jul 13 23:38:40 2021 From: tomiii at tomiii.com (Thomas Dwyer III) Date: Tue, 13 Jul 2021 16:38:40 -0700 Subject: EVP_MAC_init - specify the hash algorithm In-Reply-To: <1eaf59cc-8570-eae6-4882-67e60fb0f345@openssl.org> References: <1eaf59cc-8570-eae6-4882-67e60fb0f345@openssl.org> Message-ID: Thanks for that example. It's very helpful! I didn't know about the new EVP_MAC API (although I see it now in the migration guide). I wrote my implementation based on https://wiki.openssl.org/index.php/EVP_Signing_and_Verifying :-) Tom.III On Tue, Jul 13, 2021 at 4:07 PM Dr Paul Dale wrote: > Please don't do it the PKEY way :) > > Your code should look more like: > > OSSL_PARAMS params[2]; > EVP_MAC *mac = EVP_MAC_new(NULL, "HMAC", NULL); > EVP_MAC_CTX *mac_ctx = EVP_MAC_CTX_new(mac); > EVP_MAC_free(mac); /* Now or later is all good and depends on the app > reusing it or not */ > > params[0] = OSSL_PARAMS_construct_utf8_string("digest", "SHA256", 0); > params[1] = OSSL_PARAMS_construct_end(); > > EVP_MAC_init(mac_ctx, key, key_len, params); > EVP_MAC_update(mac_ctx, data1, data1_len); > EVP_MAC_update(mac_ctx, data2, data2_len); > EVP_MAC_update(mac_ctx, data3, data3_len); > EVP_MAC_final(mac_ctx, out, &out_size, out_len); > EVP_MAC_CTX_free(mac_ctx); > > There are various other calls that tweak the flow but this is the basic > idea. > > > Pauli > > On 14/7/21 8:48 am, Thomas Dwyer III wrote: > > This seems to work for me in 3.0, passing the EVP_MD to > EVP_DigestSignInit(): > > pkey = EVP_PKEY_new_mac_key() > EVP_DigestSignInit() > EVP_DigestSignUpdate() > EVP_DigestSignUpdate() > . > . > . > EVP_DigestSignFinal() > > > Regards, > Tom.III > > > > On Tue, Jul 13, 2021 at 11:02 AM Ken Goldman wrote: > >> Porting to 3.0 ... HMAC_Init_ex() had a place for >> the hash algorithm. EVP_MAC_init() does not, >> unless it's embedded in the 'params' parameter. >> >> Any advice? Or a sample for doing an >> HMAC with 3.0? >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Jul 14 11:31:09 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 14 Jul 2021 12:31:09 +0100 Subject: SSL_connect with TLS 1.3 and client Certificates In-Reply-To: References: Message-ID: On 13/07/2021 19:44, Christian Schmidt wrote: > Hello all, > > I am currently trying to build both client and server of an application > that uses TLS 1.3 and mutual authentication using certificates. The > application works so far - I can establish connections, certificates are > verified, data is successfully transmitted, etc. > > However, I have an issue, or maybe two. > > 1. SSL_connect returns successfully before the client certificate is > sent from the client to the server. The client certificate is only sent > on the first SSL_write_ex with > 0 bytes, and as such, at this point the > server can generate SSL alerts like access denied, etc. TLSv1.3 supports two types of certificate request. It can occur during the initial handshake, or it can occur as a post-handshake request. It sounds like you are doing the latter, but you want the former. Is that correct? What are you doing in your code to request the certificate from the client? Matt From schmidt at digadd.de Wed Jul 14 13:31:41 2021 From: schmidt at digadd.de (Christian Schmidt) Date: Wed, 14 Jul 2021 15:31:41 +0200 Subject: SSL_connect with TLS 1.3 and client Certificates In-Reply-To: References: Message-ID: <10d0c06a-7219-22c0-44d4-216ac6b89a1c@digadd.de> On 14/07/2021 13:31, Matt Caswell wrote: > > > On 13/07/2021 19:44, Christian Schmidt wrote: >> Hello all, >> >> I am currently trying to build both client and server of an application >> that uses TLS 1.3 and mutual authentication using certificates. The >> application works so far - I can establish connections, certificates are >> verified, data is successfully transmitted, etc. >> >> However, I have an issue, or maybe two. >> >> 1. SSL_connect returns successfully before the client certificate is >> sent from the client to the server. The client certificate is only sent >> on the first SSL_write_ex with > 0 bytes, and as such, at this point the >> server can generate SSL alerts like access denied, etc. > > TLSv1.3 supports two types of certificate request. It can occur during > the initial handshake, or it can occur as a post-handshake request. It > sounds like you are doing the latter, but you want the former. Is that > correct? > > What are you doing in your code to request the certificate from the client? I may have interpreted what I was seeing wrong. I was assuming that openssl was sending the client certificate together with the first data frame, but it seems that some coalescing happens on the kernel side, causing the server to retrieve both SSL records at once. The asynchronous nature of TLS implies that after sending the client certificate, SSL_connect() does not have to wait for a positive confirmation. Adding a sufficiently large usleep() between SSL_connect() and the first data record makes this visible. Please ignore my question. Best regards, Christian From kgoldman at us.ibm.com Wed Jul 14 14:14:59 2021 From: kgoldman at us.ibm.com (Ken Goldman) Date: Wed, 14 Jul 2021 10:14:59 -0400 Subject: RSA_set0_key() equivalent for 3.0.0 In-Reply-To: References: Message-ID: On 7/13/2021 5:08 PM, Nicola Tuveri wrote: > There is the migration guide: https://github.com/openssl/openssl/tree/master/doc/man7/migration_guide.pod > The migration guide is very general. It says that the low level APIs are deprecated, and should be replaced with EVP functions. Is there anything more specific - replace RSA_set0_key() with ... From bill.c.roberts at gmail.com Wed Jul 14 14:20:36 2021 From: bill.c.roberts at gmail.com (William Roberts) Date: Wed, 14 Jul 2021 09:20:36 -0500 Subject: RSA_set0_key() equivalent for 3.0.0 In-Reply-To: References: Message-ID: I'd be nice to have a more detailed porting guide, I'd been poking into this a little bit, but did you see Matt's response? (Pasted below) Those functions are deprecated. Better would be EVP_PKEY_fromdata(): https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_fromdata.html On Wed, Jul 14, 2021, 09:15 Ken Goldman wrote: > On 7/13/2021 5:08 PM, Nicola Tuveri wrote: > > There is the migration guide: > https://github.com/openssl/openssl/tree/master/doc/man7/migration_guide.pod > < > https://github.com/openssl/openssl/tree/master/doc/man7/migration_guide.pod > > > > > > The migration guide is very general. It says that the low level APIs are > deprecated, > and should be replaced with EVP functions. > > Is there anything more specific - replace RSA_set0_key() with ... > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgoldman at us.ibm.com Wed Jul 14 14:27:04 2021 From: kgoldman at us.ibm.com (Ken Goldman) Date: Wed, 14 Jul 2021 10:27:04 -0400 Subject: RSA_set0_key() equivalent for 3.0.0 In-Reply-To: References: Message-ID: On 7/13/2021 5:14 PM, William Roberts wrote: > Outside of the migration guide others have pointed out, I think the functions you need are: > > https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_set1_RSA.html > > Use use EVP level now as pointed out in the guide. Perhaps I'm reading it incorrectly, but I think that API is deprecated. 1 - When I read the SYNOPSIS, there are a few APIs, then a "deprecated since OpenSSL 3.0" separator, and then more APIs. I thought that APIs below the separator are deprecated. Is that wrong? 2 - In evp.h, there is this: OSSL_DEPRECATEDIN_3_0 int EVP_PKEY_set1_RSA(EVP_PKEY *pkey, struct rsa_st *key); I interpreted that to mean it's deprecated. Is that wrong? 3 - When I try to use it, I get: warning: 'EVP_PKEY_set1_RSA' is deprecated (declared at openssl/include/openssl/evp.h:1344) Seems deprecated. From bill.c.roberts at gmail.com Wed Jul 14 14:30:00 2021 From: bill.c.roberts at gmail.com (William Roberts) Date: Wed, 14 Jul 2021 09:30:00 -0500 Subject: RSA_set0_key() equivalent for 3.0.0 In-Reply-To: References: Message-ID: On Wed, Jul 14, 2021, 09:27 Ken Goldman wrote: > On 7/13/2021 5:14 PM, William Roberts wrote: > > Outside of the migration guide others have pointed out, I think the > functions you need are: > > > > https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_set1_RSA.html < > https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_set1_RSA.html> > > > > Use use EVP level now as pointed out in the guide. > > Perhaps I'm reading it incorrectly, but I think that API is > deprecated. > > 1 - When I read the SYNOPSIS, there are a few APIs, then a > "deprecated since OpenSSL 3.0" separator, and then more APIs. > > I thought that APIs below the separator are deprecated. > Is that wrong? > > 2 - In evp.h, there is this: > > OSSL_DEPRECATEDIN_3_0 > int EVP_PKEY_set1_RSA(EVP_PKEY *pkey, struct rsa_st *key); > > I interpreted that to mean it's deprecated. > > Is that wrong? > > 3 - When I try to use it, I get: > > warning: 'EVP_PKEY_set1_RSA' is deprecated (declared at > openssl/include/openssl/evp.h:1344) > > Seems deprecated. > Matt Caswell pointed out that you want EVP_PKEY_fromdata() -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonkbaby at gmail.com Fri Jul 16 03:55:26 2021 From: simonkbaby at gmail.com (SIMON BABY) Date: Thu, 15 Jul 2021 20:55:26 -0700 Subject: query on key usage OIDs Message-ID: Hi Team, I am looking for openssl APIs to get all the OIDs associated with user certificate Key usage extension. For example my sample Key usage extension from the certificate is below: X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment I am looking for the APIs used to get the OIDs associated with Digital Signature and Key Encipherment from the certificate. Reagrds Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Jul 16 04:15:43 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 16 Jul 2021 00:15:43 -0400 Subject: query on key usage OIDs In-Reply-To: References: Message-ID: > On 15 Jul 2021, at 11:55 pm, SIMON BABY wrote: > > I am looking for openssl APIs to get all the OIDs associated with user certificate Key usage extension. For example my sample Key usage extension from the certificate is below: > X509v3 extensions: > X509v3 Key Usage: critical > Digital Signature, Key Encipherment > > I am looking for the APIs used to get the OIDs associated with Digital Signature and Key Encipherment from the certificate. There are no keyUsage OIDs, the field is a bitstring: https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.3 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } KeyUsage ::= BIT STRING { digitalSignature (0), nonRepudiation (1), -- recent editions of X.509 have -- renamed this bit to contentCommitment keyEncipherment (2), dataEncipherment (3), keyAgreement (4), keyCertSign (5), cRLSign (6), encipherOnly (7), decipherOnly (8) } There are OIDs in the extendedKeyUsage: https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12 -- Viktor. From aerowolf at gmail.com Fri Jul 16 04:44:39 2021 From: aerowolf at gmail.com (Kyle Hamilton) Date: Fri, 16 Jul 2021 04:44:39 +0000 Subject: query on key usage OIDs In-Reply-To: References: Message-ID: Also, OIDs for extendedKeyUsage can be defined per-application, so there's no way to compile a full list of them. -Kyle H On Fri, Jul 16, 2021 at 4:23 AM Viktor Dukhovni wrote: > > > On 15 Jul 2021, at 11:55 pm, SIMON BABY wrote: > > > > I am looking for openssl APIs to get all the OIDs associated with user certificate Key usage extension. For example my sample Key usage extension from the certificate is below: > > X509v3 extensions: > > X509v3 Key Usage: critical > > Digital Signature, Key Encipherment > > > > I am looking for the APIs used to get the OIDs associated with Digital Signature and Key Encipherment from the certificate. > > There are no keyUsage OIDs, the field is a bitstring: > > https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.3 > > id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } > > KeyUsage ::= BIT STRING { > digitalSignature (0), > nonRepudiation (1), -- recent editions of X.509 have > -- renamed this bit to contentCommitment > keyEncipherment (2), > dataEncipherment (3), > keyAgreement (4), > keyCertSign (5), > cRLSign (6), > encipherOnly (7), > decipherOnly (8) } > > There are OIDs in the extendedKeyUsage: > > https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12 > > -- > Viktor. > From jb-openssl at wisemo.com Fri Jul 16 11:11:04 2021 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 16 Jul 2021 13:11:04 +0200 Subject: query on key usage OIDs In-Reply-To: References: Message-ID: <8d4b6043-5a81-37b6-4fcd-adce517e1fb0@wisemo.com> Question was how to retrieve those lists for any given certificate, using currently supported OpenSSL APIs. The lists of usage bits and extusage OIDs in any given certificate are finite, even if the list of values that could be in other certificates is infinite. On 2021-07-16 06:44, Kyle Hamilton wrote: > Also, OIDs for extendedKeyUsage can be defined per-application, so > there's no way to compile a full list of them. > > -Kyle H > > On Fri, Jul 16, 2021 at 4:23 AM Viktor Dukhovni > wrote: >>> On 15 Jul 2021, at 11:55 pm, SIMON BABY wrote: >>> >>> I am looking for openssl APIs to get all the OIDs associated with user certificate Key usage extension. For example my sample Key usage extension from the certificate is below: >>> X509v3 extensions: >>> X509v3 Key Usage: critical >>> Digital Signature, Key Encipherment >>> >>> I am looking for the APIs used to get the OIDs associated with Digital Signature and Key Encipherment from the certificate. >> There are no keyUsage OIDs, the field is a bitstring: >> >> https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.3 >> >> id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } >> >> KeyUsage ::= BIT STRING { >> digitalSignature (0), >> nonRepudiation (1), -- recent editions of X.509 have >> -- renamed this bit to contentCommitment >> keyEncipherment (2), >> dataEncipherment (3), >> keyAgreement (4), >> keyCertSign (5), >> cRLSign (6), >> encipherOnly (7), >> decipherOnly (8) } >> >> There are OIDs in the extendedKeyUsage: >> >> https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12 >> >> Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Fri Jul 16 12:37:23 2021 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 16 Jul 2021 14:37:23 +0200 Subject: OpenSSL regression when a servername callback is set Message-ID: Hello openssl-users, We came across a change in OpenSSL 1.1.1j that has introduced a regression. https://github.com/openssl/openssl/pull/13304 and https://github.com/openssl/openssl/pull/13305 introduced the behaviour change: when servername callback is set, we suppose that we are TLS1.3-capable (see https://github.com/openssl/openssl/issues/13291 as rationale) When server has a secret key that is incompatible with TLS 1.3 (in our test setup it was DSA, but we expect the same behavior with, e.g, Brainpool curves) set in httpd, when connecting to it via s_client, we get an alert in response to a ClientHello. It can be invisible for end-users because of downgrade dance, but I wonder if we have any real-life cases. The relevant GH issue is https://github.com/openssl/openssl/issues/16075 Many thanks! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sat Jul 17 15:19:22 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 17 Jul 2021 11:19:22 -0400 Subject: query on key usage OIDs In-Reply-To: <8d4b6043-5a81-37b6-4fcd-adce517e1fb0@wisemo.com> References: <8d4b6043-5a81-37b6-4fcd-adce517e1fb0@wisemo.com> Message-ID: On Fri, Jul 16, 2021 at 01:11:04PM +0200, Jakob Bohm via openssl-users wrote: > Question was how to retrieve those lists for any given certificate, > using currently supported OpenSSL APIs. > > The lists of usage bits and extusage OIDs in any given certificate > are finite, even if the list of values that could be in other > certificates is infinite. The bits can be retrieved via: X509_get_key_usage(3). https://www.openssl.org/docs/man1.1.1/man3/X509_get_key_usage.html The "standard" EKU extensions can be retrieved via: X509_get_extended_key_usage(3) X509_get_extended_key_usage() returns the value of the extended key usage extension. If extended key usage is present it will return zero or more of the flags: XKU_SSL_SERVER, XKU_SSL_CLIENT, XKU_SMIME, XKU_CODE_SIGN XKU_OCSP_SIGN, XKU_TIMESTAMP, XKU_DVCS or XKU_ANYEKU. These correspond to the OIDs id-kp-serverAuth, id-kp-clientAuth, id-kp-emailProtection, id-kp-codeSigning, id-kp-OCSPSigning, id-kp-timeStamping, id-kp-dvcs and anyExtendedKeyUsage respectively. To retrieve the full list of extended key usage OIDs: X509_get_ext_d2i(3) X509 *x; EXTENDED_KEY_USAGE *extusage; int i; ... if ((extusage = X509_get_ext_d2i(x, NID_ext_key_usage, &i, NULL)) != NULL) { for (i = 0; i < sk_ASN1_OBJECT_num(extusage); ++i) { ASN1_OBJECT *obj = sk_ASN1_OBJECT_value(extusage, i); /* Do something with "obj" */ } } sk_ASN1_OBJECT_pop_free(extusage, ASN1_OBJECT_free); -- Viktor. From claude-robitaille at hotmail.com Sun Jul 18 20:32:39 2021 From: claude-robitaille at hotmail.com (Claude Robitaille) Date: Sun, 18 Jul 2021 20:32:39 +0000 Subject: Decrypting app payload in wireshark Message-ID: Hi all, I am setting up a callback using SSL_CTX_set_keylog_callback where I simply dump to a file. In wireshark, having configured it to use the filr I created, I can see the decoded TLS handshake (prior to that, the handshake was encrypted so I know that wireshark is indeed finding the data from the callback). But the actual application data is still encrypted.... ? I am doing this client side. Any idea what is missing? -------------- next part -------------- An HTML attachment was scrubbed... URL: From claude-robitaille at hotmail.com Sun Jul 18 22:58:58 2021 From: claude-robitaille at hotmail.com (Claude Robitaille) Date: Sun, 18 Jul 2021 22:58:58 +0000 Subject: Decrypting app payload in wireshark In-Reply-To: References: Message-ID: Never mind. All is good. Wireshark simply does not show the content / result of the last data packet. In the test, I was just sending 1 packet so even though wireshark decrypts it this is not visible in the main window. But if you go to conversation details then you see the data. ________________________________ From: openssl-users on behalf of Claude Robitaille Sent: July 18, 2021 4:32 PM To: openssl-users at openssl.org Subject: Decrypting app payload in wireshark Hi all, I am setting up a callback using SSL_CTX_set_keylog_callback where I simply dump to a file. In wireshark, having configured it to use the filr I created, I can see the decoded TLS handshake (prior to that, the handshake was encrypted so I know that wireshark is indeed finding the data from the callback). But the actual application data is still encrypted.... ? I am doing this client side. Any idea what is missing? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gaardiolor at gmail.com Tue Jul 20 22:04:44 2021 From: gaardiolor at gmail.com (Gaardiolor) Date: Wed, 21 Jul 2021 00:04:44 +0200 Subject: verify ocsp manually Message-ID: <921f8d2d-163b-9d9a-1120-92f23b7d4c84@gmail.com> Good day, I don't fully understand ocsp certificate verification. In order to better understand it, I want to do it manually. I can already do that with certificates. $ openssl s_client -connect openssl.org:443 -showcerts # I save the server.crt and intermediate.crt $ openssl verify -no-CApath -partial_chain -trusted intermediate.crt server.crt server.crt: OK Manually: # Get the ASN id's of the TBS and Signature $ asn=`openssl asn1parse -i -in server.crt |egrep -e '(^ .*: SEQUENCE|: BIT STRING)'` $ asn_tbs=`echo "$asn" | head -1 | awk -F: '{print $1}' | sed 's/ //g'` $ asn_sig=`echo "$asn" | tail -1 | awk -F: '{print $1}' | sed 's/ //g'` # Get tbs openssl asn1parse -in server.crt -strparse ${asn_tbs} -out server.tbs > /dev/null # Hash tbs $ cat server.tbs | openssl sha256 -binary > server.tbs.sha256 # Get signature (ignore 'header too long' error) $ openssl asn1parse -in server.crt -strparse ${asn_sig} -out server.sig > /dev/null # Get public key of intermediate $ openssl x509 -in intermediate.crt -noout -pubkey > intermediate.pub # Recover (decrypt) the signature $ openssl rsautl -inkey intermediate.pub -pubin -in server.sig -out server.sig.recovered # Verify. Ignore the first line of server.sig.recovered, this is the hash algoritm designator $ od -An -tx1 -w19 server.sig.recovered ?30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 ?87 36 67 06 ba d7 10 18 72 d3 f6 58 00 a9 34 78 bc 82 bf ?57 37 20 ab 82 04 fb 04 78 38 e2 d3 a2 $ od -An -tx1 -w19 server.tbs.sha256 ?87 36 67 06 ba d7 10 18 72 d3 f6 58 00 a9 34 78 bc 82 bf ?57 37 20 ab 82 04 fb 04 78 38 e2 d3 a2 Yay. Now how do I do that with OCSP ? # Get OCSP $ ocsp=`openssl x509 -noout -ocsp_uri -in server.crt` # Verify $ ocsp_response=`openssl ocsp -noverify -no_nonce -respout ocsp.resp -reqout ocsp.req -issuer intermediate.crt -cert server.crt -text -url $ocsp` $ echo "$ocsp_response" | grep server.crt server.crt: good Manually: # Get the signature. Can't find how to do this with asn1parse $ for byte in `echo "$ocsp_response" | grep -A40 "??? Signature Algorithm" | grep -B40 "server.crt" | egrep -ve '(Signature Algorithm|server.crt)' | sed -e 's/ //g' -e 's/:/ /g'`; do ??? echo -ne "\x$byte" ? done > ocsp.resp.sig # Recover (decrypt) the signature $ openssl rsautl -inkey intermediate.pub -pubin -in ocsp.resp.sig -out ocsp.resp.sig.recovered # Print the decrypted signature (looks good, first line is hash algorithm designator, length looks ok, no errors) $ od -An -tx1 -w19 ocsp.resp.sig.recovered ?30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 ?b4 83 f2 c3 4a 6c 1b 4e df 66 b4 d5 31 0b 58 c3 60 3c e9 ?20 0f 4f b0 df 61 88 2f c0 e0 25 66 a8 But.. How to extract the tbs data from the response, so I can sha256 that and compare ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From webstrucs at gmail.com Wed Jul 21 02:47:25 2021 From: webstrucs at gmail.com (Webstrucs) Date: Tue, 20 Jul 2021 23:47:25 -0300 Subject: openssl ciphers Message-ID: Good luck to us all. I am Jo?o openssl's apprentice and below I describe my doubts: I needed to generate a cipher to insert as a parameter in a python function context = ssl.SSLContext.set_ciphers(ciphers), what I'm finding strange would be the generated size. My question would be if I should insert the entire cipher generated by the openssl ciphers -tls1_2 command that resulted in a cipher of more than 15 lines inside the parameter (ciphers) ? *Webstrucs* Servi?o de Atendimento Segunda - Sexta / 07:00 - 17:00 webstrucs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Jul 21 04:31:41 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 21 Jul 2021 00:31:41 -0400 Subject: openssl ciphers In-Reply-To: References: Message-ID: On Tue, Jul 20, 2021 at 11:47:25PM -0300, Webstrucs wrote: > I needed to generate a cipher to insert as a parameter in a python function > context = ssl.SSLContext.set_ciphers(ciphers), what I'm finding strange > would be the generated size. My question would be if I should insert the > entire cipher generated by the openssl ciphers -tls1_2 command that > resulted in a cipher of more than 15 lines inside the parameter (ciphers) ? With OpenSSL 1.1.x and later the sensible cipher suite to use is "DEFAULT". This is also what you get when you skip setting the ciphers. Many HOWTO guides recommend all kinds of explicit tweaks to make the cipherlist match the latest fad. They're almost always misguided. All supported OpenSSL versions ship with reasonable general purpose ciphers, and more harm than good is achieved by trying to fine-tune these. -- Viktor. From gaardiolor at gmail.com Wed Jul 21 09:11:23 2021 From: gaardiolor at gmail.com (Gaardiolor) Date: Wed, 21 Jul 2021 11:11:23 +0200 Subject: verify ocsp manually In-Reply-To: <921f8d2d-163b-9d9a-1120-92f23b7d4c84@gmail.com> References: <921f8d2d-163b-9d9a-1120-92f23b7d4c84@gmail.com> Message-ID: <67f8ec55-731c-3270-e48e-4db95f117532@gmail.com> Oh.. I'm a step further. I've checked every byte range of the ocsp response for the recovered sha256 signature. $ len=`cat ocsp.resp | wc -c` $ for start in `seq 1 $len`; do ??? echo -n "$start " ??? for end in `seq 1 $[$len+1-$start]`; do ?? ?? output=`cat ocsp.resp | tail -c +$start | head -c $end | sha256sum| grep b483f2c34a6c1b4edf66b4d5310b58c3603ce9200f4fb0df61882fc0e02566a8` ????? if [ "$output" != "" ]; then ? ? ??? echo '' ??????? echo $start $end $output ?????? cat ocsp.resp | tail -c +$start | head -c $end | od -An -tx1 ??????? break ?? ?? fi ??? done ??? if [ "$output" != "" ]; then break; fi ? done 35 193 b483f2c34a6c1b4edf66b4d5310b58c3603ce9200f4fb0df61882fc0e02566a8 - ?30 81 be a1 34 30 32 31 0b 30 09 06 03 55 04 06 ?13 02 55 53 31 16 30 14 06 03 55 04 0a 13 0d 4c ?65 74 27 73 20 45 6e 63 72 79 70 74 31 0b 30 09 ?06 03 55 04 03 13 02 52 33 18 0f 32 30 32 31 30 ?37 31 38 31 38 30 30 30 30 5a 30 75 30 73 30 4b ?30 09 06 05 2b 0e 03 02 1a 05 00 04 14 48 da c9 ?a0 fb 2b d3 2d 4f f0 de 68 d2 f5 67 b7 35 f9 b3 ?c4 04 14 14 2e b3 17 b7 58 56 cb ae 50 09 40 e6 ?1f af 9d 8b 14 c2 c6 02 12 03 dc be 01 33 c9 b8 ?33 12 54 75 b4 a7 7a b5 4a 3d f6 80 00 18 0f 32 ?30 32 31 30 37 31 38 31 38 30 30 30 30 5a a0 11 ?18 0f 32 30 32 31 30 37 32 35 31 38 30 30 30 30 ?5a So the TBS part starts in byte 35 and is 193 bytes long, meaning bytes 35-227. Looking at wireshark, that's indeed the 'tbsResponseData'. Any way to extract the tbs with openssl ? Thanks. On 2021-07-21 00:04, Gaardiolor wrote: > > Good day, > > I don't fully understand ocsp certificate verification. In order to > better understand it, I want to do it manually. I can already do that > with certificates. > > $ openssl s_client -connect openssl.org:443 -showcerts > # I save the server.crt and intermediate.crt > > $ openssl verify -no-CApath -partial_chain -trusted intermediate.crt > server.crt > server.crt: OK > > Manually: > # Get the ASN id's of the TBS and Signature > $ asn=`openssl asn1parse -i -in server.crt |egrep -e '(^ .*: > SEQUENCE|: BIT STRING)'` > $ asn_tbs=`echo "$asn" | head -1 | awk -F: '{print $1}' | sed 's/ //g'` > $ asn_sig=`echo "$asn" | tail -1 | awk -F: '{print $1}' | sed 's/ //g'` > > # Get tbs > openssl asn1parse -in server.crt -strparse ${asn_tbs} -out server.tbs > > /dev/null > > # Hash tbs > $ cat server.tbs | openssl sha256 -binary > server.tbs.sha256 > > # Get signature (ignore 'header too long' error) > $ openssl asn1parse -in server.crt -strparse ${asn_sig} -out > server.sig > /dev/null > > # Get public key of intermediate > $ openssl x509 -in intermediate.crt -noout -pubkey > intermediate.pub > > # Recover (decrypt) the signature > $ openssl rsautl -inkey intermediate.pub -pubin -in server.sig -out > server.sig.recovered > > # Verify. Ignore the first line of server.sig.recovered, this is the > hash algoritm designator > $ od -An -tx1 -w19 server.sig.recovered > ?30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 > ?87 36 67 06 ba d7 10 18 72 d3 f6 58 00 a9 34 78 bc 82 bf > ?57 37 20 ab 82 04 fb 04 78 38 e2 d3 a2 > $ od -An -tx1 -w19 server.tbs.sha256 > ?87 36 67 06 ba d7 10 18 72 d3 f6 58 00 a9 34 78 bc 82 bf > ?57 37 20 ab 82 04 fb 04 78 38 e2 d3 a2 > > Yay. Now how do I do that with OCSP ? > > # Get OCSP > $ ocsp=`openssl x509 -noout -ocsp_uri -in server.crt` > > # Verify > $ ocsp_response=`openssl ocsp -noverify -no_nonce -respout ocsp.resp > -reqout ocsp.req -issuer intermediate.crt -cert server.crt -text -url > $ocsp` > $ echo "$ocsp_response" | grep server.crt > server.crt: good > > Manually: > # Get the signature. Can't find how to do this with asn1parse > $ for byte in `echo "$ocsp_response" | grep -A40 " Signature > Algorithm" | grep -B40 "server.crt" | egrep -ve '(Signature > Algorithm|server.crt)' | sed -e 's/ //g' -e 's/:/ /g'`; do > ??? echo -ne "\x$byte" > ? done > ocsp.resp.sig > > # Recover (decrypt) the signature > $ openssl rsautl -inkey intermediate.pub -pubin -in ocsp.resp.sig -out > ocsp.resp.sig.recovered > > # Print the decrypted signature (looks good, first line is hash > algorithm designator, length looks ok, no errors) > $ od -An -tx1 -w19 ocsp.resp.sig.recovered > ?30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 > ?b4 83 f2 c3 4a 6c 1b 4e df 66 b4 d5 31 0b 58 c3 60 3c e9 > ?20 0f 4f b0 df 61 88 2f c0 e0 25 66 a8 > > But.. How to extract the tbs data from the response, so I can sha256 > that and compare ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dirkx at webweaving.org Wed Jul 21 09:16:59 2021 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Wed, 21 Jul 2021 11:16:59 +0200 Subject: verify ocsp manually In-Reply-To: <67f8ec55-731c-3270-e48e-4db95f117532@gmail.com> References: <921f8d2d-163b-9d9a-1120-92f23b7d4c84@gmail.com> <67f8ec55-731c-3270-e48e-4db95f117532@gmail.com> Message-ID: Try sending that block to pbpaste| xxd -r -p | openssl asn1parse -inform DER 0:d=0 hl=3 l= 190 cons: SEQUENCE 3:d=1 hl=2 l= 52 cons: cont [ 1 ] 5:d=2 hl=2 l= 50 cons: SEQUENCE 7:d=3 hl=2 l= 11 cons: SET 9:d=4 hl=2 l= 9 cons: SEQUENCE 11:d=5 hl=2 l= 3 prim: OBJECT :countryName 16:d=5 hl=2 l= 2 prim: PRINTABLESTRING :US 20:d=3 hl=2 l= 22 cons: SET 22:d=4 hl=2 l= 20 cons: SEQUENCE 24:d=5 hl=2 l= 3 prim: OBJECT :organizationName 29:d=5 hl=2 l= 13 prim: PRINTABLESTRING :Let's Encrypt 44:d=3 hl=2 l= 11 cons: SET 46:d=4 hl=2 l= 9 cons: SEQUENCE 48:d=5 hl=2 l= 3 prim: OBJECT :commonName 53:d=5 hl=2 l= 2 prim: PRINTABLESTRING :R3 57:d=1 hl=2 l= 15 prim: GENERALIZEDTIME :20210718180000Z 74:d=1 hl=2 l= 117 cons: SEQUENCE 76:d=2 hl=2 l= 115 cons: SEQUENCE 78:d=3 hl=2 l= 75 cons: SEQUENCE 80:d=4 hl=2 l= 9 cons: SEQUENCE 82:d=5 hl=2 l= 5 prim: OBJECT :sha1 89:d=5 hl=2 l= 0 prim: NULL 91:d=4 hl=2 l= 20 prim: OCTET STRING [HEX DUMP]:48DAC9A0FB2BD32D4FF0DE68D2F567B735F9B3C4 113:d=4 hl=2 l= 20 prim: OCTET STRING [HEX DUMP]:142EB317B75856CBAE500940E61FAF9D8B14C2C6 135:d=4 hl=2 l= 18 prim: INTEGER :03DCBE0133C9B833125475B4A77AB54A3DF6 155:d=3 hl=2 l= 0 prim: cont [ 0 ] 157:d=3 hl=2 l= 15 prim: GENERALIZEDTIME :20210718180000Z 174:d=3 hl=2 l= 17 cons: cont [ 0 ] 176:d=4 hl=2 l= 15 prim: GENERALIZEDTIME :20210725180000Z > On 21 Jul 2021, at 11:11, Gaardiolor wrote: > > Oh.. I'm a step further. I've checked every byte range of the ocsp response for the recovered sha256 signature. > > $ len=`cat ocsp.resp | wc -c` > $ for start in `seq 1 $len`; do > echo -n "$start " > for end in `seq 1 $[$len+1-$start]`; do > output=`cat ocsp.resp | tail -c +$start | head -c $end | sha256sum| grep b483f2c34a6c1b4edf66b4d5310b58c3603ce9200f4fb0df61882fc0e02566a8` > if [ "$output" != "" ]; then > echo '' > echo $start $end $output > cat ocsp.resp | tail -c +$start | head -c $end | od -An -tx1 > break > fi > done > if [ "$output" != "" ]; then break; fi > done > > > 35 193 b483f2c34a6c1b4edf66b4d5310b58c3603ce9200f4fb0df61882fc0e02566a8 - > 30 81 be a1 34 30 32 31 0b 30 09 06 03 55 04 06 > 13 02 55 53 31 16 30 14 06 03 55 04 0a 13 0d 4c > 65 74 27 73 20 45 6e 63 72 79 70 74 31 0b 30 09 > 06 03 55 04 03 13 02 52 33 18 0f 32 30 32 31 30 > 37 31 38 31 38 30 30 30 30 5a 30 75 30 73 30 4b > 30 09 06 05 2b 0e 03 02 1a 05 00 04 14 48 da c9 > a0 fb 2b d3 2d 4f f0 de 68 d2 f5 67 b7 35 f9 b3 > c4 04 14 14 2e b3 17 b7 58 56 cb ae 50 09 40 e6 > 1f af 9d 8b 14 c2 c6 02 12 03 dc be 01 33 c9 b8 > 33 12 54 75 b4 a7 7a b5 4a 3d f6 80 00 18 0f 32 > 30 32 31 30 37 31 38 31 38 30 30 30 30 5a a0 11 > 18 0f 32 30 32 31 30 37 32 35 31 38 30 30 30 30 > 5a > > > So the TBS part starts in byte 35 and is 193 bytes long, meaning bytes 35-227. > > Looking at wireshark, that's indeed the 'tbsResponseData'. Any way to extract the tbs with openssl ? Thanks. > > > > On 2021-07-21 00:04, Gaardiolor wrote: >> Good day, >> >> I don't fully understand ocsp certificate verification. In order to better understand it, I want to do it manually. I can already do that with certificates. >> >> $ openssl s_client -connect openssl.org:443 -showcerts >> # I save the server.crt and intermediate.crt >> >> $ openssl verify -no-CApath -partial_chain -trusted intermediate.crt server.crt >> server.crt: OK >> >> Manually: >> # Get the ASN id's of the TBS and Signature >> $ asn=`openssl asn1parse -i -in server.crt |egrep -e '(^ .*: SEQUENCE|: BIT STRING)'` >> $ asn_tbs=`echo "$asn" | head -1 | awk -F: '{print $1}' | sed 's/ //g'` >> $ asn_sig=`echo "$asn" | tail -1 | awk -F: '{print $1}' | sed 's/ //g'` >> >> # Get tbs >> openssl asn1parse -in server.crt -strparse ${asn_tbs} -out server.tbs > /dev/null >> >> # Hash tbs >> $ cat server.tbs | openssl sha256 -binary > server.tbs.sha256 >> >> # Get signature (ignore 'header too long' error) >> $ openssl asn1parse -in server.crt -strparse ${asn_sig} -out server.sig > /dev/null >> >> # Get public key of intermediate >> $ openssl x509 -in intermediate.crt -noout -pubkey > intermediate.pub >> >> # Recover (decrypt) the signature >> $ openssl rsautl -inkey intermediate.pub -pubin -in server.sig -out server.sig.recovered >> >> # Verify. Ignore the first line of server.sig.recovered, this is the hash algoritm designator >> $ od -An -tx1 -w19 server.sig.recovered >> 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 >> 87 36 67 06 ba d7 10 18 72 d3 f6 58 00 a9 34 78 bc 82 bf >> 57 37 20 ab 82 04 fb 04 78 38 e2 d3 a2 >> $ od -An -tx1 -w19 server.tbs.sha256 >> 87 36 67 06 ba d7 10 18 72 d3 f6 58 00 a9 34 78 bc 82 bf >> 57 37 20 ab 82 04 fb 04 78 38 e2 d3 a2 >> >> Yay. Now how do I do that with OCSP ? >> >> # Get OCSP >> $ ocsp=`openssl x509 -noout -ocsp_uri -in server.crt` >> >> # Verify >> $ ocsp_response=`openssl ocsp -noverify -no_nonce -respout ocsp.resp -reqout ocsp.req -issuer intermediate.crt -cert server.crt -text -url $ocsp` >> $ echo "$ocsp_response" | grep server.crt >> server.crt: good >> >> Manually: >> # Get the signature. Can't find how to do this with asn1parse >> $ for byte in `echo "$ocsp_response" | grep -A40 " Signature Algorithm" | grep -B40 "server.crt" | egrep -ve '(Signature Algorithm|server.crt)' | sed -e 's/ //g' -e 's/:/ /g'`; do >> echo -ne "\x$byte" >> done > ocsp.resp.sig >> >> # Recover (decrypt) the signature >> $ openssl rsautl -inkey intermediate.pub -pubin -in ocsp.resp.sig -out ocsp.resp.sig.recovered >> >> # Print the decrypted signature (looks good, first line is hash algorithm designator, length looks ok, no errors) >> $ od -An -tx1 -w19 ocsp.resp.sig.recovered >> 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 >> b4 83 f2 c3 4a 6c 1b 4e df 66 b4 d5 31 0b 58 c3 60 3c e9 >> 20 0f 4f b0 df 61 88 2f c0 e0 25 66 a8 >> >> But.. How to extract the tbs data from the response, so I can sha256 that and compare ? >> From webstrucs at gmail.com Wed Jul 21 18:33:18 2021 From: webstrucs at gmail.com (Webstrucs) Date: Wed, 21 Jul 2021 15:33:18 -0300 Subject: Directory structure ( SSL/TLS/HTTPS ) Message-ID: Learning to use opessl, I managed to generate private keys and publish in .pem format and I also signed where I was generated two types of private files (.csr and .crt), my doubts on the linux server running (debian 10) where I keep such keys because I want to serve web pages in the format (https)? *Webstrucs* Servi?o de Atendimento Segunda - Sexta / 07:00 - 17:00 webstrucs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tprabhu1989 at gmail.com Wed Jul 21 22:34:03 2021 From: tprabhu1989 at gmail.com (Thejus Prabhu) Date: Wed, 21 Jul 2021 18:34:03 -0400 Subject: Question on "unsupported certificate purpose" error when trying to read the certificate on the web server Message-ID: Hi, I am new to openssl and learning how to use it. I am trying to read the self-signed SSL certificate created on a webserver. I am using OpenSSL 1.1.1k on the client machine when I make a request using: openssl s_client -showcerts -connect 192.168.1.200:443 I end up with the following error "*unsupported certificate purpose" *from the server. CONNECTED(00000003) Can't use SSL_get_servername depth=0 O = Verint, C = US, CN = 192.168.1.200, L = Columbia, OU = Verint verify error:num=18:self signed certificate verify return:1 depth=0 O = Verint, C = US, CN = 192.168.1.200, L = Columbia, OU = Verint verify error:num=26:unsupported certificate purpose verify return:1 depth=0 O = Verint, C = US, CN = 192.168.1.200, L = Columbia, OU = Verint verify return:1 --- Certificate chain 0 s:O = Verint, C = US, CN = 192.168.1.200, L = Columbia, OU = Verint i:O = Verint, C = US, CN = 192.168.1.200, L = Columbia, OU = Verint -----BEGIN CERTIFICATE----- MIIDrjCCApagAwIBAgIBATANBgkqhkiG9w0BAQUFADBaMQ8wDQYDVQQKDAZWZXJp bnQxCzAJBgNVBAYTAlVTMRYwFAYDVQQDDA0xOTIuMTY4LjEuMjAwMREwDwYDVQQH DAhDb2x1bWJpYTEPMA0GA1UECwwGVmVyaW50MB4XDTIxMDcyMTIwNTExMloXDTIy MDcyMTIwNTExMlowWjEPMA0GA1UECgwGVmVyaW50MQswCQYDVQQGEwJVUzEWMBQG A1UEAwwNMTkyLjE2OC4xLjIwMDERMA8GA1UEBwwIQ29sdW1iaWExDzANBgNVBAsM BlZlcmludDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALjovQgQ5Nkt d1IzjBUwz4mg1L2VhRW6VDeNWxfkTT+j+wwI7n4w612T/dvzUYVgkWYE4bJV/VrP wXw6O0wwr2e4LyF8QqSGjtOo6rKOIvO3CJDsj3ogGq5ERYzbLO4g2VZ6i7nQuQtb rHvg9FMptAbLXv3Ph7ddn7vncTMn+LQB1Xh1Xpnh3H1bEngS1jgH9XM8jpti1q4w 9Y8xfkKBLRC0aiwzfEjblZyvqcqLksKTk1l6oKZC3XLouCHYdQV6j0cZyj2uiabT h/wqAsRJWCgF1dKp/PUGQB41OC4z8zHyyagWbrkKQpVu3h/3Pi3INGQAd9TPXD0o eM5gveWQCakCAwEAAaN/MH0wDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMC AQYwHQYDVR0OBBYEFKL/lWLHhbwa/tUL+PeosbS/KYt9MBEGCWCGSAGG+EIBAQQE AwICBDAoBglghkgBhvhCAQ0EGxYZZXhhbXBsZSBjb21tZW50IGV4dGVuc2lvbjAN BgkqhkiG9w0BAQUFAAOCAQEAc/RhHPG308TirrHqHj+ya7zzhYChDagGflq9K/4T zk2ATcg9SpX57pwZHWu0V3ly2QDn0b6cw08td5NxRYePmb01Q5UbaTFx+fTuAB/N 9/Qusa7nnI7LzoZQ2BtOPBF3Y1UJdEyJzjSuTnWA6J43I3Xi678n+NwHnWSzlgGE SmIjyVIPkuFKP9vHuYLpi7uJf2z8kNrhK+mPo9KMZiJaTid3+YgOfIdFxFZLyPqT fBg61c2jWW7iN6ZFV+iPH9ZluUfkXMCDgGOsLR1qD5ViABiwZk+3dlof9nwn94Y+ jfwcsNl8YERh6ev/lbQxZ9/RzvyRPvNk+srIKRY71K70Dg== -----END CERTIFICATE----- --- Server certificate subject=O = Verint, C = US, CN = 192.168.1.200, L = Columbia, OU = Verint issuer=O = Verint, C = US, CN = 192.168.1.200, L = Columbia, OU = Verint --- No client certificate CA names sent --- SSL handshake has read 1258 bytes and written 613 bytes Verification error: unsupported certificate purpose --- New, TLSv1.2, Cipher is AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : AES256-GCM-SHA384 Session-ID: CE62110F0FC98BF92D285826C94F8E243287309A5B8C685763E228E5A121B04C Session-ID-ctx: Master-Key: 1CD43EA64ED4BAABE3E2BD1B33BFFDDB3E9505D1BF786C5137E23D8FC10B117B6F05709A03312288FAAFFB0990258706 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 7200 (seconds) TLS session ticket: 0000 - 97 4d 2d 40 e0 55 22 0a-a0 9b a0 f6 76 03 a7 66 .M-@ .U".....v..f 0010 - 1c 12 4d d7 d3 48 64 48-d3 86 b8 69 a2 02 74 64 ..M..HdH...i..td 0020 - a7 01 59 99 98 f1 a7 7b-e1 8d 64 ec 42 e1 d1 9b ..Y....{..d.B... 0030 - 4d 7a e1 6b 01 8b 0d fd-b5 f0 59 b5 ba 9e d8 ab Mz.k......Y..... 0040 - 2f c4 59 9b 85 c6 78 09-28 da 86 ea a7 fe a0 53 /.Y...x.(......S 0050 - 2e 74 2c 28 e2 91 f6 94-cc 35 7f 25 ab b1 b8 cd .t,(.....5.%.... 0060 - 48 96 af 36 de 28 46 d6-65 ce 00 ac a0 df f5 d3 H..6.(F.e....... 0070 - bd f3 bb 6c 79 e6 3d 69-9c 50 0a db 3b f2 7c f4 ...ly.=i.P..;.|. 0080 - 23 c9 29 62 b4 8c a5 55-70 ab 3d 18 1a f3 86 05 #.)b...Up.=..... 0090 - b1 48 11 1d 29 d0 06 e5-df 32 3c fd 09 76 c7 55 .H..)....2<..v.U Start Time: 1626906266 Timeout : 7200 (sec) Verify return code: 26 (*unsupported certificate purpose*) Extended master secret: yes --- Now I do not have access to the server but I would like to know what "*unsupported certificate purpose" *mean? Could anyone throw some light on this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Jul 21 22:55:27 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 21 Jul 2021 18:55:27 -0400 Subject: Question on "unsupported certificate purpose" error when trying to read the certificate on the web server In-Reply-To: References: Message-ID: On Wed, Jul 21, 2021 at 06:34:03PM -0400, Thejus Prabhu wrote: > verify error:num=26:unsupported certificate purpose The certificate in question is CA certificate, not an EE certificate. Specifically, the key usage and Netscape Cert Type signal that its purpose is exclusively to be a CA, not a TLS server. X509v3 Key Usage: critical Certificate Sign, CRL Sign Netscape Cert Type: SSL CA > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 1 (0x1) > Signature Algorithm: sha1WithRSAEncryption > Issuer: O = Verint, C = US, CN = 192.168.1.200, L = Columbia, OU = Verint > Validity > Not Before: Jul 21 20:51:12 2021 GMT > Not After : Jul 21 20:51:12 2022 GMT > Subject: O = Verint, C = US, CN = 192.168.1.200, L = Columbia, OU = Verint > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > RSA Public-Key: (2048 bit) > Modulus: > 00:b8:e8:bd:08:10:e4:d9:2d:77:52:33:8c:15:30: > cf:89:a0:d4:bd:95:85:15:ba:54:37:8d:5b:17:e4: > 4d:3f:a3:fb:0c:08:ee:7e:30:eb:5d:93:fd:db:f3: > 51:85:60:91:66:04:e1:b2:55:fd:5a:cf:c1:7c:3a: > 3b:4c:30:af:67:b8:2f:21:7c:42:a4:86:8e:d3:a8: > ea:b2:8e:22:f3:b7:08:90:ec:8f:7a:20:1a:ae:44: > 45:8c:db:2c:ee:20:d9:56:7a:8b:b9:d0:b9:0b:5b: > ac:7b:e0:f4:53:29:b4:06:cb:5e:fd:cf:87:b7:5d: > 9f:bb:e7:71:33:27:f8:b4:01:d5:78:75:5e:99:e1: > dc:7d:5b:12:78:12:d6:38:07:f5:73:3c:8e:9b:62: > d6:ae:30:f5:8f:31:7e:42:81:2d:10:b4:6a:2c:33: > 7c:48:db:95:9c:af:a9:ca:8b:92:c2:93:93:59:7a: > a0:a6:42:dd:72:e8:b8:21:d8:75:05:7a:8f:47:19: > ca:3d:ae:89:a6:d3:87:fc:2a:02:c4:49:58:28:05: > d5:d2:a9:fc:f5:06:40:1e:35:38:2e:33:f3:31:f2: > c9:a8:16:6e:b9:0a:42:95:6e:de:1f:f7:3e:2d:c8: > 34:64:00:77:d4:cf:5c:3d:28:78:ce:60:bd:e5:90: > 09:a9 > Exponent: 65537 (0x10001) > X509v3 extensions: > X509v3 Basic Constraints: critical > CA:TRUE > X509v3 Key Usage: critical > Certificate Sign, CRL Sign > X509v3 Subject Key Identifier: > A2:FF:95:62:C7:85:BC:1A:FE:D5:0B:F8:F7:A8:B1:B4:BF:29:8B:7D > Netscape Cert Type: > SSL CA > Netscape Comment: > example comment extension > Signature Algorithm: sha1WithRSAEncryption > 73:f4:61:1c:f1:b7:d3:c4:e2:ae:b1:ea:1e:3f:b2:6b:bc:f3: > 85:80:a1:0d:a8:06:7e:5a:bd:2b:fe:13:ce:4d:80:4d:c8:3d: > 4a:95:f9:ee:9c:19:1d:6b:b4:57:79:72:d9:00:e7:d1:be:9c: > c3:4f:2d:77:93:71:45:87:8f:99:bd:35:43:95:1b:69:31:71: > f9:f4:ee:00:1f:cd:f7:f4:2e:b1:ae:e7:9c:8e:cb:ce:86:50: > d8:1b:4e:3c:11:77:63:55:09:74:4c:89:ce:34:ae:4e:75:80: > e8:9e:37:23:75:e2:eb:bf:27:f8:dc:07:9d:64:b3:96:01:84: > 4a:62:23:c9:52:0f:92:e1:4a:3f:db:c7:b9:82:e9:8b:bb:89: > 7f:6c:fc:90:da:e1:2b:e9:8f:a3:d2:8c:66:22:5a:4e:27:77: > f9:88:0e:7c:87:45:c4:56:4b:c8:fa:93:7c:18:3a:d5:cd:a3: > 59:6e:e2:37:a6:45:57:e8:8f:1f:d6:65:b9:47:e4:5c:c0:83: > 80:63:ac:2d:1d:6a:0f:95:62:00:18:b0:66:4f:b7:76:5a:1f: > f6:7c:27:f7:86:3e:8d:fc:1c:b0:d9:7c:60:44:61:e9:eb:ff: > 95:b4:31:67:df:d1:ce:fc:91:3e:f3:64:fa:ca:c8:29:16:3b: > d4:ae:f4:0e > -----BEGIN CERTIFICATE----- > MIIDrjCCApagAwIBAgIBATANBgkqhkiG9w0BAQUFADBaMQ8wDQYDVQQKDAZWZXJp > bnQxCzAJBgNVBAYTAlVTMRYwFAYDVQQDDA0xOTIuMTY4LjEuMjAwMREwDwYDVQQH > DAhDb2x1bWJpYTEPMA0GA1UECwwGVmVyaW50MB4XDTIxMDcyMTIwNTExMloXDTIy > MDcyMTIwNTExMlowWjEPMA0GA1UECgwGVmVyaW50MQswCQYDVQQGEwJVUzEWMBQG > A1UEAwwNMTkyLjE2OC4xLjIwMDERMA8GA1UEBwwIQ29sdW1iaWExDzANBgNVBAsM > BlZlcmludDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALjovQgQ5Nkt > d1IzjBUwz4mg1L2VhRW6VDeNWxfkTT+j+wwI7n4w612T/dvzUYVgkWYE4bJV/VrP > wXw6O0wwr2e4LyF8QqSGjtOo6rKOIvO3CJDsj3ogGq5ERYzbLO4g2VZ6i7nQuQtb > rHvg9FMptAbLXv3Ph7ddn7vncTMn+LQB1Xh1Xpnh3H1bEngS1jgH9XM8jpti1q4w > 9Y8xfkKBLRC0aiwzfEjblZyvqcqLksKTk1l6oKZC3XLouCHYdQV6j0cZyj2uiabT > h/wqAsRJWCgF1dKp/PUGQB41OC4z8zHyyagWbrkKQpVu3h/3Pi3INGQAd9TPXD0o > eM5gveWQCakCAwEAAaN/MH0wDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMC > AQYwHQYDVR0OBBYEFKL/lWLHhbwa/tUL+PeosbS/KYt9MBEGCWCGSAGG+EIBAQQE > AwICBDAoBglghkgBhvhCAQ0EGxYZZXhhbXBsZSBjb21tZW50IGV4dGVuc2lvbjAN > BgkqhkiG9w0BAQUFAAOCAQEAc/RhHPG308TirrHqHj+ya7zzhYChDagGflq9K/4T > zk2ATcg9SpX57pwZHWu0V3ly2QDn0b6cw08td5NxRYePmb01Q5UbaTFx+fTuAB/N > 9/Qusa7nnI7LzoZQ2BtOPBF3Y1UJdEyJzjSuTnWA6J43I3Xi678n+NwHnWSzlgGE > SmIjyVIPkuFKP9vHuYLpi7uJf2z8kNrhK+mPo9KMZiJaTid3+YgOfIdFxFZLyPqT > fBg61c2jWW7iN6ZFV+iPH9ZluUfkXMCDgGOsLR1qD5ViABiwZk+3dlof9nwn94Y+ > jfwcsNl8YERh6ev/lbQxZ9/RzvyRPvNk+srIKRY71K70Dg== > -----END CERTIFICATE----- -- Viktor. From tprabhu1989 at gmail.com Wed Jul 21 23:22:29 2021 From: tprabhu1989 at gmail.com (Thejus Prabhu) Date: Wed, 21 Jul 2021 19:22:29 -0400 Subject: Question on "unsupported certificate purpose" error when trying to read the certificate on the web server In-Reply-To: References: Message-ID: Thanks for your reply Viktor. I would like to add that this is a self signed certificate created on the server. What is EE certificate? On Wed, Jul 21, 2021 at 6:55 PM Viktor Dukhovni wrote: > On Wed, Jul 21, 2021 at 06:34:03PM -0400, Thejus Prabhu wrote: > > > verify error:num=26:unsupported certificate purpose > > The certificate in question is CA certificate, not an EE certificate. > Specifically, the key usage and Netscape Cert Type signal that its > purpose is exclusively to be a CA, not a TLS server. > > X509v3 Key Usage: critical > Certificate Sign, CRL Sign > Netscape Cert Type: > SSL CA > > > Certificate: > > Data: > > Version: 3 (0x2) > > Serial Number: 1 (0x1) > > Signature Algorithm: sha1WithRSAEncryption > > Issuer: O = Verint, C = US, CN = 192.168.1.200, L = Columbia, > OU = Verint > > Validity > > Not Before: Jul 21 20:51:12 2021 GMT > > Not After : Jul 21 20:51:12 2022 GMT > > Subject: O = Verint, C = US, CN = 192.168.1.200, L = Columbia, > OU = Verint > > Subject Public Key Info: > > Public Key Algorithm: rsaEncryption > > RSA Public-Key: (2048 bit) > > Modulus: > > 00:b8:e8:bd:08:10:e4:d9:2d:77:52:33:8c:15:30: > > cf:89:a0:d4:bd:95:85:15:ba:54:37:8d:5b:17:e4: > > 4d:3f:a3:fb:0c:08:ee:7e:30:eb:5d:93:fd:db:f3: > > 51:85:60:91:66:04:e1:b2:55:fd:5a:cf:c1:7c:3a: > > 3b:4c:30:af:67:b8:2f:21:7c:42:a4:86:8e:d3:a8: > > ea:b2:8e:22:f3:b7:08:90:ec:8f:7a:20:1a:ae:44: > > 45:8c:db:2c:ee:20:d9:56:7a:8b:b9:d0:b9:0b:5b: > > ac:7b:e0:f4:53:29:b4:06:cb:5e:fd:cf:87:b7:5d: > > 9f:bb:e7:71:33:27:f8:b4:01:d5:78:75:5e:99:e1: > > dc:7d:5b:12:78:12:d6:38:07:f5:73:3c:8e:9b:62: > > d6:ae:30:f5:8f:31:7e:42:81:2d:10:b4:6a:2c:33: > > 7c:48:db:95:9c:af:a9:ca:8b:92:c2:93:93:59:7a: > > a0:a6:42:dd:72:e8:b8:21:d8:75:05:7a:8f:47:19: > > ca:3d:ae:89:a6:d3:87:fc:2a:02:c4:49:58:28:05: > > d5:d2:a9:fc:f5:06:40:1e:35:38:2e:33:f3:31:f2: > > c9:a8:16:6e:b9:0a:42:95:6e:de:1f:f7:3e:2d:c8: > > 34:64:00:77:d4:cf:5c:3d:28:78:ce:60:bd:e5:90: > > 09:a9 > > Exponent: 65537 (0x10001) > > X509v3 extensions: > > X509v3 Basic Constraints: critical > > CA:TRUE > > X509v3 Key Usage: critical > > Certificate Sign, CRL Sign > > X509v3 Subject Key Identifier: > > > A2:FF:95:62:C7:85:BC:1A:FE:D5:0B:F8:F7:A8:B1:B4:BF:29:8B:7D > > Netscape Cert Type: > > SSL CA > > Netscape Comment: > > example comment extension > > Signature Algorithm: sha1WithRSAEncryption > > 73:f4:61:1c:f1:b7:d3:c4:e2:ae:b1:ea:1e:3f:b2:6b:bc:f3: > > 85:80:a1:0d:a8:06:7e:5a:bd:2b:fe:13:ce:4d:80:4d:c8:3d: > > 4a:95:f9:ee:9c:19:1d:6b:b4:57:79:72:d9:00:e7:d1:be:9c: > > c3:4f:2d:77:93:71:45:87:8f:99:bd:35:43:95:1b:69:31:71: > > f9:f4:ee:00:1f:cd:f7:f4:2e:b1:ae:e7:9c:8e:cb:ce:86:50: > > d8:1b:4e:3c:11:77:63:55:09:74:4c:89:ce:34:ae:4e:75:80: > > e8:9e:37:23:75:e2:eb:bf:27:f8:dc:07:9d:64:b3:96:01:84: > > 4a:62:23:c9:52:0f:92:e1:4a:3f:db:c7:b9:82:e9:8b:bb:89: > > 7f:6c:fc:90:da:e1:2b:e9:8f:a3:d2:8c:66:22:5a:4e:27:77: > > f9:88:0e:7c:87:45:c4:56:4b:c8:fa:93:7c:18:3a:d5:cd:a3: > > 59:6e:e2:37:a6:45:57:e8:8f:1f:d6:65:b9:47:e4:5c:c0:83: > > 80:63:ac:2d:1d:6a:0f:95:62:00:18:b0:66:4f:b7:76:5a:1f: > > f6:7c:27:f7:86:3e:8d:fc:1c:b0:d9:7c:60:44:61:e9:eb:ff: > > 95:b4:31:67:df:d1:ce:fc:91:3e:f3:64:fa:ca:c8:29:16:3b: > > d4:ae:f4:0e > > -----BEGIN CERTIFICATE----- > > MIIDrjCCApagAwIBAgIBATANBgkqhkiG9w0BAQUFADBaMQ8wDQYDVQQKDAZWZXJp > > bnQxCzAJBgNVBAYTAlVTMRYwFAYDVQQDDA0xOTIuMTY4LjEuMjAwMREwDwYDVQQH > > DAhDb2x1bWJpYTEPMA0GA1UECwwGVmVyaW50MB4XDTIxMDcyMTIwNTExMloXDTIy > > MDcyMTIwNTExMlowWjEPMA0GA1UECgwGVmVyaW50MQswCQYDVQQGEwJVUzEWMBQG > > A1UEAwwNMTkyLjE2OC4xLjIwMDERMA8GA1UEBwwIQ29sdW1iaWExDzANBgNVBAsM > > BlZlcmludDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALjovQgQ5Nkt > > d1IzjBUwz4mg1L2VhRW6VDeNWxfkTT+j+wwI7n4w612T/dvzUYVgkWYE4bJV/VrP > > wXw6O0wwr2e4LyF8QqSGjtOo6rKOIvO3CJDsj3ogGq5ERYzbLO4g2VZ6i7nQuQtb > > rHvg9FMptAbLXv3Ph7ddn7vncTMn+LQB1Xh1Xpnh3H1bEngS1jgH9XM8jpti1q4w > > 9Y8xfkKBLRC0aiwzfEjblZyvqcqLksKTk1l6oKZC3XLouCHYdQV6j0cZyj2uiabT > > h/wqAsRJWCgF1dKp/PUGQB41OC4z8zHyyagWbrkKQpVu3h/3Pi3INGQAd9TPXD0o > > eM5gveWQCakCAwEAAaN/MH0wDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMC > > AQYwHQYDVR0OBBYEFKL/lWLHhbwa/tUL+PeosbS/KYt9MBEGCWCGSAGG+EIBAQQE > > AwICBDAoBglghkgBhvhCAQ0EGxYZZXhhbXBsZSBjb21tZW50IGV4dGVuc2lvbjAN > > BgkqhkiG9w0BAQUFAAOCAQEAc/RhHPG308TirrHqHj+ya7zzhYChDagGflq9K/4T > > zk2ATcg9SpX57pwZHWu0V3ly2QDn0b6cw08td5NxRYePmb01Q5UbaTFx+fTuAB/N > > 9/Qusa7nnI7LzoZQ2BtOPBF3Y1UJdEyJzjSuTnWA6J43I3Xi678n+NwHnWSzlgGE > > SmIjyVIPkuFKP9vHuYLpi7uJf2z8kNrhK+mPo9KMZiJaTid3+YgOfIdFxFZLyPqT > > fBg61c2jWW7iN6ZFV+iPH9ZluUfkXMCDgGOsLR1qD5ViABiwZk+3dlof9nwn94Y+ > > jfwcsNl8YERh6ev/lbQxZ9/RzvyRPvNk+srIKRY71K70Dg== > > -----END CERTIFICATE----- > > -- > Viktor. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aerowolf at gmail.com Thu Jul 22 00:02:17 2021 From: aerowolf at gmail.com (Kyle Hamilton) Date: Wed, 21 Jul 2021 19:02:17 -0500 Subject: Question on "unsupported certificate purpose" error when trying to read the certificate on the web server In-Reply-To: References: Message-ID: An EE certificate is an "end entity" certificate, which identifies an entity that isn't a certifier. On Wed, Jul 21, 2021, 18:23 Thejus Prabhu wrote: > Thanks for your reply Viktor. I would like to add that this is a self > signed certificate created on the server. What is EE certificate? > > > On Wed, Jul 21, 2021 at 6:55 PM Viktor Dukhovni < > openssl-users at dukhovni.org> wrote: > >> On Wed, Jul 21, 2021 at 06:34:03PM -0400, Thejus Prabhu wrote: >> >> > verify error:num=26:unsupported certificate purpose >> >> The certificate in question is CA certificate, not an EE certificate. >> Specifically, the key usage and Netscape Cert Type signal that its >> purpose is exclusively to be a CA, not a TLS server. >> >> X509v3 Key Usage: critical >> Certificate Sign, CRL Sign >> Netscape Cert Type: >> SSL CA >> >> > Certificate: >> > Data: >> > Version: 3 (0x2) >> > Serial Number: 1 (0x1) >> > Signature Algorithm: sha1WithRSAEncryption >> > Issuer: O = Verint, C = US, CN = 192.168.1.200, L = Columbia, >> OU = Verint >> > Validity >> > Not Before: Jul 21 20:51:12 2021 GMT >> > Not After : Jul 21 20:51:12 2022 GMT >> > Subject: O = Verint, C = US, CN = 192.168.1.200, L = >> Columbia, OU = Verint >> > Subject Public Key Info: >> > Public Key Algorithm: rsaEncryption >> > RSA Public-Key: (2048 bit) >> > Modulus: >> > 00:b8:e8:bd:08:10:e4:d9:2d:77:52:33:8c:15:30: >> > cf:89:a0:d4:bd:95:85:15:ba:54:37:8d:5b:17:e4: >> > 4d:3f:a3:fb:0c:08:ee:7e:30:eb:5d:93:fd:db:f3: >> > 51:85:60:91:66:04:e1:b2:55:fd:5a:cf:c1:7c:3a: >> > 3b:4c:30:af:67:b8:2f:21:7c:42:a4:86:8e:d3:a8: >> > ea:b2:8e:22:f3:b7:08:90:ec:8f:7a:20:1a:ae:44: >> > 45:8c:db:2c:ee:20:d9:56:7a:8b:b9:d0:b9:0b:5b: >> > ac:7b:e0:f4:53:29:b4:06:cb:5e:fd:cf:87:b7:5d: >> > 9f:bb:e7:71:33:27:f8:b4:01:d5:78:75:5e:99:e1: >> > dc:7d:5b:12:78:12:d6:38:07:f5:73:3c:8e:9b:62: >> > d6:ae:30:f5:8f:31:7e:42:81:2d:10:b4:6a:2c:33: >> > 7c:48:db:95:9c:af:a9:ca:8b:92:c2:93:93:59:7a: >> > a0:a6:42:dd:72:e8:b8:21:d8:75:05:7a:8f:47:19: >> > ca:3d:ae:89:a6:d3:87:fc:2a:02:c4:49:58:28:05: >> > d5:d2:a9:fc:f5:06:40:1e:35:38:2e:33:f3:31:f2: >> > c9:a8:16:6e:b9:0a:42:95:6e:de:1f:f7:3e:2d:c8: >> > 34:64:00:77:d4:cf:5c:3d:28:78:ce:60:bd:e5:90: >> > 09:a9 >> > Exponent: 65537 (0x10001) >> > X509v3 extensions: >> > X509v3 Basic Constraints: critical >> > CA:TRUE >> > X509v3 Key Usage: critical >> > Certificate Sign, CRL Sign >> > X509v3 Subject Key Identifier: >> > >> A2:FF:95:62:C7:85:BC:1A:FE:D5:0B:F8:F7:A8:B1:B4:BF:29:8B:7D >> > Netscape Cert Type: >> > SSL CA >> > Netscape Comment: >> > example comment extension >> > Signature Algorithm: sha1WithRSAEncryption >> > 73:f4:61:1c:f1:b7:d3:c4:e2:ae:b1:ea:1e:3f:b2:6b:bc:f3: >> > 85:80:a1:0d:a8:06:7e:5a:bd:2b:fe:13:ce:4d:80:4d:c8:3d: >> > 4a:95:f9:ee:9c:19:1d:6b:b4:57:79:72:d9:00:e7:d1:be:9c: >> > c3:4f:2d:77:93:71:45:87:8f:99:bd:35:43:95:1b:69:31:71: >> > f9:f4:ee:00:1f:cd:f7:f4:2e:b1:ae:e7:9c:8e:cb:ce:86:50: >> > d8:1b:4e:3c:11:77:63:55:09:74:4c:89:ce:34:ae:4e:75:80: >> > e8:9e:37:23:75:e2:eb:bf:27:f8:dc:07:9d:64:b3:96:01:84: >> > 4a:62:23:c9:52:0f:92:e1:4a:3f:db:c7:b9:82:e9:8b:bb:89: >> > 7f:6c:fc:90:da:e1:2b:e9:8f:a3:d2:8c:66:22:5a:4e:27:77: >> > f9:88:0e:7c:87:45:c4:56:4b:c8:fa:93:7c:18:3a:d5:cd:a3: >> > 59:6e:e2:37:a6:45:57:e8:8f:1f:d6:65:b9:47:e4:5c:c0:83: >> > 80:63:ac:2d:1d:6a:0f:95:62:00:18:b0:66:4f:b7:76:5a:1f: >> > f6:7c:27:f7:86:3e:8d:fc:1c:b0:d9:7c:60:44:61:e9:eb:ff: >> > 95:b4:31:67:df:d1:ce:fc:91:3e:f3:64:fa:ca:c8:29:16:3b: >> > d4:ae:f4:0e >> > -----BEGIN CERTIFICATE----- >> > MIIDrjCCApagAwIBAgIBATANBgkqhkiG9w0BAQUFADBaMQ8wDQYDVQQKDAZWZXJp >> > bnQxCzAJBgNVBAYTAlVTMRYwFAYDVQQDDA0xOTIuMTY4LjEuMjAwMREwDwYDVQQH >> > DAhDb2x1bWJpYTEPMA0GA1UECwwGVmVyaW50MB4XDTIxMDcyMTIwNTExMloXDTIy >> > MDcyMTIwNTExMlowWjEPMA0GA1UECgwGVmVyaW50MQswCQYDVQQGEwJVUzEWMBQG >> > A1UEAwwNMTkyLjE2OC4xLjIwMDERMA8GA1UEBwwIQ29sdW1iaWExDzANBgNVBAsM >> > BlZlcmludDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALjovQgQ5Nkt >> > d1IzjBUwz4mg1L2VhRW6VDeNWxfkTT+j+wwI7n4w612T/dvzUYVgkWYE4bJV/VrP >> > wXw6O0wwr2e4LyF8QqSGjtOo6rKOIvO3CJDsj3ogGq5ERYzbLO4g2VZ6i7nQuQtb >> > rHvg9FMptAbLXv3Ph7ddn7vncTMn+LQB1Xh1Xpnh3H1bEngS1jgH9XM8jpti1q4w >> > 9Y8xfkKBLRC0aiwzfEjblZyvqcqLksKTk1l6oKZC3XLouCHYdQV6j0cZyj2uiabT >> > h/wqAsRJWCgF1dKp/PUGQB41OC4z8zHyyagWbrkKQpVu3h/3Pi3INGQAd9TPXD0o >> > eM5gveWQCakCAwEAAaN/MH0wDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMC >> > AQYwHQYDVR0OBBYEFKL/lWLHhbwa/tUL+PeosbS/KYt9MBEGCWCGSAGG+EIBAQQE >> > AwICBDAoBglghkgBhvhCAQ0EGxYZZXhhbXBsZSBjb21tZW50IGV4dGVuc2lvbjAN >> > BgkqhkiG9w0BAQUFAAOCAQEAc/RhHPG308TirrHqHj+ya7zzhYChDagGflq9K/4T >> > zk2ATcg9SpX57pwZHWu0V3ly2QDn0b6cw08td5NxRYePmb01Q5UbaTFx+fTuAB/N >> > 9/Qusa7nnI7LzoZQ2BtOPBF3Y1UJdEyJzjSuTnWA6J43I3Xi678n+NwHnWSzlgGE >> > SmIjyVIPkuFKP9vHuYLpi7uJf2z8kNrhK+mPo9KMZiJaTid3+YgOfIdFxFZLyPqT >> > fBg61c2jWW7iN6ZFV+iPH9ZluUfkXMCDgGOsLR1qD5ViABiwZk+3dlof9nwn94Y+ >> > jfwcsNl8YERh6ev/lbQxZ9/RzvyRPvNk+srIKRY71K70Dg== >> > -----END CERTIFICATE----- >> >> -- >> Viktor. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philipp_subx at redfish-solutions.com Fri Jul 23 00:55:16 2021 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Thu, 22 Jul 2021 18:55:16 -0600 Subject: [openssl-users] Verifying Android hardware attestation certificates with OpenSSL In-Reply-To: References: Message-ID: Did you ever get to the root of this? -Philip > On Oct 30, 2018, at 5:52 PM, Pietu Pohjalainen wrote: > > Dear all, > > I have been trying to verify hardware attestation certificates originating from different Android phones with the OpenSSL tool. There seems to be not too much information about how are these supposed to work. With OpenSSL I'm getting mixed results. > > Android developer spec for certificate extension data schema is available at > https://developer.android.com/training/articles/security-key-attestation and is linking to a few years old Java code example at https://github.com/googlesamples/android-key-attestation . Unfortunately this Java code has not been updated to match later versions of key attestation, and it fails with many of my real world use cases. > > The OpenSSL command shipping with Mac OS 10.13 (LibreSSL 2.2.7) fails even to parse these certificates. > > OpenSSL 1.1.0g shipping with Ubuntu parses all of my example certificates just fine. However, trying to verify certificate chains sometime succeeds, sometime fails. ver 1.1.2-dev follows the same pattern. > > So far, I have figured out the following patterns: > - Certificate chain extracted from a real world device is either 3 or 4 certificates. > - When the chain is 4 certificates, the last one is equal to Google's root certificate found in the Java code example https://github.com/googlesamples/android-key-attestation/blob/master/server/src/main/java/com/android/example/KeyAttestationExample.java > - When the chain is 3 certificates, the middle and last certificates are always the same. > > - Out of these 8 real world chains, I'm having > * 3 cases where OpenSSL verifies the chain just nice - branches a, g and h in the upcoming transcript. > * 1 case where OpenSSL gives error > error 20 at 0 depth lookup: unable to get local issuer certificate > error f1.pem: verification failed > 139747492622784:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long:crypto/asn1/asn1_lib.c:101: > 139747492622784:error:0D068066:asn1 encoding routines:asn1_check_tlen:bad object header:crypto/asn1/tasn_dec.c:1118: > 139747492622784:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:553: > * 4 cases where OpenSSL gives error > error 20 at 0 depth lookup: unable to get local issuer certificate > error e1.pem: verification failed > > The hardware devices are in somewhat random order, as follows: > a: Nokia 8 running Android 8.1 > b: Motorola Moto Z running Android 7.1.1 > c: Nokia 1 running Android 8.1 > d: Nokia 2 running Android 7.1.1 > e: Sony Oneplus A5000 running Android 7.1.1 > f: Huawei Honor 8 running Android 7.0 > g: Nokia 5.1 running Android 8.0 > h: OnePlus 3T running Android 8.0 > > > Due to other OpenSSL implementations failing to even parse these certificates, I'm now in doubt is it my wrong usage pattern, certificates that are really faulty, or is this a bug with OpenSSL. > > > br, > Pietu > > --- clip --- > > Here's my full set of files and commands tried: > $ /usr/local/bin/openssl version > OpenSSL 1.1.2-dev xx XXX xxxx > > $ md5sum a2.pem b2.pem d2.pem e2.pem f2.pem h2.pem > 2575f8bb229a2c5bc02260dbc8af5575 a2.pem > 2575f8bb229a2c5bc02260dbc8af5575 b2.pem > 2575f8bb229a2c5bc02260dbc8af5575 d2.pem > 2575f8bb229a2c5bc02260dbc8af5575 e2.pem > 2575f8bb229a2c5bc02260dbc8af5575 f2.pem > 2575f8bb229a2c5bc02260dbc8af5575 h2.pem > > $ md5sum a3.pem b3.pem d3.pem e3.pem f3.pem h3.pem > 0ec1822cb22ea66f96fc459633dfee78 a3.pem > 0ec1822cb22ea66f96fc459633dfee78 b3.pem > 0ec1822cb22ea66f96fc459633dfee78 d3.pem > 0ec1822cb22ea66f96fc459633dfee78 e3.pem > 0ec1822cb22ea66f96fc459633dfee78 f3.pem > 0ec1822cb22ea66f96fc459633dfee78 h3.pem > > $ # Test out chains with 3 certificates - a and h verify fine. > $ for branch in a; do echo; echo "Checking $branch"; cat "$branch"1.pem "$branch"2.pem "$branch"3.pem; /usr/local/bin/openssl verify -CAfile <(cat "$branch"2.pem "$branch"3.pem) "$branch"1.pem; echo; done > > Checking a > -----BEGIN CERTIFICATE----- > MIICgDCCAiagAwIBAgIBATAKBggqhkjOPQQDAjCBiDELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWExFTATBgNVBAoMDEdvb2dsZSwgSW5jLjEQMA4GA1UECwwHQW5kcm9pZDE7MDkGA1UEAwwyQW5kcm9pZCBLZXlzdG9yZSBTb2Z0d2FyZSBBdHRlc3RhdGlvbiBJbnRlcm1lZGlhdGUwIBcNNzAwMTAxMDAwMDAwWhgPMjEwNjAyMDcwNjI4MTVaMB8xHTAbBgNVBAMMFEFuZHJvaWQgS2V5c3RvcmUgS2V5MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEDRgbsaYD1OPI5P78IVIJsgQlAIDKIoGl7BAbuV4tkx0Km3tfcoMAwfWL1exnBoAxuw2ZHUhlNUhWE8kyAW7bsaOB5jCB4zALBgNVHQ8EBAMCB4AwgbIGCisGAQQB1nkCAREEgaMwgaACAQIKAQACAQEKAQEEC2hlbGxvIHdvcmxkBAAwSr+FPQgCBgFmrBioCL+FRToEODA2MRAwDgQJY29tLnB5eXBsAgEMMSIEIIMi9g2//U87C53x3twp61y6K1+22oaTkEjGgyTgXw37MDehBTEDAgECogMCAQOjBAICAQClCzEJAgEEAgEFAgEGqgMCAQG/g3cCBQC/hT4DAgEAv4U/AgUAMB8GA1UdIwQYMBaAFD/8rNYasTqegSC41SUcxWW7HpGpMAoGCCqGSM49BAMCA0gAMEUCIQC+ty2c6G69zydlw3mhdTV0C+IMN45WIxC4K4kpvQIT2wIgBE48WjBNlRTH3RWURiL1oIriLcfTlN7sKeMVkeH1PCU= > -----END CERTIFICATE----- > > -----BEGIN CERTIFICATE----- > MIICeDCCAh6gAwIBAgICEAEwCgYIKoZIzj0EAwIwgZgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQHDA1Nb3VudGFpbiBWaWV3MRUwEwYDVQQKDAxHb29nbGUsIEluYy4xEDAOBgNVBAsMB0FuZHJvaWQxMzAxBgNVBAMMKkFuZHJvaWQgS2V5c3RvcmUgU29mdHdhcmUgQXR0ZXN0YXRpb24gUm9vdDAeFw0xNjAxMTEwMDQ2MDlaFw0yNjAxMDgwMDQ2MDlaMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEVMBMGA1UECgwMR29vZ2xlLCBJbmMuMRAwDgYDVQQLDAdBbmRyb2lkMTswOQYDVQQDDDJBbmRyb2lkIEtleXN0b3JlIFNvZnR3YXJlIEF0dGVzdGF0aW9uIEludGVybWVkaWF0ZTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABOueefhCY1msyyqRTImGzHCtkGaTgqlzJhP+rMv4ISdMIXSXSir+pblNf2bU4GUQZjW8U7ego6ZxWD7bPhGuEBSjZjBkMB0GA1UdDgQWBBQ//KzWGrE6noEguNUlHMVlux6RqTAfBgNVHSMEGDAWgBTIrel3TEXDo88NFhDkeUM6IVowzzASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIChDAKBggqhkjOPQQDAgNIADBFAiBLipt77oK8wDOHri/AiZi03cONqycqRZ9pDMfDktQPjgIhAO7aAV229DLp1IQ7YkyUBO86fMy9Xvsiu+f+uXc/WT/7 > -----END CERTIFICATE----- > > -----BEGIN CERTIFICATE----- > MIICizCCAjKgAwIBAgIJAKIFntEOQ1tXMAoGCCqGSM49BAMCMIGYMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNTW91bnRhaW4gVmlldzEVMBMGA1UECgwMR29vZ2xlLCBJbmMuMRAwDgYDVQQLDAdBbmRyb2lkMTMwMQYDVQQDDCpBbmRyb2lkIEtleXN0b3JlIFNvZnR3YXJlIEF0dGVzdGF0aW9uIFJvb3QwHhcNMTYwMTExMDA0MzUwWhcNMzYwMTA2MDA0MzUwWjCBmDELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcxFTATBgNVBAoMDEdvb2dsZSwgSW5jLjEQMA4GA1UECwwHQW5kcm9pZDEzMDEGA1UEAwwqQW5kcm9pZCBLZXlzdG9yZSBTb2Z0d2FyZSBBdHRlc3RhdGlvbiBSb290MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE7l1ex+HA220Dpn7mthvsTWpdamguD/9/SQ59dx9EIm29sa/6FsvHrcV30lacqrewLVQBXT5DKyqO107sSHVBpKNjMGEwHQYDVR0OBBYEFMit6XdMRcOjzw0WEOR5QzohWjDPMB8GA1UdIwQYMBaAFMit6XdMRcOjzw0WEOR5QzohWjDPMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgKEMAoGCCqGSM49BAMCA0cAMEQCIDUho++LNEYenNVg8x1YiSBq3KNlQfYNns6KGYxmSGB7AiBNC/NR2TB8fVvaNTQdqEcbY6WFZTytTySn502vQX3xvw== > -----END CERTIFICATE----- > > a1.pem: OK > > > $ #for keeping msg length in moderation, not duplicating root and intermediate certificates > $ for branch in b d e f h; do echo; echo "Checking $branch"1.pem; cat "$branch"1.pem; /usr/local/bin/openssl verify -CAfile <(cat "$branch"2.pem "$branch"3.pem) "$branch"1.pem; echo; done > > Checking b1.pem > -----BEGIN CERTIFICATE----- > MIIBzTCCAXOgAwIBAgIBATAKBggqhkjOPQQDAjAcMRowGAYDVQQDDBFBbmRyb2lkIEtleW1hc3RlcjAgFw03MDAxMDEwMDAwMDBaGA8yMTA2MDIwNzA2MjgxNVowGjEYMBYGA1UEAwwPQSBLZXltYXN0ZXIgS2V5MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEuvoG6Aobkj6eP+Q4bCf7vIY2hLvsQ9rRKG0mdD1YDPoE7lnth4ekSa+lhlMnieHrsH2pnGLZxP4jZoSk3GQdJaOBpTCBojALBgNVHQ8EBAMCB4AwcgYKKwYBBAHWeQIBEQRkMGICAQEKAQACAQEKAQEEC2hlbGxvIHdvcmxkBAAwDL+FPQgCBgFmrHjFgDA3oQUxAwIBAqIDAgEDowQCAgEApQsxCQIBBAIBBQIBBqoDAgEBv4N3AgUAv4U+AwIBAL+FPwIFADAfBgNVHSMEGDAWgBQ//KzWGrE6noEguNUlHMVlux6RqTAKBggqhkjOPQQDAgNIADBFAiEA+atKJFXAli8iI4u42gP+dRCarhtXYTPvSx4gBUoGWEsCIGdA9chHpZmRaNYr+oODruhF+Q1xIyLJYX+pq2q6wHvl > -----END CERTIFICATE----- > > CN = A Keymaster Key > error 20 at 0 depth lookup: unable to get local issuer certificate > error b1.pem: verification failed > > > Checking d1.pem > -----BEGIN CERTIFICATE----- > MIIB1zCCAX2gAwIBAgIBATAKBggqhkjOPQQDAjAcMRowGAYDVQQDDBFBbmRyb2lkIEtleW1hc3RlcjAeFw03MDAxMDEwMDAwMDBaFw02OTEyMzEyMzU5NTlaMBoxGDAWBgNVBAMMD0EgS2V5bWFzdGVyIEtleTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABD2A/WLrFMSEGX3XdgKDlxcTAstZnlXgJRZsLC+Z55JR80UYfNgV7EfN3arpKMuJ3fFJ/cYEoACTLHjinhmXVFijgbEwga4wCwYDVR0PBAQDAgeAMH4GCisGAQQB1nkCAREEcDBuAgEBCgEAAgECCgEABAtoZWxsbyB3b3JsZAQAME+hBTEDAgECogMCAQOjBAICAQClCzEJAgEEAgEFAgEGqgMCAQG/g3cCBQC/hT0IAgYBZq9Wdbi/hT4DAgEAv4VBBQIDARHVv4VCBQIDAxRPMAAwHwYDVR0jBBgwFoAUP/ys1hqxOp6BILjVJRzFZbsekakwCgYIKoZIzj0EAwIDSAAwRQIhAObHcoPKw6ntrXr+EC7HmGJO9heDbSuFMjO9sbcOw6rYAiBXtqcI6p0VCDN+jPtztLYtxeqkCnZYDve8MTkrReNSJQ== > -----END CERTIFICATE----- > > CN = A Keymaster Key > error 20 at 0 depth lookup: unable to get local issuer certificate > error d1.pem: verification failed > > > Checking e1.pem > -----BEGIN CERTIFICATE----- > MIIBzTCCAXOgAwIBAgIBATAKBggqhkjOPQQDAjAcMRowGAYDVQQDDBFBbmRyb2lkIEtleW1hc3RlcjAgFw03MDAxMDEwMDAwMDBaGA8yMTA2MDIwNzA2MjgxNVowGjEYMBYGA1UEAwwPQSBLZXltYXN0ZXIgS2V5MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE+KjC/Y5eImDnRgreH+fZeXj9r4725cHz3T8p7wCyWJKajku2c8khAJepG4fUEqHwiggPj7V5IWhaxzi29g7U1aOBpTCBojALBgNVHQ8EBAMCB4AwcgYKKwYBBAHWeQIBEQRkMGICAQEKAQACAQEKAQEEC2hlbGxvIHdvcmxkBAAwDL+FPQgCBgFmr+53yDA3oQUxAwIBAqIDAgEDowQCAgEApQsxCQIBBAIBBQIBBqoDAgEBv4N3AgUAv4U+AwIBAL+FPwIFADAfBgNVHSMEGDAWgBQ//KzWGrE6noEguNUlHMVlux6RqTAKBggqhkjOPQQDAgNIADBFAiEAmm+LNCeZRpBBHUxXGVU9VC/fxEwoLfbC3x7UNCd3ra4CIAW9JO5u6msXwvix4QD0OSBrdrzUCzuS9ItwfjZv+mB3 > -----END CERTIFICATE----- > > CN = A Keymaster Key > error 20 at 0 depth lookup: unable to get local issuer certificate > error e1.pem: verification failed > > > Checking f1.pem > -----BEGIN CERTIFICATE----- > MIIB/TCCAaSgAwIBAgIBATAKBggqhkjOPQQDAjAdMRswGQYDVQQDExJBbmRyb2lkIEtleW1hc3RlcjIwHhcNNzAwMTAxMDAwMDAwWhcNMDYwMjA3MDYyODE1WjAaMRgwFgYDVQQDEw9BIEtleW1hc3RlciBLZXkwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASiqHWB8dQg1/Fw67gZvYqIq2WZvbWFll4W5y2uz0UymS34g0FMGkwsJqAlnCquVFraoiaJH35x+jPrGqmdXy6Mo4HXMIHUMAsGA1UdDwQEAwIHgDAIBgNVHR8EAQAwgboGCisGAQQB1nkCAREEgaswgagCAQEKAQECAQIKAQEEC2hlbGxvIHdvcmxkBAAwJL+DdwIFAL+FPQgCBgFmxPuCBb+FQQUCAwERcL+FQgUCAwMUUDBloQUxAwIBAqIDAgEDowQCAgEApQUxAwIBBKoDAgEBv4U+AwIBAL+FQCowKAQgU0HmsmRpeacOV2UwB6HzEBaUIeyb3Z8aVkj3Wt4AWvEBAf8KAQC/hUEFAgMBEXC/hUIFAgMDFFAwCgYIKoZIzj0EAwIDRwAwRAIgEH9o6neMfv7o6ixwUkL4t7r5uS9FbMGAS9Pt9St9qecCICKhqBjZBisaGDSqE3Qo2vFUpvtB03tDHqlzScWXbry1 > -----END CERTIFICATE----- > > > CN = A Keymaster Key > error 20 at 0 depth lookup: unable to get local issuer certificate > error f1.pem: verification failed > 140121898299840:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long:crypto/asn1/asn1_lib.c:101: > 140121898299840:error:0D068066:asn1 encoding routines:asn1_check_tlen:bad object header:crypto/asn1/tasn_dec.c:1118: > 140121898299840:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:553: > > > Checking h1.pem > -----BEGIN CERTIFICATE----- > MIICgDCCAiagAwIBAgIBATAKBggqhkjOPQQDAjCBiDELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWExFTATBgNVBAoMDEdvb2dsZSwgSW5jLjEQMA4GA1UECwwHQW5kcm9pZDE7MDkGA1UEAwwyQW5kcm9pZCBLZXlzdG9yZSBTb2Z0d2FyZSBBdHRlc3RhdGlvbiBJbnRlcm1lZGlhdGUwIBcNNzAwMTAxMDAwMDAwWhgPMjEwNjAyMDcwNjI4MTVaMB8xHTAbBgNVBAMMFEFuZHJvaWQgS2V5c3RvcmUgS2V5MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE99dbLWDWw+j/h1MO8Sap27sC+wnjS3w4I2FIea+Tw8AzjCnG3F9tqNwPEDP1Y/NILB0TqgLQ8sKwxXrxXR7yW6OB5jCB4zALBgNVHQ8EBAMCB4AwgbIGCisGAQQB1nkCAREEgaMwgaACAQIKAQACAQEKAQEEC2hlbGxvIHdvcmxkBAAwSr+FPQgCBgFmxQWrGL+FRToEODA2MRAwDgQJY29tLnB5eXBsAgEMMSIEIIMi9g2//U87C53x3twp61y6K1+22oaTkEjGgyTgXw37MDehBTEDAgECogMCAQOjBAICAQClCzEJAgEEAgEFAgEGqgMCAQG/g3cCBQC/hT4DAgEAv4U/AgUAMB8GA1UdIwQYMBaAFD/8rNYasTqegSC41SUcxWW7HpGpMAoGCCqGSM49BAMCA0gAMEUCIDyO1O3bN1RqAPlmEku6Bm64EZVsnXP2AUqABbh5uZQmAiEApb4XgXemFO2By1Uk/2YSTmZY8wKUAf4ZsWCc6+fxiio= > -----END CERTIFICATE----- > > h1.pem: OK > > > # Test out chains with 4 certificates - g verifies fine. > $ for branch in c g; do echo; echo "Checking $branch"; cat "$branch"1.pem "$branch"2.pem "$branch"3.pem "$branch"4.pem; /usr/local/bin/openssl verify -CAfile <(cat "$branch"2.pem "$branch"3.pem "$branch"4.pem) "$branch"1.pem; echo; done > > Checking c > -----BEGIN CERTIFICATE----- > MIICUTCCAfagAwIBAgIBATAKBggqhkjOPQQDAjAbMRkwFwYDVQQFExA5NWU3MzI4NzZiNjUxNjhkMCIYDzE5MDAwMTAwMDAwMDAwWhgPMTkwMDAxMDAwMDAwMDBaMB8xHTAbBgNVBAMMFEFuZHJvaWQgS2V5c3RvcmUgS2V5MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE7Sd6FaAz8BONTGJvtGw5AIaiLhGH4ILfaD9OKzLYjfjB/nTcW6ti+CjSMtaROpXzbuYh6IgCGlD089gPnP5+BaOCASEwggEdMAsGA1UdDwQEAwIHgDCB7AYKKwYBBAHWeQIBEQSB3TCB2gIBAgoBAQIBAwoBAQQLaGVsbG8gd29ybGQEADBKv4U9CAIGAWasjANIv4VFOgQ4MDYxEDAOBAljb20ucHl5cGwCAQwxIgQggyL2Db/9TzsLnfHe3CnrXLorX7bahpOQSMaDJOBfDfswcaEFMQMCAQKiAwIBA6MEAgIBAKULMQkCAQQCAQUCAQaqAwIBAb+DdwIFAL+FPgMCAQC/hUAqMCgEIE15D6Cl/oHWs1K5Cv5DBoTZvIF1GM0kxQ5jQzlffFHyAQEBCgEAv4VBBQIDATjkv4VCBQIDAxRQMB8GA1UdIwQYMBaAFBuQe659NNU7MawBkucw39T1flt2MAoGCCqGSM49BAMCA0kAMEYCIQC14bLPGSNXwYUrFzO3Xno7WLHCy1wFtcP+mXCnVlvCngIhAMX60lRiVTvfl2Bq09opnfb3Y7QgE0DViuhheQyNSvL4 > -----END CERTIFICATE----- > > -----BEGIN CERTIFICATE----- > MIICKzCCAbKgAwIBAgIKFhlXZkYXJGEUNDAKBggqhkjOPQQDAjAbMRkwFwYDVQQFExA1YjAzNTljY2E4ODc5Y2I1MB4XDTE2MDUyNjE2NTQxNloXDTI2MDUyNDE2NTQxNlowGzEZMBcGA1UEBRMQOTVlNzMyODc2YjY1MTY4ZDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJoEzxn1L0hLklubtqi8kvk9KEJf4nu8UB7EfcHn5zGbONW9HGgwBlq5X5llRvmNUToPcgbI3sHOvFoHky5nrgyjgd0wgdowHQYDVR0OBBYEFBuQe659NNU7MawBkucw39T1flt2MB8GA1UdIwQYMBaAFAbd7gqSHZtx4caJQUTvOTlwJgA1MAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgeAMCQGA1UdHgQdMBugGTAXghVpbnZhbGlkO2VtYWlsOmludmFsaWQwVAYDVR0fBE0wSzBJoEegRYZDaHR0cHM6Ly9hbmRyb2lkLmdvb2dsZWFwaXMuY29tL2F0dGVzdGF0aW9uL2NybC8xNjE5NTc2NjQ2MTcyNDYxMTQzNDAKBggqhkjOPQQDAgNnADBkAjAMeVZ84Z55FM2+nOrljCQlb7xpdiYDTc96LQyh8OE6EZj8jkQQL9Lh3MT5p5lZ+QsCMGLwHkdPAeD1M8PYEJRyurfC4EYV1k3zJowZbRmYu3N8ztCb3FBgE+1oJpxEPNXIGQ== > -----END CERTIFICATE----- > > -----BEGIN CERTIFICATE----- > MIIDwzCCAaugAwIBAgIKA4gmZ2BliZaFczANBgkqhkiG9w0BAQsFADAbMRkwFwYDVQQFExBmOTIwMDllODUzYjZiMDQ1MB4XDTE2MDUyNjE2NDEyOVoXDTI2MDUyNDE2NDEyOVowGzEZMBcGA1UEBRMQNWIwMzU5Y2NhODg3OWNiNTB2MBAGByqGSM49AgEGBSuBBAAiA2IABHf4FUKTZivDuwdyVbXyPF12IRuDzZKq61MbqooE3/gx9gIS9pFS4NZgGTnjSMm6ltYrCv3sDzuPQls+V+BLPQgNfRHavmP9eulc1uR3GNgCnKqxB2o0QcTQGPAxJA81c6OBtjCBszAdBgNVHQ4EFgQUBt3uCpIdm3HhxolBRO85OXAmADUwHwYDVR0jBBgwFoAUNmHhAHyIBQlRi0RsR/8aTMnqTxIwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAYYwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cHM6Ly9hbmRyb2lkLmdvb2dsZWFwaXMuY29tL2F0dGVzdGF0aW9uL2NybC9FOEZBMTk2MzE0RDJGQTE4MA0GCSqGSIb3DQEBCwUAA4ICAQAsPFNbAeVGRXKg0H1Ixy31n+vc1GAtLTtdruQGZ3rk6Dq3G5OiNfwLI4vRowDERgTr5RoVRMLs9HzTTCvvdEBhcILKOnaPAd6Jg4HvBi8hsfbXEvRi2kmIfiYAabC71ErJLFEMprTJMSDEOe3lXCJG409z99ofsf/s1M1i77NFVCwstAvRLMjc9TjxRXrGrGD0rMdG2RkionXa3H+4cYqSUf7JCIW6dMB2p+4R3n463DqxxSJNGbchGGUbL6b0qIWdaVcwG2ro+WyItfyw5C4h9XSosauyC9ajjZLt8RAK2ouZHN/kyIXcD1U7IFbSy0SZfaRDLNCzse4iL6IOnuyITEFLnvLfcDSwNX1/ptBRAeeme7G1nwpeohJjiddmf20e421+n3tWUyUhLk9s83MJQQp+mhfApA1Qvz+a7M3OqPvHhBoeu6C4NOlYkb8mrjtuZ/RU5WIRXfyXZqA05Qnu8usuxxNFozU5hWbXIZQx7at2x/7t8/kgHSJhKs4hWIdbVgIDyWIhgoDD+gqTIRlzTwrS876dgy0MTZm1riMEBB5jvAhaeciDBf8u6AFWnMsS0UVtOinr5lTRkHSwie2n90kazqpkeMUdnbBSG7HSMhyg5lvem9G82NakH4S1EPgRBLN1eF8Q51ZmzeNl3DnIGGjNI+LAXw10KVuEkzgd8A== > -----END CERTIFICATE----- > > -----BEGIN CERTIFICATE----- > MIIFYDCCA0igAwIBAgIJAOj6GWMU0voYMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNVBAUTEGY5MjAwOWU4NTNiNmIwNDUwHhcNMTYwNTI2MTYyODUyWhcNMjYwNTI0MTYyODUyWjAbMRkwFwYDVQQFExBmOTIwMDllODUzYjZiMDQ1MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAr7bHgiuxpwHsK7Qui8xUFmOr75gvMsd/dTEDDJdSSxtf6An7xyqpRR90PL2abxM1dEqlXnf2tqw1Ne4Xwl5jlRfdnJLmN0pTy/4lj4/7tv0Sk3iiKkypnEUtR6WfMgH0QZfKHM1+di+y9TFRtv6y//0rb+T+W8a9nsNL/ggjnar86461qO0rOs2cXjp3kOG1FEJ5MVmFmBGtnrKpa73XpXyTqRxB/M0n1n/W9nGqC4FSYa04T6N5RIZGBN2z2MT5IKGbFlbC8UrW0DxW7AYImQQcHtGl/m00QLVWutHQoVJYnFPlXTcHYvASLu+RhhsbDmxMgJJ0mcDpvsC4PjvB+TxywElgS70vE0XmLD+OJtvsBslHZvPBKCOdT0MS+tgSOIfga+z1Z1g7+DVagf7quvmag8jfPioyKvxnK/EgsTUVi2ghzq8wm27ud/mIM7AY2qEORR8Go3TVB4HzWQgpZrt3i5MIlCaY504LzSRiigHCzAPlHws+W0rB5N+er5/2pJKnfBSDiCiFAVtCLOZ7gLiMm0jhO2B6tUXHI/+MRPjy02i59lINMRRev56GKtcd9qO/0kUJWdZTdA2XoS82ixPvZtXQpUpuL12ab+9EaDK8Z4RHJYYfCT3Q5vNAXaiWQ+8PTWm2QgBR/bkwSWc+NpUFgNPN9PvQi8WEg5UmAGMCAwEAAaOBpjCBozAdBgNVHQ4EFgQUNmHhAHyIBQlRi0RsR/8aTMnqTxIwHwYDVR0jBBgwFoAUNmHhAHyIBQlRi0RsR/8aTMnqTxIwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAYYwQAYDVR0fBDkwNzA1oDOgMYYvaHR0cHM6Ly9hbmRyb2lkLmdvb2dsZWFwaXMuY29tL2F0dGVzdGF0aW9uL2NybC8wDQYJKoZIhvcNAQELBQADggIBACDIw41L3KlXG0aMiS//cqrG+EShHUGo8HNsw30W1kJtjn6UBwRM6jnmiwfBPb8VA91chb2vssAtX2zbTvqBJ9+LBPGCdw/E53Rbf86qhxKaiAHOjpvAy5Y3m00mqC0w/Zwvju1twb4vhLaJ5NkUJYsUS7rmJKHHBnETLi8GFqiEsqTWpG/6ibYCv7rYDBJDcR9W62BW9jfIoBQcxUCUJouMPH25lLNcDc1ssqvC2v7iUgI9LeoM1sNovqPmQUiG9rHli1vXxzCyaMTjwftkJLkf6724DFhuKug2jITV0QkXvaJWF4nUaHOTNA4uJU9WDvZLI1j83A+/xnAJUucIv/zGJ1AMH2boHqF8CY16LpsYgBt6tKxxWH00XcyDCdW2KlBCeqbQPcsFmWyWugxdcekhYsAWyoSf818NUsZdBWBaR/OukXrNLfkQ79IyZohZbvabO/X+MVT3rriAoKc8oE2Uws6DF+60PV7/WIPjNvXySdqspImSN78mflxDqwLqRBYkA3I75qppLGG9rp7UCdRjxMl8ZDBld+7yvHVgt1cVzJx9xnyGCC23UaicMDSXYrB4I4WHXPGjxhZuCuPBLTdOLU8YRvMYdEvYebWHMpvwGCF6bAx3JBpIeOQ1wDB5y0USicV3YgYGmi+NZfhA4URSh77Yd6uuJOJENRaNVTzk > -----END CERTIFICATE----- > > CN = Android Keystore Key > error 20 at 0 depth lookup: unable to get local issuer certificate > error c1.pem: verification failed > > > Checking g > -----BEGIN CERTIFICATE----- > MIICMzCCAdmgAwIBAgIBATAKBggqhkjOPQQDAjApMRkwFwYDVQQFExBhMTk1Mzk2NGJhMmEyODlkMQwwCgYDVQQMDANURUUwHhcNNzAwMTAxMDAwMDAwWhcNNDkxMjMxMjM1OTU5WjAfMR0wGwYDVQQDDBRBbmRyb2lkIEtleXN0b3JlIEtleTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABP8c/Ldx44Ms4bM37CyNoE6Us5uS8dAERkRV8kyxCY7bD3P9rds93fflXJS8Pccyb/fXXJgSS3T2SVdbbPrc5oqjgfswgfgwDAYDVR0PBAUDAweAADCB5wYKKwYBBAHWeQIBEQSB2DCB1QIBAgoBAQIBAwoBAQQLaGVsbG8gd29ybGQEADBLv4U9CQIHBXlxm+8jSL+FRToEODA2MRAwDgQJY29tLnB5eXBsAgEPMSIEIIMi9g2//U87C53x3twp61y6K1+22oaTkEjGgyTgXw37MGuhBTEDAgECogMCAQOjBAICAQClBTEDAgEEqgMCAQG/g3cCBQC/hT4DAgEAv4VAKjAoBCBNeQ+gpf6B1rNSuQr+QwaE2byBdRjNJMUOY0M5X3xR8gEB/woBAL+FQQUCAwE4gL+FQgUCAwMUUDAKBggqhkjOPQQDAgNIADBFAiEA7cObHYk5pcrMI+ZGd5KmVMlr83SbHzDJe6z3rNLqtlwCIAM/9o4YhpHmujecGzSX9sMk/xEaNHXdytqmxwh2wFBM > -----END CERTIFICATE----- > > -----BEGIN CERTIFICATE----- > MIICJjCCAaugAwIBAgIKEyY3BBKHSRYpeTAKBggqhkjOPQQDAjApMRkwFwYDVQQFExAyOTYwY2I5YWViZDUwNWY0MQwwCgYDVQQMDANURUUwHhcNMTgwMzIxMjA1ODE1WhcNMjgwMzE4MjA1ODE1WjApMRkwFwYDVQQFExBhMTk1Mzk2NGJhMmEyODlkMQwwCgYDVQQMDANURUUwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATHJiYgEb7N5f8ZnbKTZkDSvp2VugEEvz4Mm7wxVmcizwSPMPiTjv6gm2n1CoNBSHLVnTZ84ywfEk7HiftX1K6Co4G6MIG3MB0GA1UdDgQWBBQkYNkasG1v9aQK31IvheOpubhN5jAfBgNVHSMEGDAWgBTZCjmyzP+wdzrAqIzS/zURX5DNxjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwICBDBUBgNVHR8ETTBLMEmgR6BFhkNodHRwczovL2FuZHJvaWQuZ29vZ2xlYXBpcy5jb20vYXR0ZXN0YXRpb24vY3JsLzEzMjYzNzA0MTI4NzQ5MTYyOTc5MAoGCCqGSM49BAMCA2kAMGYCMQCsCvSIoT/6E+cbiD+v4e+Y6PUYX3ZcatDAAM1eWTAWZmnabkTW9u3/BWhzYYYm4fYCMQCdsRDgh8XG4ZWJhuvFtHy/C3vi1Hf1wD93YoHOLLJaIPvuv/hWR+1UpKO2lgHo9+4= > -----END CERTIFICATE----- > > -----BEGIN CERTIFICATE----- > MIID0TCCAbmgAwIBAgIKA4gmZ2BliZaFfTANBgkqhkiG9w0BAQsFADAbMRkwFwYDVQQFExBmOTIwMDllODUzYjZiMDQ1MB4XDTE4MDMyMTIwNTM1M1oXDTI4MDMxODIwNTM1M1owKTEZMBcGA1UEBRMQMjk2MGNiOWFlYmQ1MDVmNDEMMAoGA1UEDAwDVEVFMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEjXELw7zFszCPjAS+Qn6zEFajdp6hD+53zSpN7egUzWfkFEh+wcLa4k67Fv2tKuekmLIhr4xidPllElgiwAyeB33abMJ5BckSX1ayj4lnpMVvYRovl/5ZHIKNIJMN/hC6o4G2MIGzMB0GA1UdDgQWBBTZCjmyzP+wdzrAqIzS/zURX5DNxjAfBgNVHSMEGDAWgBQ2YeEAfIgFCVGLRGxH/xpMyepPEjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwICBDBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwczovL2FuZHJvaWQuZ29vZ2xlYXBpcy5jb20vYXR0ZXN0YXRpb24vY3JsL0U4RkExOTYzMTREMkZBMTgwDQYJKoZIhvcNAQELBQADggIBAJKrsCoJam9qc1ZaHeQWf2TAjHDDVylLuUvczTSuu8VhZJiU0+yKGbTNnA13n/dvn7rmMj8W6ObWL582Se9MBBdKtAVeCG7qYFq+m6kYFIfL8sOuutKXG5eW+8VY4he0hu+5eZiS2e3mAZGYF9JwQTAv0H//6+9eLm/+j+L5tr2X4b7H6k2h4YW5HTIzIbVMvp/ic/zmv+RvrmYyXliaz1xglRqrJ6EiFI9/KsYYsSSVgorlrXPyKOBeXGc2SFIVQmLwfW4gc9BC8V4qBDcpFK1kxOfnkyXloVZeat4yuYFSIdtJq9FErMFHfp+pDjIKRGeeWWrPzkbELqtHUSeSktbqN229c+86YRfScxpx5iJ0Jp2YsHkiYDFs+0LOex2RNdOKErGKZ+8QbMtVxUIQARTlhZkeLTLAWufFcclEbZkpoe6jo131VjAlUrkQfK6dVVMx+gLhOffLjH9EmUOD8Y1an9DQCsZl1tpBN4WgInbRMlzBsKF17Z9BEW1f2A+Gn0mnznZoq6t0OxsvRJTEHEgswQh4Vkr77UYSdcwQ0flrpD9Oe6ObnB0VSSCVo1yhPC39R35Z5KDhiNS8BkuPaJoUK8RBbkl5ay4O86LFfY9tdAoHT0A/2hmq/NZhz48K1C9AJGtS+0+zHwSatjWJ7rM/KXAhJ0Nln/nMaeteQy2f > -----END CERTIFICATE----- > > -----BEGIN CERTIFICATE----- > MIIFYDCCA0igAwIBAgIJAOj6GWMU0voYMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNVBAUTEGY5MjAwOWU4NTNiNmIwNDUwHhcNMTYwNTI2MTYyODUyWhcNMjYwNTI0MTYyODUyWjAbMRkwFwYDVQQFExBmOTIwMDllODUzYjZiMDQ1MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAr7bHgiuxpwHsK7Qui8xUFmOr75gvMsd/dTEDDJdSSxtf6An7xyqpRR90PL2abxM1dEqlXnf2tqw1Ne4Xwl5jlRfdnJLmN0pTy/4lj4/7tv0Sk3iiKkypnEUtR6WfMgH0QZfKHM1+di+y9TFRtv6y//0rb+T+W8a9nsNL/ggjnar86461qO0rOs2cXjp3kOG1FEJ5MVmFmBGtnrKpa73XpXyTqRxB/M0n1n/W9nGqC4FSYa04T6N5RIZGBN2z2MT5IKGbFlbC8UrW0DxW7AYImQQcHtGl/m00QLVWutHQoVJYnFPlXTcHYvASLu+RhhsbDmxMgJJ0mcDpvsC4PjvB+TxywElgS70vE0XmLD+OJtvsBslHZvPBKCOdT0MS+tgSOIfga+z1Z1g7+DVagf7quvmag8jfPioyKvxnK/EgsTUVi2ghzq8wm27ud/mIM7AY2qEORR8Go3TVB4HzWQgpZrt3i5MIlCaY504LzSRiigHCzAPlHws+W0rB5N+er5/2pJKnfBSDiCiFAVtCLOZ7gLiMm0jhO2B6tUXHI/+MRPjy02i59lINMRRev56GKtcd9qO/0kUJWdZTdA2XoS82ixPvZtXQpUpuL12ab+9EaDK8Z4RHJYYfCT3Q5vNAXaiWQ+8PTWm2QgBR/bkwSWc+NpUFgNPN9PvQi8WEg5UmAGMCAwEAAaOBpjCBozAdBgNVHQ4EFgQUNmHhAHyIBQlRi0RsR/8aTMnqTxIwHwYDVR0jBBgwFoAUNmHhAHyIBQlRi0RsR/8aTMnqTxIwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAYYwQAYDVR0fBDkwNzA1oDOgMYYvaHR0cHM6Ly9hbmRyb2lkLmdvb2dsZWFwaXMuY29tL2F0dGVzdGF0aW9uL2NybC8wDQYJKoZIhvcNAQELBQADggIBACDIw41L3KlXG0aMiS//cqrG+EShHUGo8HNsw30W1kJtjn6UBwRM6jnmiwfBPb8VA91chb2vssAtX2zbTvqBJ9+LBPGCdw/E53Rbf86qhxKaiAHOjpvAy5Y3m00mqC0w/Zwvju1twb4vhLaJ5NkUJYsUS7rmJKHHBnETLi8GFqiEsqTWpG/6ibYCv7rYDBJDcR9W62BW9jfIoBQcxUCUJouMPH25lLNcDc1ssqvC2v7iUgI9LeoM1sNovqPmQUiG9rHli1vXxzCyaMTjwftkJLkf6724DFhuKug2jITV0QkXvaJWF4nUaHOTNA4uJU9WDvZLI1j83A+/xnAJUucIv/zGJ1AMH2boHqF8CY16LpsYgBt6tKxxWH00XcyDCdW2KlBCeqbQPcsFmWyWugxdcekhYsAWyoSf818NUsZdBWBaR/OukXrNLfkQ79IyZohZbvabO/X+MVT3rriAoKc8oE2Uws6DF+60PV7/WIPjNvXySdqspImSN78mflxDqwLqRBYkA3I75qppLGG9rp7UCdRjxMl8ZDBld+7yvHVgt1cVzJx9xnyGCC23UaicMDSXYrB4I4WHXPGjxhZuCuPBLTdOLU8YRvMYdEvYebWHMpvwGCF6bAx3JBpIeOQ1wDB5y0USicV3YgYGmi+NZfhA4URSh77Yd6uuJOJENRaNVTzk > -----END CERTIFICATE----- > > > g1.pem: OK > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From philipp_subx at redfish-solutions.com Fri Jul 23 00:56:40 2021 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Thu, 22 Jul 2021 18:56:40 -0600 Subject: iOS app attest server side Message-ID: <5C112AD2-7425-4506-B652-EE585DF0D2B3@redfish-solutions.com> Hi all, Does anyone have any reference code for implementing server-side App Attest for iOS clients? Thanks, -Philip From philipp_subx at redfish-solutions.com Fri Jul 23 01:29:50 2021 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Thu, 22 Jul 2021 19:29:50 -0600 Subject: Parsing subject/issuer strings in X.509 Message-ID: Hi, I'm wondering what the function is that takes a string and returns X509_NAME with the attribute/value pairs of the parsed DN. Thanks, -Philip From openssl-users at dukhovni.org Fri Jul 23 05:49:28 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 23 Jul 2021 01:49:28 -0400 Subject: Parsing subject/issuer strings in X.509 In-Reply-To: References: Message-ID: <2D71ED82-D22D-406A-8A64-5C52DC5CB0F9@dukhovni.org> > On 22 Jul 2021, at 9:29 pm, Philip Prindeville wrote: > > I'm wondering what the function is that takes a string and returns X509_NAME with the attribute/value pairs of the parsed DN. There is no such function in general, since the are many potential string forms of X.509 names, not all of which are unambiguously machine readable. There are various functions for augmenting a partially built name with an attribute-value pair, but the parsing of a string a list of such attribute-value pairs is up to you. :-( -- Viktor. From dev at ddvo.net Fri Jul 23 06:57:40 2021 From: dev at ddvo.net (David von Oheimb) Date: Fri, 23 Jul 2021 08:57:40 +0200 Subject: Parsing subject/issuer strings in X.509 In-Reply-To: <2D71ED82-D22D-406A-8A64-5C52DC5CB0F9@dukhovni.org> References: <2D71ED82-D22D-406A-8A64-5C52DC5CB0F9@dukhovni.org> Message-ID: <2e53f73c-7130-c21b-a2b2-45e6568b1966@ddvo.net> What I use is ??????? X509_NAME *nname = parse_name(string, MBSTRING_ASC, 1, desc); which is not an official API function but defined in apps/lib/apps.c: /* ?* name is expected to be in the format /type0=value0/type1=value1/type2=... ?* where + can be used instead of / to form multi-valued RDNs if canmulti ?* and characters may be escaped by \ ?*/ X509_NAME *parse_name(const char *cp, int chtype, int canmulti, const char *desc) Would be good to have such a function as part of the X.509 API. ??? David On 23.07.21 07:49, Viktor Dukhovni wrote: >> On 22 Jul 2021, at 9:29 pm, Philip Prindeville wrote: >> >> I'm wondering what the function is that takes a string and returns X509_NAME with the attribute/value pairs of the parsed DN. > There is no such function in general, since the are many potential > string forms of X.509 names, not all of which are unambiguously > machine readable. > > There are various functions for augmenting a partially built name > with an attribute-value pair, but the parsing of a string a list > of such attribute-value pairs is up to you. :-( > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.kosuri at f5.com Fri Jul 23 11:29:02 2021 From: m.kosuri at f5.com (Venkata Mallikarjunarao Kosuri) Date: Fri, 23 Jul 2021 11:29:02 +0000 Subject: Dynamic CRL not working when signed by intermediate CA Message-ID: Hi, Dynamic CRL not working when signed by intermediate CA when ca-file (Trusted CA certs bundle) includes only the intermediate CA that signed the CRL. Causing to this the handshake is failing, is there a way to avoid in OpenSSL 1.0.2s-fips 28 May 2019? Br, Malli -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Jul 23 14:52:38 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 23 Jul 2021 10:52:38 -0400 Subject: Parsing subject/issuer strings in X.509 In-Reply-To: <2e53f73c-7130-c21b-a2b2-45e6568b1966@ddvo.net> References: <2D71ED82-D22D-406A-8A64-5C52DC5CB0F9@dukhovni.org> <2e53f73c-7130-c21b-a2b2-45e6568b1966@ddvo.net> Message-ID: <5C11FD13-542B-495D-AA13-C65BD21C798B@dukhovni.org> > On 23 Jul 2021, at 2:57 am, David von Oheimb wrote: > > What I use is > > X509_NAME *nname = parse_name(string, MBSTRING_ASC, 1, desc); > > which is not an official API function but defined in apps/lib/apps.c: > > /* > * name is expected to be in the format /type0=value0/type1=value1/type2=... > * where + can be used instead of / to form multi-valued RDNs if canmulti > * and characters may be escaped by \ > */ > X509_NAME *parse_name(const char *cp, int chtype, int canmulti, const char *desc) > > Would be good to have such a function as part of the X.509 API. Note that the "/"-separated form is not the output format of the issuer or subject names in X509_NAME_oneline(3), x509(1), ... So a public API for that format may not be a good idea. Perhaps there could be parsers for the "rfc2253", "rfc2254" and "oneline" formats (or a single parser with flags to select the format). -- Viktor. From philipp_subx at redfish-solutions.com Fri Jul 23 18:17:40 2021 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Fri, 23 Jul 2021 12:17:40 -0600 Subject: Parsing subject/issuer strings in X.509 In-Reply-To: <2e53f73c-7130-c21b-a2b2-45e6568b1966@ddvo.net> References: <2D71ED82-D22D-406A-8A64-5C52DC5CB0F9@dukhovni.org> <2e53f73c-7130-c21b-a2b2-45e6568b1966@ddvo.net> Message-ID: Yeah, agreed, although I'd like the parser to work with the output of "openssl x509 ... -subject", i.e. RFC-4514 format, which is "CN=name, O=Acme Corporation, C=US" ... etc. > On Jul 23, 2021, at 12:57 AM, David von Oheimb wrote: > > What I use is > > X509_NAME *nname = parse_name(string, MBSTRING_ASC, 1, desc); > > which is not an official API function but defined in apps/lib/apps.c: > > /* > * name is expected to be in the format /type0=value0/type1=value1/type2=... > * where + can be used instead of / to form multi-valued RDNs if canmulti > * and characters may be escaped by \ > */ > X509_NAME *parse_name(const char *cp, int chtype, int canmulti, const char *desc) > > Would be good to have such a function as part of the X.509 API. > > David > > On 23.07.21 07:49, Viktor Dukhovni wrote: >>> On 22 Jul 2021, at 9:29 pm, Philip Prindeville wrote: >>> >>> I'm wondering what the function is that takes a string and returns X509_NAME with the attribute/value pairs of the parsed DN. >> There is no such function in general, since the are many potential >> string forms of X.509 names, not all of which are unambiguously >> machine readable. >> >> There are various functions for augmenting a partially built name >> with an attribute-value pair, but the parsing of a string a list >> of such attribute-value pairs is up to you. :-( >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From philipp_subx at redfish-solutions.com Fri Jul 23 18:18:25 2021 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Fri, 23 Jul 2021 12:18:25 -0600 Subject: Parsing subject/issuer strings in X.509 In-Reply-To: <5C11FD13-542B-495D-AA13-C65BD21C798B@dukhovni.org> References: <2D71ED82-D22D-406A-8A64-5C52DC5CB0F9@dukhovni.org> <2e53f73c-7130-c21b-a2b2-45e6568b1966@ddvo.net> <5C11FD13-542B-495D-AA13-C65BD21C798B@dukhovni.org> Message-ID: <4DD60B5F-2A1D-4B5B-ABF4-D0475085E308@redfish-solutions.com> > On Jul 23, 2021, at 8:52 AM, Viktor Dukhovni wrote: > >> On 23 Jul 2021, at 2:57 am, David von Oheimb wrote: >> >> What I use is >> >> X509_NAME *nname = parse_name(string, MBSTRING_ASC, 1, desc); >> >> which is not an official API function but defined in apps/lib/apps.c: >> >> /* >> * name is expected to be in the format /type0=value0/type1=value1/type2=... >> * where + can be used instead of / to form multi-valued RDNs if canmulti >> * and characters may be escaped by \ >> */ >> X509_NAME *parse_name(const char *cp, int chtype, int canmulti, const char *desc) >> >> Would be good to have such a function as part of the X.509 API. > > Note that the "/"-separated form is not the output format of the issuer or > subject names in X509_NAME_oneline(3), x509(1), ... So a public API for > that format may not be a good idea. Perhaps there could be parsers for > the "rfc2253", "rfc2254" and "oneline" formats (or a single parser with > flags to select the format). > > -- > Viktor. > And "rfc4514"... yeah, that would work too. -Philip From philipp_subx at redfish-solutions.com Fri Jul 23 18:18:56 2021 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Fri, 23 Jul 2021 12:18:56 -0600 Subject: Parsing subject/issuer strings in X.509 In-Reply-To: <2e53f73c-7130-c21b-a2b2-45e6568b1966@ddvo.net> References: <2D71ED82-D22D-406A-8A64-5C52DC5CB0F9@dukhovni.org> <2e53f73c-7130-c21b-a2b2-45e6568b1966@ddvo.net> Message-ID: <91AE71AB-F18A-4978-85A6-C1D75EC59F9B@redfish-solutions.com> Yeah, agreed, although I'd like the parser to work with the output of "openssl x509 ... -subject", i.e. RFC-4514 format, which is "CN=name, O=Acme Corporation, C=US" ... etc. > On Jul 23, 2021, at 12:57 AM, David von Oheimb wrote: > > What I use is > > X509_NAME *nname = parse_name(string, MBSTRING_ASC, 1, desc); > > which is not an official API function but defined in apps/lib/apps.c: > > /* > * name is expected to be in the format /type0=value0/type1=value1/type2=... > * where + can be used instead of / to form multi-valued RDNs if canmulti > * and characters may be escaped by \ > */ > X509_NAME *parse_name(const char *cp, int chtype, int canmulti, const char *desc) > > Would be good to have such a function as part of the X.509 API. > > David > > On 23.07.21 07:49, Viktor Dukhovni wrote: >>> On 22 Jul 2021, at 9:29 pm, Philip Prindeville >>> wrote: >>> >>> I'm wondering what the function is that takes a string and returns X509_NAME with the attribute/value pairs of the parsed DN. >>> >> There is no such function in general, since the are many potential >> string forms of X.509 names, not all of which are unambiguously >> machine readable. >> >> There are various functions for augmenting a partially built name >> with an attribute-value pair, but the parsing of a string a list >> of such attribute-value pairs is up to you. :-( >> >> From dclarke at blastwave.org Sun Jul 25 21:14:05 2021 From: dclarke at blastwave.org (Dennis Clarke) Date: Sun, 25 Jul 2021 17:14:05 -0400 Subject: OpenSSL 3.0.0 beta1 link issues on Solaris 10 Message-ID: <2dde0ca0-88d4-4281-faf2-6813aff5d5ef@blastwave.org> I am not sure what testing is happening with old Solaris 10 but I can tell you there are still servers out there running. I had no issues with the configuration stage but, as usual, I do need to make a few tweaks to Configurations/10-main.conf. Merely to get a consistent set of CFLAGS that I use for libraries that I may want to single step through. In any case the link stage fails with a truely massive list of undefined symbols and it seems as if the previous 1.1.1k libs are being found by the build process. So I wrote a manual link script and specified the build directory for the RUNPATH and the library search path however that resulted in a pile of undefined symbols. So then I went and deleted my previous 1.1.1k libs and the openssl binary and tried the manual link once again with success. Not sure if anyone else runs into this but I would hope that the previous libs would not be located *before* the new current 3.0.0 libs that are in the build directory. Regardless I may need to simply start over as the new libssl.so.3 seems to have a "NEEDED" libcrypto.so.1.1 and that can't be right. Here is the result of perl configdata.pm --dump : alpha$ /opt/bw/bin/perl configdata.pm --dump Command line (with current working directory = .): /opt/bw/bin/perl ./Configure solaris64-sparcv9-cc no-asm --prefix=/opt/bw shared no-hw no-engine -DPEDANTIC Perl information: /opt/bw/bin/perl 5.32.0 for sun4-solaris-64-ld Enabled features: aria async autoalginit autoerrinit autoload-config bf blake2 bulk cached-fetch camellia cast chacha cmac cmp cms comp ct deprecated des dgram dh dsa dso dtls ec ec2m ecdh ecdsa err filenames gost idea legacy md4 mdc2 module multiblock nextprotoneg ocb ocsp pic pinshared poly1305 posix-io psk rc2 rc4 rdrand rfc3779 rmd160 scrypt secure-memory seed shared siphash siv sm2 sm3 sm4 sock srp srtp sse2 ssl ssl-trace static-engine stdio tests threads tls ts ui-console whirlpool tls1 tls1-method tls1_1 tls1_1-method tls1_2 tls1_2-method tls1_3 dtls1 dtls1-method dtls1_2 dtls1_2-method Disabled features: acvp-tests [default] OPENSSL_NO_ACVP_TESTS afalgeng [cascade] OPENSSL_NO_AFALGENG asan [default] OPENSSL_NO_ASAN asm [option] OPENSSL_NO_ASM buildtest-c++ [default] capieng [cascade] OPENSSL_NO_CAPIENG crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG devcryptoeng [default] OPENSSL_NO_DEVCRYPTOENG dynamic-engine [cascade] ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 egd [default] OPENSSL_NO_EGD engine [option] OPENSSL_NO_ENGINE (skip engines, crypto/engine) external-tests [default] OPENSSL_NO_EXTERNAL_TESTS fips [default] fips-securitychecks [cascade] OPENSSL_NO_FIPS_SECURITYCHECKS fuzz-afl [default] OPENSSL_NO_FUZZ_AFL fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER ktls [default] OPENSSL_NO_KTLS loadereng [cascade] OPENSSL_NO_LOADERENG makedepend [unavailable] md2 [default] OPENSSL_NO_MD2 (skip crypto/md2) msan [default] OPENSSL_NO_MSAN padlockeng [cascade] OPENSSL_NO_PADLOCKENG rc5 [default] OPENSSL_NO_RC5 (skip crypto/rc5) sctp [default] OPENSSL_NO_SCTP trace [default] OPENSSL_NO_TRACE ubsan [default] OPENSSL_NO_UBSAN unit-test [default] OPENSSL_NO_UNIT_TEST uplink [no uplink_arch] OPENSSL_NO_UPLINK weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS zlib [default] zlib-dynamic [default] ssl3 [default] OPENSSL_NO_SSL3 ssl3-method [default] OPENSSL_NO_SSL3_METHOD Config target attributes: AR => "ar", ARFLAGS => "qc", CC => "cc", CFLAGS => "-xO0 -g -xdepend", HASHBANGPERL => "/usr/bin/env perl", RANLIB => "ranlib", RC => "windres", asm_arch => "sparcv9", bn_ops => "BN_LLONG RC4_CHAR", build_file => "Makefile", build_scheme => [ "unified", "unix" ], cflags => "-m64 -xarch=sparc -g -xO0 -Xa -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -Qy -xdebugformat=dwarf -xstrconst -Xa", cppflags => "-D_REENTRANT -D_REENTRANT", defines => [ "OPENSSL_BUILDING_OPENSSL" ], disable => [ ], dso_scheme => "dlfcn", enable => [ ], ex_libs => "-lsocket -lnsl -ldl -lrt -lpthread", includes => [ ], lflags => "-mt", lib_cflags => "", lib_cppflags => "-DFILIO_H -DB_ENDIAN -DBN_DIV2W", lib_defines => [ ], module_cflags => "-KPIC", module_cxxflags => undef, module_ldflags => "-G -dy -z text -Wl,-Bsymbolic", multilib => "/64", perl_platform => "Unix", perlasm_scheme => "void", shared_cflag => "-KPIC", shared_defflag => "-Wl,-M,", shared_defines => [ ], shared_ldflag => "-G -dy -z text -Wl,-Bsymbolic", shared_rcflag => "", shared_sonameflag => "-Wl,-h,", shared_target => "solaris", thread_defines => [ ], thread_scheme => "pthreads", unistd => "", Recorded environment: AR = BUILDFILE = CC = /opt/developerstudio12.6/bin/cc CFLAGS = -m64 -xarch=sparc -g -xO0 -Xa -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -Qy -xdebugformat=dwarf CPPFLAGS = -I/opt/bw/include -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO CROSS_COMPILE = CXX = /opt/developerstudio12.6/bin/CC CXXFLAGS = HASHBANGPERL = LDFLAGS = -L/opt/bw/lib LDLIBS = OPENSSL_LOCAL_CONFIG_DIR = PERL = /opt/bw/bin/perl RANLIB = RC = RCFLAGS = WINDRES = __CNF_CFLAGS = __CNF_CPPDEFINES = __CNF_CPPFLAGS = __CNF_CPPINCLUDES = __CNF_CXXFLAGS = __CNF_LDFLAGS = __CNF_LDLIBS = Makevars: AR = ar ARFLAGS = qc CC = /opt/developerstudio12.6/bin/cc CFLAGS = -m64 -xarch=sparc -g -xO0 -Xa -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -Qy -xdebugformat=dwarf CPPDEFINES = PEDANTIC CPPFLAGS = -I/opt/bw/include -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO CPPINCLUDES = CXX = /opt/developerstudio12.6/bin/CC CXXFLAGS = HASHBANGPERL = /opt/bw/bin/perl LDFLAGS = -L/opt/bw/lib LDLIBS = PERL = /opt/bw/bin/perl RANLIB = ranlib RC = windres RCFLAGS = NOTE: These variables only represent the configuration view. The build file template may have processed these variables further, please have a look at the build file for more exact data: Makefile build file: Makefile build file templates: Configurations/common0.tmpl Configurations/unix-Makefile.tmpl alpha$ I will start over now with the previous 1.1.1k bin and libs entirely removed. If there is some option within the Configuration step that I am missing I would be glad to hear it. Thank you. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From dclarke at blastwave.org Sun Jul 25 23:17:05 2021 From: dclarke at blastwave.org (Dennis Clarke) Date: Sun, 25 Jul 2021 19:17:05 -0400 Subject: OpenSSL 3.0.0 beta1 with a vast number of failures Message-ID: After some work to clean out previous versions of OpenSSL 1.1.1x for some x I was able to get 3.0.0 beta1 to build. However it looks like some horrific perl problem in the test harness : # ------------------------------------------------------------------------------ # Failed test 'Name constraints bad othername name constraint' # at test/recipes/25-test_verify.t line 375. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Global symbol "$use_system" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "$waitcode" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "$waitcode" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "$exitcode" requires explicit package name at ../../util/wrap.pl line 20. syntax error at ../../util/wrap.pl line 56, near "perlport#exit # https://perldoc.perl.org/perlvms#$? if" ../../util/wrap.pl has too many errors. ../../util/wrap.pl ../../apps/openssl verify -auth_level 1 -auth_level 0 -trusted ../../test/certs/root-cert.pem -untrusted ../../test/certs/ca-cert.pem ../../test/certs/ee-pss-sha1-cert.pem => 255 not ok 135 - Accept PSS signature using SHA1 at auth level 0 # ------------------------------------------------------------------------------ # Failed test 'Accept PSS signature using SHA1 at auth level 0' # at test/recipes/25-test_verify.t line 380. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Global symbol "$use_system" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "$waitcode" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "$waitcode" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "$exitcode" requires explicit package name at ../../util/wrap.pl line 20. syntax error at ../../util/wrap.pl line 56, near "perlport#exit # https://perldoc.perl.org/perlvms#$? if" ../../util/wrap.pl has too many errors. ../../util/wrap.pl ../../apps/openssl verify -auth_level 1 -trusted ../../test/certs/root-cert.pem -untrusted ../../test/certs/ca-cert.pem ../../test/certs/ee-pss-sha256-cert.pem => 255 not ok 136 - CA with PSS signature using SHA256 # ------------------------------------------------------------------------------ Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Global symbol "$use_system" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "$waitcode" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "$waitcode" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "$exitcode" requires explicit package name at ../../util/wrap.pl line 20. syntax error at ../../util/wrap.pl line 56, near "perlport#exit # https://perldoc.perl.org/perlvms#$? if" ../../util/wrap.pl has too many errors. ../../util/wrap.pl ../../apps/openssl verify -auth_level 1 -auth_level 2 -trusted ../../test/certs/root-cert.pem -untrusted ../../test/certs/ca-cert.pem ../../test/certs/ee-pss-sha256-cert.pem => 255 not ok 138 - PSS signature using SHA256 and auth level 2 # ------------------------------------------------------------------------------ # Failed test 'PSS signature using SHA256 and auth level 2' # at test/recipes/25-test_verify.t line 389. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Global symbol "$use_system" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "$waitcode" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "$waitcode" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "$exitcode" requires explicit package name at ../../util/wrap.pl line 20. syntax error at ../../util/wrap.pl line 56, near "perlport#exit # https://perldoc.perl.org/perlvms#$? if" ../../util/wrap.pl has too many errors. ../../util/wrap.pl ../../apps/openssl verify -auth_level 1 -trusted ../../test/certs/root-cert.pem -untrusted ../../test/certs/ca-pss-cert.pem ../../test/certs/ee-pss-cert.pem => 255 not ok 139 - CA PSS signature # ------------------------------------------------------------------------------ Seems like a perl issue to me and I do have a valid perl 5.32.0 here. Any insights would be appreciated. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From pauli at openssl.org Mon Jul 26 00:16:01 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Mon, 26 Jul 2021 10:16:01 +1000 Subject: OpenSSL 3.0.0 beta1 link issues on Solaris 10 In-Reply-To: <2dde0ca0-88d4-4281-faf2-6813aff5d5ef@blastwave.org> References: <2dde0ca0-88d4-4281-faf2-6813aff5d5ef@blastwave.org> Message-ID: <6ea26b36-4f41-bd5e-eb95-611f45ec5334@openssl.org> None of the core developers have access to Solaris machines, thus we rely on the community for reports and fixes for this kind of thing. We're happy to assist and can sometimes identify and fix the problem but we still require help testing. This would best be raised as an issue on GitHub [https://github.com/openssl/openssl/issues/new?assignees=&labels=issue%3A+bug+report&template=bug_report.md]. This way it is tracked and resource time can be allocated to it -- although in this case I suspect it will be the community that cracks it for us. Since you seem to have figured out a work around, including details of what you needed to do would be very useful.? Putting them up as a pull request would be even better. Paul Dale On 26/7/21 7:14 am, Dennis Clarke via openssl-users wrote: > I am not sure what testing is happening with old Solaris 10 but I can > tell you there are still servers out there running. I had no issues with > the configuration stage but, as usual, I do need to make a few tweaks to > Configurations/10-main.conf. Merely to get a consistent set of CFLAGS > that I use for libraries that I may want to single step through. In any > case the link stage fails with a truely massive list of undefined > symbols and it seems as if the previous 1.1.1k libs are being found by > the build process. So I wrote a manual link script and specified the > build directory for the RUNPATH and the library search path however that > resulted in a pile of undefined symbols. > > So then I went and deleted my previous 1.1.1k libs and the openssl > binary and tried the manual link once again with success. > > Not sure if anyone else runs into this but I would hope that the > previous libs would not be located *before* the new current 3.0.0 libs > that are in the build directory. Regardless I may need to simply start > over as the new libssl.so.3 seems to have a "NEEDED" libcrypto.so.1.1 > and that can't be right. > > Here is the result of perl configdata.pm --dump : > > alpha$ /opt/bw/bin/perl configdata.pm --dump > > Command line (with current working directory = .): > > /opt/bw/bin/perl ./Configure solaris64-sparcv9-cc no-asm > --prefix=/opt/bw shared no-hw no-engine -DPEDANTIC > > Perl information: > > /opt/bw/bin/perl > 5.32.0 for sun4-solaris-64-ld > > Enabled features: > > aria > async > autoalginit > autoerrinit > autoload-config > bf > blake2 > bulk > cached-fetch > camellia > cast > chacha > cmac > cmp > cms > comp > ct > deprecated > des > dgram > dh > dsa > dso > dtls > ec > ec2m > ecdh > ecdsa > err > filenames > gost > idea > legacy > md4 > mdc2 > module > multiblock > nextprotoneg > ocb > ocsp > pic > pinshared > poly1305 > posix-io > psk > rc2 > rc4 > rdrand > rfc3779 > rmd160 > scrypt > secure-memory > seed > shared > siphash > siv > sm2 > sm3 > sm4 > sock > srp > srtp > sse2 > ssl > ssl-trace > static-engine > stdio > tests > threads > tls > ts > ui-console > whirlpool > tls1 > tls1-method > tls1_1 > tls1_1-method > tls1_2 > tls1_2-method > tls1_3 > dtls1 > dtls1-method > dtls1_2 > dtls1_2-method > > Disabled features: > > acvp-tests [default] OPENSSL_NO_ACVP_TESTS > afalgeng [cascade] OPENSSL_NO_AFALGENG > asan [default] OPENSSL_NO_ASAN > asm [option] OPENSSL_NO_ASM > buildtest-c++ [default] > capieng [cascade] OPENSSL_NO_CAPIENG > crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG > devcryptoeng [default] OPENSSL_NO_DEVCRYPTOENG > dynamic-engine [cascade] > ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 > egd [default] OPENSSL_NO_EGD > engine [option] OPENSSL_NO_ENGINE (skip > engines, crypto/engine) > external-tests [default] OPENSSL_NO_EXTERNAL_TESTS > fips [default] > fips-securitychecks [cascade] OPENSSL_NO_FIPS_SECURITYCHECKS > fuzz-afl [default] OPENSSL_NO_FUZZ_AFL > fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER > ktls [default] OPENSSL_NO_KTLS > loadereng [cascade] OPENSSL_NO_LOADERENG > makedepend [unavailable] > md2 [default] OPENSSL_NO_MD2 (skip crypto/md2) > msan [default] OPENSSL_NO_MSAN > padlockeng [cascade] OPENSSL_NO_PADLOCKENG > rc5 [default] OPENSSL_NO_RC5 (skip crypto/rc5) > sctp [default] OPENSSL_NO_SCTP > trace [default] OPENSSL_NO_TRACE > ubsan [default] OPENSSL_NO_UBSAN > unit-test [default] OPENSSL_NO_UNIT_TEST > uplink [no uplink_arch] OPENSSL_NO_UPLINK > weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS > zlib [default] > zlib-dynamic [default] > ssl3 [default] OPENSSL_NO_SSL3 > ssl3-method [default] OPENSSL_NO_SSL3_METHOD > > Config target attributes: > > AR => "ar", > ARFLAGS => "qc", > CC => "cc", > CFLAGS => "-xO0 -g -xdepend", > HASHBANGPERL => "/usr/bin/env perl", > RANLIB => "ranlib", > RC => "windres", > asm_arch => "sparcv9", > bn_ops => "BN_LLONG RC4_CHAR", > build_file => "Makefile", > build_scheme => [ "unified", "unix" ], > cflags => "-m64 -xarch=sparc -g -xO0 -Xa -errfmt=error -erroff=%none > -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 > -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 > -Qy -xdebugformat=dwarf -xstrconst -Xa", > cppflags => "-D_REENTRANT -D_REENTRANT", > defines => [ "OPENSSL_BUILDING_OPENSSL" ], > disable => [ ], > dso_scheme => "dlfcn", > enable => [ ], > ex_libs => "-lsocket -lnsl -ldl -lrt -lpthread", > includes => [ ], > lflags => "-mt", > lib_cflags => "", > lib_cppflags => "-DFILIO_H -DB_ENDIAN -DBN_DIV2W", > lib_defines => [ ], > module_cflags => "-KPIC", > module_cxxflags => undef, > module_ldflags => "-G -dy -z text -Wl,-Bsymbolic", > multilib => "/64", > perl_platform => "Unix", > perlasm_scheme => "void", > shared_cflag => "-KPIC", > shared_defflag => "-Wl,-M,", > shared_defines => [ ], > shared_ldflag => "-G -dy -z text -Wl,-Bsymbolic", > shared_rcflag => "", > shared_sonameflag => "-Wl,-h,", > shared_target => "solaris", > thread_defines => [ ], > thread_scheme => "pthreads", > unistd => "", > > Recorded environment: > > AR = > BUILDFILE = > CC = /opt/developerstudio12.6/bin/cc > CFLAGS = -m64 -xarch=sparc -g -xO0 -Xa -errfmt=error -erroff=%none > -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 > -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 > -Qy -xdebugformat=dwarf > CPPFLAGS = -I/opt/bw/include -D_POSIX_PTHREAD_SEMANTICS > -D_LARGEFILE64_SOURCE -D_TS_ERRNO > CROSS_COMPILE = > CXX = /opt/developerstudio12.6/bin/CC > CXXFLAGS = > HASHBANGPERL = > LDFLAGS = -L/opt/bw/lib > LDLIBS = > OPENSSL_LOCAL_CONFIG_DIR = > PERL = /opt/bw/bin/perl > RANLIB = > RC = > RCFLAGS = > WINDRES = > __CNF_CFLAGS = > __CNF_CPPDEFINES = > __CNF_CPPFLAGS = > __CNF_CPPINCLUDES = > __CNF_CXXFLAGS = > __CNF_LDFLAGS = > __CNF_LDLIBS = > > Makevars: > > AR = ar > ARFLAGS = qc > CC = /opt/developerstudio12.6/bin/cc > CFLAGS = -m64 -xarch=sparc -g -xO0 -Xa -errfmt=error > -erroff=%none -errshort=full -xstrconst -xildoff -xmemalign=8s > -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none > -xbuiltin=%none -xunroll=1 -Qy -xdebugformat=dwarf > CPPDEFINES = PEDANTIC > CPPFLAGS = -I/opt/bw/include -D_POSIX_PTHREAD_SEMANTICS > -D_LARGEFILE64_SOURCE -D_TS_ERRNO > CPPINCLUDES = > CXX = /opt/developerstudio12.6/bin/CC > CXXFLAGS = > HASHBANGPERL = /opt/bw/bin/perl > LDFLAGS = -L/opt/bw/lib > LDLIBS = > PERL = /opt/bw/bin/perl > RANLIB = ranlib > RC = windres > RCFLAGS = > > NOTE: These variables only represent the configuration view. The build file > template may have processed these variables further, please have a look > at the > build file for more exact data: > Makefile > > build file: > > Makefile > > build file templates: > > Configurations/common0.tmpl > Configurations/unix-Makefile.tmpl > alpha$ > > > I will start over now with the previous 1.1.1k bin and libs entirely > removed. If there is some option within the Configuration step that I am > missing I would be glad to hear it. Thank you. > From dclarke at blastwave.org Mon Jul 26 00:53:06 2021 From: dclarke at blastwave.org (Dennis Clarke) Date: Sun, 25 Jul 2021 20:53:06 -0400 Subject: OpenSSL 3.0.0 beta1 link issues on Solaris 10 In-Reply-To: <6ea26b36-4f41-bd5e-eb95-611f45ec5334@openssl.org> References: <2dde0ca0-88d4-4281-faf2-6813aff5d5ef@blastwave.org> <6ea26b36-4f41-bd5e-eb95-611f45ec5334@openssl.org> Message-ID: <8d6e4571-e9cc-f109-0981-6fa17b82cb0c@blastwave.org> On 7/25/21 20:16, Dr Paul Dale wrote: > None of the core developers have access to Solaris machines, thus we > rely on the community for reports and fixes for this kind of thing. Well access can be easily arranged. > We're happy to assist and can sometimes identify and fix the problem but > we still require help testing. Not a problem. I do understand. This is not exactly a common platform anymore but the things just keep on running. And running. > This would best be raised as an issue on GitHub > [https://github.com/openssl/openssl/issues/new?assignees=&labels=issue%3A+bug+report&template=bug_report.md]. > This way it is tracked and resource time can be allocated to it -- > although in this case I suspect it will be the community that cracks it > for us. > It will come back to me most likely. Fine. > Since you seem to have figured out a work around, including details of > what you needed to do would be very useful.? Putting them up as a pull > request would be even better. I am working my way through the process now and also making changes as I go. Nothing too involved. For the most part this feels very much like the situation with 1.1.1k and all the previous flavours. Just a few tweaks needed. ALL of the perl scripts are mildly annoying but that is also easy to fix with some sed/grep/awk foo. I have the testsuite running now. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From dclarke at blastwave.org Mon Jul 26 19:00:29 2021 From: dclarke at blastwave.org (Dennis Clarke) Date: Mon, 26 Jul 2021 15:00:29 -0400 Subject: OpenSSL 3.0.0 beta1 test results on Sun/Oracle Solaris SPARC64 ( Fujitsu ) Message-ID: <89fbf087-53af-534a-e742-55e05119f6ac@blastwave.org> After a pile of tweaks here and there as well as EVERY perl file needed to be slightly touched I was able to get a clean compile and a reasonable result ( for a beta1 ) from the testsuite : ( SRCTOP=. \ BLDTOP=. \ PERL="/opt/bw/bin/perl" \ FIPSKEY="f4556650ac31d35461610bac4ed81b1a181b2d8a43ea2854cbae22ca74560813" \ EXE_EXT= \ /opt/bw/bin/perl ./test/run_tests.pl ) 00-prep_fipsmodule_cnf.t .. skipped: FIPS module config file only supported in a fips build Files=1, Tests=0, 1 wallclock secs ( 0.03 usr 0.01 sys + 0.89 cusr 0.04 csys = 0.97 CPU) Result: NOTESTS 01-test_abort.t .................... ok 01-test_fipsmodule_cnf.t ........... skipped: Test only supported in a fips build 01-test_sanity.t ................... ok 01-test_symbol_presence.t .......... ok 01-test_test.t ..................... ok 02-test_errstr.t ................... ok 02-test_internal_context.t ......... ok 02-test_internal_ctype.t ........... ok 02-test_internal_keymgmt.t ......... ok 02-test_internal_provider.t ........ ok 02-test_lhash.t .................... ok 02-test_ordinals.t ................. ok 02-test_sparse_array.t ............. ok 02-test_stack.t .................... ok 03-test_exdata.t ................... ok 03-test_fipsinstall.t .............. skipped: Test only supported in a fips build 03-test_internal_asn1.t ............ ok 03-test_internal_asn1_dsa.t ........ ok 03-test_internal_bn.t .............. ok 03-test_internal_chacha.t .......... ok 03-test_internal_curve448.t ........ ok 03-test_internal_ec.t .............. ok 03-test_internal_ffc.t ............. ok 03-test_internal_mdc2.t ............ ok ../../util/wrap.pl ../../test/modes_internal_test => 138 not ok 1 - running modes_internal_test # ------------------------------------------------------------------------------ # Failed test 'running modes_internal_test' # at /opt/bw/build/openssl-3.0.0-beta1_sunos5.10_sparcv9.002/util/perl/OpenSSL/Test/Simple.pm line 77. # Looks like you failed 1 test of 1.03-test_internal_modes.t ........... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests 03-test_internal_namemap.t ......... ok 03-test_internal_poly1305.t ........ ok 03-test_internal_rsa_sp800_56b.t ... ok 03-test_internal_siphash.t ......... ok 03-test_internal_sm2.t ............. ok 03-test_internal_sm4.t ............. ok 03-test_internal_ssl_cert_table.t .. ok 03-test_internal_x509.t ............ ok 03-test_params_api.t ............... ok 03-test_property.t ................. ok 03-test_ui.t ....................... ok 04-test_asn1_decode.t .............. ok 04-test_asn1_encode.t .............. ok 04-test_asn1_string_table.t ........ ok 04-test_bio_callback.t ............. ok 04-test_bio_core.t ................. ok 04-test_bioprint.t ................. ok 04-test_conf.t ..................... ok 04-test_encoder_decoder.t .......... ok 04-test_encoder_decoder_legacy.t ... ok 04-test_err.t ...................... ok 04-test_hexstring.t ................ ok 04-test_param_build.t .............. ok 04-test_params.t ................... ok 04-test_params_conversion.t ........ ok 04-test_pem_read_depr.t ............ ok 04-test_pem_reading.t .............. ok 04-test_provfetch.t ................ ok 04-test_provider.t ................. ok 04-test_provider_fallback.t ........ ok 04-test_upcalls.t .................. ok 05-test_bf.t ....................... ok 05-test_cast.t ..................... ok 05-test_cmac.t ..................... ok 05-test_des.t ...................... ok 05-test_hmac.t ..................... ok 05-test_idea.t ..................... ok 05-test_pbe.t ...................... ok 05-test_rand.t ..................... ok 05-test_rc2.t ...................... ok 05-test_rc4.t ...................... ok 05-test_rc5.t ...................... skipped: rc5 is not supported by this OpenSSL build 06-test_algorithmid.t .............. ok 06-test_rdrand_sanity.t ............ ok 10-test_bn.t ....................... ok 10-test_exp.t ...................... ok 15-test_dh.t ....................... ok 15-test_dsa.t ...................... ok 15-test_dsaparam.t ................. ok 15-test_ec.t ....................... ok 15-test_ecdsa.t .................... ok 15-test_ecparam.t .................. ok 15-test_gendh.t .................... ok 15-test_gendhparam.t ............... ok 15-test_gendsa.t ................... ok 15-test_genec.t .................... ok 15-test_genrsa.t ................... ok 15-test_mp_rsa.t ................... ok 15-test_out_option.t ............... ok 15-test_rsa.t ...................... ok 15-test_rsaoaep.t .................. ok 15-test_rsapss.t ................... ok 15-test_sha.t ...................... ok 20-test_app.t ...................... ok 20-test_cli_fips.t ................. skipped: Test only supported in a fips build with security checks 20-test_dgst.t ..................... ok 20-test_dhparam.t .................. ok 20-test_dhparam_check.t ............ ok 20-test_enc.t ...................... ok 20-test_enc_more.t ................. ok 20-test_kdf.t ...................... ok 20-test_mac.t ...................... ok 20-test_passwd.t ................... ok 20-test_pkeyutl.t .................. ok 20-test_rand_config.t .............. ok 20-test_spkac.t .................... ok 25-test_crl.t ...................... ok 25-test_d2i.t ...................... ok 25-test_eai_data.t ................. ok 25-test_pkcs7.t .................... ok 25-test_req.t ...................... ok 25-test_rusext.t ................... ok 25-test_sid.t ...................... ok 25-test_verify.t ................... ok 25-test_verify_store.t ............. ok 25-test_x509.t ..................... ok 30-test_acvp.t ..................... skipped: ACVP is not supported by this test 30-test_aesgcm.t ................... ok 30-test_afalg.t .................... skipped: test_afalg not supported for this build 30-test_defltfips.t ................ ok 30-test_engine.t ................... ok 30-test_evp.t ...................... ok 30-test_evp_extra.t ................ ok 30-test_evp_fetch_prov.t ........... ok 30-test_evp_kdf.t .................. ok 30-test_evp_libctx.t ............... ok 30-test_evp_pkey_dparam.t .......... ok 30-test_evp_pkey_provided.t ........ ok 30-test_pbelu.t .................... ok 30-test_pkey_meth.t ................ ok 30-test_pkey_meth_kdf.t ............ ok 30-test_provider_status.t .......... skipped: provider_status is not supported by this test 40-test_rehash.t ................... ok 60-test_x509_check_cert_pkey.t ..... ok 60-test_x509_dup_cert.t ............ ok 60-test_x509_store.t ............... ok 60-test_x509_time.t ................ ok ../../util/wrap.pl ../../test/bio_prefix_text < ../../test/recipes/61-test_bio_prefix_data/in1.txt > test_bio_prefix-in1.txt-stdout => 139 not ok 1 - prefixing in1.txt with args # ------------------------------------------------------------------------------ ../../util/wrap.pl ../../test/bio_prefix_text < ../../test/recipes/61-test_bio_prefix_data/in2.txt > test_bio_prefix-in2.txt-stdout => 139 not ok 3 - prefixing in2.txt with args # ------------------------------------------------------------------------------ # Looks like you failed 2 tests of 4.61-test_bio_prefix.t ............... Dubious, test returned 2 (wstat 512, 0x200) Failed 2/4 subtests (less 2 skipped subtests: 0 okay) 61-test_bio_readbuffer.t ........... ok 65-test_cmp_asn.t .................. ok 65-test_cmp_client.t ............... ok 65-test_cmp_ctx.t .................. ok 65-test_cmp_hdr.t .................. ok 65-test_cmp_msg.t .................. ok 65-test_cmp_protect.t .............. ok 65-test_cmp_server.t ............... ok 65-test_cmp_status.t ............... ok 65-test_cmp_vfy.t .................. ok 66-test_ossl_store.t ............... ok 70-test_asyncio.t .................. ok 70-test_bad_dtls.t ................. ok 70-test_clienthello.t .............. ok 70-test_comp.t ..................... skipped: test_comp needs the dynamic engine feature enabled 70-test_key_share.t ................ skipped: test_key_share needs the dynamic engine feature enabled 70-test_packet.t ................... ok 70-test_recordlen.t ................ ok 70-test_renegotiation.t ............ skipped: test_renegotiation needs the dynamic engine feature enabled 70-test_servername.t ............... ok 70-test_sslcbcpadding.t ............ skipped: test_sslcbcpadding needs the dynamic engine feature enabled 70-test_sslcertstatus.t ............ skipped: test_sslcertstatus needs the dynamic engine feature enabled 70-test_sslextension.t ............. skipped: test_sslextension needs the dynamic engine feature enabled 70-test_sslmessages.t .............. skipped: test_sslmessages needs the dynamic engine feature enabled 70-test_sslrecords.t ............... skipped: test_sslrecords needs the dynamic engine feature enabled 70-test_sslsessiontick.t ........... skipped: test_sslsessiontick needs the dynamic engine feature enabled 70-test_sslsigalgs.t ............... skipped: test_sslsigalgs needs the dynamic engine feature enabled 70-test_sslsignature.t ............. skipped: test_sslsignature needs the dynamic engine feature enabled 70-test_sslskewith0p.t ............. skipped: test_sslskewith0p needs the dynamic engine feature enabled 70-test_sslversions.t .............. skipped: test_sslversions needs the dynamic engine feature enabled 70-test_sslvertol.t ................ skipped: test_sslvertol needs the dynamic engine feature enabled 70-test_tls13alerts.t .............. skipped: test_tls13alerts needs the dynamic engine feature enabled 70-test_tls13cookie.t .............. skipped: test_tls13cookie needs the dynamic engine feature enabled 70-test_tls13downgrade.t ........... skipped: test_tls13downgrade needs the dynamic engine feature enabled 70-test_tls13hrr.t ................. skipped: test_tls13hrr needs the dynamic engine feature enabled 70-test_tls13kexmodes.t ............ skipped: test_tls13kexmodes needs the dynamic engine feature enabled 70-test_tls13messages.t ............ skipped: test_tls13messages needs the dynamic engine feature enabled 70-test_tls13psk.t ................. skipped: test_tls13psk needs the dynamic engine feature enabled 70-test_tlsextms.t ................. skipped: test_tlsextms needs the dynamic engine feature enabled 70-test_verify_extra.t ............. ok 70-test_wpacket.t .................. ok 71-test_ssl_ctx.t .................. ok 79-test_http.t ..................... ok 80-test_ca.t ....................... ok 80-test_cipherbytes.t .............. ok 80-test_cipherlist.t ............... ok 80-test_ciphername.t ............... ok # Killing mock server with pid=1267980-test_cmp_http.t ................. ok # 80-test_cms.t ...................... ok 80-test_cmsapi.t ................... ok 80-test_ct.t ....................... ok 80-test_dane.t ..................... ok 80-test_dtls.t ..................... ok 80-test_dtls_mtu.t ................. ok 80-test_dtlsv1listen.t ............. ok 80-test_ocsp.t ..................... ok 80-test_pkcs12.t ................... ok 80-test_ssl_new.t .................. ok 80-test_ssl_old.t .................. ok 80-test_ssl_test_ctx.t ............. ok 80-test_sslcorrupt.t ............... ok 80-test_tsa.t ...................... ok 80-test_x509aux.t .................. ok 81-test_cmp_cli.t .................. ok 90-test_asn1_time.t ................ ok 90-test_async.t .................... ok 90-test_bio_enc.t .................. ok 90-test_bio_memleak.t .............. ok 90-test_constant_time.t ............ ok 90-test_fatalerr.t ................. ok 90-test_fipsload.t ................. skipped: Test is disabled with disabled fips 90-test_gmdiff.t ................... ok ../../util/wrap.pl ../../test/igetest => 138 not ok 1 - running igetest # ------------------------------------------------------------------------------ # Failed test 'running igetest' # at /opt/bw/build/openssl-3.0.0-beta1_sunos5.10_sparcv9.002/util/perl/OpenSSL/Test/Simple.pm line 77. # Looks like you failed 1 test of 1.90-test_ige.t ...................... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests 90-test_includes.t ................. ok 90-test_memleak.t .................. ok 90-test_overhead.t ................. ok 90-test_secmem.t ................... ok 90-test_shlibload.t ................ ok 90-test_srp.t ...................... ok 90-test_sslapi.t ................... ok 90-test_sslbuffers.t ............... ok 90-test_store.t .................... ok 90-test_sysdefault.t ............... ok 90-test_threads.t .................. ok 90-test_time_offset.t .............. ok 90-test_tls13ccs.t ................. ok 90-test_tls13encryption.t .......... ok 90-test_tls13secrets.t ............. ok 90-test_v3name.t ................... ok 91-test_pkey_check.t ............... ok 95-test_external_gost_engine.t ..... skipped: No external tests in this configuration 95-test_external_krb5.t ............ skipped: No external tests in this configuration 95-test_external_pyca.t ............ skipped: No external tests in this configuration 99-test_ecstress.t ................. ok 99-test_fuzz_asn1.t ................ ok 99-test_fuzz_asn1parse.t ........... ok 99-test_fuzz_bignum.t .............. ok 99-test_fuzz_bndiv.t ............... ok 99-test_fuzz_client.t .............. ok 99-test_fuzz_cmp.t ................. ok 99-test_fuzz_cms.t ................. ok 99-test_fuzz_conf.t ................ ok 99-test_fuzz_crl.t ................. ok 99-test_fuzz_ct.t .................. ok 99-test_fuzz_server.t .............. ok 99-test_fuzz_x509.t ................ ok Test Summary Report ------------------- 03-test_internal_modes.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 61-test_bio_prefix.t (Wstat: 512 Tests: 4 Failed: 2) Failed tests: 1, 3 Non-zero exit status: 2 90-test_ige.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 Files=239, Tests=2815, 7127 wallclock secs (18.23 usr 2.34 sys + 6784.88 cusr 151.77 csys = 6957.22 CPU) Result: FAIL gmake[1]: *** [Makefile:830: run_tests] Error 1 gmake[1]: Leaving directory '/opt/bw/build/openssl-3.0.0-beta1_sunos5.10_sparcv9.002' gmake: *** [Makefile:826: tests] Error 2 Yes it really did take a very very long time to run and at times I thought the tests had stalled. That may be likely due to the fact that I went with a no-asm build and debug options with no optimizations. I will likely want to be able to single step into this later. If anyone has thoughts on the test failures please let me know. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From andreaerdna at libero.it Wed Jul 28 09:22:44 2021 From: andreaerdna at libero.it (Andrea Giudiceandrea) Date: Wed, 28 Jul 2021 11:22:44 +0200 Subject: Wrong signature type error trying to connect to gibs.earthdata.nasa.gov on Ubuntu 20.04 In-Reply-To: <9f2851e0-099a-4646-ba77-a38b0498890d@t8m.info> References: <9f2851e0-099a-4646-ba77-a38b0498890d@t8m.info> Message-ID: Hi ?Tom??? and openssl users, finally the server at gibs.earthdata.nasa.gov was upgraded in order to support SHA256 (instead of SHA1) as peer signing digest algorithm. So, it is now possible to properly connect to it on Ubuntu 20.04 without the need of lower the default SECURITY LEVEL from 2 to 1. Regards. Andrea Giudiceandrea Il 14/08/2020 08:41, Tomas Mraz ha scritto: > It is not a bug in OpenSSL and it is not a misconfiguration or non-compliance on the server side either. Basically to enhance security the default seclevel on Debian and Ubuntu was raised to 2 which doesn't allow SHA1 signatures which are weak. The server apparently doesn't support them which indicates that it is some older implementation but that doesn't necessarily mean it is non-compliant. It is just less capable. > > However the SHA1 signatures are regarded as seriously weakened currently, so it would be certainly a very good idea to upgrade/fix the server to support SHA2 based signatures. > > ?Tom??? Mr?z From matt at openssl.org Thu Jul 29 15:30:46 2021 From: matt at openssl.org (Matt Caswell) Date: Thu, 29 Jul 2021 15:30:46 +0000 Subject: OpenSSL version VERSION published Message-ID: <20210729153046.GA8417@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 3.0 beta 2 released =================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in beta. OpenSSL 3.0 beta 2 has now been made available. We anticipate that this release candidate will be the final beta release and, barring critical problems, that the final OpenSSL 3.0.0 release will occur in the next one to two weeks. Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. Specific notes on upgrading to OpenSSL 3.0 from previous versions are available in the OpenSSL Migration Guide, here: https://www.openssl.org/docs/manmaster/man7/migration_guide.html Two items of interest: * FIPS 140-2 algorithm testing for the operational environments is currently in progress and OpenSSL 3.0 will be submitted to NIST for validation before the September 21st dead line. * Engines are deprecated and will be removed in a future release. The new provider concept should be used instead. The beta release is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.0.0-beta2.tar.gz Size: 14912360 SHA1 checksum: 261ea1ad4bbf7738622bea5caa97da0283fc3166 SHA256 checksum: e76ab22879201b12f014393ee4becec7f264d8f6955b1036839128002868df71 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-beta2.tar.gz openssl sha256 openssl-3.0.0-beta2.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----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmECwXsACgkQ2cTSbQ5g RJGIogf/d+wGwy6MQ5sYFU1skRVvJ05xXOgV9c9YwxO5UmyC3V2p6YHd6oXOhi17 lxbd5o8l9mtuIWKIMo9r222LIE8DtSrwdnO8BMpRBzxT56pUKHuF+qVmMnxOhuU6 jGkKjK6Tel8k4jLCJriRF8G0EWnWClqmvuz6z2rQkzVVcTh/TrtIJn+uMzjg1ZyZ 9T5/TljLQTtsAnx0F6i3TxgOShNpYhObWxyy4byncDX6YPdcedwHREJkhpS3pIh7 DKySPOZicP5jgHDSmp2Ip1Zl6/yTTpcQ1ncd+MHK2fPLtKmr50aCD3MF9qj49kgQ JoXg93pEYV1gdf5aya+TgS+j5VjKeA== =JLdr -----END PGP SIGNATURE----- From om at integral.be Fri Jul 30 12:57:34 2021 From: om at integral.be (Olivier Mascia) Date: Fri, 30 Jul 2021 14:57:34 +0200 Subject: Accessing bignums of a RSA key with OpenSSL 3.0? Message-ID: <73A02CB4-2415-4F1D-8C1C-6A7033733C38@integral.be> Dear all, Testing migration to OpenSSL 3.0. Got to update some code building a JWK (in relation to ACME LetsEncrypt protocols). Having an EVP_PKEY which happens to be a RSA key, I proceeded this way (1.1.1) to extract the bignums needed for inclusion into the JWK: // Access the numerical components of the certificate RSA keys. BIGNUM* n; BIGNUM* e; BIGNUM* d; RSA_get0_key(cert.RSAkey(), &n, &e, &d); ( my cert.RSAkey() returned RSA* from my embedded EVP_PKEY* through EVP_PKEY_get0_RSA() ) I understand I should now start straight from the EVP_PKEY and use : EVP_PKEY_get_bn_param(cert.key(), "name-n?", &n); EVP_PKEY_get_bn_param(cert.key(), "name-e?", &e); EVP_PKEY_get_bn_param(cert.key(), "name-d?", &d); ( cert.key() returns EVP_KEY* ) The question is: where can I find the proper names for these bignums out of a RSA key? __ Best Regards, Meilleures salutations, Met vriendelijke groeten, Mit freundlichen Gr??en, Olivier Mascia From pauli at openssl.org Fri Jul 30 13:07:18 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Fri, 30 Jul 2021 23:07:18 +1000 Subject: Accessing bignums of a RSA key with OpenSSL 3.0? In-Reply-To: <73A02CB4-2415-4F1D-8C1C-6A7033733C38@integral.be> References: <73A02CB4-2415-4F1D-8C1C-6A7033733C38@integral.be> Message-ID: Try: include/openssl/core_names.h The names are "n", "e" and "d" in this case. Pauli On 30/7/21 10:57 pm, Olivier Mascia via openssl-users wrote: > Dear all, > > Testing migration to OpenSSL 3.0. > Got to update some code building a JWK (in relation to ACME LetsEncrypt protocols). > > Having an EVP_PKEY which happens to be a RSA key, I proceeded this way (1.1.1) to extract the bignums needed for inclusion into the JWK: > > // Access the numerical components of the certificate RSA keys. > BIGNUM* n; > BIGNUM* e; > BIGNUM* d; > RSA_get0_key(cert.RSAkey(), &n, &e, &d); > > ( my cert.RSAkey() returned RSA* from my embedded EVP_PKEY* through EVP_PKEY_get0_RSA() ) > > I understand I should now start straight from the EVP_PKEY and use : > > EVP_PKEY_get_bn_param(cert.key(), "name-n?", &n); > EVP_PKEY_get_bn_param(cert.key(), "name-e?", &e); > EVP_PKEY_get_bn_param(cert.key(), "name-d?", &d); > > ( cert.key() returns EVP_KEY* ) > > The question is: where can I find the proper names for these bignums out of a RSA key? > > __ > Best Regards, Meilleures salutations, Met vriendelijke groeten, Mit freundlichen Gr??en, > Olivier Mascia > > From om at integral.be Fri Jul 30 13:29:59 2021 From: om at integral.be (Olivier Mascia) Date: Fri, 30 Jul 2021 15:29:59 +0200 Subject: Accessing bignums of a RSA key with OpenSSL 3.0? In-Reply-To: References: <73A02CB4-2415-4F1D-8C1C-6A7033733C38@integral.be> Message-ID: Thanks! BIGNUM* n; BIGNUM* e; BIGNUM* d; EVP_PKEY_get_bn_param(cert.key(), OSSL_PKEY_PARAM_RSA_N, &n); EVP_PKEY_get_bn_param(cert.key(), OSSL_PKEY_PARAM_RSA_E, &e); EVP_PKEY_get_bn_param(cert.key(), OSSL_PKEY_PARAM_RSA_D, &d); Now, the reverse exercise for me: to create another RSA key, solely through EVP_PKEY interfaces (knowing these n, e, d parameters), I think I should go this route: mKey = EVP_PKEY_new(); EVP_PKEY_set_type(mKey, some int type ?); EVP_PKEY_set_bn_param(mKey, OSSL_PKEY_PARAM_RSA_N, n2); EVP_PKEY_set_bn_param(mKey, OSSL_PKEY_PARAM_RSA_E, e2); EVP_PKEY_set_bn_param(mKey, OSSL_PKEY_PARAM_RSA_D, d2); But how to get the proper int type to pass to EVP_PKEY_set_type()? Thanks all for support switching to OpenSSL 3.0. __ Best Regards, Meilleures salutations, Met vriendelijke groeten, Mit freundlichen Gr??en, Olivier Mascia > Le 30 juil. 2021 ? 15:07, Dr Paul Dale a ?crit : > > Try: include/openssl/core_names.h > The names are "n", "e" and "d" in this case. > > > Pauli > > > On 30/7/21 10:57 pm, Olivier Mascia via openssl-users wrote: >> Dear all, >> >> Testing migration to OpenSSL 3.0. >> Got to update some code building a JWK (in relation to ACME LetsEncrypt protocols). >> >> Having an EVP_PKEY which happens to be a RSA key, I proceeded this way (1.1.1) to extract the bignums needed for inclusion into the JWK: >> >> // Access the numerical components of the certificate RSA keys. >> BIGNUM* n; >> BIGNUM* e; >> BIGNUM* d; >> RSA_get0_key(cert.RSAkey(), &n, &e, &d); >> >> ( my cert.RSAkey() returned RSA* from my embedded EVP_PKEY* through EVP_PKEY_get0_RSA() ) >> >> I understand I should now start straight from the EVP_PKEY and use : >> >> EVP_PKEY_get_bn_param(cert.key(), "name-n?", &n); >> EVP_PKEY_get_bn_param(cert.key(), "name-e?", &e); >> EVP_PKEY_get_bn_param(cert.key(), "name-d?", &d); >> >> ( cert.key() returns EVP_KEY* ) >> >> The question is: where can I find the proper names for these bignums out of a RSA key? >> >> __ >> Best Regards, Meilleures salutations, Met vriendelijke groeten, Mit freundlichen Gr??en, >> Olivier Mascia >> >> > From matt at openssl.org Fri Jul 30 13:47:41 2021 From: matt at openssl.org (Matt Caswell) Date: Fri, 30 Jul 2021 14:47:41 +0100 Subject: Accessing bignums of a RSA key with OpenSSL 3.0? In-Reply-To: References: <73A02CB4-2415-4F1D-8C1C-6A7033733C38@integral.be> Message-ID: <853b64cd-b178-d8f8-c5a6-176c873cb3ae@openssl.org> Note that the names are also documented here: https://www.openssl.org/docs/manmaster/man7/EVP_KEYMGMT-RSA.html On 30/07/2021 14:29, Olivier Mascia via openssl-users wrote: > Thanks! > > BIGNUM* n; > BIGNUM* e; > BIGNUM* d; > EVP_PKEY_get_bn_param(cert.key(), OSSL_PKEY_PARAM_RSA_N, &n); > EVP_PKEY_get_bn_param(cert.key(), OSSL_PKEY_PARAM_RSA_E, &e); > EVP_PKEY_get_bn_param(cert.key(), OSSL_PKEY_PARAM_RSA_D, &d); > > Now, the reverse exercise for me: to create another RSA key, solely through EVP_PKEY interfaces (knowing these n, e, d parameters), I think I should go this route: > > mKey = EVP_PKEY_new(); > EVP_PKEY_set_type(mKey, some int type ?); > > EVP_PKEY_set_bn_param(mKey, OSSL_PKEY_PARAM_RSA_N, n2); > EVP_PKEY_set_bn_param(mKey, OSSL_PKEY_PARAM_RSA_E, e2); > EVP_PKEY_set_bn_param(mKey, OSSL_PKEY_PARAM_RSA_D, d2); > > But how to get the proper int type to pass to EVP_PKEY_set_type()? Don't do it like this. Instead you need to use EVP_PKEY_fromdata(): https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_fromdata.html Here's an example of doing it with DSA. The same principle applies to RSA: https://github.com/openssl/openssl/blob/5540855bda5e58f4b33f2306feb6ff4e93c0af81/apps/testdsa.h#L239-L268 Matt > > Thanks all for support switching to OpenSSL 3.0. > __ > Best Regards, Meilleures salutations, Met vriendelijke groeten, Mit freundlichen Gr??en, > Olivier Mascia > >> Le 30 juil. 2021 ? 15:07, Dr Paul Dale a ?crit : >> >> Try: include/openssl/core_names.h >> The names are "n", "e" and "d" in this case. >> >> >> Pauli >> >> >> On 30/7/21 10:57 pm, Olivier Mascia via openssl-users wrote: >>> Dear all, >>> >>> Testing migration to OpenSSL 3.0. >>> Got to update some code building a JWK (in relation to ACME LetsEncrypt protocols). >>> >>> Having an EVP_PKEY which happens to be a RSA key, I proceeded this way (1.1.1) to extract the bignums needed for inclusion into the JWK: >>> >>> // Access the numerical components of the certificate RSA keys. >>> BIGNUM* n; >>> BIGNUM* e; >>> BIGNUM* d; >>> RSA_get0_key(cert.RSAkey(), &n, &e, &d); >>> >>> ( my cert.RSAkey() returned RSA* from my embedded EVP_PKEY* through EVP_PKEY_get0_RSA() ) >>> >>> I understand I should now start straight from the EVP_PKEY and use : >>> >>> EVP_PKEY_get_bn_param(cert.key(), "name-n?", &n); >>> EVP_PKEY_get_bn_param(cert.key(), "name-e?", &e); >>> EVP_PKEY_get_bn_param(cert.key(), "name-d?", &d); >>> >>> ( cert.key() returns EVP_KEY* ) >>> >>> The question is: where can I find the proper names for these bignums out of a RSA key? >>> >>> __ >>> Best Regards, Meilleures salutations, Met vriendelijke groeten, Mit freundlichen Gr??en, >>> Olivier Mascia >>> >>> >> > > From kgoldman at us.ibm.com Fri Jul 30 16:55:25 2021 From: kgoldman at us.ibm.com (Ken Goldman) Date: Fri, 30 Jul 2021 12:55:25 -0400 Subject: EVP_MD_CTX_free documentation Message-ID: It would be nice if the documentation would guarantee that this function is a no-op when the parameter is NULL - like the standard free() call. This would save coding (if not NULL) all the time. Same comment for all the _free functions. I know I can look at the code, but that doesn't provide an API guarantee. From matt at openssl.org Fri Jul 30 19:03:03 2021 From: matt at openssl.org (Matt Caswell) Date: Fri, 30 Jul 2021 20:03:03 +0100 Subject: EVP_MD_CTX_free documentation In-Reply-To: References: Message-ID: <0100df9d-d8eb-ebb5-7045-fc6c38581ca3@openssl.org> All our _free functions will accept NULL. We rely on this extensively *everywhere*. We perhaps could be better at documenting it, but you can rely on it. Matt On 30/07/2021 17:55, Ken Goldman wrote: > It would be nice if the documentation would guarantee that > this function is a no-op when the parameter is NULL - like > the standard free() call. > > This would save coding (if not NULL) all the time. > > Same comment for all the _free functions. > > I know I can look at the code, but that doesn't > provide an API guarantee. > From Vlad.Malkin at viasat.com Fri Jul 30 20:49:33 2021 From: Vlad.Malkin at viasat.com (Malkin, Vlad) Date: Fri, 30 Jul 2021 20:49:33 +0000 Subject: Algorithms Used for openssl- pkcs12 Message-ID: Hello We're unable to find documentation on the specific standards/algorithms used by the openssl -pkcs12 command for OpenSSL version 1.1.1k. Specifically, when a password is used (-password) for private key wrap key derivation, is the algorithm compliant with NIST SP 800-132? Also, when the AES-256 is selected for private key wrap (-aes256), is the implementation compliant with NIST 800-38F? Any help will be greatly appreciated! --Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgoldman at us.ibm.com Fri Jul 30 23:28:05 2021 From: kgoldman at us.ibm.com (Ken Goldman) Date: Fri, 30 Jul 2021 19:28:05 -0400 Subject: EVP_MD_CTX_free documentation In-Reply-To: <0100df9d-d8eb-ebb5-7045-fc6c38581ca3@openssl.org> References: <0100df9d-d8eb-ebb5-7045-fc6c38581ca3@openssl.org> Message-ID: Thanks. It would be good to document it (and that all the _new's return NULL on an error). On 7/30/2021 3:03 PM, Matt Caswell wrote: > All our _free functions will accept NULL. We rely on this extensively *everywhere*. We perhaps could be better at documenting it, but you can rely on it. > > Matt > > On 30/07/2021 17:55, Ken Goldman wrote: >> It would be nice if the documentation would guarantee that >> this function is a no-op when the parameter is NULL - like >> the standard free() call. >> >> This would save coding (if not NULL) all the time. >> >> Same comment for all the _free functions. >> >> I know I can look at the code, but that doesn't >> provide an API guarantee. >> >