From levitte at openssl.org Sun Dec 1 12:20:40 2019 From: levitte at openssl.org (Richard Levitte) Date: Sun, 01 Dec 2019 13:20:40 +0100 Subject: Writing an ENGINE for OpenSSL-1.1.1 and 3.0 In-Reply-To: References: Message-ID: <87imn0xmnb.wl-levitte@openssl.org> When you say you put it in "the appropriate of the lib/", what directory is that exactly? Does it correspond to the output of "openssl3 version -e"? On Sun, 01 Dec 2019 00:58:00 +0100, Blumenthal, Uri - 0553 - MITLL wrote: > > > In preparation for writing a new engine that supports message digest and asymmetric crypto (sign > and decrypt), I am trying to port the existing simple/demo engines from the Engine Corner examples > (thanks, Richard!). > > The fork of https://github.com/engine-corner/Lesson-2-A-digest.git that compiles and runs > correctly (apparently) on OpenSSL-1.1.1 is https://github.com/mouse07410/Lesson-2-A-digest.git . > > But no matter what, I was unable to make either of these two repos to run successfully with > OpenSSL-3.0 (master), even though the latter repo at least seems to compile correctly, and answers > ?Available?. Here?s what I?m getting (for both versions I built the sample ?emd5?engine and copied > to the appropriate subdir of the lib/; ?openssl3? is an alias that points OPENSSL_CONF at the > correct file, and invokes the correct OpenSSL-3.0 ?openssl? binary, as it?s not on the main path): > > $ penssl version > > OpenSSL 1.1.1d 10 Sep 2019 > > $ openssl engine -t -c emd5 > > (emd5) A simple md5 engine for demonstration purposes > > [MD5] > > [ available ] > > $ echo "shoot" | openssl dgst -md5 -engine emd5 > > engine "emd5" set. > > (stdin)= 61a08703a6a4c774cad650afaedd9c10 > > $ echo "shoot" | openssl dgst -md5 > > (stdin)= 61a08703a6a4c774cad650afaedd9c10 > > $ > > $ openssl3 version > > OpenSSL 3.0.0-dev xx XXX xxxx (Library: OpenSSL 3.0.0-dev xx XXX xxxx) > > $ openssl3 engine -t -vv -c emd5 > > (emd5) A simple md5 engine for demonstration purposes > > [MD5] > > [ available ] > > $ echo "shoot" | openssl3 dgst -md5 > > MD5(stdin)= 61a08703a6a4c774cad650afaedd9c10 > > $ echo "shoot" | openssl3 dgst -md5 -engine emd5 > > engine "emd5" set. > > Error setting digest > > C0:05:98:0C:01:00:00:00:error:digital envelope routines:EVP_DigestInit_ex:initialization > error:crypto/evp/digest.c:224: > > $ > > Something must be missing from the configuration/setup ? but what?? Help would be greatly > appreciated! > > Thanks! > > ? > > Regards, > > Uri > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From aeris+openssl at imirhil.fr Mon Dec 2 20:05:33 2019 From: aeris+openssl at imirhil.fr (aeris) Date: Mon, 02 Dec 2019 21:05:33 +0100 Subject: SNI disable by default on 1.0 and 1.1.0? Message-ID: <2160996.fJFgsvPLcY@endor> Hello here, I try to compile 1.0.2t and 1.1.0l, but I notice SNI seems disabled by default, when it's enabled by default on 1.1.1d? openssl-1.0.2t $ ./config enable-tlsext && make $ echo -n "" | ./apps/openssl s_client -connect blog.imirhil.fr:443 | ./apps/ openssl x509 -noout -subject subject= /CN=localhost # No SNI by default, default vhost, bad certificate $ echo -n "" | ./apps/openssl s_client -connect blog.imirhil.fr:443 - servername blog.imirhil.fr | ./apps/openssl x509 -noout -subject subject= /CN=blog.imirhil.fr # SNI, correct vhost, good certificate openssl-1.1.1d $ ./config && make $ echo -n "" | ./apps/openssl s_client -connect blog.imirhil.fr:443 | ./apps/ openssl x509 -noout -subject subject= /CN=blog.imirhil.fr # SNI by default, correct vhost, good certificate According to changelog, enable-tlsext is available since 0.9.8f and by default since 0.9.8j, but seems something is wrong somewhere? The observed behaviour breaks all applications which don't set SNI explicitly, hitting the default vhost and not the real content? Is there any way to force SNI activation by default at build time on pre 1.1.1 versions, like under 1.1.1d ? Regards, -- aeris Individual crypto-terrorist group self-radicalized on the digital darknet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://caf?-vie-priv?e.fr/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From openssl-users at dukhovni.org Mon Dec 2 20:48:29 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 2 Dec 2019 15:48:29 -0500 Subject: SNI disable by default on 1.0 and 1.1.0? In-Reply-To: <2160996.fJFgsvPLcY@endor> References: <2160996.fJFgsvPLcY@endor> Message-ID: <20191202204829.GN34850@straasha.imrryr.org> On Mon, Dec 02, 2019 at 09:05:33PM +0100, aeris wrote: > I try to compile 1.0.2t and 1.1.0l, but I notice SNI seems disabled by > default, when it's enabled by default on 1.1.1d? SNI is not "disabled" in any of these versions, it is not just turned on by default in the s_client command-line utility (a testing tool). The OpenSSL library does not by default turn on SNI in any of these releases. The application code has to call SSL_set_tlsext_host_name(3) in order to enable SNI. > The observed behaviour breaks all applications which don't set SNI explicitly, > hitting the default vhost and not the real content? Applications have to set SNI explicitly. > Is there any way to force SNI activation by default at build time on pre 1.1.1 > versions, like under 1.1.1d ? No, and the same applies to 1.1.1d. -- Viktor. From bkaduk at akamai.com Mon Dec 2 20:52:55 2019 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Mon, 2 Dec 2019 12:52:55 -0800 Subject: SNI disable by default on 1.0 and 1.1.0? In-Reply-To: <2160996.fJFgsvPLcY@endor> References: <2160996.fJFgsvPLcY@endor> Message-ID: <20191202205254.GL3397@akamai.com> On Mon, Dec 02, 2019 at 09:05:33PM +0100, aeris wrote: > Hello here, > > I try to compile 1.0.2t and 1.1.0l, but I notice SNI seems disabled by > default, when it's enabled by default on 1.1.1d? Please specify whether you are concerned about the s_client behavior specifically or the libssl library behavior. > openssl-1.0.2t > $ ./config enable-tlsext && make > $ echo -n "" | ./apps/openssl s_client -connect blog.imirhil.fr:443 | ./apps/ > openssl x509 -noout -subject > subject= /CN=localhost # No SNI by default, default vhost, bad certificate > $ echo -n "" | ./apps/openssl s_client -connect blog.imirhil.fr:443 - > servername blog.imirhil.fr | ./apps/openssl x509 -noout -subject > subject= /CN=blog.imirhil.fr # SNI, correct vhost, good certificate > > openssl-1.1.1d > $ ./config && make > $ echo -n "" | ./apps/openssl s_client -connect blog.imirhil.fr:443 | ./apps/ > openssl x509 -noout -subject > subject= /CN=blog.imirhil.fr # SNI by default, correct vhost, good certificate > > According to changelog, enable-tlsext is available since 0.9.8f and by default > since 0.9.8j, but seems something is wrong somewhere? > The observed behaviour breaks all applications which don't set SNI explicitly, > hitting the default vhost and not the real content? > Is there any way to force SNI activation by default at build time on pre 1.1.1 > versions, like under 1.1.1d ? I think your tests are just finding the changes from https://github.com/openssl/openssl/pull/2614 but other applications using libssl still need to use the SSL_set_tlsext_host_name() API in order to send the SNI extension. -Ben From Michael.Wojcik at microfocus.com Mon Dec 2 22:39:26 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 2 Dec 2019 22:39:26 +0000 Subject: SNI disable by default on 1.0 and 1.1.0? In-Reply-To: <20191202204829.GN34850@straasha.imrryr.org> References: <2160996.fJFgsvPLcY@endor> <20191202204829.GN34850@straasha.imrryr.org> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of > Viktor Dukhovni > Sent: Monday, December 02, 2019 13:48 > To: openssl-users at openssl.org > Subject: Re: SNI disable by default on 1.0 and 1.1.0? > > SNI is not "disabled" in any of these versions, it is not just turned on > by default in the s_client command-line utility (a testing tool). The > OpenSSL library does not by default turn on SNI in any of these > releases. The application code has to call SSL_set_tlsext_host_name(3) > in order to enable SNI. And, indeed, how could it be otherwise? The value of the SNI extension should always be the peer name, as intended by the client. Is OpenSSL supposed to discern this by magic? The caller has to tell the library what value to put in the extension. -- Michael Wojcik Distinguished Engineer, Micro Focus From openssl-users at dukhovni.org Mon Dec 2 23:13:36 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 2 Dec 2019 18:13:36 -0500 Subject: SNI disable by default on 1.0 and 1.1.0? In-Reply-To: References: <2160996.fJFgsvPLcY@endor> <20191202204829.GN34850@straasha.imrryr.org> Message-ID: <20191202231336.GR34850@straasha.imrryr.org> On Mon, Dec 02, 2019 at 10:39:26PM +0000, Michael Wojcik wrote: > > SNI is not "disabled" in any of these versions, it is not just turned on > > by default in the s_client command-line utility (a testing tool). The > > OpenSSL library does not by default turn on SNI in any of these > > releases. The application code has to call SSL_set_tlsext_host_name(3) > > in order to enable SNI. > > And, indeed, how could it be otherwise? The value of the SNI extension > should always be the peer name, as intended by the client. Is OpenSSL > supposed to discern this by magic? The caller has to tell the library what > value to put in the extension. Well, OpenSSL does have some interfaces for connecting to a named host, and those could potentially enable SNI by default, but that is not yet the case, and is not necessarily appropriate in all cases. That said enabling SNI for the cases where OpenSSL is doing the name to IP resolution and setting up the socket is perhaps something that can be done in a future major release. -- Viktor. From aeris+openssl at imirhil.fr Tue Dec 3 08:27:47 2019 From: aeris+openssl at imirhil.fr (aeris) Date: Tue, 03 Dec 2019 09:27:47 +0100 Subject: SNI disable by default on 1.0 and 1.1.0? In-Reply-To: <20191202205254.GL3397@akamai.com> References: <2160996.fJFgsvPLcY@endor> <20191202205254.GL3397@akamai.com> Message-ID: <13022337.8PONJLHxin@endor> > I think your tests are just finding the changes from > https://github.com/openssl/openssl/pull/2614 but other applications using > libssl still need to use the SSL_set_tlsext_host_name() API in order to > send the SNI extension. OK got it. I have trouble with certificate verification on software using libssl 1.0.2 and not 1.1.1. And when debugging, I spot the difference of behaviour with openssl client which also generate _the same_ verification error. This confuse me? Network debugging the flow show SNI in both case with libssl. In fact my real problem was because OPENSSLDIR are not the same, and 1.0.2 have no CA but 1.1.1 have one? Regards, -- aeris Individual crypto-terrorist group self-radicalized on the digital darknet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://caf?-vie-priv?e.fr/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From angus at magsys.co.uk Tue Dec 3 16:30:00 2019 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Tue, 3 Dec 2019 16:30 +0000 (GMT Standard Time) Subject: Json Web Keys again Message-ID: Google has started using RSA-PSS private keys for Json Web Keys. I create an RSA JWK using EVP_PKEY_get1_RSA and RSA_get0_key, but this does not work for RSA-PSS. EVP_PKEY_print_private does work OK, but parsing data from the output is messy. EVP_PKEY_set_alias_type seemed worth a try, but does not set the base_id. Are there any other workarounds? Is RSA-PSS fully supported in 3.0? Angus From matt at openssl.org Tue Dec 3 16:43:41 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 3 Dec 2019 16:43:41 +0000 Subject: Json Web Keys again In-Reply-To: References: Message-ID: <2c17d235-37f6-679e-2d36-2a4d80476f9d@openssl.org> On 03/12/2019 16:29, Angus Robertson - Magenta Systems Ltd wrote: > Google has started using RSA-PSS private keys for Json Web Keys. > > I create an RSA JWK using EVP_PKEY_get1_RSA and RSA_get0_key, but this > does not work for RSA-PSS. In what way does this not work? Perhaps you are missing access to the PSS parameters? I notice that 3.0 recently had the accessor RSA_get0_pss_params() added. Probably that should also have been backported to 1.1.1. > Are there any other workarounds? Is RSA-PSS fully supported in 3.0? Aside from the possible missing accessor (which looks like a bug), its fully supported in 1.1.1. Matt From angus at magsys.co.uk Tue Dec 3 17:00:00 2019 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Tue, 3 Dec 2019 17:00 +0000 (GMT Standard Time) Subject: Json Web Keys again In-Reply-To: <2c17d235-37f6-679e-2d36-2a4d80476f9d@openssl.org> Message-ID: > > I create an RSA JWK using EVP_PKEY_get1_RSA and RSA_get0_key, > > but this does not work for RSA-PSS. > > In what way does this not work? error:0607907F:digital envelope routines: EVP_PKEY_get0_RSA:expecting an rsa key > I notice that 3.0 recently had the accessor RSA_get0_pss_params() > added. Probably that should also have been backported to 1.1.1. Others have asked for that here before, so please. But I don't need it for JWK. Angus From matt at openssl.org Tue Dec 3 17:04:40 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 3 Dec 2019 17:04:40 +0000 Subject: Json Web Keys again In-Reply-To: References: Message-ID: On 03/12/2019 16:59, Angus Robertson - Magenta Systems Ltd wrote: >>> I create an RSA JWK using EVP_PKEY_get1_RSA and RSA_get0_key, >>> but this does not work for RSA-PSS. >> >> In what way does this not work? > > error:0607907F:digital envelope routines: EVP_PKEY_get0_RSA:expecting > an rsa key Hmm. That is odd because that function *does* support PSS: RSA *EVP_PKEY_get0_RSA(const EVP_PKEY *pkey) { if (pkey->type != EVP_PKEY_RSA && pkey->type != EVP_PKEY_RSA_PSS) { EVPerr(EVP_F_EVP_PKEY_GET0_RSA, EVP_R_EXPECTING_AN_RSA_KEY); return NULL; } return pkey->pkey.rsa; } What does EVP_PKEY_base_id() return for your pkey? How did you create it? Matt > >> I notice that 3.0 recently had the accessor RSA_get0_pss_params() >> added. Probably that should also have been backported to 1.1.1. > > Others have asked for that here before, so please. But I don't need it > for JWK. > > Angus > From angus at magsys.co.uk Tue Dec 3 17:24:00 2019 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Tue, 3 Dec 2019 17:24 +0000 (GMT Standard Time) Subject: Json Web Keys again In-Reply-To: Message-ID: > What does EVP_PKEY_base_id() return for your pkey? How did you > create it? base_id is 912, EVP_PKEY_RSA_PSS=NID_rsassaPss. But my code is Pascal so not using your header files directly, seems okay though. It was created with OpenSSL APIs and EVP_PKEY_print_private reports: RSA-PSS Private-Key: (2048 bit, 2 primes) Angus From matt at openssl.org Tue Dec 3 17:35:39 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 3 Dec 2019 17:35:39 +0000 Subject: Json Web Keys again In-Reply-To: References: Message-ID: <23f4e869-749b-61d4-99de-f5c2d7189542@openssl.org> On 03/12/2019 17:23, Angus Robertson - Magenta Systems Ltd wrote: >> What does EVP_PKEY_base_id() return for your pkey? How did you >> create it? > > base_id is 912, EVP_PKEY_RSA_PSS=NID_rsassaPss. Sorry. My mistake. I actually meant what does EVP_PKEY_id() return. That just does this: int EVP_PKEY_id(const EVP_PKEY *pkey) { return pkey->type; } So if you get EVP_PKEY_RSA_PSS returned from that I don't currently understand how this: RSA *EVP_PKEY_get0_RSA(const EVP_PKEY *pkey) { if (pkey->type != EVP_PKEY_RSA && pkey->type != EVP_PKEY_RSA_PSS) { EVPerr(EVP_F_EVP_PKEY_GET0_RSA, EVP_R_EXPECTING_AN_RSA_KEY); return NULL; } return pkey->pkey.rsa; } Can return the error you saw!! Something strange going on... Matt > > But my code is Pascal so not using your header files directly, seems > okay though. > > It was created with OpenSSL APIs and EVP_PKEY_print_private reports: > RSA-PSS Private-Key: (2048 bit, 2 primes) > > Angus > > > From angus at magsys.co.uk Tue Dec 3 18:03:00 2019 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Tue, 3 Dec 2019 18:03 +0000 (GMT Standard Time) Subject: Json Web Keys again In-Reply-To: <23f4e869-749b-61d4-99de-f5c2d7189542@openssl.org> Message-ID: >> Sorry. My mistake. I actually meant what does EVP_PKEY_id() > return. Also returns 912, the same as base_id. RSA keys both return 6. > So if you get EVP_PKEY_RSA_PSS returned from that I don't > currently understand how this: > > RSA *EVP_PKEY_get0_RSA(const EVP_PKEY *pkey) > { > if (pkey->type != EVP_PKEY_RSA && pkey->type != > EVP_PKEY_RSA_PSS) { > EVPerr(EVP_F_EVP_PKEY_GET0_RSA, > EVP_R_EXPECTING_AN_RSA_KEY); > return NULL; > } > return pkey->pkey.rsa; > } > > Can return the error you saw!! Something strange going on... Agreed, code looks clear enough, but was this was for 1.1.1 or master? Just created a new RSA-PSS key with the latest OpenSSL and same error. Angus From matt at openssl.org Tue Dec 3 18:53:57 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 3 Dec 2019 18:53:57 +0000 Subject: Json Web Keys again In-Reply-To: References: Message-ID: <93226d0e-d551-a4ce-f63d-f3d4270bf22c@openssl.org> On 03/12/2019 18:02, Angus Robertson - Magenta Systems Ltd wrote: >>> Sorry. My mistake. I actually meant what does EVP_PKEY_id() >> return. > > Also returns 912, the same as base_id. RSA keys both return 6. > >> So if you get EVP_PKEY_RSA_PSS returned from that I don't >> currently understand how this: >> >> RSA *EVP_PKEY_get0_RSA(const EVP_PKEY *pkey) >> { >> if (pkey->type != EVP_PKEY_RSA && pkey->type != >> EVP_PKEY_RSA_PSS) { >> EVPerr(EVP_F_EVP_PKEY_GET0_RSA, >> EVP_R_EXPECTING_AN_RSA_KEY); >> return NULL; >> } >> return pkey->pkey.rsa; >> } >> >> Can return the error you saw!! Something strange going on... > > Agreed, code looks clear enough, but was this was for 1.1.1 or master? This code looks the same in 1.1.1 and master. Perhaps some form of memory corruption? Maybe you could step through it in a debugger? Matt > > Just created a new RSA-PSS key with the latest OpenSSL and same error. > > Angus > > > From angus at magsys.co.uk Tue Dec 3 19:08:00 2019 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Tue, 3 Dec 2019 19:08 +0000 (GMT Standard Time) Subject: Json Web Keys again In-Reply-To: <93226d0e-d551-a4ce-f63d-f3d4270bf22c@openssl.org> Message-ID: > > Agreed, code looks clear enough, but was this was for 1.1.1 or > > master? > > This code looks the same in 1.1.1 and master. It seems the EVP_PKEY_RSA_PSS addition was only committed 28th October 2019, so need to wait for 1.1.1e, hopefully real soon... RSA_get0_pss_params as well would be good. Thanks for your help. Angus From openssl at eckner.net Wed Dec 4 08:25:56 2019 From: openssl at eckner.net (Erich Eckner) Date: Wed, 4 Dec 2019 09:25:56 +0100 (CET) Subject: verbosity of `openssl ca` error Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I'm trying to sign a csr by running `CA=signing-ca openssl ca -verbose -config /etc/simple-pki/ca-ssl.conf -name signing_ca -in /tmp/tmp.Qz3EoKa0S4/fileserver-lo.ddns.eckner.net.csr -out /tmp/tmp.Qz3EoKa0S4/fileserver-lo.ddns.eckner.net.crt -extensions server_ext` but it fails with exit code 1, solely printing the message "Using configuration from /etc/simple-pki/ca-ssl.conf" How can I see what's going wrong? Should I use gdb and/or strace to find what the issue is or is there an easier option to enable debug output? For the sake of completeness, here comes the content of - -------->8--------/etc/simple-pki/ca-ssl.conf----------->8-------------- # Simple Root & Signing CA # The [default] section contains global constants that can be referred to from # the entire configuration file. It may also hold settings pertaining to more # than one openssl command. [ default ] ca = $ENV::CA dir = /etc/simple-pki # Top dir # The next part of the configuration file is used by the openssl req command. # It defines the CA's key pair, its DN, and the desired extensions for the CA # certificate. [ req ] default_bits = 4096 # RSA key size encrypt_key = no # Protect private key default_md = sha1 # MD to use utf8 = yes # Input is UTF-8 string_mask = utf8only # Emit UTF-8 strings prompt = no # Don't prompt for DN distinguished_name = ca_dn # DN section req_extensions = ca_reqext # Desired extensions [ ca_dn ] 0.domainComponent = "net" 1.domainComponent = "eckner" organizationName = "Eckner Net" organizationalUnitName = "Eckner Net CA" commonName = "Eckner Net Root CA" [ ca_reqext ] keyUsage = critical,keyCertSign,cRLSign basicConstraints = critical,CA:true subjectKeyIdentifier = hash # The remainder of the configuration file is used by the openssl ca command. # The CA section defines the locations of CA assets, as well as the policies # applying to the CA. [ root_ca ] certificate = $dir/ca/$ca.crt # The CA cert private_key = $dir/ca/$ca/private/$ca.key # CA private key new_certs_dir = $dir/ca/$ca # Certificate archive serial = $dir/ca/$ca/db/$ca.crt.srl # Serial number file crlnumber = $dir/ca/$ca/db/$ca.crl.srl # CRL number file database = $dir/ca/$ca/db/$ca.db # Index file unique_subject = no # Require unique subject default_days = 365 # How long to certify for default_md = sha1 # MD to use policy = match_pol # Default naming policy email_in_dn = no # Add email to cert DN preserve = no # Keep passed DN ordering name_opt = ca_default # Subject DN display options cert_opt = ca_default # Certificate display options copy_extensions = none # Copy extensions from CSR x509_extensions = signing_ca_ext # Default cert extensions default_crl_days = 30 # How long before next CRL crl_extensions = crl_ext # CRL extensions [ signing_ca ] certificate = $dir/ca/$ca.crt # The CA cert private_key = $dir/ca/$ca/private/$ca.key # CA private key new_certs_dir = $dir/ca/$ca # Certificate archive serial = $dir/ca/$ca/db/$ca.crt.srl # Serial number file crlnumber = $dir/ca/$ca/db/$ca.crl.srl # CRL number file database = $dir/ca/$ca/db/$ca.db # Index file unique_subject = no # Require unique subject default_days = 60 # How long to certify for default_md = sha1 # MD to use policy = match_pol # Default naming policy email_in_dn = no # Add email to cert DN preserve = no # Keep passed DN ordering name_opt = ca_default # Subject DN display options cert_opt = ca_default # Certificate display options copy_extensions = copy # Copy extensions from CSR x509_extensions = email_ext # Default cert extensions default_crl_days = 7 # How long before next CRL crl_extensions = crl_ext # CRL extensions # Naming policies control which parts of a DN end up in the certificate and # under what circumstances certification should be denied. [ match_pol ] domainComponent = match # Must match 'simple.org' organizationName = match # Must match 'Simple Inc' organizationalUnitName = optional # Included if present commonName = supplied # Must be present [ any_pol ] domainComponent = optional countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = optional emailAddress = optional # Certificate extensions define what types of certificates the CA is able to # create. [ root_ca_ext ] keyUsage = critical,keyCertSign,cRLSign basicConstraints = critical,CA:true subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always [ signing_ca_ext ] keyUsage = critical,keyCertSign,cRLSign basicConstraints = critical,CA:true,pathlen:0 subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always # Certificate extensions define what types of certificates the CA is able to # create. [ email_ext ] keyUsage = critical,digitalSignature,keyEncipherment basicConstraints = CA:false extendedKeyUsage = emailProtection,clientAuth subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always [ server_ext ] keyUsage = critical,digitalSignature,keyEncipherment basicConstraints = CA:false extendedKeyUsage = serverAuth,clientAuth subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always # CRL extensions exist solely to point to the CA certificate that has issued # the CRL. [ crl_ext ] authorityKeyIdentifier = keyid:always - --------8<--------/etc/simple-pki/ca-ssl.conf-----------8<-------------- regards, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl3nbZcACgkQCu7JB1Xa e1pJdQ//fCLL2aBokfMvsVB7y5nEegxYZ6IVNnPSFAO4dBXkvnQ5AjiF+f2U7H05 I6pzGoYO1obyPyqm49TRfcOW4J3RbQ/k4JKtqW/eplqwOMGZ0QhHmGQNOIn9RDkR FIYeKZlQN92ArOC2SAY6Br9l9ok7ovd8ScvOR9aKga1usG5TRHh5GrzzM7tdVAoM 3RGzm+X+/8efOTchkt2rYZcTf9hhzuvHXcZfJtxnGxuXAQfaXhaLN5x91lQ6qJJc houZqLXHznuygYyM21steeW0bCJjWZS664HB3pnPXaRiz6R4WO5bJTGBIElGpDA8 wBimQGViR++GN+4ZNLX0ha+OZYdACewakR5qXJhJIKThJwpfOpm7aFHqHvijYN+/ dw9Z16rTlXLenBbJIji57KFtv9p3VvzHCyo1RXFpcEGW5NFw3bSBXkoR0UrlB9tj /Mr3gL22YzrNB5MKUsdypunypTJ5J9Et1fxjPpRYzwm+uDaH/ktTKXX5O2VQ+9S7 yraG0G3Pkw6LX8ElcmwoBHtxccGMuXf41owPAMvCf+QaIJ9XsaMt6YlbbXhZEx60 wcD3n7QXkoLKkxQpoolnaW48PVqOr08FdNhEUD3rtML3nGCxC+Wmwh7xOCprUtq2 JnbYs8ShICnrts0GMLuJWEbwUI/IgiOWucPQ0ex9GO38+me5/Ck= =Ho1j -----END PGP SIGNATURE----- From matt at openssl.org Wed Dec 4 10:34:51 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 4 Dec 2019 10:34:51 +0000 Subject: Json Web Keys again In-Reply-To: References: Message-ID: On 03/12/2019 19:07, Angus Robertson - Magenta Systems Ltd wrote: >>> Agreed, code looks clear enough, but was this was for 1.1.1 or >>> master? >> >> This code looks the same in 1.1.1 and master. > > It seems the EVP_PKEY_RSA_PSS addition was only committed 28th October > 2019, so need to wait for 1.1.1e, hopefully real soon... Ah, that explains it! > > RSA_get0_pss_params as well would be good. Backport PR here: https://github.com/openssl/openssl/pull/10568 Matt From angus at magsys.co.uk Wed Dec 4 11:23:00 2019 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Wed, 4 Dec 2019 11:23 +0000 (GMT Standard Time) Subject: Json Web Keys again In-Reply-To: Message-ID: > > It seems the EVP_PKEY_RSA_PSS addition was only committed 28th > > October 2019, so need to wait for 1.1.1e, hopefully real soon... > > Ah, that explains it! Now tested with 1.1.1e-dev and I can generate a JWK from an RSA-PSS key. Since JWK is for signing, I also tried to support ED25519 private keys, but get: error:0D0A40A7:asn1 encoding routines:i2d_PublicKey:unsupported public key type A binary public key is all I need for JWK, simple format. A search of master suggests nothing yet. Angus From matt at openssl.org Wed Dec 4 12:04:23 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 4 Dec 2019 12:04:23 +0000 Subject: Json Web Keys again In-Reply-To: References: Message-ID: On 04/12/2019 11:22, Angus Robertson - Magenta Systems Ltd wrote: >>> It seems the EVP_PKEY_RSA_PSS addition was only committed 28th >>> October 2019, so need to wait for 1.1.1e, hopefully real soon... >> >> Ah, that explains it! > > Now tested with 1.1.1e-dev and I can generate a JWK from an RSA-PSS key. > > > Since JWK is for signing, I also tried to support ED25519 private keys, > but get: > > error:0D0A40A7:asn1 encoding routines:i2d_PublicKey:unsupported public > key type > > A binary public key is all I need for JWK, simple format. A search of > master suggests nothing yet. i2d_PublicKey() serializes a public key using key specific (legacy) formats where available. There isn't a key specific format for Ed25519. It just uses the generic SubjectPublicKeyInfo format. You need to use i2d_PUBKEY() for that. Arguably we should make i2d_PublicKey() fallback to i2d_PUBKEY() where no key specific format is available. Matt From angus at magsys.co.uk Wed Dec 4 18:39:00 2019 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Wed, 4 Dec 2019 18:39 +0000 (GMT Standard Time) Subject: Json Web Keys again In-Reply-To: Message-ID: > There isn't a key specific format for Ed25519. > You need to use i2d_PUBKEY() for that. I used EVP_PKEY_get_raw_public_key which got added for these raw keys, works fine for Ed25519. On the EVP_PKEY_get_raw_public_key.html page, it would help if it mentioned that *len should be set to the passed buffer size on the get_raw functions which fail if you pass zero. Angus From deepak.redmi2 at gmail.com Wed Dec 4 20:03:56 2019 From: deepak.redmi2 at gmail.com (Dipak B) Date: Thu, 5 Dec 2019 01:33:56 +0530 Subject: Fingerprint mismatch only for 32-bit DLL linked statically to FIPS Capable OpenSSL Message-ID: *Appreciate any help on the following.* 1. Built OpenSSL Fips Module and then 'static binaries' of FIPS capable OSSL which 'statically link to the windows run-time'. Thus, my application binary (FipsApp.exe) does not depend on OSSL DLLs. 2. Consumed these static binaries namely (libeaycompat32.lib, libeayfips32.lib and ssleay32.lib) into myapp.dll using msincore.pl. 3. FipsApp.exe calls function foo() inside myapp.dll which executes FIPS_mode_set() which returns (100:error:2D06B06F:lib(45):func(107): reason (111):/FIPS/FIPS.c:232) Result 1. On executing 64-bit FipsApp.exe, the FIPS mode gets set and working with 64-bit myapp.dll 2. But on executing 32-bit FipsApp.exe which uses 32-bit myapp.dll with same configuration, FIPS_mode_set() fails with reason 111 (Fingerprint mismatch) Attempted Since above 32-bit myapp.dll did not work, some additional configuration changes were made. 1. ReBuilt 32-bit myapp.dll with above LFLAGS "/DynamicBase:No /Fixed". Here default base address gets used for myapp.dll 2. ReBuilt 32-bit myapp.dll with base address of 0xFB00000. (OSSL does same thing for FIPS dlls) 3. Checking out following http://openssl.6102.n7.nabble.com/FIPS-Static-Library-linked-into-Win32-Dll-builds-but-fails-self-test-td63011.html But 32-bit myapp DLL does always fail with fingerprint mismatch. Question How do I get 32-bit myapp.dll working in FIPS mode? FIPS_mode_set() returns (100:error:2D06B06F:lib(45):func(107): reason (111):/FIPS/FIPS.c:232) Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdrotter at us.ibm.com Wed Dec 4 20:52:23 2019 From: pdrotter at us.ibm.com (Neptune) Date: Wed, 4 Dec 2019 13:52:23 -0700 (MST) Subject: Fingerprint mismatch only for 32-bit DLL linked statically to FIPS Capable OpenSSL In-Reply-To: References: Message-ID: <1575492743353-0.post@n7.nabble.com> I ran into the same issue on my FIPS journey a few years ago. I'm assuming you are building for windows in which case setting the /FIXED flag is the right thing to do, however you cannot be guaranteed to get the address you specify - it may already be occupied in which case the dll will be re-based and then you're bound to get a fingerprint mismatch. I used the Process Explorer tool to verify that when my dll loaded, the address it wanted was already occupied. I would suggest you do the same as a first step to make sure this is actually the problem you are experiencing. Unfortunately, I don't believe there is any way to guarantee that your dll will not be re-based using FIPS in 32-bit Windows dlls...it's a bit of a game of chance. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From joky27 at sjtu.edu.cn Thu Dec 5 05:19:44 2019 From: joky27 at sjtu.edu.cn (=?gb2312?B?1uy80dPu?=) Date: Thu, 5 Dec 2019 13:19:44 +0800 (CST) Subject: What will it happen when a certificate has an empty issuer? Message-ID: <626407395.6221887.1575523184058.JavaMail.zimbra@sjtu.edu.cn> Hi, all, ? I recently created a certificate chain, on which some certificates happen to have ?empty? issuers/subjects. Clearly, these certificates violate Section 4.1.2.4, RFC5280: ?The issuer field MUST contain a non-empty distinguished name (DN)?. Meanwhile, the chain can still pass certificate verification. Does openssl have a bug here? (Or do I have some misunderstandings on openssl in its parsing or verification procedure?) Will it cause any further problems in certificate verification? ? The command I used is: openssl verify --show_chain --CAfile 5009_root.pem 5009_leaf.pem 5009_root.pem (it contains two certificates inside): -----BEGIN RSA PRIVATE KEY----- MIIEowIBAAKCAQEA1QUBgnureUishKtOaMYYaI+MXommBYHrdWk5RLhwlBTMRWUN vb2UkN1dYU8SNQ91DsEM2Vs+eHWLkVvluK3ug2upsJdbG8GmFkScSMz4/oY6Mv59 8ib28uWA8F/ipu/DQhEHG2Nrccss9bBLOW7J0+Haj2UfZPZjQ1gxRwBO4Y4ZRKTw xcxvEkk5AFsLr89B8kcqn385FrJqgFcnzWSfDNqK32xaoCu1gctpzNH4x76HEGGH 1N37v++HHa73EW6UrrDRsx4FkKOjG4iyXi8I7IUzHRyY6GRihJTLwrxBSDkPkS69 FfjYZqlb/dGszQG9MUGGLh2pyDMlSPzCu1knswIDAQABAoIBAEidADq+dWFOiKBg 1MWaYU+jPzIqsdFGzEClscPfK2EPBeLR47E+IpqPGvnEvmwf7MMuw3aER/M//md6 cABYKenalWmA7qmzhS4qDSwz0tzQXJ5taflVlvCNkzpdNSG6sVCgBVAsv792hsjp Y3scbOgxIROoYN9FreiS85lEXZ889d+1ytTBSqWf6RpPWibQ+xBCHPW6UoMDJBlV n+eC6eVTsmzG5QDUvY0FLLuxcyFLO1YUkFQ1jFmR7QuOrG6Bw67Am10QxzGDiiCc eegqxlWEK6aUWATzN+CVkvWNJm43G+FOicpkbY5N9wlCONFDCD1QFP53EHG6BBle Sii4M4ECgYEA7IPdz7+fYiWbZnRrOA0OpXUmVVUSDU4MT1zBTlEy/O8SQeWu3PNA 3OAD0Xpc4cypTOrTU+3pPuoK99amr3WkXv8WYimADqHTpYBv6qNp0xxp2Le2+sIe wKCOCkw8Yt4u0Vas/m+N1Q9yIaIOMyzqlY+/oq7P8L73WAa0BhsKRnECgYEA5pGd hpHizSG6oCVwn6G1RJrc7zyADZuSc7yR2PfIve/KHxM14m2wJcFr/hIIAtOui34R aBoK9lNG5WNooR1kVaye245tpju91+FVzmoW3Poz0RUi5SLjiBYzizOq9LLECuLi bOlzxL3lcHSATM14ipbS2zeo3AAs7f5fP4xXimMCgYAvhY9b3rS3k7bVry6b5IO8 2v0IyD8ITVZL2+c7RTVpfN++PdgUrQurVZduz5c6B1U9DzHG+1aSPZRWl9qGBq0w KTDmKFCCoCFWb6gNDSiGMn9R/BfX6okjSx8/EnJPqzTc+v1nYiKtXJ0iBN21iqDX zDpFBbriNHyeQzqIv4YhAQKBgHJeMIEbxCB0ZpoheCf2km+hUY3puKsHTDHUi5PP 9OciFmQrp0LVndZchzDTyN1+GspekkvM/zsIO9Z05OVmKurEYVgO4hze7WA0CdgF j6m1AhboIRL/p1VNjeuyiU4vjkbIHABiHGauuyx43Vs7YFt+TMEobr4R6Dd1QdHH z3R5AoGBAL9PGWeOu1ptVs+OHPPBUIqvrZIluWjFEP96wCPcCyEWqcvJ2lCN4z4K b76PV1S5/dQmLsG98H7NnrH6sstcxh8ylddD10CEEi49C5rb9Ju4YVPeGtdCFNIb niOb8hgCX3MV/+ypRTaC0bzeQNAPhD+r07zIDkqAtnL+SG+RCMa1 -----END RSA PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIIC0jCCAbqgAwIBAgIBATANBgkqhkiG9w0BAQ4FADBAMQswCQYDVQQGEwJDTjEL MAkGA1UECAwCU0gxEjAQBgNVBAoMCVNKVFUgRERTVDEQMA4GA1UEAwwHRERTVCBD QTAiGA8xOTk2MDgwMTAwMDAwMFoYDzIwMjAxMjMxMjM1OTU5WjAAMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs5aM8KCuLHVK0mpFLfbvBaFNx6uDHWM0 ksxXTQDXAeqaakymmOnpZGwf8GhWSCg3xSdId2/kCBJaQMkgMTjUqiTeiHFhB7T4 zOj3d+R8gbYjPw5oHK+aXk7B0fSUTVLXnlidu/EuwRTU9dERBzN1EtrptNzUJZJa ZUbUjTV14amSJ9HOJvVghEiZ1CWPdhfI0I8om6AqO3akBpdwx4h1MT26lxTIAEj8 vUa33OM/Ac933q9cgoii6EmVwOfe9riFFwRFzZh0ygzVhsd83ujvBRLT2dDl7oxE 6himl1D/iSOQv7VxosVdca3k/5iXEDeENncNNCWoCZwZRsDQwKZ6DwIDAQABoxMw ETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBDgUAA4IBAQAiQvULr9pFxgIJ yjtxVHxY9dPKRumSnjQnUfd86mICk/XD1ywQM/amRyVrIInUxP6Gg2xCnYr7gNuG FeYf3EqtlEZYqfWLIClJSU62mKbCXwfRIldh1ihSiH5+IV0Put4SAvjamQ5xnSAm KG4TH/v8d+cmx2vC/gyRe1uH60g1o7yOgwzP5UYe6WeGx3lIRW2Av9u/roYMmegv lXUBbMSpqpp/nGoAn9IxaNticZWlz4pkYXTWn0NFoaDDz7855zeXJ3IBBrfR5R1O sK6jmqhXPfGGAtS0+Wz8bnl1pHeNtNI5gqjamji6NOutR0oZv/FzDcfds3erBBD2 AktONs4U -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDUzCCAjugAwIBAgIJAJl+82Li87lfMA0GCSqGSIb3DQEBCwUAMEAxCzAJBgNV BAYTAkNOMQswCQYDVQQIDAJTSDESMBAGA1UECgwJU0pUVSBERFNUMRAwDgYDVQQD DAdERFNUIENBMB4XDTE5MDczMDA2NTc1NVoXDTIyMDExNDA2NTc1NVowQDELMAkG A1UEBhMCQ04xCzAJBgNVBAgMAlNIMRIwEAYDVQQKDAlTSlRVIEREU1QxEDAOBgNV BAMMB0REU1QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDVBQGC e6t5SKyEq05oxhhoj4xeiaYFget1aTlEuHCUFMxFZQ29vZSQ3V1hTxI1D3UOwQzZ Wz54dYuRW+W4re6Da6mwl1sbwaYWRJxIzPj+hjoy/n3yJvby5YDwX+Km78NCEQcb Y2txyyz1sEs5bsnT4dqPZR9k9mNDWDFHAE7hjhlEpPDFzG8SSTkAWwuvz0HyRyqf fzkWsmqAVyfNZJ8M2orfbFqgK7WBy2nM0fjHvocQYYfU3fu/74cdrvcRbpSusNGz HgWQo6MbiLJeLwjshTMdHJjoZGKElMvCvEFIOQ+RLr0V+NhmqVv90azNAb0xQYYu HanIMyVI/MK7WSezAgMBAAGjUDBOMB0GA1UdDgQWBBSkoyQbQziu3QnuUSBHdEnP VAbUszAfBgNVHSMEGDAWgBSkoyQbQziu3QnuUSBHdEnPVAbUszAMBgNVHRMEBTAD AQH/MA0GCSqGSIb3DQEBCwUAA4IBAQADCzh/BOVeuBzYLukXD4WmADAbBLWccunP 0i0m1X8CePPT7OYuZV7ie150ViP55I74D0u9uaqzadXJ6Q8WPJVPv95/boAIJCoe SHkh3hPAsHfqfjrAquwXsM9I1KpxsHSMUluMJbbty+OpRWRT8sBcdBwFqIxZuEvO z8M0LDGd7EgQfaXJuWXJggXOtf0Da4l9kJjE6M68ns+rEShK+wenxuJeLEI9FwZA gSt7PnmJVLz1eXLtZRTsbMuukFH6jDTQyMekxhODyskj5sch5IoiF2KrcQT09LPX 3JzTb6+14WI1YvQm+ve7mnQOWOhdsi9gJ00yfAHOuku7tEyWBN2m -----END CERTIFICATE----- 5009_leaf.pem: -----BEGIN PRIVATE KEY----- MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDGK3/TkVnaeeEy RE2fo8QPH8uH1aSmwt3PqaFfYjl+r5+Ksp0O2WH2kBAInVZ9JySiQpiscAmtNlqE EvolOZCDOEgRVn7UeqZkpKo1kYObrPbDDPtQA3ZVszsBSHvVBhjQv/qYtNFOdDBz ko5Qg7Razz5sWu6JkIHWvW7jJWr7AJPstYJsZOrtG/kuXS4wZGnRWCedhGatYk+s My3lwPHlwZEmSBEaK1mrL72YrsVa5oqdSPvvKhrXTJslKk1+OSqytwhV+1hsAaCA uO93cmHeE+fNZkCJILdzxWJqWJM+r/PBIcYasdlARF/xND7XSbzzKR5UJs5xGjjy t5YiO5ljAgMBAAECggEBALK64NsMKSIm8rjHacslhNqvLn4gbhQJhMyajXTdvkVI WHhbh9Ows+4RGKTsYukVuLCvp8s+cTvL3e9ovjt8o5310OnyPQmeZRw4d1tBFpX9 dcGNn8wWk0/QCtOpcCY9DXyY6Yd47Z34pQpXkAuF/dA5Qm+vw5xGvRPUXoJ3aPlf gPVr17UceSK9jyM+Q0set+kOW/0FkJYTVoG+debpFJbqn29LW0vZ/Q6Pd9SFXVOG J3tjOhoF/5xqWgrnTrFevWkaVuyRFSUp1inAOSwtY+nImPIpn9F6dU69BKrjegR/ BrfIp9wwQX2UKno7foNIWxgL9o2TVM/ekeU8TayVsUECgYEA78Xa/P0EdLVS4Vvu eNg8vkSy8GkLESI1giAP5yvGOGmIJ2KlSP18ntCtz7m8SOPAd+4zTJgNvXybK0xe 89wMyGVZniNGlZrbryuvkoLgt0tf3IhZOvza99si1KJi88sNfRLzIdujtpyQwzDW snzSX2ZCCbo7J4Tgf2BTgpcC+UsCgYEA05Tb4oxyMSq+/CJpjVY0uC4Cui3DRFee U3V9qIQJQwFCp3KL4pqtEBYZv5A0FcN7Qq7C2fPTREaSOa+XbCrfYhPiXFxafpEx DOoDuFbAaBqF4WcHpIBlP8XgMivH71ni5VFp6Mb7BPjyaZC3HHqXHEVgAnTE7AzD V0H6zUFwqUkCgYAmydE1YBEaeELiJicb8Y9SEHcKIVQi/2+8j0dDVHeKpLfb9z9Z 4XgJkSStGBT3jbCTNjuiRm7imofXp1EtDgobWRn4VSiUBytG2UBb6URFIrJtULlu q30Y36Bw2Zw8aDrUYv5mGcwQPJ/Gk94Hnd3ChR5lyHTNXdebg4++7oMSpQKBgClf T0vSaLXihOvqkrc3ZyGopZHgRvGDLItnSwX7o4/9nBoAFQhfdH3TxH8n5Hdo/R5B 7AoQWnxcTFWJV1OoYnvcJYQn7u4W1/+NduLB2+e/X/R+YAkzrhi1Sayl0PelnO94 ZvxEhGspfsVTreqcshWuHyL70FHUARJ77V3bcPs5AoGAdeMMaTvRYkw33h0WLafW O0bpnTOQLr5fEMryt3XSWNqJlESf8XHu5pEEbzgT1aQS++33tuAl/JBS/nhSi46/ O1cekxLmmV0lq8M++jalv4BoK02hyqU1Hy7e6Y3XzV5iqgPySra/5dK8XFYbDlDS CM1Kmd5p/V9GsOmAEL9Yh7A= -----END PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIIDGTCCAgGgAwIBAgIBADANBgkqhkiG9w0BAQ4FADAAMCIYDzIwMDkwNDA4MDQ1 NjQ3WhgPMjAyOTA0MDgwNDU2NDdaMFgxCzAJBgNVBAYTAkpQMSswKQYDVQQKEyJK YXBhbiBDZXJ0aWZpY2F0aW9uIFNlcnZpY2VzLCBJbmMuMRwwGgYDVQQDExNTZWN1 cmVTaWduIFJvb3RDQTExMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA xit/05FZ2nnhMkRNn6PEDx/Lh9WkpsLdz6mhX2I5fq+firKdDtlh9pAQCJ1WfSck okKYrHAJrTZahBL6JTmQgzhIEVZ+1HqmZKSqNZGDm6z2wwz7UAN2VbM7AUh71QYY 0L/6mLTRTnQwc5KOUIO0Ws8+bFruiZCB1r1u4yVq+wCT7LWCbGTq7Rv5Ll0uMGRp 0VgnnYRmrWJPrDMt5cDx5cGRJkgRGitZqy+9mK7FWuaKnUj77yoa10ybJSpNfjkq srcIVftYbAGggLjvd3Jh3hPnzWZAiSC3c8VialiTPq/zwSHGGrHZQERf8TQ+10m8 8ykeVCbOcRo48reWIjuZYwIDAQABo0IwQDAdBgNVHQ4EFgQUW/hNT7KlhtQ60vFj mqC+CfZXt94wDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZI hvcNAQEOBQADggEBAHcwO3SSQ/dFuU8oTKGGaHEXtWdwgbHm1KxIxDXrzJ6YLJok yYG55c7U90Cn87WV+IKF0QXz+GhIakCX0KoddKvJc/SaJzY/9S6LQExlwi+cUXG2 gETlVWRo8e4Cv4RF2Bnb8iTMoh/ysxpdDJ6KQvmyip7iEANV9BUtiJ0scbMSyS/z TrwOmCqZ7hpAOimnMNjqZ9h9LAKDqMGkaMn8O6aH8R1E2TE6LAmW0w5Sn909AkFL 2TpLr+8iq5d68ieZMdpSWDV4VvczsIJK8+r4qfx69tBuf1IufbgzYWzESLuobugP TIklQXJwo6WL0vuJtZVod092EZh5KyXwEE3UP5w= -----END CERTIFICATE----- The verification returns ok Chain: depth=0: C = JP, O = "Japan Certification Services, Inc.", CN = SecureSign RootCA11 (untrusted) depth=1: depth=2: C = CN, ST = SH, O = SJTU DDST, CN = DDST CA Regards, Jiayu -------------- next part -------------- A non-text attachment was scrubbed... Name: 5009_leaf.pem Type: application/x-x509-ca-cert Size: 2884 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 5009_root.pem Type: application/x-x509-ca-cert Size: 3990 bytes Desc: not available URL: From narasimha.nayak at gmail.com Fri Dec 6 02:50:45 2019 From: narasimha.nayak at gmail.com (Narasimha Nayak) Date: Thu, 5 Dec 2019 18:50:45 -0800 Subject: ssl3_read_bytes() - Need to reset the "rwstate" of session on receipt of alert (completion of async crypto op). Message-ID: Hello Experts, Came across a minor issue with handling of alert messages with an async crypto engine. Would like to get feedback if this has already been resolved or if the attached fix will work ? Issue observed: The client sends an encrypted "Close_Notify" and we use async processing for decryption. On resubmission of the decrypted data to the SSL_read(), the function returns with "0" and on invoking SSL_get_error() we see the previous error code "SSL_ERROR_WANT_ASYNC" being returned. Likely Solution (file: ssl/record/rec_layer_s3.c): In ssl3_read_bytes(), the "rwstate" variable is not reset when the alert has been processed. The following did ensure the return code now returned changed to "SSL_ERROR_ZERO_RETURN" on invoking SSL_get_error(). --- a/openssl/openssl-1.1.1c/ssl/record/rec_layer_s3.c +++ b/openssl/openssl-1.1.1c/ssl/record/rec_layer_s3.c @@ -1526,6 +1526,7 @@ int ssl3_read_bytes(SSL *s, int type, int *recvd_type, unsigned char *buf, } else if (alert_descr == SSL_AD_CLOSE_NOTIFY && (is_tls13 || alert_level == SSL3_AL_WARNING)) { s->shutdown |= SSL_RECEIVED_SHUTDOWN; + s->rwstate = SSL_NOTHING; return 0; } else if (alert_level == SSL3_AL_FATAL || is_tls13) { char tmp[16]; -- Thanks, Narasimha -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at eckner.net Fri Dec 6 14:29:37 2019 From: openssl at eckner.net (Erich Eckner) Date: Fri, 6 Dec 2019 15:29:37 +0100 (CET) Subject: verbosity of `openssl ca` error In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I found the cause of my issue: When creating a new intermediate ca, I did not purge the old directory, thus starting with an serial>01 and issued certificates, revocation list which does not match the new private key. Still my wish remains: a more verbose error message would have made the problem with the setup much clearer! regards, Erich On Wed, 4 Dec 2019, Erich Eckner wrote: > Hi, > > I'm trying to sign a csr by running > `CA=signing-ca openssl ca -verbose -config /etc/simple-pki/ca-ssl.conf -name > signing_ca -in /tmp/tmp.Qz3EoKa0S4/fileserver-lo.ddns.eckner.net.csr -out > /tmp/tmp.Qz3EoKa0S4/fileserver-lo.ddns.eckner.net.crt -extensions server_ext` > but it fails with exit code 1, solely printing the message > "Using configuration from /etc/simple-pki/ca-ssl.conf" > > How can I see what's going wrong? Should I use gdb and/or strace to find what > the issue is or is there an easier option to enable debug output? > > For the sake of completeness, here comes the content of - > -------->8--------/etc/simple-pki/ca-ssl.conf----------->8-------------- > # Simple Root & Signing CA > > # The [default] section contains global constants that can be referred to > from > # the entire configuration file. It may also hold settings pertaining to more > # than one openssl command. > > [ default ] > ca = $ENV::CA > dir = /etc/simple-pki # Top dir > > # The next part of the configuration file is used by the openssl req command. > # It defines the CA's key pair, its DN, and the desired extensions for the CA > # certificate. > > [ req ] > default_bits = 4096 # RSA key size > encrypt_key = no # Protect private key > default_md = sha1 # MD to use > utf8 = yes # Input is UTF-8 > string_mask = utf8only # Emit UTF-8 strings > prompt = no # Don't prompt for DN > distinguished_name = ca_dn # DN section > req_extensions = ca_reqext # Desired extensions > > [ ca_dn ] > 0.domainComponent = "net" > 1.domainComponent = "eckner" > organizationName = "Eckner Net" > organizationalUnitName = "Eckner Net CA" > commonName = "Eckner Net Root CA" > > [ ca_reqext ] > keyUsage = critical,keyCertSign,cRLSign > basicConstraints = critical,CA:true > subjectKeyIdentifier = hash > > # The remainder of the configuration file is used by the openssl ca command. > # The CA section defines the locations of CA assets, as well as the policies > # applying to the CA. > > [ root_ca ] > certificate = $dir/ca/$ca.crt # The CA cert > private_key = $dir/ca/$ca/private/$ca.key # CA private key > new_certs_dir = $dir/ca/$ca # Certificate archive > serial = $dir/ca/$ca/db/$ca.crt.srl # Serial number file > crlnumber = $dir/ca/$ca/db/$ca.crl.srl # CRL number file > database = $dir/ca/$ca/db/$ca.db # Index file > unique_subject = no # Require unique subject > default_days = 365 # How long to certify for > default_md = sha1 # MD to use > policy = match_pol # Default naming policy > email_in_dn = no # Add email to cert DN > preserve = no # Keep passed DN ordering > name_opt = ca_default # Subject DN display options > cert_opt = ca_default # Certificate display options > copy_extensions = none # Copy extensions from CSR > x509_extensions = signing_ca_ext # Default cert extensions > default_crl_days = 30 # How long before next CRL > crl_extensions = crl_ext # CRL extensions > > [ signing_ca ] > certificate = $dir/ca/$ca.crt # The CA cert > private_key = $dir/ca/$ca/private/$ca.key # CA private key > new_certs_dir = $dir/ca/$ca # Certificate archive > serial = $dir/ca/$ca/db/$ca.crt.srl # Serial number file > crlnumber = $dir/ca/$ca/db/$ca.crl.srl # CRL number file > database = $dir/ca/$ca/db/$ca.db # Index file > unique_subject = no # Require unique subject > default_days = 60 # How long to certify for > default_md = sha1 # MD to use > policy = match_pol # Default naming policy > email_in_dn = no # Add email to cert DN > preserve = no # Keep passed DN ordering > name_opt = ca_default # Subject DN display options > cert_opt = ca_default # Certificate display options > copy_extensions = copy # Copy extensions from CSR > x509_extensions = email_ext # Default cert extensions > default_crl_days = 7 # How long before next CRL > crl_extensions = crl_ext # CRL extensions > > # Naming policies control which parts of a DN end up in the certificate and > # under what circumstances certification should be denied. > > [ match_pol ] > domainComponent = match # Must match 'simple.org' > organizationName = match # Must match 'Simple Inc' > organizationalUnitName = optional # Included if present > commonName = supplied # Must be present > > [ any_pol ] > domainComponent = optional > countryName = optional > stateOrProvinceName = optional > localityName = optional > organizationName = optional > organizationalUnitName = optional > commonName = optional > emailAddress = optional > > # Certificate extensions define what types of certificates the CA is able to > # create. > > [ root_ca_ext ] > keyUsage = critical,keyCertSign,cRLSign > basicConstraints = critical,CA:true > subjectKeyIdentifier = hash > authorityKeyIdentifier = keyid:always > > [ signing_ca_ext ] > keyUsage = critical,keyCertSign,cRLSign > basicConstraints = critical,CA:true,pathlen:0 > subjectKeyIdentifier = hash > authorityKeyIdentifier = keyid:always > > # Certificate extensions define what types of certificates the CA is able to > # create. > > [ email_ext ] > keyUsage = critical,digitalSignature,keyEncipherment > basicConstraints = CA:false > extendedKeyUsage = emailProtection,clientAuth > subjectKeyIdentifier = hash > authorityKeyIdentifier = keyid:always > > [ server_ext ] > keyUsage = critical,digitalSignature,keyEncipherment > basicConstraints = CA:false > extendedKeyUsage = serverAuth,clientAuth > subjectKeyIdentifier = hash > authorityKeyIdentifier = keyid:always > > # CRL extensions exist solely to point to the CA certificate that has issued > # the CRL. > > [ crl_ext ] > authorityKeyIdentifier = keyid:always > - --------8<--------/etc/simple-pki/ca-ssl.conf-----------8<-------------- > > regards, > Erich > -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl3qZdMACgkQCu7JB1Xa e1q+iQ//ZHTpV9yLPUZj3U2g2DKN5iCT3JcNAO3hiwtFyletDIzuks3CsJCLnHEz k5qDJ/JpyJz6kMrj9wffxYwBsbo9NL8bFdlt58u0PQYSlqxq6ZGO9NSmhf+3mzvO nD7xiBR9UD8/Yh4pzMtGAGD4Wd2jvBkZtnRcJmayhSurniSnkSQYL932SwkL/q6Q 4sQoZ2axViuRnUdLctMarDOLLmwYS1duDOjlcdpdSYmkzh7I8uAfHjm5lKscBsn1 LX/nvB80fb8MYuUV+CdCvQvZr0mV0nIm1aU8IvXyBCR2ZuV0yulL4DS7DX/JSg3M BR6kmT/PFxiNkMcNkNnZmYNT4zzoE4WbmvthtClniAxpDNtIefbLCOt4vPfh4RK+ TbI3PZPEt1S0sZYa1CqCa2hR2XfHoX46KySa6hdni7tQQM+EYiYpginpBI67OPDV bnI4UjUXEUgl5gwWXiPfUMrHBdKUHxpzFfGsHzCbslFr30Dm6NZs5lOZ2SmRNaSU yNk9N6EHH3TblY1PjUZOkYSZKJpjOXhEXsNaSxZc8upoFesTp63G75+Ck17ZcX4C i6pDnHY3fZ0usb2HjcQOFHnzXU2U7aCoRGWnDSUl0dN4X1kyWk23Y3nFP6jdgsUi aAu+2id1oWFqaDEHRzyzxDtYsRtqmlA75rcZNmdmrG8jK0Q2XWM= =Lsck -----END PGP SIGNATURE----- From openssl at openssl.org Fri Dec 6 16:46:08 2019 From: openssl at openssl.org (OpenSSL) Date: Fri, 6 Dec 2019 16:46:08 +0000 Subject: OpenSSL Security Advisory Message-ID: <20191206164608.GA6057@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL Security Advisory [6 December 2019] =========================================== rsaz_512_sqr overflow bug on x86_64 (CVE-2019-1551) =================================================== Severity: Low There is an overflow bug in the x64_64 Montgomery squaring procedure used in exponentiation with 512-bit moduli. No EC algorithms are affected. Analysis suggests that attacks against 2-prime RSA1024, 3-prime RSA1536, and DSA1024 as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH512 are considered just feasible. However, for an attack the target would have to re-use the DH512 private key, which is not recommended anyway. Also applications directly using the low level API BN_mod_exp may be affected if they use BN_FLG_CONSTTIME. OpenSSL versions 1.1.1 and 1.0.2 are affected by this issue. However due to the low severity of this issue we are not creating new releases at this time. The 1.1.1 mitigation for this issue can be found in commit 419102400. The 1.0.2 mitigation for this issue can be found in commit f1c5eea8a. This issue was found by OSS-Fuzz and Guido Vranken and reported to OpenSSL on 12th September 2019. The fix was developed by Andy Polyakov with additional analysis by Bernd Edlinger. Note ===== OpenSSL 1.0.2 is currently only receiving security updates. Support for 1.0.2 will end on 31st December 2019. Extended support is available for premium support customers: https://www.openssl.org/support/contracts.html OpenSSL 1.1.0 is out of support and no longer receiving updates. It is unknown whether issues in this advisory affect it. Users of these versions should upgrade to OpenSSL 1.1.1. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20191206.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl3qhRUACgkQ2cTSbQ5g RJHQvwgAhVefbdppxDZbGhiIjc/MLTeZmYC5U57rGMvGQ7WL8+xbkGVYmFPu69kp dN+kGPVJAZySmbhJZVmbrdxgl/zCvwE1WXPh5ILQCvA8cF0z762TCJpxbDJksy/9 igmavYVMxWLePMz7+HsVo6VCcvmBNGykg8zpJm33v2/wc9dBE+c/sJoep/pcXYNI fLrcLUnsnJoWhg23VNUXEkW8Ru4jkaXTtg4v4sdxHzPbp0qBbekdhj6GAekyFRjn Zpv4buJDxohcJw91rBK36tXU/PZARW4tO6TR6CdVuB16T7XMye0wKp3kRNd0QPE9 O/LGrT1Jq8cFTxYHfFYeOrkVJKpgog== =6Z6t -----END PGP SIGNATURE----- From phill at thesusis.net Fri Dec 6 18:50:37 2019 From: phill at thesusis.net (Phillip Susi) Date: Fri, 06 Dec 2019 13:50:37 -0500 Subject: Usage of Secure C (memcpy_s, strcpy_s etc) functions on OpenSSL In-Reply-To: References: <87d0ddgyaw.fsf@vps.thesusis.net> Message-ID: <87lfrpuw3m.fsf@vps.thesusis.net> Michael Wojcik writes: > No, for a number of reasons: > - The buffer may be dynamically allocated, in which case sizeof buffer > is very much the wrong thing. Obviously then you would use whatever variable you have the buffer size in rather than sizeof. The point is that you just tell strncpy 1 less and make sure the buffer starts off zeroed ( so use calloc ) and then you don't have to worry about strncpy not null terminating if it was too long. > - A trailing nul byte is not always desirable (not everything is a string), and not all of the Appendix K > functions will append one. Neither will strncpy, if the limit is > reached; strncpy has broken semantics. I fail to see where there is any issue to discuss when you aren't using null terminated strings. If you are just using memcpy, then you know exactly how many bytes you want to copy and that is exactly how many gets copied. How can you screw that up that needs a _s version to protect you from? > - The buffer size (less 1) is the wrong value to pass when using strncat with a destination that does not start > with a nul character. Developers also frequently miss the fact that strncat can append length+1 bytes to > the buffer. (strncat's semantics are dangerously non-obvious.) Obviously for strncat you need to subtract strlen() first. > - Non-trivial programs *will still have to handle truncation properly*. It's rarely the case for a non-trivial > program that "silently truncate the data" is a good way to handle it. A well-behaved program will treat > truncation as an error or a special case that needs further handling, or at least needs to be flagged to the > user or some other diagnostic sink. The C90 length-checked functions don't communicate truncation to > the caller; the Annex K ones only return "a non-zero value" if a constraint is violated, so there's no > standardization as to how a particular constraint violation is communicated. Makes sense in theory.. I've just never seen a program bother in practice. This may be one of those differences between acadamia and the real world. > Also, sizeof is an operator, not a function. There's no reason to parenthesize its argument unless the > argument is a type name, in which case it's parenthesized as a special syntactic case. I'm aware, but virtually all C code I've seen since I learned it in the '90s has used the parethesis. On the very rare occasion I see someone not do it, it feels weird. From myronjoffe at gmail.com Sat Dec 7 11:41:32 2019 From: myronjoffe at gmail.com (Myron Joffe) Date: Sat, 7 Dec 2019 11:41:32 +0000 Subject: OpenSSL 1.0.2x support for Extended Master Secret (EMS) Message-ID: <50705457-884B-467B-B848-1F7034E3A9C4@gmail.com> ?Hi all Does either OpenSSL 1.0.2j or 1.0.2r support Extend Master Secret (EMS)? From deepak.redmi2 at gmail.com Sat Dec 7 19:47:06 2019 From: deepak.redmi2 at gmail.com (Dipak B) Date: Sun, 8 Dec 2019 01:17:06 +0530 Subject: FINGERPRINT_premain() not getting called Message-ID: Hi, Appreciate any help on following. In continuation with email sent earlier, for me FINGERPRINT_premain() is not getting called after failure of FIPS_mode_set(). Background My 32bit application (Myapp32.exe) uses myFips32.dll which statically links to FIPS capable openssl and statically to windows runtime. On running myapp32.exe, FIPS_mode_set() inside fips32.dll fails with fingerprint mismatch error 111. The function FIPS_check_incore_fingerprint(void) calculates incore fingerprint properly but hash embedded using fips_premain.c is read as empty from virtual memory. For same configuration, 64bit app and it's corresponding 64bit DLL, enters fips mode successfully. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Dec 9 09:36:17 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 9 Dec 2019 09:36:17 +0000 Subject: OpenSSL 1.0.2x support for Extended Master Secret (EMS) In-Reply-To: <50705457-884B-467B-B848-1F7034E3A9C4@gmail.com> References: <50705457-884B-467B-B848-1F7034E3A9C4@gmail.com> Message-ID: <0756f8e0-23af-c316-af46-5d1a96e73255@openssl.org> On 07/12/2019 11:41, Myron Joffe wrote: > ?Hi all > > Does either OpenSSL 1.0.2j or 1.0.2r support Extend Master Secret (EMS)? > No. Extended Master Secret support was first added in OpenSSL 1.1.0. Matt From rashok.svks at gmail.com Wed Dec 11 11:06:20 2019 From: rashok.svks at gmail.com (Raja Ashok) Date: Wed, 11 Dec 2019 16:36:20 +0530 Subject: Using SSL_read and SSL_write on parallel threads Message-ID: Hi All, A TLS server application spawns 2 thread and handles 'n' number of TLS clients. All connections SSL_read operations are performed on one thread and SSL_write on another thread. To achieve this currently I lock the `SSL` connection handle. This application uses TLSv1.2 and TLSv1.3. My question is does anyone uses SSL_read and SSL_write in parallel thread in much better way ? Regards, Raja Ashok -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Dec 11 19:17:25 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 11 Dec 2019 14:17:25 -0500 Subject: Using SSL_read and SSL_write on parallel threads In-Reply-To: References: Message-ID: <20191211191725.GC19679@straasha.imrryr.org> On Wed, Dec 11, 2019 at 04:36:20PM +0530, Raja Ashok wrote: > A TLS server application spawns 2 thread and handles 'n' number of TLS > clients. All connections SSL_read operations are performed on one thread > and SSL_write on another thread. To achieve this currently I lock the `SSL` > connection handle. This application uses TLSv1.2 and TLSv1.3. > > My question is does anyone uses SSL_read and SSL_write in parallel thread > in much better way ? General best-practice is either an event based state-machine or one thread per connection, with both the reads and the writes for a given connection done in the same thread. If for some reason you have to separate the reads and writes into separate threads, then indeed locks are required, but then a blocked reader can starve the write side and vice versa. If the connection is non-blocking, then you must deal with SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE in both threads, waiting for the socket to become readable or writable before retrying the operation. -- Viktor. From navin.shivanna at gmail.com Thu Dec 12 16:09:52 2019 From: navin.shivanna at gmail.com (Naveen Shivanna) Date: Thu, 12 Dec 2019 21:39:52 +0530 Subject: Regarding interoperability between no-asm and asm enabled Message-ID: Hi, I am using 'DTLS over SCTP' and the OpenSSL version is 1.1.1c. I compiled OpenSSL with target 'linux-arm64ilp32' on armv8. GCC used is aarch64_be_linux-gnuilp32-gcc. So it is ILP32 and Big-end. I compiled two sets of OpenSSL libraries: 1) OpenSSL with no-asm present 2) OpenSSL with no-asm absent (means, enabled the assembler instruction acceleration) I observed that the DTLS handshake fails when the client with lib 1) and server with lib 2) are run. When client sends the CCS, encrypted_handshake_finish_message, the server sends back the ALERT (Fatal, Illegal parameter). At the server side, when SSL_accept() fails, thr error code is 244 (SSL_R_UNEXPECTED_MESSAGE). Cipher used is TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 However, the handshake is success when both client and server use the same lib type, either 1) or 2). This suggests that there is interoperability issue. Does anyone faced this issue? Rgds, Navi -------------- next part -------------- An HTML attachment was scrubbed... URL: From space.ship.traveller at gmail.com Thu Dec 12 21:31:31 2019 From: space.ship.traveller at gmail.com (Samuel Williams) Date: Fri, 13 Dec 2019 10:31:31 +1300 Subject: Digest algorithms for Ruby In-Reply-To: <0101016e2808d331-1d8d1851-59d4-4a90-9796-39a08c388228-000000@us-west-2.amazonses.com> References: <167EC78D-8587-4CE2-9B24-DB454B8E7490@dukhovni.org> <0101016e2808d331-1d8d1851-59d4-4a90-9796-39a08c388228-000000@us-west-2.amazonses.com> Message-ID: Thanks everyone, your replies were most helpful. On Sat, 2 Nov 2019 at 06:42, Jordan Brown wrote: > On 10/31/2019 7:35 AM, Viktor Dukhovni wrote: > > My advice would be to avoid specific support for any *particular* digest > algorithm. Instead, provide bindings to: > > - EVP_get_digestbyname(), > - EVP_MD_CTX_create(3), > - EVP_DigestInit_ex(3), > - EVP_DigestUpdate(3), > - EVP_DigestFinal_ex(3), > - EVP_MD_CTX_destroy(3) > > which can they use *any* available digest algorithm (by name). > > > That avoids having *your* software be dependent on the digest algorithms, > but it does so by exporting the dependency out to your caller. > > The bottom line for somebody trying to maintain compatibility is that when > you remove some algorithm X, there's always a risk that something in the > stack - be it software or user configuration - explicitly depends on X and > so will fail on upgrade. > > -- > Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From justnoxx at gmail.com Fri Dec 13 16:46:32 2019 From: justnoxx at gmail.com (Shamatrin Dmitriy) Date: Fri, 13 Dec 2019 18:46:32 +0200 Subject: OpenSSL source modification Message-ID: <96F6B870-914A-4781-BA53-CA9BEC7A5BC9@gmail.com> Hello! I have few questions related to openssl distribution. Let's say that I need this: https://pastebin.com/D4Eh0i6P For my application to keep working. Could someone please help me with these questions? Is that ok to apply this patch to my openssl library and ship it with application (in binary form)? Is this a license violation, if I do so? Do I need to mention my changes and share them with users? May this patch lead to issues for users of my application under any conditions? I.e. does it mean that patching openssl is a security violation? Is that possible to achieve the same result without openssl source code modification, by configuration flags. If it is not possible, is that an issue to create a pull request and propose to make these options configurable? Please, consider that I am trying to avoid openssl source modification. Kindly appreciate answers for my questions. Thanks. /Dmitriy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhb at FreeBSD.org Fri Dec 13 23:52:17 2019 From: jhb at FreeBSD.org (John Baldwin) Date: Fri, 13 Dec 2019 15:52:17 -0800 Subject: Backporting KTLS to 1.1.1 Message-ID: I've recently been working on adding support for kernel TLS offload to FreeBSD and have some patches merged into master already along with a couple of open reviews (and at least one other patchset in progress). With the recent-ish announcement of 3.0's release being delayed, I'm curious if OpenSSL would consider accepting patches to backport KTLS to 1.1.1 or if that is too large a feature to consider backporting? (I'm not really familiar with OpenSSL's norms in terms of what gets merged.) I will probably end up doing the work no matter what and if "it depends" is the answer then I can come up with a candidate patch series. -- John Baldwin From matt at openssl.org Sat Dec 14 10:09:36 2019 From: matt at openssl.org (Matt Caswell) Date: Sat, 14 Dec 2019 10:09:36 +0000 Subject: Backporting KTLS to 1.1.1 In-Reply-To: References: Message-ID: <4b174378-6312-f46d-9a09-65f93a21cafe@openssl.org> On 13/12/2019 23:52, John Baldwin wrote: > I've recently been working on adding support for kernel TLS offload > to FreeBSD and have some patches merged into master already along > with a couple of open reviews (and at least one other patchset in > progress). > > With the recent-ish announcement of 3.0's release being delayed, > I'm curious if OpenSSL would consider accepting patches to backport > KTLS to 1.1.1 or if that is too large a feature to consider > backporting? (I'm not really familiar with OpenSSL's norms in > terms of what gets merged.) I will probably end up doing the work > no matter what and if "it depends" is the answer then I can come > up with a candidate patch series. > Unfortunately, we do not allow new features in stable branches so we could not accept such a backport. Matt From matt at openssl.org Mon Dec 16 09:50:14 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 16 Dec 2019 09:50:14 +0000 Subject: OpenSSL source modification In-Reply-To: <96F6B870-914A-4781-BA53-CA9BEC7A5BC9@gmail.com> References: <96F6B870-914A-4781-BA53-CA9BEC7A5BC9@gmail.com> Message-ID: <1524c0a8-851d-e2dc-c066-8a07f75317ec@openssl.org> On 13/12/2019 16:46, Shamatrin Dmitriy wrote: > Hello! > > I have few questions related to openssl distribution. > > Let's say that I need this: > > https://pastebin.com/D4Eh0i6P > > For my application to keep working. > > Could someone please help me with these questions? > > 1. Is that ok to apply this patch to my openssl library and ship it > with application (in binary form)? > 2. Is this a license violation, if I do so? > 3. Do I need to mention my changes and share them with users? > 4. May this patch lead to issues for users of my application under any > conditions? I.e. does it mean that patching openssl is a security > violation? > 5. Is that possible to achieve the same result without openssl source > code modification, by configuration flags. You seem to be attempting to modify the DEFAULT OpenSSL ciphersuites by modifying the code. Why are you doing that? Why not just change the configured ciphersuites, e.g. https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_cipher_list.html In general it is best to avoid making modifications to the OpenSSL source if possible. It is not a license violation to do so however and there is no requirement to mention the changes to users. However, having made a change means that *you* are responsible for maintaining it moving forwards and checking there are no security issues - either now, or in the future. This will mean you will have to continually update your patch as we release new versions of OpenSSL. Unless you are a large organisation willing to invest significant effort in maintaining your own OpenSSL patches it is best just to use standard OpenSSL. Matt From uri at ll.mit.edu Mon Dec 16 15:29:41 2019 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 16 Dec 2019 15:29:41 +0000 Subject: MacOS: lost ability to use p11-kit??? Message-ID: <94499902-2CB4-4072-ADC2-7B747498F0CD@ll.mit.edu> macOS 10.14.6, Xcode-11.3 (with older Xcode it used to work), p11-kit 0.23.18, OpenSSL-1.1.1d, current master of OpenSC and libp11. Somehow, p11-kit proxy that selects the correct PKCS#11 library to pass the request to, is no longer invoked. Any help is appreciated! $ openssl cms -engine pkcs11 -keyform engine -aes256 -decrypt -binary -inform PEM -in /tmp/derive.95470.text.cms -out /tmp/derive.95470.text.dec -inkey "pkcs11:manufacturer=piv_II;object=KEY%20MAN%20key;object-type=private" engine "pkcs11" set. GOST engine already loaded Unable to load module /opt/local/lib/p11-kit-proxy.dylib GOST engine already loaded Unable to load module /opt/local/lib/p11-kit-proxy.dylib PKCS11_get_private_key returned NULL cannot load signing key file from engine 4458096064:error:260B606D:engine routines:dynamic_load:init failed:crypto/engine/eng_dyn.c:485: 4458096064:error:260BC066:engine routines:int_engine_configure:engine configuration error:crypto/engine/eng_cnf.c:141:section=gost_section, name=dynamic_path, value=/opt/local/lib/engines-1.1/gost.dylib 4458096064:error:0E07606D:configuration file routines:module_run:module initialization error:crypto/conf/conf_mod.c:177:module=engines, value=engine_section, retcode=-1 4458096064:error:83065006:PKCS#11 module:pkcs11_check_token:Function failed:p11_load.c:92: 4458096064:error:26096080:engine routines:ENGINE_load_private_key:failed loading private key:crypto/engine/eng_pkey.c:78: unable to load signing key file $ ll /opt/local/lib/p11-kit-proxy.dylib lrwxr-xr-x 1 root admin 18 Dec 11 13:21 /opt/local/lib/p11-kit-proxy.dylib@ -> libp11-kit.0.dylib $ ll /opt/local/lib/libp11-kit.0.dylib -rwxr-xr-x 1 root admin 1442912 Dec 11 13:23 /opt/local/lib/libp11-kit.0.dylib* $ ? Regards, Uri -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3367 bytes Desc: not available URL: From jhb at FreeBSD.org Mon Dec 16 17:44:12 2019 From: jhb at FreeBSD.org (John Baldwin) Date: Mon, 16 Dec 2019 09:44:12 -0800 Subject: Backporting KTLS to 1.1.1 In-Reply-To: <4b174378-6312-f46d-9a09-65f93a21cafe@openssl.org> References: <4b174378-6312-f46d-9a09-65f93a21cafe@openssl.org> Message-ID: On 12/14/19 2:09 AM, Matt Caswell wrote: > > > On 13/12/2019 23:52, John Baldwin wrote: >> I've recently been working on adding support for kernel TLS offload >> to FreeBSD and have some patches merged into master already along >> with a couple of open reviews (and at least one other patchset in >> progress). >> >> With the recent-ish announcement of 3.0's release being delayed, >> I'm curious if OpenSSL would consider accepting patches to backport >> KTLS to 1.1.1 or if that is too large a feature to consider >> backporting? (I'm not really familiar with OpenSSL's norms in >> terms of what gets merged.) I will probably end up doing the work >> no matter what and if "it depends" is the answer then I can come >> up with a candidate patch series. >> > > Unfortunately, we do not allow new features in stable branches so we > could not accept such a backport. No problem. That was my guess, but I figured it wouldn't hurt to ask just in case. -- John Baldwin From hsc at mission-embedded.com Tue Dec 17 15:58:07 2019 From: hsc at mission-embedded.com (Schuster Harald) Date: Tue, 17 Dec 2019 15:58:07 +0000 Subject: DTLS-SRTP Support for AES GCM Message-ID: Hi I am using OpenSSL_1.0.2h and I want to use "SRTP_AEAD_AES_256_GCM". I know that there is no srtp profile for AES_256_GCM available in "d1_srtp.c" in my version . I know that the support is added in OpenSSL_1.1.0 but I am not able to update the version. So is there any possibility to solve my problem? Best regards Harald -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Dec 17 23:45:45 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 17 Dec 2019 23:45:45 +0000 Subject: Forthcoming OpenSSL release Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The OpenSSL project team would like to announce the forthcoming release of OpenSSL version 1.0.2u This release will be made available on Friday 20th December 2019 between 1300-1700 UTC. This will contain one LOW severity fix for CVE-2019-1551 previously announced here: https://www.openssl.org/news/secadv/20191206.txt Please see the following page for further details of severity levels: https://www.openssl.org/policies/secpolicy.html This is expected to be the last 1.0.2 release before its End Of Life date on 31st December 2019. Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl35aKkACgkQ2cTSbQ5g RJFTrQgAs5QMVDvkcEaSqKCKxYqTRaFlBCevtyEV/GaMdhWBEwGDsRfn+8jDSD20 i+UbtL6ymCf7xWrIFHbZaY4E/vyT1UhxkBYXj9DCS02eMRqwy7ileWxqs3xZ2Tiq vqCd+PR13hUdfnOZ62P8Uly9MaR7mTnf+bdJ1vvfOMI6DaUy1HqGghI9YHVwuwqE p6TR/jSCp64BpdsWSNKFTIwvd5u/LkpApO2ngLa5pB8BfUFPwu00ekYNtyb5qrya Gu3dIqJrirPl5ePaci/SC2lkjT2LjKcxIbXn1/rXN1WtsCItV9ztBdrjJvt/rbGM r8O+JOLIa0jEDAgC6fwgmeB7ryNY1w== =PqVo -----END PGP SIGNATURE----- From darshanmody at avaya.com Wed Dec 18 08:54:32 2019 From: darshanmody at avaya.com (Mody, Darshan Arvindkumar (Darshan)) Date: Wed, 18 Dec 2019 08:54:32 +0000 Subject: SSL certificate verification Message-ID: Hi We are using SSL_CTX_use_certificate and SSL_CTX_use_certificate_chain_file APIs to load the certificates. My query is when we are loading the certificate in the Context does openssl verify the certificates for e.g. whether the certificate is expired already etc. Thanks and Regards Darshan -------------- next part -------------- An HTML attachment was scrubbed... URL: From janjust at nikhef.nl Wed Dec 18 16:10:42 2019 From: janjust at nikhef.nl (Jan Just Keijser) Date: Wed, 18 Dec 2019 17:10:42 +0100 Subject: SSL certificate verification In-Reply-To: References: Message-ID: <9ee33318-9dcc-ed6e-8f25-8968a69a0ef3@nikhef.nl> On 18/12/19 09:54, Mody, Darshan Arvindkumar (Darshan) wrote: > > Hi > > We are using SSL_CTX_use_certificate and > SSL_CTX_use_certificate_chain_file APIs to load the certificates. > > My query is when we are loading the certificate in the Context does > openssl verify the certificates for e.g. whether the certificate is > expired already etc. > > the short answer is no, it does not; the openssl library will let you load expired/invalid certificates if you do not do any explicit checks.? Use a verify_callback and call X509_verify_cert() to check the validity. HTH, JJK -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Dec 18 17:40:33 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 18 Dec 2019 12:40:33 -0500 Subject: SSL certificate verification In-Reply-To: <9ee33318-9dcc-ed6e-8f25-8968a69a0ef3@nikhef.nl> References: <9ee33318-9dcc-ed6e-8f25-8968a69a0ef3@nikhef.nl> Message-ID: > On Dec 18, 2019, at 11:10 AM, Jan Just Keijser wrote: > > the short answer is no, it does not; the openssl library will let you load expired/invalid certificates if you do not do any explicit checks. Use a verify_callback and call X509_verify_cert() to check the validity. The verify callback is not needed, unless one wants to log the chain or allow some subset of errors. What is needed is an appropriate CAfile and/or CApath or an explicitly specified trust-anchor stack (X509_STORE_CTX_set0_trusted()), and of course X509_STORE_CTX_new(), X509_STORE_CTX_init() and perhaps X509_STORE_CTX_free() unless the the object is reused for the lifetime of the process. -- Viktor. From hujunhua10 at 163.com Thu Dec 19 07:36:34 2019 From: hujunhua10 at 163.com (JoinSenior) Date: Thu, 19 Dec 2019 00:36:34 -0700 (MST) Subject: How to compile OpenSSL 1.1.0f under QNX6.5? Message-ID: <1576740994119-0.post@n7.nabble.com> I am developing QNX software using QNX Momentics Tool Suite. Momentics Tool Suite is installed on my Window7 system, and Neutrino RTOS 6.5 system runs on the target IPC ( Industrial Personal Computer ). Now I need to use openssl 1.1.0f in my program. I download the OpenSSL source code from https://www.openssl.org/source/old/1.1.0/ In OpenSSL compilation guide, OpenSSL library seems to have to be compiled via command line. Configure first, then make. I found this, QNX 6.5 OpenSSL Build http://openssl.6102.n7.nabble.com/QNX-6-5-OpenSSL-Build-td74950.html This page seems to use command line to compile openssl too. But in my situation, no command line is used. How can I create a command line environment to compile openssl in my current situation? Or, can I compile openssl library by QNX Momentics IDE? Thanks -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From openssl at openssl.org Fri Dec 20 13:38:24 2019 From: openssl at openssl.org (OpenSSL) Date: Fri, 20 Dec 2019 13:38:24 +0000 Subject: OpenSSL version 1.0.2u published Message-ID: <20191220133824.GA10996@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.0.2u released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2u of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.0.2-notes.html OpenSSL 1.0.2u is available for download via HTTP 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-1.0.2u.tar.gz Size: 5355412 SHA1 checksum: 740916d79ab0d209d2775277b1c6c3ec2f6502b2 SHA256 checksum: ecd0c6ffb493dd06707d38b14bb4d8c2288bb7033735606569d8f90f89669d16 The checksums were calculated using the following commands: openssl sha1 openssl-1.0.2u.tar.gz openssl sha256 openssl-1.0.2u.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl38yAQACgkQ2cTSbQ5g RJHhkggAgL/QJ1zRY8yppCnf9zT1h3DW6t6nHC+n01GV5Fu6L4lvJqmJEtR+Vr5l u/z+kNDWdeTdic73MAdD9RO/k+sraZ13kAaj5VaQ7Sn16LIok0cQl09Q0yVYaXlC aEVcQ3RUcOneqI+sMLlpIWE26tMCn9MvNmuFNmyOHvYDotJbHQc379Qt6qoYmqHd Hn9vJrIAgjtuwtb2InA5Y29788dwQPXS9qPOWWN/xMOq2t4dSM43vvwrC2jgyTtR tT/l/FZQuu8Y1oVKwuHB43tDM8Gnvpot9DwSxXSxBPcSKxNpKVqvyNUrYohYaruB a6I9lBE7rbRojDiAvg9nUF3PTG0O/w== =IOW8 -----END PGP SIGNATURE----- From doctor at doctor.nl2k.ab.ca Sat Dec 21 06:32:30 2019 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Fri, 20 Dec 2019 23:32:30 -0700 Subject: Daily snapshots Message-ID: <20191221063230.GA46669@doctor.nl2k.ab.ca> What is happening. For 2 days in a row, the snapshots are not available. What gives? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism Merry Christmas 2019 and Happy New Year 2020 ! From levitte at openssl.org Sat Dec 21 19:28:13 2019 From: levitte at openssl.org (Richard Levitte) Date: Sat, 21 Dec 2019 20:28:13 +0100 Subject: Daily snapshots In-Reply-To: <20191221063230.GA46669@doctor.nl2k.ab.ca> References: <20191221063230.GA46669@doctor.nl2k.ab.ca> Message-ID: <87pnghlbqq.wl-levitte@openssl.org> Fixed. Side note: openssl-dev at openssl.org does not exist any more. Cheers, Richard On Sat, 21 Dec 2019 07:32:30 +0100, The Doctor wrote: > > What is happening. > > For 2 days in a row, the snapshots are not available. > > What gives? > -- > Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca > Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! > https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism > Merry Christmas 2019 and Happy New Year 2020 ! > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From dougbmorris at yahoo.com Mon Dec 23 02:18:57 2019 From: dougbmorris at yahoo.com (Douglas Morris) Date: Mon, 23 Dec 2019 02:18:57 +0000 (UTC) Subject: JSON Web Key (JWK) for public key requires x and y coordinates. References: <624395981.1686018.1577067537116.ref@mail.yahoo.com> Message-ID: <624395981.1686018.1577067537116@mail.yahoo.com> Hello, Not a genius with openssl or encryption at all. Thanks for reading. Background: * Generate a private key (really key set) with named curve:openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:prime256v1 -pkeyopt ec_param_enc:named_curve -outform PEM -out account-privkey-prime256v1.pem * Look at named curves representation:openssl pkey -in account-privkey-prime256v1.pem -noout -text * Look at explicit encoding ( I want x and y coordinates ):openssl ec -in? account-privkey-prime256v1.pem -param_enc explicit -text -noout Example output:read EC key Private-Key: (256 bit) priv: ??? ae:b7:b9:30:ed:3d:2f:03:b9:0c:bd:b8:39:b9:5c: ??? 39:33:c0:48:f1:45:a2:b4:8a:1b:4c:8c:86:f0:86: ??? 2a:5a pub: ??? 04:68:1f:bc:7f:2b:c8:c3:c1:4d:5e:b1:2c:b5:29: ??? 62:d7:01:21:51:70:bc:e5:30:ab:10:96:c8:23:0a: ??? 7b:df:85:00:7b:fb:bb:58:4d:e6:4a:80:a6:ef:a1: ??? be:df:72:08:48:e0:3c:13:d4:7d:f8:62:75:d0:d8: ??? b5:aa:c2:b3:c1 Field Type: prime-field Prime: ??? 00:ff:ff:ff:ff:00:00:00:01:00:00:00:00:00:00: ??? 00:00:00:00:00:00:ff:ff:ff:ff:ff:ff:ff:ff:ff: ??? ff:ff:ff A:? ? ??? 00:ff:ff:ff:ff:00:00:00:01:00:00:00:00:00:00: ??? 00:00:00:00:00:00:ff:ff:ff:ff:ff:ff:ff:ff:ff: ??? ff:ff:fc B:? ? ??? 5a:c6:35:d8:aa:3a:93:e7:b3:eb:bd:55:76:98:86: ??? bc:65:1d:06:b0:cc:53:b0:f6:3b:ce:3c:3e:27:d2: ??? 60:4b Generator (uncompressed): ??? 04:6b:17:d1:f2:e1:2c:42:47:f8:bc:e6:e5:63:a4: ??? 40:f2:77:03:7d:81:2d:eb:33:a0:f4:a1:39:45:d8: ??? 98:c2:96:4f:e3:42:e2:fe:1a:7f:9b:8e:e7:eb:4a: ??? 7c:0f:9e:16:2b:ce:33:57:6b:31:5e:ce:cb:b6:40: ??? 68:37:bf:51:f5 Order: ??? 00:ff:ff:ff:ff:00:00:00:00:ff:ff:ff:ff:ff:ff: ??? ff:ff:bc:e6:fa:ad:a7:17:9e:84:f3:b9:ca:c2:fc: ??? 63:25:51 Cofactor:? 1 (0x1) Seed: ??? c4:9d:36:08:86:e7:04:93:6a:66:78:e1:13:9d:26: ??? b7:81:9f:7e:90 * RFC7518, sec. 6.2.1 requires for public key representation key-value pairs for keys 'crv', 'x', and 'y'.The 'crv' value is easy. It's the line NIST CURVE: P-256 from the -text for named curve format, not shown above.The 'x' and the 'y' are not shown. My guess from looking online is that x and y are in the value for openssl -textvalue 'pub'. In output above, pub value (abbreviated) is 04:68...b3:c1. I have not been successful in unpackingthe pub value to show anything coherent. I think the colons can be dropped and what's left can be decodedbase64 or base64url. My openssl (Debian linux) has no 'base64' subcommand. I have found nothing online about this. I figure this should be important. Typically, lack of relevant documentation online means I am making a very original mistake. I am not subscribed to the openssl-users at openssl.org mailing list. I can of course checkthe archives and see if this went into it. What am I doing wrong? I think it's a conceptual thing. I am not a C programmer and don't exactly want to figure out how to use the C functions. Even so, I am interested in what's a reasonable? approach, even if not so reasonable for me. I must be doing something unreasonable. Thanks. Happy Holidays if that applies to you. Bonus Question: Do I or should I worry about seeding for the Pseudorandom Number Generator (PRNG). It seems to me that it would be nice to get a pseudo-random number and just mess it up a bit in a text editor and use that as the seed for making a new key. Just a guess. If you have an informed thought on that, I'd be interested. Thanks for openssl and everything! It's indispensible free software. Douglas Morris -------------- next part -------------- An HTML attachment was scrubbed... URL: From nic.tuv at gmail.com Mon Dec 23 06:24:42 2019 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Mon, 23 Dec 2019 08:24:42 +0200 Subject: JSON Web Key (JWK) for public key requires x and y coordinates. In-Reply-To: <624395981.1686018.1577067537116@mail.yahoo.com> References: <624395981.1686018.1577067537116.ref@mail.yahoo.com> <624395981.1686018.1577067537116@mail.yahoo.com> Message-ID: Hi Douglas, I don't think OpenSSL supports the encoding of keys specified in RFC7518: you are right in believing that the x and y values can be retrieved from the 'pub:' field of the `-text` output for the key, but that field conforms to Sec 2.3.4 of the SEC1 standard (which is referenced also by RFC7518, although they preferred to use a custom representation for the curve point). If I am reading RFC7518 correctly, you would need a piece of software that would take the affine x and y coordinate for the public EC point encoded as the base64 encoding of the octet representation of a field element (zero padded to the byte length of the field order). It is possible to achieve this writing a C/C++ program using the OpenSSL API, but as far as I know, no OpenSSL CLI tool currently supports that format. With a quick glance at Google results though, it seems that many modules supporting JOSE for NodeJS/Ruby/Erlang/Elixir/Python also have methods to parse a public key PEM file and transform into an RFC7518 key. So depending on what language you are using to develop your application you should be able to call something like `JOSE::JWK::from_pem_file('pubkey.pem')` and obtain an object representing the public key that can be exported to the RFC7518 encoding. In Ruby, for example, using the 'jose' gem, you could: ```sh $ openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:prime256v1 -pkeyopt ec_param_enc:named_curve -outform PEM -out account-privkey-prime256v1.pem $ openssl pkey -in account-privkey-prime256v1.pem -pubout -out account-pubkey-prime256v1.pem $ ruby -e 'require "jose"; puts JOSE::JWK::from_pem_file("account-pubkey-prime256v1.pem").to_map.to_h' {"y"=>"vUFxfD2pBMjv-iaX8zKnNeXe2GaZcspLdnyoPzEK89w", "kty"=>"EC", "crv"=>"P-256", "x"=>"-3zPuCvv1VTw1hs5X4pCLkj3QQjocw9lYEKxqKG27W8"} ``` Bonus answer: I am not an expert on the RAND module of OpenSSL, but the short answer should be that if you are using the latest release of OpenSSL, most likely you don't need to worry about seeding manually the PRNG, as the RAND module should be doing everything it can to gather the required entropy from the facilities provided by your platform and feeding it through a state-of-the-art cryptographic PRNG implementation to obtain the cryptographically secure randomness needed, e.g. for the key generation above. Of course I cannot say anything about the functionality provided by whatever framework you are going to use for the rest of your RFC7518 operations, as what they use depends on their cryptographic backend (which could be OpenSSL or some other software). Best regards (and Happy Holidays to you as well) Nicola Tuveri From cpatil1818 at gmail.com Mon Dec 23 09:34:03 2019 From: cpatil1818 at gmail.com (Channa Patil) Date: Mon, 23 Dec 2019 15:04:03 +0530 Subject: Memory leaks in OpenSSL while using for EAP-FAST In-Reply-To: References: Message-ID: Hi, > > I am using OpenSSL 1.0.2l to implement EAP-FAST. > Auth is successful, but I am seeing memory leak in OpenSSL > Allocated in tasn_utl.c:174 and bn_lib.c:303 (approx. 550-600 bytes) > > In other flows I have seen its getting freed in lh_delete from SSL_CTX_free > > not sure I what I am missing. > > Anyone seen similar issue?/ how to overcome this? > > Best Regards, > Patil > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougbmorris at yahoo.com Tue Dec 24 01:27:31 2019 From: dougbmorris at yahoo.com (Douglas Morris) Date: Tue, 24 Dec 2019 01:27:31 +0000 (UTC) Subject: Great answer, Nicola Tuveri! References: <1337278572.1951284.1577150851088.ref@mail.yahoo.com> Message-ID: <1337278572.1951284.1577150851088@mail.yahoo.com> Thanks, Nicola. You know your stuff and write well. Reading your answer was actually pleasant. Douglas Morris -------------- next part -------------- An HTML attachment was scrubbed... URL: From mann.patidar at gmail.com Tue Dec 24 05:01:47 2019 From: mann.patidar at gmail.com (Manish Patidar) Date: Tue, 24 Dec 2019 10:31:47 +0530 Subject: Openssl3.0. Fips release Message-ID: Hi Is there any update on Openssl3.0 fips release date. When we can expect the formal version ? Regards Manish -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Tue Dec 24 05:05:49 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Tue, 24 Dec 2019 15:05:49 +1000 Subject: Openssl3.0. Fips release In-Reply-To: References: Message-ID: <6F168D87-EC11-4291-BAC7-50EA135E7713@oracle.com> The expected date for submission to NIST for validation is Q4 2020. The actual validation will occur at some point after this. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 24 Dec 2019, at 3:01 pm, Manish Patidar wrote: > > Hi > > Is there any update on Openssl3.0 fips release date. When we can expect the formal version ? > > > Regards > Manish -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougbmorris at yahoo.com Wed Dec 25 03:49:29 2019 From: dougbmorris at yahoo.com (Douglas Morris) Date: Wed, 25 Dec 2019 03:49:29 +0000 (UTC) Subject: X25519 Unlisted by -list_curves and Any Trusted Python Code for X, Y Coordinates References: <329198284.2186653.1577245769159.ref@mail.yahoo.com> Message-ID: <329198284.2186653.1577245769159@mail.yahoo.com> Hello, I've done some research of other peoples opinions and that's the best I can do. Please advise SVP. I want to us ECDSA for my Web server's SSL certificate via an ACME client to Let's Encrypt and maybe later BuyPass. I thought that EC is better than RSA, but now I don't think so. The answer seems to be: it depends. Safe Curves (SafeCurves: Introduction) says that the NIST curves are P-224, P-256 (ye prime256v1 and what I was trying to implement with Python3 ACME client), and P-384 and NOT SAFE. They did not mention RSA. They give key type Curve25519 a fully passing grade. I think that is ye X25519, also know as ed25519. Linux program ssh has ed25519. I don't trust NIST 'cause I don't trust NSA. | | | | SafeCurves: Introduction | | | This is a comparison that favors old RSA over new ECDSA: Comparing ECDSA vs RSA - SSL.com | | | | | | | | | | | Comparing ECDSA vs RSA - SSL.com A discussion of the pros and cons of RSA and ECDSA, two of the most widely-used digital signature algorithms. | | | This suggests that RSA keys are mostly safe: Is it still safe to use RSA Encryption? - Hashed Out by The SSL Store? | | | | | | | | | | | Is it still safe to use RSA Encryption? - Hashed Out by The SSL Store? RSA could potentially be cracked by careless implementation, but does that mean it?s broken? Let?s talk about RS... | | | So my conclusion is to prefer in descending order of preference: ed25519, RSA-4096 (I suppose RSA-8196 is sorta overkill maybe. I suspect quantum computers would make it not overkill, but then mobile devises might not like it for the overhead.) My local version of openssl is:OpenSSL 1.1.1d? 10 Sep 2019 When I openssl ecparam -list_curves I do NOT get X25519. However, I was apple to generate a private key per ye documentation (manpage for genpkey): /docs/man1.1.0/man1/genpkey.html | | | | /docs/man1.1.0/man1/genpkey.html OpenSSL Foundation, Inc. | | | Hey, I have that manpage on my linux. So whadayouknow? My remote virtual machine has OpenSSL 1.0.2g? 1 Mar 2016 and no X25519. On my local machine, the CSR generation fails only for the X25519 private key: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Two-letter Country Code [US]: 139873970037888:error:0608D096:digital envelope routines:EVP_PKEY_sign_init:operation not supported for this keytype:../crypto/evp/pmeth_fn.c:40: Supposing I can get a resolution to using X25519, anybody know of how to get the X and Y coordinates of a public key of type X29915 in the Python3 language? The PYPI repository has python-jose, which uses pyca/cryptography, which is in PYPI as plain, old 'cryptography 2.8'. My exploration of pyca/cryptography's documentation is what led me to the safe curves webpage. Maybe I can get the x and y coordinates with it. Looks scary. So any informed assessments on:(1) key types RSA, PRIME-256, and ed25519,(2) on openssl and X25519, or(3) getting the X and Y coordinates of the ed25519 public key for making a JSON Web Key (JWK) for a ACME client in Python3. The ACME protocol is rfc8555 and refers to 'the "EdDSA" signature algorithm using the "Ed25519" variant'. Interestingly, rfc 7518 for JWA (A is for Algorithms) does not have ed25519--though I can't rule out a standards repository somewhere could have it as an addition, for all I know--and does have the curves P-256, P-384, and P-521. Emhhm. Maybe I should just use RSA and likewise regress to ed for all my editing needs. I knew a consultant who used ed and was quite good. My supervisor joked about rubbing two sticks together. I'm sure there's lot of vi fans here. 'Twas the night before Christmas and I was stirring. Stirring I tell ya. Me and a mouse. Douglas Morris -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Dec 25 23:50:29 2019 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 25 Dec 2019 23:50:29 +0000 Subject: X25519 Unlisted by -list_curves and Any Trusted Python Code for X, Y Coordinates In-Reply-To: <329198284.2186653.1577245769159@mail.yahoo.com> References: <329198284.2186653.1577245769159.ref@mail.yahoo.com> <329198284.2186653.1577245769159@mail.yahoo.com> Message-ID: <94DF060A-2079-4E2A-9CBB-3067590FCEA1@akamai.com> * I want to us ECDSA for my Web server's SSL certificate via an ACME client to Let's Encrypt and maybe later BuyPass. That?s fine. * I thought that EC is better than RSA, but now I don't think so. The answer seems to be: it depends. There are trade-offs. The biggest one is that EC gives equivalent security with a much smaller keysize. * Safe Curves (SafeCurves: Introduction) says ? FWIW, SafeCurves is mostly the guy behind 25519 :) This is not a slam against djb, who?s kinda brilliant. If you?re not sure what to do, perhaps follow what the browsers do. That way if something?s wrong you?ll just be going up in flames with the rest of the world. If you don?t trust the NSA and therefore don?t trust NIST, do you accept AES? What about when they approve 25519? -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Sat Dec 28 13:16:03 2019 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Sat, 28 Dec 2019 16:16:03 +0300 Subject: OIDs parent-child comparison Message-ID: Hello, Does openssl have any function allowing OID parent-child comparison (is "1.2.3.4.5" a descendant of "1.2.3") or such comparison should be implemented as comparing OBJ_obj2txt? Thanks! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.peillon at caenlamer.fr Sat Dec 28 22:02:50 2019 From: s.peillon at caenlamer.fr (PEILLON Stephane) Date: Sat, 28 Dec 2019 22:02:50 +0000 Subject: Segfault with Libcrypto.so Message-ID: Hello For several days, we have been unable to carry out operating commands on our OpenLdap server (2.4.48), such as: /usr/local/openldap/sbin/slapcat ?F /usr/local/openldap/etc/openldap/slapd.d -b 'cn = config' -a '(| (objectclass = olcBdbConfig) (objectclass = olcHdbConfig) (objectclass = olcMdbConfig))' The errors are: kernel: [110775.944931] slapcat [2659]: segfault at 60 ip 00007fa1afc98300 sp00007fff98c66b20 error 4 in libcrypto.so.1.1 [7fa1afaa2000 + 29b000] This server is in version: Linux XXXXXXXX 4.15.0-72-generic-81-Ubuntu SMP Tue Nov 26 12:20:02 UTC 2019 x86_64 x86_64 x86_64 GNU / Linux The version of openSSL is: OpenSSL 1.1.1 11 Sep 2018 built on: Tue Nov 12 16:58:35 2019 UTC platform: debian-amd64 options: bn (64,64) rc4 (16x, int) des (int) blowfish (ptr) compile: gcc -fPIC -pthread -m64 -Wa, - noexecstack -Wall -Wa, - noexecstack -g -O2 -fdebug-prefix-map = / build / openssl-kxN_24 / openssl-1.1.1 =. -fstack-protector-strong -Wformat -Werror = size-security -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 -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE = 2 OPENSSLDIR: "/ usr / lib / ssl" ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1" Seeding source: os-specific Can you tell me what to modify to correct this error? thank you in advance for your help! Stephane [http://disclaimer.caenlamer.fr/img/bandeau.jpg] -------------- next part -------------- An HTML attachment was scrubbed... URL: From nic.tuv at gmail.com Sat Dec 28 22:43:30 2019 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Sun, 29 Dec 2019 00:43:30 +0200 Subject: Segfault with Libcrypto.so In-Reply-To: References: Message-ID: Is it possible you have compiled and installed the openldap tool you are using against an older version of the system installed openssl library which has since been updated? In that case you would probably need to recompile and reinstall your custom openldap against the new version of the library. Best regards, Nicola Tuveri On Sun, Dec 29, 2019, 00:11 PEILLON Stephane wrote: > Hello > > > > For several days, we have been unable to carry out operating commands on > our OpenLdap server (2.4.48), such as: > > /usr/local/openldap/sbin/slapcat ?F > /usr/local/openldap/etc/openldap/slapd.d -b 'cn = config' -a '(| > (objectclass = olcBdbConfig) (objectclass = olcHdbConfig) (objectclass = > olcMdbConfig))' > > > > The errors are: > > kernel: [110775.944931] slapcat [2659]: segfault at 60 ip 00007fa1afc98300 > sp00007fff98c66b20 error 4 in libcrypto.so.1.1 [7fa1afaa2000 + 29b000] > > > > This server is in version: Linux XXXXXXXX 4.15.0-72-generic-81-Ubuntu SMP > Tue Nov 26 12:20:02 UTC 2019 x86_64 x86_64 x86_64 GNU / Linux > > > > The version of openSSL is: > > OpenSSL 1.1.1 11 Sep 2018 > > built on: Tue Nov 12 16:58:35 2019 UTC > > platform: debian-amd64 > > options: bn (64,64) rc4 (16x, int) des (int) blowfish (ptr) > > compile: gcc -fPIC -pthread -m64 -Wa, - noexecstack -Wall -Wa, - > noexecstack -g -O2 -fdebug-prefix-map = / build / openssl-kxN_24 / > openssl-1.1.1 =. -fstack-protector-strong -Wformat -Werror = size-security > -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 -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM > -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DNDEBUG > -Wdate-time -D_FORTIFY_SOURCE = 2 > > OPENSSLDIR: "/ usr / lib / ssl" > > ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1" > > Seeding source: os-specific > > > > Can you tell me what to modify to correct this error? > > > > thank you in advance for your help! > > Stephane > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From felipe at felipegasper.com Tue Dec 31 13:34:41 2019 From: felipe at felipegasper.com (Felipe Gasper) Date: Tue, 31 Dec 2019 08:34:41 -0500 Subject: OpenSSL + ktls Message-ID: <4F899FC9-723C-471E-97BE-F38B7D162689@felipegasper.com> Hello, Is it possible, after having done a TLS handshake in OpenSSL, to extract the necessary connection parameters from OpenSSL and pass those to the requisite setsockopt() call to initiate ktls outside of OpenSSL? Thank you! -Felipe Gasper