From jb-openssl at wisemo.com Tue Jan 2 02:21:38 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 2 Jan 2018 03:21:38 +0100 Subject: [openssl-users] Can't build OpenSSL on Windows In-Reply-To: References: <20171229.000641.1297349608194041259.levitte@openssl.org> <20171229145927.2201-1-martin@eclypsium.com> <20171229.181404.780642950361658869.levitte@openssl.org> Message-ID: On 29/12/2017 19:34, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Richard Levitte >> Sent: Friday, December 29, 2017 12:14 >> >> If any of those are newer, 'nmake' will >> automatically reconfigure and ask you to run again. > It's also worth noting that nmake's dependency-graph generation is flaky (possibly due to flaws in Windows file timestamping, though I've never tracked down the exact cause). I have a number of nmake files that regularly rebuild things unnecessarily, and others that sporadically do. > > So as Richard said, check the time on the machine and try running nmake again. Sometimes it's worth temporarily throttling the CPU to slow the build down a bit. > FYI: The historic "Windows/DOS" timestamp implementation issue was that many years ago, the FAT file system had a timestamp resolution of 2 seconds, which meant that naively ported versions of *n*x make would sometimes not realize that it was ok for a derived file to have the same timestamp (rounded) as the file from which it was derived. This is not the case for NTFS (currently dominant) which has a timestamp resolution of 100ns, nor for modernized versions of the FAT file system (stores sub-second decimals in a previously unused field). nmake was historically written to run under DOS, and was thus never affected by the 2s rounding or other such limitations.? However nmake may not have been well maintained as Microsoft shifted focus to their more complex (but less capable) build systems, such as the old Visual Studio (devenv.com) build system or the XML-based MSBuild system. These days the most common "timestamp related" build issues on Windows are about the fact that the Windows file commands default to preserving the timestamps of files (similar to GNU "cp --preserve=timestamps" ). This sometimes confuses build systems that assume file timestamps get updated when a file is copied into a build directory. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From asteja.chowdary.ece13 at itbhu.ac.in Tue Jan 2 13:15:55 2018 From: asteja.chowdary.ece13 at itbhu.ac.in (Sai Teja Chowdary) Date: Tue, 2 Jan 2018 18:45:55 +0530 Subject: [openssl-users] How to form a proper hash after writing somethinginto SSL handshake.(Revised) In-Reply-To: References: Message-ID: <5a4b860c.02bf630a.130a4.09df@mx.google.com> Hi, Happy 2018 everyone. I figured out this issue, I think it would be good to share it here in case if anyone is interested in knowing. The right way to make a hash is by calculating hash individually for the messages client certificate, client key exchange and store the message buffer in an array before calculating the signature in certificate verify message. later after forming the certificate verify message append this to the previous array and write the whole buffer into the wire with ssl3_write_bytes().This way all three message CC, CKE and CV goes in a single record as multiple handshake messages. The function ssl3_finish_mac() is the one that does the hash (Digest) of bytes which ever are to be written to or read from wire. Regards Saiteja. From: Viktor Dukhovni Sent: Saturday, December 30, 2017 10:48 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] How to form a proper hash after writing somethinginto SSL handshake.(Revised) > On Dec 29, 2017, at 10:18 PM, Sai Teja Chowdary wrote: > > I want to send client certificate, client key exchange and client verify in a single handshake message which appears as multiple handshake messages in a single record. But to sent the client verify I need to first make a hash of previous messages(client certificate and client key exchange) to create the signature. I tried framing the record with above three messages and then directly sending the record in the wire using SSL3_write_machine() which is giving me Bad signature error. So i thought of doing a hash of client certificate and client key exchange messages that go before client verify. > > Can anyone help me to find the function in OpenSSL 1.1.1-dev xx XXX xxxx (or right procedure that needs to be done before creating a certificate verify message)that can do a proper transcript(digest or hash not clear). I tried using ssl3_finish_mac() on the message containing client certificate and client key exchange and then tried to generate the signature in certificate verify message. There is no such feature, and none is likely to ever be offered. The reason is that you're essentially trying to write your own TLS implementation, and SSL library in OpenSSL is provides public interfaces for SSL users, not for new SSL implementations. You can of course build your OpenSSL implementation based on the OpenSSL source code, but figuring out how the code works is then up to you. :-( -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at denninger.net Wed Jan 3 00:38:56 2018 From: karl at denninger.net (Karl Denninger) Date: Tue, 2 Jan 2018 18:38:56 -0600 Subject: [openssl-users] Unclear docs -- request clarification on X509_STORE_add_cert Message-ID: Assume the following code snippet: const unsigned char a_cert = {....... }; (A DER certificate we wish to load into the context's chain storage) int size_a_cert = sizeof(a_cert); const unsigned char *cp; X509 *cc_cert; X509_STORE *cc = SSL_CTX_get_cert_store(a_context); if (cc == NULL) { ??? panic ("Cannot get chain; fail"); } cp = a_cert; cc_cert = d2i_X509(NULL, &cp, size_a_cert); if (cc_cert == NULL) { ????? panic("Cert not valid"); } if (!X509_STORE_add_cert(cc, cc_cert)) {??????? /* Push the cert into the chain store */ ???? panic ("Cannot add required chain certificate"); } /*? X509_free(cc_cert); */ The question is the last line and whether it should be there (uncommented) -- does the X509_STORE_add_cert call load the *reference* or does it load the *data* (allocating whatever it needs internally to do so)?? In other words do I need to keep that X509 structure around that got allocated by the d2i_X509 call or do I free it after I've pushed it into the store? The docs are silent on this as far as I can tell but some example code I've seen floating around doesn't free it. -- Karl Denninger karl at denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4897 bytes Desc: S/MIME Cryptographic Signature URL: From dcoombs at carillon.ca Wed Jan 3 01:10:47 2018 From: dcoombs at carillon.ca (Dave Coombs) Date: Tue, 2 Jan 2018 20:10:47 -0500 Subject: [openssl-users] Unclear docs -- request clarification on X509_STORE_add_cert In-Reply-To: References: Message-ID: <7F07C4F9-1EBB-42E3-9366-F87DB385F393@carillon.ca> Hello, Looking at the code in x509_lu.c, X509_STORE_add_cert() takes ownership of your X509 *cc_cert -- you don't need to (and probably shouldn't) free it. Cheers, -Dave > On Jan 2, 2018, at 19:38, Karl Denninger wrote: > > Assume the following code snippet: > > const unsigned char a_cert = {....... }; (A DER certificate we wish to load into the context's chain storage) > int size_a_cert = sizeof(a_cert); > > const unsigned char *cp; > > X509 *cc_cert; > X509_STORE *cc = SSL_CTX_get_cert_store(a_context); > if (cc == NULL) { > panic ("Cannot get chain; fail"); > } > cp = a_cert; > cc_cert = d2i_X509(NULL, &cp, size_a_cert); > if (cc_cert == NULL) { > panic("Cert not valid"); > } > if (!X509_STORE_add_cert(cc, cc_cert)) { /* Push the cert into the chain store */ > panic ("Cannot add required chain certificate"); > } > /* X509_free(cc_cert); */ > The question is the last line and whether it should be there (uncommented) -- does the X509_STORE_add_cert call load the *reference* or does it load the *data* (allocating whatever it needs internally to do so)? In other words do I need to keep that X509 structure around that got allocated by the d2i_X509 call or do I free it after I've pushed it into the store? > > The docs are silent on this as far as I can tell but some example code I've seen floating around doesn't free it. > -- > Karl Denninger > karl at denninger.net > The Market Ticker > [S/MIME encrypted email preferred] > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Jan 3 01:25:52 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 2 Jan 2018 20:25:52 -0500 Subject: [openssl-users] Unclear docs -- request clarification on X509_STORE_add_cert In-Reply-To: References: Message-ID: <18D16D5D-7421-4B1E-A0E3-868AAD24FD20@dukhovni.org> > On Jan 2, 2018, at 7:38 PM, Karl Denninger wrote: > > The question is the last line and whether it should be there (uncommented) -- does the X509_STORE_add_cert call load the *reference* or does it load the *data* (allocating whatever it needs internally to do so)? In other words do I need to keep that X509 structure around that got allocated by the d2i_X509 call or do I free it after I've pushed it into the store? > > The docs are silent on this as far as I can tell but some example code I've seen floating around doesn't free it. The store takes ownership of the object (bumps its reference count when it is added to the store) and so the caller should free it if no longer needed outside the store. At first glance I thought that commit: c0452248ea1a59a41023a4765ef7d9825e80a62b changed this in master, but a more careful reading of the code reveals that the behaviour remains the same (corect). The behaviour should of course be documented. Feel free to open an issue on github. I should note that taking ownership of the object when added to the store is the "natural" or "expected" behaviour, and while this does not "excuse" not documenting it, that should be the best guess of how the function behaves. -- Viktor. From openssl-users at dukhovni.org Wed Jan 3 01:27:29 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 2 Jan 2018 20:27:29 -0500 Subject: [openssl-users] Unclear docs -- request clarification on X509_STORE_add_cert In-Reply-To: <7F07C4F9-1EBB-42E3-9366-F87DB385F393@carillon.ca> References: <7F07C4F9-1EBB-42E3-9366-F87DB385F393@carillon.ca> Message-ID: <1FF7DDB5-AF17-4336-970B-6F3BB6751E60@dukhovni.org> > On Jan 2, 2018, at 8:10 PM, Dave Coombs wrote: > > Looking at the code in x509_lu.c, X509_STORE_add_cert() takes ownership of your X509 *cc_cert -- you don't need to (and probably shouldn't) free it. The observation is correct, but the conclusion is wrong. The object is reference counted, and X509_free() is needed to avoid a leak (when the store is freed along with the context). -- Viktor. From dcoombs at carillon.ca Wed Jan 3 01:36:45 2018 From: dcoombs at carillon.ca (Dave Coombs) Date: Tue, 2 Jan 2018 20:36:45 -0500 Subject: [openssl-users] Unclear docs -- request clarification on X509_STORE_add_cert In-Reply-To: <1FF7DDB5-AF17-4336-970B-6F3BB6751E60@dukhovni.org> References: <7F07C4F9-1EBB-42E3-9366-F87DB385F393@carillon.ca> <1FF7DDB5-AF17-4336-970B-6F3BB6751E60@dukhovni.org> Message-ID: <9CA5256C-9FB5-4886-8174-345960BC4FB9@carillon.ca> > The observation is correct, but the conclusion is wrong. > The object is reference counted, and X509_free() is needed > to avoid a leak (when the store is freed along with the > context). My apologies -- I assumed based on its name that X509_OBJECT_up_ref_count was upping the refcount on the internal X509_OBJECT, which had taken over the X509*, which led to my conclusion that freeing the X509_STORE frees the X509 too. However, you're right, it ups the refcount on the underlying X509, and so the caller *should* free the underlying object when finished with it. I've now confirmed with a quick test program and valgrind. Oops, -Dave From karl at denninger.net Wed Jan 3 02:24:49 2018 From: karl at denninger.net (Karl Denninger) Date: Tue, 2 Jan 2018 20:24:49 -0600 Subject: [openssl-users] Unclear docs -- request clarification on X509_STORE_add_cert In-Reply-To: <9CA5256C-9FB5-4886-8174-345960BC4FB9@carillon.ca> References: <7F07C4F9-1EBB-42E3-9366-F87DB385F393@carillon.ca> <1FF7DDB5-AF17-4336-970B-6F3BB6751E60@dukhovni.org> <9CA5256C-9FB5-4886-8174-345960BC4FB9@carillon.ca> Message-ID: On 1/2/2018 19:36, Dave Coombs wrote: >> The observation is correct, but the conclusion is wrong. >> The object is reference counted, and X509_free() is needed >> to avoid a leak (when the store is freed along with the >> context). > My apologies -- I assumed based on its name that X509_OBJECT_up_ref_count was upping the refcount on the internal X509_OBJECT, which had taken over the X509*, which led to my conclusion that freeing the X509_STORE frees the X509 too. However, you're right, it ups the refcount on the underlying X509, and so the caller *should* free the underlying object when finished with it. > > I've now confirmed with a quick test program and valgrind. > > Oops, > -Dave Thanks. -- Karl Denninger karl at denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4897 bytes Desc: S/MIME Cryptographic Signature URL: From grace.priscilla at gmail.com Wed Jan 3 10:40:46 2018 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Wed, 3 Jan 2018 16:10:46 +0530 Subject: [openssl-users] Issue on DTLS over UDP In-Reply-To: References: Message-ID: Hi, Can someone please respond to the below mail as we want to confirm if it is an issue with our application or a bug in openSSL. Thanks, Grace On Fri, Dec 15, 2017 at 3:23 PM, Grace Priscilla Jero < grace.priscilla at gmail.com> wrote: > Hi All, > > We are having an issue with DTLS on UDP. > > The scenario is that, when a client of DTLS version 1.2 is trying to > connect to a server which is at version DTLS 1.0 the SSL_accept > continuously loops with error 2. The ALERT is not processed. > Is this a known bug? > > Because of the loop, the application is unable to process new changes. > > Thanks, > Grace > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Jan 3 10:53:29 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 3 Jan 2018 10:53:29 +0000 Subject: [openssl-users] Issue on DTLS over UDP In-Reply-To: References: Message-ID: On 03/01/18 10:40, Grace Priscilla Jero wrote: > Hi, > Can someone please respond to the below mail as we want to confirm if it > is an issue with our application or a bug in openSSL. It isn't a known bug (which doesn't mean it isn't an unknown bug!). I think we're going to need some more information to help you with this issue. If I understand you correctly you have a server application which only supports DTLS 1.0 and it is that application which is failing? Which version of OpenSSL is this? All currently supported versions of OpenSSL have the capability to support DTLS1.2 so I'm not sure why you have this scenario. You say that "SSL_accept continuously loops with error 2". Do you mean by that SSL_accept() returns an error and calling SSL_get_error() gives you SSL_ERROR_WANT_READ (value 2)? "The ALERT is not processed": does this mean you are expecting to see an alert but it isn't sent? Or an alert is sent but it is ignored? Perhaps a wireshark trace of the exchange would help us to understand what you are seeing. Matt > > Thanks, > Grace > > On Fri, Dec 15, 2017 at 3:23 PM, Grace Priscilla Jero > > wrote: > > Hi All, > > We are having an issue with DTLS on UDP. > > The scenario is that, when a client of DTLS version 1.2 is trying to > connect to a server which is at version DTLS 1.0 the SSL_accept > continuously loops with error 2. The ALERT is not processed.? > Is this a known bug? > > Because of the loop, the application is unable to process new changes.? > > Thanks, > Grace > > > > From gadphly at gmail.com Wed Jan 3 22:02:33 2018 From: gadphly at gmail.com (Gelareh Taban) Date: Wed, 3 Jan 2018 16:02:33 -0600 Subject: [openssl-users] Padding for RSA signatures In-Reply-To: <17ab7c75-e4a1-65ee-85c8-4b32d07fbceb@openssl.org> References: <17ab7c75-e4a1-65ee-85c8-4b32d07fbceb@openssl.org> Message-ID: Hi Matt, Thanks so much for your replies. Got my signature verification to fail which makes me happy :-) The only remaining question is: > 4 - In general, is there a way of making the Signature/Encryptions in > OpenSSL be deterministic for debugging/testing purposes? > Any ideas or thoughts? cheers, Gelareh On Fri, Dec 29, 2017 at 10:07 AM, Matt Caswell wrote: > Some comments inserted below. > > Matt > > On 29/12/17 15:20, Gelareh Taban wrote: > > Hi all, > > > > Any help would be *much* appreciated. I am playing around with RSA > > signatures with different padding options and I have some questions. > > > > I am trying to define different padding options and so am defining and > > using a EVP_PKEY_CTX . However I am not sure if this padding is getting > > used in the signature since my Verify outputs OK regardless of which > > option my Sign uses. Which leads to: > > > > 1 - Do I need to use a EVP_PKEY_CTX with the same options when doing > > verify? If so, I assume I can't reuse the same PKey_Ctx and I have to > > define another one. Right now even when I don't use any EVP_PKEY_CTX in > > Verify, I still verify OK, which makes me question if the padding option > > has been set. > > It hasn't. The call to EVP_DigestSignInit() expects an EVP_PKEY_CTX **. > This is because that function creates its *own* EVP_PKEY_CTX * and > stores it in the location you provide (if you give one). In your code > the EVP_PKEY_CTX you are creating is being overwritten by the one > created by EVP_DigestSignInit(). From the documentation: > > EVP_DigestSignInit() sets up signing context ctx to use digest type > from ENGINE impl and private key pkey. ctx must be created with > EVP_MD_CTX_new() before calling this function. If pctx is not NULL the > EVP_PKEY_CTX of the signing operation will be written to *pctx: this > can be used to set alternative signing options. > > Try removing the creation of your own EVP_PKEY_CTX *, and moving the > EVP_PKEY_CTX_set_rsa_padding() call to after EVP_DigestSignInit(). > > > > > 2 - Is there a way to figure out what padding/hashing/etc option was > > used for the Sign/verify operation? This way I can be sure what > > algorithm or standard is being used. > > > > 3 - Do I need to set the hash function I am using in both EVP_PKEY_CTX > > as well as EVP_MD_CTX ? Or the latter is what defines this for the > > signing option? > > You only need to specify the hash function in > EVP_DigestSignInit()/EVP_DigestVerifyInit(). > > To answer your question in the code, there is no need to call > EVP_PKEY_CTX_set_signature_md() directly in this scenario. It is called > for you by EVP_DigestSignInit()/EVP_DigestVerifyInit(). > > > > > 4 - In general, is there a way of making the Signature/Encryptions in > > OpenSSL be deterministic for debugging/testing purposes? > > > 5 - I noticed that there are two ways of determining the signature size: > > (a) by calling EVP_PKEY_size(rsaKeypair) as I am doing below, as well as > > (b) calling EVP_DigestSignFinal(md_ctx, nil, &sig_len) . Is one better > > than the other? > > The former gives you a maximum bound on the size of the signature before > the signature is created. The latter gives you the *actual* size of the > signature that is generated (which could be smaller). > > > > > > My sample code is below for reference. It's in Swift (but it should > > still be close enough to C to be readable). Also in Swift, some of the > > complex macros in OpenSSL have to be broken down to be compilable hence > > my usage of EVP_DigestUpdate instead of EVP_DigestVerifyUpdate . > > > > Thanks in advance for any insight in the above. > > > > cheers! > > Gelareh > > > > > > let md_ctx = EVP_MD_CTX_create() > > > > let md_ctx_verify = EVP_MD_CTX_create() > > > > > > > > // To define padding option used in signature > > > > let pkey_ctx = EVP_PKEY_CTX_new(rsaKeypair, nil) > > > > > > > > // EVP_PKEY_CTX_set_rsa_padding(pkey_ctx, RSA_PKCS1_PADDING) - > > complex macro needs to be replaced > > > > EVP_PKEY_CTX_ctrl(pkey_ctx, EVP_PKEY_RSA, -1, > > EVP_PKEY_CTRL_RSA_PADDING, RSA_X931_PADDING, nil) > > > > > > // EVP_PKEY_CTX_set_signature_md() When should this be set? > > > > > > > > // SIGN > > > > var rc = EVP_DigestSignInit(md_ctx, &pkey_ctx, EVP_sha256(), > > nil, myRSA.rsaKeypair) > > > > // EVP_DigestSignUpdate(md_ctx, message, message.count) > > > > // Complex macro needs to be replaced > > > > rc = EVP_DigestUpdate(md_ctx, message, message.count) > > > > > > > > // allocate memory for signature > > > > var sig_len: Int = Int(EVP_PKEY_size(rsaKeypair)) > > > > let sig = UnsafeMutablePointer.allocate(capacity: > sig_len) > > > > > > rc = EVP_DigestSignFinal(md_ctx, sig, &sig_len) > > > > > > > > > > > > // VERIFY > > > > rc = EVP_DigestVerifyInit(md_ctx_verify, nil, EVP_sha256(), nil, > > rsaKeypair) > > > > > > // rc = EVP_DigestVerifyUpdate(md_ctx_verify, message, > > message.count) > > > > rc = EVP_DigestUpdate(md_ctx_verify, message, message.count) > > > > > > > > rc = EVP_DigestVerifyFinal(md_ctx_verify, sig, sig_len) > > > > print("signature verified = \(rc == 1? "OK": "FAIL")") > > > > > > > > > > > > > > > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Jan 4 02:55:24 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 4 Jan 2018 02:55:24 +0000 Subject: [openssl-users] Padding for RSA signatures In-Reply-To: References: <17ab7c75-e4a1-65ee-85c8-4b32d07fbceb@openssl.org> Message-ID: <480E41FC-1F11-4393-B7D2-9AF2BE8F239C@akamai.com> > 4 - In general, is there a way of making the Signature/Encryptions in > OpenSSL be deterministic for debugging/testing purposes? > You can define your own RAND method that implements a known sequence. Look at test/ecdsatest.c in master, for example. -------------- next part -------------- An HTML attachment was scrubbed... URL: From inmotiont at gmail.com Thu Jan 4 18:08:22 2018 From: inmotiont at gmail.com (InMotion Man) Date: Thu, 4 Jan 2018 10:08:22 -0800 Subject: [openssl-users] AES_unwrap_key returns 0 In-Reply-To: References: Message-ID: Hello all, I'm having trouble using the AES_unwrap_key function. I have tried different things but it always returns 0 and the out buffer does not get written to. I can wrap a key with the AES_wrap_key. Then I pass the wrapped key output to AES_unwrap_key and it is not able to unwrap it. This is regardless if I use the default IV (passing NULL to the function) or pass an explicit IV.See sample code below. Has anybody seen this issue? Any help will be appreciated. I'm using OpenSSL 1.1.0.f *#include * *int* *main(int argc, char **argv)* *{* * int i;* * int ret;* * unsigned char wrappedKeyData[24];* * unsigned char KEK[] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F};* * unsigned char keyData[] = {0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF};* * unsigned char IV[8] = {0xA6, 0xA6, 0xA6, 0xA6, 0xA6, 0xA6, 0xA6, 0xA6};* * AES_KEY wrp_key;* * AES_set_encrypt_key(KEK, 128, &wrp_key);* * /* wrapping */* * ret = AES_wrap_key(&wrp_key, NULL, wrappedKeyData, keyData, 16);* * printf("openssl wrapping returns %i\n", ret);* * printf("wrapped keyData: ");* * for (i = 0; i < ret; i++) {* * printf ("%02x", wrappedKeyData[i]);* * }* * printf("\n");* * /* unwrapping */* * unsigned char keyDataOut[16];* * ret = AES_unwrap_key(&wrp_key, NULL, keyDataOut, wrappedKeyData, 24);* * printf("unwrapping openssl returns %i\n", ret);* * printf("unwrapped keyData: ");* * for (i = 0; i < 16; i++) {* * printf ("%02x", keyDataOut[i]) ;* * }* * printf("\n");* * return EXIT_SUCCESS;* *}* -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Jan 5 10:58:58 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 5 Jan 2018 10:58:58 +0000 Subject: [openssl-users] Issue on DTLS over UDP In-Reply-To: References: Message-ID: <409506d7-ffaa-1a37-2598-e207b2f73556@openssl.org> On 05/01/18 05:30, Grace Priscilla Jero wrote: > Hi Matt, > We are using openssl v 1.1.0g. > Attaching the pcap files. Thanks - that helped a lot and I have been able to recreate your issue. The problem is this: - The server is DTLSv1.0 only - The client is DTLSv1.2 only - When the server selects DTLSv1.0 the client sends back a protocol version alert with a record version of DTLSv1.2 - The server is expecting incoming records of version DTLSv1.0, because that is the version it selected. Anything else is silently discarded, including the incoming protocol version alert. Whether this behaviour is a "bug" or not is debatable. The spec is quite unclear in this regards. The only thing relevant I can see is this: "Unlike TLS, DTLS is resilient in the face of invalid records (e.g., invalid formatting, length, MAC, etc.). In general, invalid records SHOULD be silently discarded, thus preserving the association; ..." An OpenSSL client (at least in 1.1.0 - I didn't check other versions), will respond with a DTLSv1.0 alert record if it doesn't like the protocol version selected by the server, so this situation never arises when an OpenSSL client is talking to an OpenSSL server. Probably the right thing for us to do is be more tolerant of record version number mismatches when the record type is alert. I have created a patch to do that here (master and 1.1.0): https://github.com/openssl/openssl/pull/5018 And the 1.0.2 version is here: https://github.com/openssl/openssl/pull/5019 I've also attached a patch file suitable for applying to 1.1.0g. This issue triggers a few other thoughts for your case: - I am wondering why you have configured your server for DTLSv1.0 only given that 1.1.0g is perfectly capable of talking both DTLSv1.2 and DTSLv1.0 - Your server application should probably be modified to ensure it is capable of handling a stalled connection like this (e.g. by timing out after a period if a connection is not achieved). Such stalled connections can happen in DTLS due to packet loss. For example the protocol version alert could be dropped at a network level. Alerts are never retransmitted, so the server will wait for ever waiting for the next message. - Do you control the client in this case? I wonder why the client is configured for DTLSv1.2 only (rather than being able to handle both DTLSv1.2 *and* DTLSv1.0). Is this a deliberate choice or a mis-configuration? Matt > > yes, the SSL_get_error() gives 2. > The alert is sent but ignored. > > Thanks, > Grace > > On Wed, Jan 3, 2018 at 4:23 PM, Matt Caswell > wrote: > > > > On 03/01/18 10:40, Grace Priscilla Jero wrote: > > Hi, > > Can someone please respond to the below mail as we want to confirm if it > > is an issue with our application or a bug in openSSL. > > It isn't a known bug (which doesn't mean it isn't an unknown bug!). > > I think we're going to need some more information to help you with this > issue. If I understand you correctly you have a server application which > only supports DTLS 1.0 and it is that application which is failing? > Which version of OpenSSL is this? All currently supported versions of > OpenSSL have the capability to support DTLS1.2 so I'm not sure why you > have this scenario. > > You say that "SSL_accept continuously loops with error 2". Do you mean > by that SSL_accept() returns an error and calling SSL_get_error() gives > you SSL_ERROR_WANT_READ (value 2)? > > "The ALERT is not processed": does this mean you are expecting to see an > alert but it isn't sent? Or an alert is sent but it is ignored? > > Perhaps a wireshark trace of the exchange would help us to understand > what you are seeing. > > Matt > > > > > > Thanks, > > Grace > > > > On Fri, Dec 15, 2017 at 3:23 PM, Grace Priscilla Jero > > > >> wrote: > > > >? ? ?Hi All, > > > >? ? ?We are having an issue with DTLS on UDP. > > > >? ? ?The scenario is that, when a client of DTLS version 1.2 is > trying to > >? ? ?connect to a server which is at version DTLS 1.0 the SSL_accept > >? ? ?continuously loops with error 2. The ALERT is not processed.? > >? ? ?Is this a known bug? > > > >? ? ?Because of the loop, the application is unable to process new > changes.? > > > >? ? ?Thanks, > >? ? ?Grace > > > > > > > > > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: tolerate-dtls-alerts.patch Type: text/x-patch Size: 1524 bytes Desc: not available URL: From murugesh.pitchaiah at gmail.com Fri Jan 5 11:07:48 2018 From: murugesh.pitchaiah at gmail.com (murugesh pitchaiah) Date: Fri, 5 Jan 2018 16:37:48 +0530 Subject: [openssl-users] FIPS_mode_set - failed - SSLEAY_RAND_BYTES:PRNG not seeded Message-ID: Hi All, Need your inputs on below issue: When I try to set the FIPS mode, seeing below error and failure intermittently: Error: FIPS_mode_set(1) failed. Reason: error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not seeded I am using following versions: openssl-1.0.2k openssl-fips-ecp-2.0.16 in canister model. Please share if this is known issue and any fix available for the same. Thanks, Murugesh P. From mithunsingh at gmail.com Fri Jan 5 13:40:55 2018 From: mithunsingh at gmail.com (Mithun Kumar) Date: Fri, 5 Jan 2018 19:10:55 +0530 Subject: [openssl-users] FIPS_mode_set - failed - SSLEAY_RAND_BYTES:PRNG not seeded In-Reply-To: References: Message-ID: I have seen similar issue on linux when /dev/random failed to generate seed when application tries to create many SSL connections in parallel. On Fri, Jan 5, 2018 at 4:37 PM, murugesh pitchaiah < murugesh.pitchaiah at gmail.com> wrote: > Hi All, > > Need your inputs on below issue: > > When I try to set the FIPS mode, seeing below error and failure > intermittently: > > Error: FIPS_mode_set(1) failed. Reason: error:24064064:random number > generator:SSLEAY_RAND_BYTES:PRNG not seeded > > I am using following versions: > openssl-1.0.2k > openssl-fips-ecp-2.0.16 in canister model. > > Please share if this is known issue and any fix available for the same. > > Thanks, > Murugesh P. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcoombs at carillon.ca Fri Jan 5 13:44:35 2018 From: dcoombs at carillon.ca (Dave Coombs) Date: Fri, 5 Jan 2018 08:44:35 -0500 Subject: [openssl-users] AES_unwrap_key returns 0 In-Reply-To: References: Message-ID: <4467FDCC-0F4C-49D8-AABF-700D3C83E17D@carillon.ca> Hello, This is just a guess, but try AES_set_decrypt_key() before trying to unwrap? -Dave > On Jan 4, 2018, at 13:08, InMotion Man wrote: > > Hello all, > I'm having trouble using the AES_unwrap_key function. I have tried different things but it always returns 0 and the out buffer does not get written to. > > I can wrap a key with the AES_wrap_key. Then I pass the wrapped key output to AES_unwrap_key and it is not able to unwrap it. This is regardless if I use the default IV (passing NULL to the function) or pass an explicit IV.See sample code below. > > Has anybody seen this issue? Any help will be appreciated. > I'm using OpenSSL 1.1.0.f > > #include > > int > main(int argc, char **argv) > { > int i; > int ret; > unsigned char wrappedKeyData[24]; > unsigned char KEK[] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F}; > unsigned char keyData[] = {0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF}; > unsigned char IV[8] = {0xA6, 0xA6, 0xA6, 0xA6, 0xA6, 0xA6, 0xA6, 0xA6}; > > AES_KEY wrp_key; > AES_set_encrypt_key(KEK, 128, &wrp_key); > > /* wrapping */ > ret = AES_wrap_key(&wrp_key, NULL, wrappedKeyData, keyData, 16); > printf("openssl wrapping returns %i\n", ret); > printf("wrapped keyData: "); > for (i = 0; i < ret; i++) { > printf ("%02x", wrappedKeyData[i]); > } > printf("\n"); > > /* unwrapping */ > unsigned char keyDataOut[16]; > ret = AES_unwrap_key(&wrp_key, NULL, keyDataOut, wrappedKeyData, 24); > printf("unwrapping openssl returns %i\n", ret); > printf("unwrapped keyData: "); > for (i = 0; i < 16; i++) { > printf ("%02x", keyDataOut[i]) ; > } > printf("\n"); > > return EXIT_SUCCESS; > } > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From inmotiont at gmail.com Fri Jan 5 18:29:17 2018 From: inmotiont at gmail.com (InMotion Man) Date: Fri, 5 Jan 2018 10:29:17 -0800 Subject: [openssl-users] AES_unwrap_key returns 0 In-Reply-To: <4467FDCC-0F4C-49D8-AABF-700D3C83E17D@carillon.ca> References: <4467FDCC-0F4C-49D8-AABF-700D3C83E17D@carillon.ca> Message-ID: Hello Dave, Your guess exactly right. This is my first time using the OpenSSL library and I didn't know there was a different function to create encryption and decryption AES_KEY. Thank you for the help and sorry for the newbie question. Cheers, IMM. On Fri, Jan 5, 2018 at 5:44 AM, Dave Coombs wrote: > Hello, > > This is just a guess, but try AES_set_decrypt_key() before trying to unwrap? > > -Dave > > > On Jan 4, 2018, at 13:08, InMotion Man wrote: > > Hello all, > I'm having trouble using the AES_unwrap_key function. I have tried different > things but it always returns 0 and the out buffer does not get written to. > > I can wrap a key with the AES_wrap_key. Then I pass the wrapped key output > to AES_unwrap_key and it is not able to unwrap it. This is regardless if I > use the default IV (passing NULL to the function) or pass an explicit IV.See > sample code below. > > Has anybody seen this issue? Any help will be appreciated. > I'm using OpenSSL 1.1.0.f > > #include > > int > main(int argc, char **argv) > { > int i; > int ret; > unsigned char wrappedKeyData[24]; > unsigned char KEK[] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, > 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F}; > unsigned char keyData[] = {0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, > 0x77, 0x88, 0x99, 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF}; > unsigned char IV[8] = {0xA6, 0xA6, 0xA6, 0xA6, 0xA6, 0xA6, 0xA6, 0xA6}; > > AES_KEY wrp_key; > AES_set_encrypt_key(KEK, 128, &wrp_key); > > /* wrapping */ > ret = AES_wrap_key(&wrp_key, NULL, wrappedKeyData, keyData, 16); > printf("openssl wrapping returns %i\n", ret); > printf("wrapped keyData: "); > for (i = 0; i < ret; i++) { > printf ("%02x", wrappedKeyData[i]); > } > printf("\n"); > > /* unwrapping */ > unsigned char keyDataOut[16]; > ret = AES_unwrap_key(&wrp_key, NULL, keyDataOut, wrappedKeyData, 24); > printf("unwrapping openssl returns %i\n", ret); > printf("unwrapped keyData: "); > for (i = 0; i < 16; i++) { > printf ("%02x", keyDataOut[i]) ; > } > printf("\n"); > > return EXIT_SUCCESS; > } > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From openssl-users at dukhovni.org Mon Jan 8 23:57:22 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 8 Jan 2018 18:57:22 -0500 Subject: [openssl-users] Failed to access LDAP server when a valid certificate is at .1+ In-Reply-To: <5A53F4B7.8030401@oracle.com> References: <59EB65C1.80100@oracle.com> <80538E95-D469-4208-A7E1-39111C64AB4C@dukhovni.org> <5A53F4B7.8030401@oracle.com> Message-ID: <27BB0350-B953-489B-8C18-EA1F84F0E66E@dukhovni.org> > On Jan 8, 2018, at 5:46 PM, Misaki Miyashita wrote: > > I would like to suggest the following fix so that a valid certificate at .x can be recognized during the cert validation even when .0 is linking to a bad/expired certificate. This may not be the most elegant solution, but it is a minimal change with low impact to the rest of the code. The patch looks wrong to me. It seems to have a memory leak. It is also not clear that with CApath all the certificates will already be loaded, so the iterator may not find the desired matching element. > Could I possibly get a review on the change? and possibly be considered to be integrated to the upstream? > (This is for the 1.0.1 branch) The 1.0.1 branch is no longer supported. -- Viktor. From norm.green at gemtalksystems.com Tue Jan 9 00:33:16 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Mon, 8 Jan 2018 16:33:16 -0800 Subject: [openssl-users] cert chain file ordering question Message-ID: <5b21f521-5f95-71c1-2e59-3dd3f8a10581@gemtalksystems.com> This question is regarding OpenSSL 1.1. Let's say I have this trust hierarchy: RootCA CA1 CA2 CA3 userCert So userCert is signed by CA3, CA3 is signed by CA2, and so on up to RootCA, which is a self-signed root cert. If I combine CA1,CA2,CA3 and userCert into single PEM file, chain.pem, the openssl verify command only verifies the chain is correct if the order of the file is such that the user cert occurs *last* in the chain as follows: CA1 CA2 CA3 userCert openssl verify -CAfile RootCA.pem chain.pem What strikes me as odd is the order shown above is the *opposite* of what is needed for the SSL_CTX_user_certificate_chain_file() function, which requires the highest level CA to appear at the end of the file. From the man page: SSL_CTX_use_certificate_chain_file() loads a certificate chain from file into ctx. The certificates must be in PEM format and must be sorted starting with the subject's certificate (actual client or server certificate), followed by intermediate CA certificates if applicable, and ending at the highest level (root) CA. SSL_use_certificate_chain_file() is similar except it loads the certificate chain into ssl. Is my understanding of things correct?? Seems like there should be a way for the openssl command to verify a chain file which will be used with the SSL_CTX_use_certificate_chain_file() function. Norm Green From bkaduk at akamai.com Tue Jan 9 14:03:23 2018 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 9 Jan 2018 08:03:23 -0600 Subject: [openssl-users] cert chain file ordering question In-Reply-To: <5b21f521-5f95-71c1-2e59-3dd3f8a10581@gemtalksystems.com> References: <5b21f521-5f95-71c1-2e59-3dd3f8a10581@gemtalksystems.com> Message-ID: <694f45d0-cf11-a0ab-e788-897254bd3a5c@akamai.com> On 01/08/2018 06:33 PM, Norm Green wrote: > This question is regarding OpenSSL 1.1. > > Let's say I have this trust hierarchy: > > RootCA > CA1 > CA2 > CA3 > userCert > > > So userCert is signed by CA3, CA3 is signed by CA2, and so on up to > RootCA, which is a self-signed root cert. > > If I combine CA1,CA2,CA3 and userCert into single PEM file, chain.pem, > the openssl verify command only verifies the chain is correct if the > order of the file is such that the user cert occurs *last* in the > chain as follows: > > CA1 > CA2 > CA3 > userCert > > openssl verify -CAfile RootCA.pem chain.pem > > > What strikes me as odd is the order shown above is the *opposite* of > what is needed for the SSL_CTX_user_certificate_chain_file() function, > which requires the highest level CA to appear at the end of the file. > From the man page: > > SSL_CTX_use_certificate_chain_file() loads a certificate chain from > file into ctx. The certificates must be in PEM format and must be > sorted starting with the subject's certificate (actual client or > server certificate), followed by intermediate CA certificates if > applicable, and ending at the highest level (root) CA. > SSL_use_certificate_chain_file() is similar except it loads the > certificate chain into ssl. > > Is my understanding of things correct?? Seems like there should be a > way for the openssl command to verify a chain file which will be used > with the > SSL_CTX_use_certificate_chain_file() function. But the verify command is intended to verify an *individual* certificate, not a file containing an entire chain -- the specific chain used is somewhat incidental. Did you try something like (with a 1.1.0 installation): openssl verify -CAfile RootCA.pem -untrusted chain.pem chain.pem with the leaf certificate as the first one in chain.pem? -Ben From patrick at schlangen.me Tue Jan 9 17:56:56 2018 From: patrick at schlangen.me (Patrick Schlangen) Date: Tue, 9 Jan 2018 18:56:56 +0100 Subject: [openssl-users] SSL_dane_tlsa_add function signature Message-ID: <001a01d38973$3e3cc250$bab646f0$@schlangen.me> Hi, please forgive me if this question has been asked before. > int SSL_dane_tlsa_add(SSL *s, uint8_t usage, uint8_t selector, > uint8_t mtype, unsigned char *data, size_t dlen); Reading the docs, my impression ist hat SSL_dane_tlsa_add adds a TLSA record to the SSL object for later use during verification. What puzzles me is that the data argument of type unsigned char is not const. Will the function modify the data buffer in any way? Also, is it safe to free the data after calling SSL_dane_tlsa_add, or phrased differently: Will SSL_dane_tlsa_add create a copy of the data? Thanks a lot in advance, Patrick From openssl-users at dukhovni.org Tue Jan 9 18:24:46 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 9 Jan 2018 13:24:46 -0500 Subject: [openssl-users] SSL_dane_tlsa_add function signature In-Reply-To: <001a01d38973$3e3cc250$bab646f0$@schlangen.me> References: <001a01d38973$3e3cc250$bab646f0$@schlangen.me> Message-ID: > On Jan 9, 2018, at 12:56 PM, Patrick Schlangen wrote: > > Reading the docs, my impression ist hat SSL_dane_tlsa_add adds a TLSA record > to the SSL object for later use during verification. > What puzzles me is that the data argument of type unsigned char is not > const. It should have been "const". Sorry about that. If you're enthusiastic to contribute, please feel free to file a githu pull-request against ssl/ssl_lib.c and include/openssl/ssl.h (which for a first pull-request will also require you to file contributor license agreement). If that's all too much work, I can fix the issue on your behalf. > Will the function modify the data buffer in any way? No. > Also, is it safe to free the data after calling SSL_dane_tlsa_add Yes. > or phrased differently: Will SSL_dane_tlsa_add create a copy of the data? Yes. -- Viktor. From patrick at schlangen.me Tue Jan 9 18:56:10 2018 From: patrick at schlangen.me (Patrick Schlangen) Date: Tue, 9 Jan 2018 19:56:10 +0100 Subject: [openssl-users] SSL_dane_tlsa_add function signature In-Reply-To: References: <001a01d38973$3e3cc250$bab646f0$@schlangen.me> Message-ID: <002e01d3897b$849c60e0$8dd522a0$@schlangen.me> > On Jan 9, 2018, at 19:25 PM, Viktor Dukhovni wrote: > If you're enthusiastic to contribute, please feel free to file a githu pull-request Thanks a lot for the fast reply. I've submitted a pull request at https://github.com/openssl/openssl/pull/5046 and will mail the CLA ASAP. Best Regards, Patrick From openssl-users at dukhovni.org Tue Jan 9 19:08:40 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 9 Jan 2018 14:08:40 -0500 Subject: [openssl-users] SSL_dane_tlsa_add function signature In-Reply-To: <002e01d3897b$849c60e0$8dd522a0$@schlangen.me> References: <001a01d38973$3e3cc250$bab646f0$@schlangen.me> <002e01d3897b$849c60e0$8dd522a0$@schlangen.me> Message-ID: <49C0BCFA-6A42-4717-8A37-87F28DA1DBA8@dukhovni.org> > On Jan 9, 2018, at 1:56 PM, Patrick Schlangen wrote: > > Thanks a lot for the fast reply. I've submitted a pull request at > https://github.com/openssl/openssl/pull/5046 and will mail the CLA ASAP. Great! Appreciated. Are you at all at liberty to say how (really to what end) you plan to use the DANE support in OpenSSL? Feel free to reply off-list if that makes a difference. -- Viktor. From misaki.miyashita at oracle.com Tue Jan 9 20:49:22 2018 From: misaki.miyashita at oracle.com (Misaki Miyashita) Date: Tue, 9 Jan 2018 14:49:22 -0600 Subject: [openssl-users] Failed to access LDAP server when a valid certificate is at .1+ In-Reply-To: <27BB0350-B953-489B-8C18-EA1F84F0E66E@dukhovni.org> References: <59EB65C1.80100@oracle.com> <80538E95-D469-4208-A7E1-39111C64AB4C@dukhovni.org> <5A53F4B7.8030401@oracle.com> <27BB0350-B953-489B-8C18-EA1F84F0E66E@dukhovni.org> Message-ID: <77b72a00-17dd-48f6-0603-d68505988d53@oracle.com> Thank you so much for the review, Viktor. On 1/8/2018 5:57 PM, Viktor Dukhovni wrote: >> On Jan 8, 2018, at 5:46 PM, Misaki Miyashita wrote: >> >> I would like to suggest the following fix so that a valid certificate at .x can be recognized during the cert validation even when .0 is linking to a bad/expired certificate. This may not be the most elegant solution, but it is a minimal change with low impact to the rest of the code. > The patch looks wrong to me. It seems to have a memory leak. > It is also not clear that with CApath all the certificates will > already be loaded, so the iterator may not find the desired > matching element. I will look into the code to see if there is a memory leak issue. However, we have tested internally and all certificates (valid and invalid) were loaded, and the suggested fix is able to identify the matching valid certificate. > >> Could I possibly get a review on the change? and possibly be considered to be integrated to the upstream? >> (This is for the 1.0.1 branch) > The 1.0.1 branch is no longer supported. Sorry, that was a typo :-(? I meant the 1.0.2 branch. -- misaki From norm.green at gemtalksystems.com Tue Jan 9 22:55:02 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Tue, 9 Jan 2018 14:55:02 -0800 Subject: [openssl-users] cert chain file ordering question In-Reply-To: <694f45d0-cf11-a0ab-e788-897254bd3a5c@akamai.com> References: <5b21f521-5f95-71c1-2e59-3dd3f8a10581@gemtalksystems.com> <694f45d0-cf11-a0ab-e788-897254bd3a5c@akamai.com> Message-ID: On 1/9/2018 6:03 AM, Benjamin Kaduk wrote: > Did you try something like (with a 1.1.0 installation): > > openssl verify -CAfile RootCA.pem -untrusted chain.pem chain.pem > > with the leaf certificate as the first one in chain.pem? Same result. The only way it seems to work is if the leaf cert appears at the end of the file. Norm From d3ck0r at gmail.com Tue Jan 9 23:04:04 2018 From: d3ck0r at gmail.com (J Decker) Date: Tue, 9 Jan 2018 15:04:04 -0800 Subject: [openssl-users] cert chain file ordering question In-Reply-To: References: <5b21f521-5f95-71c1-2e59-3dd3f8a10581@gemtalksystems.com> <694f45d0-cf11-a0ab-e788-897254bd3a5c@akamai.com> Message-ID: The certs are built into a stack... they are pushed... so element 0 is the last thing in the list. The chain starts with 0, and then can search the rest. On Tue, Jan 9, 2018 at 2:55 PM, Norm Green wrote: > On 1/9/2018 6:03 AM, Benjamin Kaduk wrote: > >> Did you try something like (with a 1.1.0 installation): >> >> openssl verify -CAfile RootCA.pem -untrusted chain.pem chain.pem >> >> with the leaf certificate as the first one in chain.pem? >> > > Same result. The only way it seems to work is if the leaf cert appears at > the end of the file. > > Norm > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Jan 9 23:36:26 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 9 Jan 2018 18:36:26 -0500 Subject: [openssl-users] cert chain file ordering question In-Reply-To: References: <5b21f521-5f95-71c1-2e59-3dd3f8a10581@gemtalksystems.com> <694f45d0-cf11-a0ab-e788-897254bd3a5c@akamai.com> Message-ID: > On Jan 9, 2018, at 5:55 PM, Norm Green wrote: > > Same result. The only way it seems to work is if the leaf cert appears at the end of the file. You're badly mistaken. *ONLY* the first certificate in the file is verified. When you put the leaf cert at the end, you're *ONLY* verifying the top-most issuer CA certificate. The correct way to verify a chain is to put the root CA in a CAfile, intermediate CAs in an "untrusted" chain file, and the leaf cert all by itself in a separate file. As explained upstream. If that's not working, then perhaps your chain is actually incomplete or otherwise does not satisfy all the requirements. -- Viktor. From openssl-users at dukhovni.org Tue Jan 9 23:38:05 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 9 Jan 2018 18:38:05 -0500 Subject: [openssl-users] cert chain file ordering question In-Reply-To: References: <5b21f521-5f95-71c1-2e59-3dd3f8a10581@gemtalksystems.com> <694f45d0-cf11-a0ab-e788-897254bd3a5c@akamai.com> Message-ID: <2D8ACDA1-7F20-4774-AEF3-C4A6CB0DAF41@dukhovni.org> > On Jan 9, 2018, at 6:04 PM, J Decker wrote: > > The certs are built into a stack... they are pushed... so element 0 is the last thing in the list. > The chain starts with 0, and then can search the rest. This is either false or irrelevant depending on what you intended (too terse to know which). -- Viktor. From norm.green at gemtalksystems.com Tue Jan 9 23:43:57 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Tue, 9 Jan 2018 15:43:57 -0800 Subject: [openssl-users] cert chain file ordering question In-Reply-To: References: <5b21f521-5f95-71c1-2e59-3dd3f8a10581@gemtalksystems.com> <694f45d0-cf11-a0ab-e788-897254bd3a5c@akamai.com> Message-ID: <1e08abcd-039c-7e01-5b0c-42435c1554db@gemtalksystems.com> Well that is not *at all* obvious from the documentation, but ok. What is the correct order of intermediate CA certs in the untrusted chain file? On 1/9/2018 3:36 PM, Viktor Dukhovni wrote: > The correct way to verify a chain is to put the root CA in a CAfile, > intermediate CAs in an "untrusted" chain file, and the leaf cert all > by itself in a separate file. From openssl-users at dukhovni.org Tue Jan 9 23:57:31 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 9 Jan 2018 18:57:31 -0500 Subject: [openssl-users] cert chain file ordering question In-Reply-To: <1e08abcd-039c-7e01-5b0c-42435c1554db@gemtalksystems.com> References: <5b21f521-5f95-71c1-2e59-3dd3f8a10581@gemtalksystems.com> <694f45d0-cf11-a0ab-e788-897254bd3a5c@akamai.com> <1e08abcd-039c-7e01-5b0c-42435c1554db@gemtalksystems.com> Message-ID: <61F1A10E-5B8C-4F0D-8DC3-4D01255F0338@dukhovni.org> > On Jan 9, 2018, at 6:43 PM, Norm Green wrote: > > What is the correct order of intermediate CA certs in the untrusted chain file? The untrusted CA list is a heap, the order is irrelevant. -- Viktor. From norm.green at gemtalksystems.com Wed Jan 10 00:28:39 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Tue, 9 Jan 2018 16:28:39 -0800 Subject: [openssl-users] cert chain file ordering question In-Reply-To: <61F1A10E-5B8C-4F0D-8DC3-4D01255F0338@dukhovni.org> References: <5b21f521-5f95-71c1-2e59-3dd3f8a10581@gemtalksystems.com> <694f45d0-cf11-a0ab-e788-897254bd3a5c@akamai.com> <1e08abcd-039c-7e01-5b0c-42435c1554db@gemtalksystems.com> <61F1A10E-5B8C-4F0D-8DC3-4D01255F0338@dukhovni.org> Message-ID: It still doesn't verify correctly. To simplify, I tried it with 1 intermediate CA. Here's the chain: rootCa.pem - self-signed root cert. CN = rootCA firstIntermedCa.pem - intermediate CA cert signed by rootCa.pem. CN = EmeaCA secondIntermedCa.pem - intermediate CA cert signed by firstIntermedCa.pem.? CN = KapitalCA openssl verify -verbose -show_chain -CAfile rootCa.pem -untrusted firstIntermedCa.pem secondIntermedCa.pem 1.3.6.1.4.1.47749.1.1 = userCA, CN = KapitalCA error 20 at 0 depth lookup: unable to get local issuer certificate error secondIntermedCa.pem: verification failed On 1/9/2018 3:57 PM, Viktor Dukhovni wrote: > >> On Jan 9, 2018, at 6:43 PM, Norm Green wrote: >> >> What is the correct order of intermediate CA certs in the untrusted chain file? > The untrusted CA list is a heap, the order is irrelevant. > From openssl-users at dukhovni.org Wed Jan 10 00:55:50 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 9 Jan 2018 19:55:50 -0500 Subject: [openssl-users] cert chain file ordering question In-Reply-To: References: <5b21f521-5f95-71c1-2e59-3dd3f8a10581@gemtalksystems.com> <694f45d0-cf11-a0ab-e788-897254bd3a5c@akamai.com> <1e08abcd-039c-7e01-5b0c-42435c1554db@gemtalksystems.com> <61F1A10E-5B8C-4F0D-8DC3-4D01255F0338@dukhovni.org> Message-ID: > On Jan 9, 2018, at 7:28 PM, Norm Green wrote: > > It still doesn't verify correctly. Or correctly fails to verify? > To simplify, I tried it with 1 intermediate CA. Here's the chain: > > rootCa.pem - self-signed root cert. CN = rootCA > firstIntermedCa.pem - intermediate CA cert signed by rootCa.pem. CN = EmeaCA > secondIntermedCa.pem - intermediate CA cert signed by firstIntermedCa.pem. CN = KapitalCA Without the certificates (no private keys, just the certs) in question it quite difficult to offer much help. > openssl verify -verbose -show_chain -CAfile rootCa.pem -untrusted firstIntermedCa.pem secondIntermedCa.pem > 1.3.6.1.4.1.47749.1.1 = userCA, CN = KapitalCA > error 20 at 0 depth lookup: unable to get local issuer certificate > error secondIntermedCa.pem: verification failed In addition to posting the certificates in question, please post (again even if posted previously) what version of OpenSSL you're using, the output of: $ openssl version -a will suffice. -- Viktor. From norm.green at gemtalksystems.com Wed Jan 10 01:29:59 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Tue, 9 Jan 2018 17:29:59 -0800 Subject: [openssl-users] cert chain file ordering question In-Reply-To: References: <5b21f521-5f95-71c1-2e59-3dd3f8a10581@gemtalksystems.com> <694f45d0-cf11-a0ab-e788-897254bd3a5c@akamai.com> <1e08abcd-039c-7e01-5b0c-42435c1554db@gemtalksystems.com> <61F1A10E-5B8C-4F0D-8DC3-4D01255F0338@dukhovni.org> Message-ID: >Or correctly fails to verify? Perhaps.? Hopefully you'll be able to tellme. Here's the version info and a dump of the certs. Thanks for your help. Norm openssl version -a OpenSSL 1.1.0g? 2 Nov 2017 built on: reproducible build, date unspecified platform: linux-x86_64 compiler: /usr/bin/gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/export/moop3/users/normg/gs64-3xm3/slow50/openssl_1.1/install50/ssl\"" -DENGINESDIR="\"/export/moop3/users/normg/gs64-3xm3/slow50/openssl_1.1/install50/lib/engines-1.1\"" OPENSSLDIR: "/export/moop3/users/normg/gs64-3xm3/slow50/openssl_1.1/install50/ssl" ENGINESDIR: "/export/moop3/users/normg/gs64-3xm3/slow50/openssl_1.1/install50/lib/engines-1.1" opensslx509 -in secondIntermedCa.pem -noout -text Certificate: ??? Data: ??????? Version: 3 (0x2) ??????? Serial Number: 4097 (0x1001) ??? Signature Algorithm: sha256WithRSAEncryption ??????? Issuer: 1.3.6.1.4.1.47749.1.1 = userCA, CN = EmeaCA ??????? Validity ??????????? Not Before: Jan? 8 23:23:59 2018 GMT ??????????? Not After : Jan? 8 23:23:59 2019 GMT ??????? Subject: 1.3.6.1.4.1.47749.1.1 = userCA, CN = KapitalCA ??????? Subject Public Key Info: ??????????? Public Key Algorithm: rsaEncryption ??????????????? Public-Key: (2048 bit) ??????????????? Modulus: 00:d1:26:00:3b:36:08:50:1b:30:96:c4:d9:c9:48: 1d:26:e4:f7:5a:ea:27:7a:ce:e6:3f:83:c6:e8:3e: f9:88:e0:e9:e3:a5:81:05:ff:e5:3f:63:d9:db:5e: da:33:62:aa:a6:26:a3:b0:d5:f9:5e:1a:24:af:1e: a8:e9:bb:58:25:84:bb:90:86:4a:58:aa:a8:95:87: e5:b1:f3:0f:9a:e4:24:a4:60:2b:bb:02:f5:38:34: 6b:75:58:e6:a1:d4:04:3e:1c:cb:70:14:61:cf:6a: 09:52:a9:d0:e3:90:63:f5:77:3c:d0:6a:04:13:56: f1:79:fe:49:05:de:ff:19:cb:1a:61:77:b5:34:0b: 7e:b7:e9:35:b0:bd:b1:57:20:50:9a:b5:2f:ac:35: e5:c4:81:ac:61:4d:81:e3:05:1c:a4:04:f9:80:c0: 44:e6:01:76:9d:8e:7d:a5:0a:ff:92:5f:44:06:52: be:49:b5:44:c4:6a:43:91:d3:d3:f9:14:ad:f5:78: 62:fa:3b:53:e2:84:0c:cc:7d:6e:46:46:f1:7b:b5: bb:df:12:7d:0d:23:0c:8d:a8:33:8a:c5:b6:b0:e5: bc:fd:38:b4:e1:96:ca:96:ce:bb:99:c2:d0:6b:35: e3:17:7c:5f:20:2c:52:51:4d:61:9f:63:e3:fc:f9: ??????????????????? c8:ab ??????????????? Exponent: 65537 (0x10001) ??????? X509v3 extensions: ??????????? X509v3 Subject Key Identifier: C7:26:0D:BB:DF:7E:90:CA:7F:A0:C8:B7:CC:09:44:27:C0:53:A7:97 ??????????? X509v3 Authority Key Identifier: keyid:0F:D8:48:FB:6C:8D:C3:1A:E1:5C:94:32:45:E8:EA:DE:5B:C5:E5:34 ??????????? X509v3 Basic Constraints: critical ??????????????? CA:TRUE ??????????? X509v3 Key Usage: ??????????????? Digital Signature, Key Encipherment ??? Signature Algorithm: sha256WithRSAEncryption 84:5d:c1:1d:f1:b0:03:f1:b2:32:17:0e:be:45:6b:41:f8:97: 17:6a:d0:3e:37:5b:c6:d7:a7:23:83:37:d0:e6:6c:f0:9e:63: ca:8a:89:c4:96:ee:c9:58:d8:97:f6:35:71:57:f9:fc:a5:d2: 98:ba:f4:77:5c:83:62:7a:2a:06:73:13:25:5d:ae:c7:05:0d: 67:51:b3:4d:06:cb:41:3a:26:ac:59:34:6c:e8:9f:f2:f8:a9: 55:b0:b6:c4:5e:1c:f7:5c:25:16:89:c4:2a:e0:7d:9d:6f:db: 47:20:48:3c:42:4b:f0:cd:a6:b1:fc:98:b2:b0:83:8a:4d:47: 01:33:b2:67:5f:90:94:50:39:31:ef:16:22:52:5d:fe:c1:13: c8:67:43:70:ff:3f:8c:d5:ef:5f:a7:eb:3a:f7:8e:b3:f2:28: 37:41:3b:aa:c7:af:e7:7b:96:17:6c:5e:47:ff:2c:2d:b5:63: 55:12:77:ce:61:83:52:a9:5a:83:3b:d8:e9:0a:e6:6a:4d:eb: 79:2c:54:33:36:2e:f6:67:4b:a2:1b:86:71:f5:56:50:d7:34: 85:45:6c:4d:11:0a:2e:b9:98:e9:3a:07:d6:ea:7b:89:d3:ae: d0:71:5b:b1:5b:fa:e9:f8:e5:18:f3:1e:3e:05:d6:27:9a:bf: ???????? 89:7c:ac:b4 opensslx509 -in firstIntermedCa.pem -noout -text Certificate: ??? Data: ??????? Version: 3 (0x2) ??????? Serial Number: 4096 (0x1000) ??? Signature Algorithm: sha256WithRSAEncryption ??????? Issuer: 1.3.6.1.4.1.47749.1.1 = rootCA ??????? Validity ??????????? Not Before: Jan? 8 23:23:08 2018 GMT ??????????? Not After : Jan? 8 23:23:08 2019 GMT ??????? Subject: 1.3.6.1.4.1.47749.1.1 = userCA, CN = EmeaCA ??????? Subject Public Key Info: ??????????? Public Key Algorithm: rsaEncryption ??????????????? Public-Key: (2048 bit) ??????????????? Modulus: 00:cd:46:bf:77:3c:b5:89:fc:58:96:b3:6c:df:93: 30:28:79:e7:d2:61:ca:37:78:e3:eb:3b:da:13:d7: a3:b7:dd:89:1c:35:b2:5e:77:eb:df:4b:c5:c3:fe: 38:23:8b:bc:ff:f2:1a:f4:b3:0a:92:ee:2a:27:0e: c0:a9:bc:3f:05:dd:88:b7:ca:c8:b6:6a:fe:b0:b3: 6f:da:fa:ef:aa:61:f3:31:d3:55:70:ca:3f:aa:d0: 1f:7a:3d:57:04:a9:e1:16:a8:79:04:4a:3e:6e:1a: e5:0f:7a:a9:3e:02:d5:44:a1:18:74:1d:96:ba:98: 5f:fc:97:1d:62:36:3a:4b:3b:64:85:1a:8d:10:80: 3f:15:00:9b:18:ed:a6:0f:f1:a9:6e:f9:ab:42:bd: 72:75:13:bb:48:56:80:d3:5d:06:f6:32:59:9f:b4: 62:32:4d:fb:7e:12:6a:3f:a5:0d:05:74:a9:3e:11: 6f:9b:a3:61:7f:8b:ac:7d:52:1c:99:f5:be:bd:48: 6e:6c:ae:70:b5:44:27:1f:40:4a:b3:9c:e5:78:02: c7:b0:a3:c6:18:86:51:a8:8a:1a:86:fc:73:6c:7f: d9:a7:95:55:ed:b3:6c:65:d0:0a:b6:15:69:e3:24: ea:b9:c9:33:f1:48:46:6c:5a:10:d0:37:41:53:bd: ??????????????????? 00:f9 ??????????????? Exponent: 65537 (0x10001) ??????? X509v3 extensions: ??????????? X509v3 Subject Key Identifier: 0F:D8:48:FB:6C:8D:C3:1A:E1:5C:94:32:45:E8:EA:DE:5B:C5:E5:34 ??????????? X509v3 Authority Key Identifier: keyid:5D:A3:87:58:67:E9:3D:B2:4F:8A:87:DA:CA:26:39:FF:FE:70:D5:F2 ??????????? X509v3 Basic Constraints: critical ??????????????? CA:TRUE ??????????? X509v3 Key Usage: ??????????????? Digital Signature, Key Encipherment ??? Signature Algorithm: sha256WithRSAEncryption 1c:31:e5:b4:9a:de:81:5f:0d:6d:70:50:4d:cc:09:db:07:e0: 7e:fa:ca:65:a8:5e:32:6f:90:28:c1:34:1b:e1:89:8f:0d:ed: c5:80:d6:12:20:c7:7f:dc:ec:87:51:5a:95:cd:16:d1:06:bc: b5:6c:da:18:a8:88:1a:27:6f:91:8d:c4:0f:7a:a9:39:a1:68: 15:09:16:b3:09:ba:e3:b4:d2:48:32:b8:b9:6f:43:01:d2:d7: a2:63:ae:3f:21:90:15:e6:7e:b0:e4:c9:69:7a:aa:6a:93:72: ec:22:b8:e6:ce:a0:f2:93:4b:f4:e1:5d:2f:ce:01:78:c1:8f: 43:87:fb:99:37:60:b3:6f:75:0d:10:99:5c:44:90:7d:28:22: f6:e5:df:c2:d6:44:7a:8d:7d:6f:74:a2:55:0c:5a:97:8f:97: dc:c4:e5:aa:e5:08:f5:74:ea:6c:7c:43:ba:b7:91:e4:e6:bb: ef:82:53:25:13:4d:7d:dc:1b:f0:b2:05:c2:a3:46:b5:ff:b9: e7:83:64:83:67:75:f9:c4:32:66:a2:a6:bb:f2:01:b5:c2:71: 10:b1:f9:9b:c6:20:c1:de:00:b8:80:a4:9d:97:91:d2:ac:ec: 80:4d:b2:11:f9:b5:25:7b:03:3c:e5:37:c9:50:6f:d6:29:12: ???????? f7:27:46:5d opensslx509 -in rootCa.pem -noout -text Certificate: ??? Data: ??????? Version: 3 (0x2) ??????? Serial Number: ??????????? 90:ef:af:e5:b9:0d:0c:a7 ??? Signature Algorithm: sha256WithRSAEncryption ??????? Issuer: 1.3.6.1.4.1.47749.1.1 = rootCA ??????? Validity ??????????? Not Before: Jan? 8 23:21:46 2018 GMT ??????????? Not After : Jan? 8 23:21:46 2019 GMT ??????? Subject: 1.3.6.1.4.1.47749.1.1 = rootCA ??????? Subject Public Key Info: ??????????? Public Key Algorithm: rsaEncryption ??????????????? Public-Key: (2048 bit) ??????????????? Modulus: 00:c0:34:94:b1:a0:d7:e1:04:a0:2f:bf:0c:43:b4: 26:3a:98:aa:29:37:56:09:d0:1a:e1:b0:51:c9:47: 33:d9:1d:3e:62:f9:53:0e:85:17:27:33:bb:5c:f3: 8d:24:29:9f:e4:df:fd:93:bb:e1:2d:d0:6c:23:4e: 60:72:d1:cb:3d:32:64:4d:09:4b:cc:fb:57:6b:74: 1a:19:80:44:af:a3:35:93:c3:ea:f9:fc:66:5a:21: ea:18:c0:75:82:87:51:36:47:b5:69:73:34:01:49: f9:b2:f4:ad:3f:ee:eb:25:50:0d:b4:43:57:18:95: 75:5b:09:8c:95:4d:60:28:12:af:4f:56:bc:bb:11: 7b:cf:82:6b:16:ca:95:8f:25:34:10:3c:e1:4b:92: 07:83:da:3f:d4:e4:21:8e:dc:86:1d:ae:1e:4c:6b: 88:bd:7e:7f:eb:57:49:17:0c:f6:70:1a:78:48:4a: 15:0a:6b:a6:df:20:d3:35:ac:6a:20:23:9f:3c:d6: 88:22:7a:a0:a4:d7:e5:25:f0:f8:60:54:6e:d3:3f: 9c:47:d4:3b:f7:21:25:c3:4b:bd:7b:9c:76:58:ea: 73:be:5e:48:ca:fb:e1:02:82:98:ce:15:a0:3d:87: 54:df:2b:f7:6c:41:ce:fc:4e:fc:b2:49:14:65:e7: ??????????????????? e8:d3 ??????????????? Exponent: 65537 (0x10001) ??????? X509v3 extensions: ??????????? X509v3 Subject Key Identifier: 5D:A3:87:58:67:E9:3D:B2:4F:8A:87:DA:CA:26:39:FF:FE:70:D5:F2 ??????????? X509v3 Authority Key Identifier: keyid:5D:A3:87:58:67:E9:3D:B2:4F:8A:87:DA:CA:26:39:FF:FE:70:D5:F2 ??????????? X509v3 Basic Constraints: critical ??????????????? CA:TRUE ??????????? X509v3 Key Usage: ??????????????? Certificate Sign, CRL Sign ??? Signature Algorithm: sha256WithRSAEncryption 20:52:6d:e7:01:cc:17:5d:10:7e:c0:48:ca:60:78:a5:c7:80: d9:ee:6f:90:41:b6:12:dc:2f:37:14:be:0d:97:5b:e6:4a:86: f9:e8:4d:89:15:de:93:c2:b5:ab:30:c8:9d:1d:93:86:8a:b4: 3a:bf:e3:75:53:42:b9:fb:77:21:2f:05:38:ed:9f:12:3e:b7: 32:02:ae:cb:18:78:e8:df:c3:cb:78:6c:21:f1:f0:ab:99:4f: b4:02:d2:9d:e4:1d:31:05:1d:b6:37:5f:99:ba:59:87:da:78: 55:7d:fb:06:c2:f8:a1:d6:59:dc:54:3f:63:ee:8b:43:c3:c5: f8:36:dc:c0:ab:78:20:cc:ba:8f:06:cb:0b:e0:3d:15:d5:1c: a9:90:1f:d6:57:6c:ab:4e:b6:52:ce:61:d9:6f:32:56:ba:a5: e8:4b:49:c8:85:2d:ae:f1:cd:ee:7b:9d:39:df:25:2d:ac:64: 04:36:11:99:f3:29:26:a1:f8:ba:e2:02:c0:41:79:38:09:1d: c2:e7:41:ec:d2:73:5c:a3:53:28:f5:b5:af:fe:66:84:54:58: 43:b5:21:de:42:ba:9f:67:0a:cd:14:d9:ad:02:b3:35:b0:dd: 73:70:24:ca:bc:34:93:e7:c1:20:ee:da:11:6b:a0:95:55:2a: ???????? 61:33:da:55 On 1/9/2018 4:55 PM, Viktor Dukhovni wrote: > >> On Jan 9, 2018, at 7:28 PM, Norm Green wrote: >> >> It still doesn't verify correctly. > Or correctly fails to verify? > >> To simplify, I tried it with 1 intermediate CA. Here's the chain: >> >> rootCa.pem - self-signed root cert. CN = rootCA >> firstIntermedCa.pem - intermediate CA cert signed by rootCa.pem. CN = EmeaCA >> secondIntermedCa.pem - intermediate CA cert signed by firstIntermedCa.pem. CN = KapitalCA > Without the certificates (no private keys, just the certs) in question it quite > difficult to offer much help. > >> openssl verify -verbose -show_chain -CAfile rootCa.pem -untrusted firstIntermedCa.pem secondIntermedCa.pem >> 1.3.6.1.4.1.47749.1.1 = userCA, CN = KapitalCA >> error 20 at 0 depth lookup: unable to get local issuer certificate >> error secondIntermedCa.pem: verification failed > In addition to posting the certificates in question, please post (again even if > posted previously) what version of OpenSSL you're using, the output of: > > $ openssl version -a > > will suffice. > From openssl-users at dukhovni.org Wed Jan 10 02:31:24 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 9 Jan 2018 21:31:24 -0500 Subject: [openssl-users] cert chain file ordering question In-Reply-To: References: <5b21f521-5f95-71c1-2e59-3dd3f8a10581@gemtalksystems.com> <694f45d0-cf11-a0ab-e788-897254bd3a5c@akamai.com> <1e08abcd-039c-7e01-5b0c-42435c1554db@gemtalksystems.com> <61F1A10E-5B8C-4F0D-8DC3-4D01255F0338@dukhovni.org> Message-ID: <2350D32A-4FA5-4374-92E3-C71A441135D8@dukhovni.org> > On Jan 9, 2018, at 8:29 PM, Norm Green wrote: > > >Or correctly fails to verify? > Perhaps. Hopefully you'll be able to tellme. When you post machine-readable certificates, not just "-text" output. -- Viktor. From openssl-users at dukhovni.org Wed Jan 10 03:32:57 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 9 Jan 2018 22:32:57 -0500 Subject: [openssl-users] cert chain file ordering question In-Reply-To: References: <5b21f521-5f95-71c1-2e59-3dd3f8a10581@gemtalksystems.com> <694f45d0-cf11-a0ab-e788-897254bd3a5c@akamai.com> <1e08abcd-039c-7e01-5b0c-42435c1554db@gemtalksystems.com> <61F1A10E-5B8C-4F0D-8DC3-4D01255F0338@dukhovni.org> Message-ID: <5D4FEB39-F7F9-40FF-AC1F-E8AD81393FCE@dukhovni.org> > On Jan 9, 2018, at 8:29 PM, Norm Green wrote: > > opensslx509 -in secondIntermedCa.pem -noout -text > Signature Algorithm: sha256WithRSAEncryption > Issuer: 1.3.6.1.4.1.47749.1.1 = userCA, CN = EmeaCA > Subject: 1.3.6.1.4.1.47749.1.1 = userCA, CN = KapitalCA > X509v3 extensions: > X509v3 Subject Key Identifier: > C7:26:0D:BB:DF:7E:90:CA:7F:A0:C8:B7:CC:09:44:27:C0:53:A7:97 > X509v3 Authority Key Identifier: > keyid:0F:D8:48:FB:6C:8D:C3:1A:E1:5C:94:32:45:E8:EA:DE:5B:C5:E5:34 > X509v3 Basic Constraints: critical > CA:TRUE > X509v3 Key Usage: > Digital Signature, Key Encipherment The Key Usage is not what'd I'd expect for a CA. > opensslx509 -in firstIntermedCa.pem -noout -text > Issuer: 1.3.6.1.4.1.47749.1.1 = rootCA > Subject: 1.3.6.1.4.1.47749.1.1 = userCA, CN = EmeaCA > X509v3 extensions: > X509v3 Subject Key Identifier: > 0F:D8:48:FB:6C:8D:C3:1A:E1:5C:94:32:45:E8:EA:DE:5B:C5:E5:34 > X509v3 Authority Key Identifier: > keyid:5D:A3:87:58:67:E9:3D:B2:4F:8A:87:DA:CA:26:39:FF:FE:70:D5:F2 > X509v3 Basic Constraints: critical > CA:TRUE > X509v3 Key Usage: > Digital Signature, Key Encipherment Same here. > opensslx509 -in rootCa.pem -noout -text > Issuer: 1.3.6.1.4.1.47749.1.1 = rootCA > Subject: 1.3.6.1.4.1.47749.1.1 = rootCA > X509v3 extensions: > X509v3 Subject Key Identifier: > 5D:A3:87:58:67:E9:3D:B2:4F:8A:87:DA:CA:26:39:FF:FE:70:D5:F2 > X509v3 Authority Key Identifier: > keyid:5D:A3:87:58:67:E9:3D:B2:4F:8A:87:DA:CA:26:39:FF:FE:70:D5:F2 > > X509v3 Basic Constraints: critical > CA:TRUE > X509v3 Key Usage: > Certificate Sign, CRL Sign This Key Usage is more appropriate. When the "Key Usage" is present in a CA certificate, it *MUST* include "Certificate Sign". -- Viktor. From joshi.sanjaya at gmail.com Wed Jan 10 06:41:46 2018 From: joshi.sanjaya at gmail.com (Sanjaya Joshi) Date: Wed, 10 Jan 2018 12:11:46 +0530 Subject: [openssl-users] Binding the socket to a source IP address before connect Message-ID: Hello, Is there a BIO family of API that OpenSSL provides to bind to a specific source IP address before creating a socket connection (using for e.g. BIO_new_connect()) ? My application does not need to rely on the kernel-provided source IP address and hence the need for this. Regards, Sanjaya -------------- next part -------------- An HTML attachment was scrubbed... URL: From grace.priscilla at gmail.com Wed Jan 10 09:24:44 2018 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Wed, 10 Jan 2018 14:54:44 +0530 Subject: [openssl-users] Issue on DTLS over UDP In-Reply-To: <409506d7-ffaa-1a37-2598-e207b2f73556@openssl.org> References: <409506d7-ffaa-1a37-2598-e207b2f73556@openssl.org> Message-ID: Thankyou Matt for the patch. It works fine now with the patch. In which release will you be including this patch? It is a negative scenario setup on configuration. Thanks, Grace On Fri, Jan 5, 2018 at 4:28 PM, Matt Caswell wrote: > > > On 05/01/18 05:30, Grace Priscilla Jero wrote: > > Hi Matt, > > We are using openssl v 1.1.0g. > > Attaching the pcap files. > > Thanks - that helped a lot and I have been able to recreate your issue. > > The problem is this: > > - The server is DTLSv1.0 only > - The client is DTLSv1.2 only > - When the server selects DTLSv1.0 the client sends back a protocol > version alert with a record version of DTLSv1.2 > - The server is expecting incoming records of version DTLSv1.0, because > that is the version it selected. Anything else is silently discarded, > including the incoming protocol version alert. > > Whether this behaviour is a "bug" or not is debatable. The spec is quite > unclear in this regards. The only thing relevant I can see is this: > > "Unlike TLS, DTLS is resilient in the face of invalid records (e.g., > invalid formatting, length, MAC, etc.). In general, invalid records > SHOULD be silently discarded, thus preserving the association; ..." > > An OpenSSL client (at least in 1.1.0 - I didn't check other versions), > will respond with a DTLSv1.0 alert record if it doesn't like the > protocol version selected by the server, so this situation never arises > when an OpenSSL client is talking to an OpenSSL server. > > Probably the right thing for us to do is be more tolerant of record > version number mismatches when the record type is alert. I have created > a patch to do that here (master and 1.1.0): > > https://github.com/openssl/openssl/pull/5018 > > And the 1.0.2 version is here: > > https://github.com/openssl/openssl/pull/5019 > > I've also attached a patch file suitable for applying to 1.1.0g. > > This issue triggers a few other thoughts for your case: > > - I am wondering why you have configured your server for DTLSv1.0 only > given that 1.1.0g is perfectly capable of talking both DTLSv1.2 and > DTSLv1.0 > > - Your server application should probably be modified to ensure it is > capable of handling a stalled connection like this (e.g. by timing out > after a period if a connection is not achieved). Such stalled > connections can happen in DTLS due to packet loss. For example the > protocol version alert could be dropped at a network level. Alerts are > never retransmitted, so the server will wait for ever waiting for the > next message. > > - Do you control the client in this case? I wonder why the client is > configured for DTLSv1.2 only (rather than being able to handle both > DTLSv1.2 *and* DTLSv1.0). Is this a deliberate choice or a > mis-configuration? > > > Matt > > > > > yes, the SSL_get_error() gives 2. > > The alert is sent but ignored. > > > > Thanks, > > Grace > > > > On Wed, Jan 3, 2018 at 4:23 PM, Matt Caswell > > wrote: > > > > > > > > On 03/01/18 10:40, Grace Priscilla Jero wrote: > > > Hi, > > > Can someone please respond to the below mail as we want to confirm > if it > > > is an issue with our application or a bug in openSSL. > > > > It isn't a known bug (which doesn't mean it isn't an unknown bug!). > > > > I think we're going to need some more information to help you with > this > > issue. If I understand you correctly you have a server application > which > > only supports DTLS 1.0 and it is that application which is failing? > > Which version of OpenSSL is this? All currently supported versions of > > OpenSSL have the capability to support DTLS1.2 so I'm not sure why > you > > have this scenario. > > > > You say that "SSL_accept continuously loops with error 2". Do you > mean > > by that SSL_accept() returns an error and calling SSL_get_error() > gives > > you SSL_ERROR_WANT_READ (value 2)? > > > > "The ALERT is not processed": does this mean you are expecting to > see an > > alert but it isn't sent? Or an alert is sent but it is ignored? > > > > Perhaps a wireshark trace of the exchange would help us to understand > > what you are seeing. > > > > Matt > > > > > > > > > > Thanks, > > > Grace > > > > > > On Fri, Dec 15, 2017 at 3:23 PM, Grace Priscilla Jero > > > > > > >> wrote: > > > > > > Hi All, > > > > > > We are having an issue with DTLS on UDP. > > > > > > The scenario is that, when a client of DTLS version 1.2 is > > trying to > > > connect to a server which is at version DTLS 1.0 the SSL_accept > > > continuously loops with error 2. The ALERT is not processed. > > > Is this a known bug? > > > > > > Because of the loop, the application is unable to process new > > changes. > > > > > > Thanks, > > > Grace > > > > > > > > > > > > > > -- > > openssl-users mailing list > > To unsubscribe: > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcr at sandelman.ca Wed Jan 10 14:25:03 2018 From: mcr at sandelman.ca (Michael Richardson) Date: Wed, 10 Jan 2018 09:25:03 -0500 Subject: [openssl-users] Binding the socket to a source IP address before connect In-Reply-To: References: Message-ID: <11419.1515594303@obiwan.sandelman.ca> Sanjaya Joshi wrote: > Is there a BIO family of API that OpenSSL provides to bind to a > specific source IP address before creating a socket connection (using > for e.g. BIO_new_connect()) ? I think not... BIO_new_connect() allocates the BIO, and so there isn't any state to set up before you call that. I've had to add a place to store the sockaddr to the DGRAM method in order to make DTLS work the way I want it, and it could be extended to TCP sockets I think, but not using the flow that you are using. However, you can provide the FD to the SSL context using BIO_set_fd() and SSL_set_bio(): BIO_set_fd(inbio, connectedfd, BIO_NOCLOSE); SSL_set_bio(ssl, inbio, outbio); Then you can set up the connectedfd any way you want, calling bind() before connect. That means that you might have to parse the host/IP + port yourself, but getaddrinfo() can do that for you, and int BIO_lookup(const char *host, const char *service, enum BIO_lookup_type lookup_type, int family, int socktype, BIO_ADDRINFO **res); wraps it all nicely for you. > My application does not need to rely on the kernel-provided source IP > address and hence the need for this. Just remember to test with IPv6 Link-Local addresses, because they do matter, and they are hard to get right from userspace. (And if you aren't doing IPv6 testing, then you probably shouldn't be creating new code) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From karl at denninger.net Wed Jan 10 14:41:41 2018 From: karl at denninger.net (Karl Denninger) Date: Wed, 10 Jan 2018 08:41:41 -0600 Subject: [openssl-users] Confirmation of what I believe to be true from docs and observation Message-ID: We start with a context that I load a dhparam file to (so I can take a DH connection) along with an edh curve, then set an acceptable cipher list for it to use. Assume I next manually load both the CA store (using X509_STORE_add_cert as many times as necessary to load the intermediate components and the root of trust) and then load the cert/key pair (using SSL_CTX_use_certificate/SSL_CTX_use_PrivateKey) I then create some number of SSLs from that context to perform communication with and all is well. Now I want to rekey that context for some reason.? It appears that while I can add things to the CA chain trying to load the same component that is already in there returns a failure (somewhat-expected; that is, it does not overwrite but rather adds, and if you try to add what's already there you get an error back) and there's no call to CLEAR the certificate validation chain -- if I want to *replace* the validation chain I have to destroy the context and initialize a new one from scratch. It appears, however, that I *can* load over the top of a certificate and private key of the same type and that's acceptable.? In other words, if I have an RSA key/cert pair in the context and I load another one, the first one is replaced.? This *looks* to be working ok as far as I can tell and it doesn't appear to leak memory doing that but it's not explicitly stated that this is considered acceptable (rather than destroying and re-creating the context.) Is my understanding correct? -- Karl Denninger karl at denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4897 bytes Desc: S/MIME Cryptographic Signature URL: From norm.green at gemtalksystems.com Wed Jan 10 18:04:34 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Wed, 10 Jan 2018 10:04:34 -0800 Subject: [openssl-users] cert chain file ordering question In-Reply-To: <5D4FEB39-F7F9-40FF-AC1F-E8AD81393FCE@dukhovni.org> References: <5b21f521-5f95-71c1-2e59-3dd3f8a10581@gemtalksystems.com> <694f45d0-cf11-a0ab-e788-897254bd3a5c@akamai.com> <1e08abcd-039c-7e01-5b0c-42435c1554db@gemtalksystems.com> <61F1A10E-5B8C-4F0D-8DC3-4D01255F0338@dukhovni.org> <5D4FEB39-F7F9-40FF-AC1F-E8AD81393FCE@dukhovni.org> Message-ID: <537c21c1-c68d-cf02-997c-da9228e836e2@gemtalksystems.com> On 1/9/18 19:32, Viktor Dukhovni wrote: > This Key Usage is more appropriate. When the "Key Usage" is present in > a CA certificate, it*MUST* include "Certificate Sign". That was indeed the problem.? Thank you!! It seems strange to me that OpenSSL will allow creation of a CA cert (CA:TRUE) that may not be used to sign other certs. I appreciate your help Viktor. Norm P.S. Seems you didn't need machine-readable certificates to help me after all ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Jan 10 19:31:29 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 10 Jan 2018 19:31:29 +0000 Subject: [openssl-users] Issue on DTLS over UDP In-Reply-To: References: <409506d7-ffaa-1a37-2598-e207b2f73556@openssl.org> Message-ID: <69b03b1e-28f1-7037-8f98-827aff845250@openssl.org> On 10/01/18 09:24, Grace Priscilla Jero wrote: > Thankyou Matt for the patch. > It works fine now with the patch. In which release will you be including > this patch? The patch is already merged into the 1.1.0 branch so it will be in the next release (1.1.0h). Matt > > It is a negative scenario setup on configuration. > Thanks, > Grace > > > On Fri, Jan 5, 2018 at 4:28 PM, Matt Caswell > wrote: > > > > On 05/01/18 05:30, Grace Priscilla Jero wrote: > > Hi Matt, > > We are using openssl v 1.1.0g. > > Attaching the pcap files. > > Thanks - that helped a lot and I have been able to recreate your issue. > > The problem is this: > > - The server is DTLSv1.0 only > - The client is DTLSv1.2 only > - When the server selects DTLSv1.0 the client sends back a protocol > version alert with a record version of DTLSv1.2 > - The server is expecting incoming records of version DTLSv1.0, because > that is the version it selected. Anything else is silently discarded, > including the incoming protocol version alert. > > Whether this behaviour is a "bug" or not is debatable. The spec is quite > unclear in this regards. The only thing relevant I can see is this: > > "Unlike TLS, DTLS is resilient in the face of invalid records (e.g., > invalid formatting, length, MAC, etc.).? In general, invalid records > SHOULD be silently discarded, thus preserving the association; ..." > > An OpenSSL client (at least in 1.1.0 - I didn't check other versions), > will respond with a DTLSv1.0 alert record if it doesn't like the > protocol version selected by the server, so this situation never arises > when an OpenSSL client is talking to an OpenSSL server. > > Probably the right thing for us to do is be more tolerant of record > version number mismatches when the record type is alert. I have created > a patch to do that here (master and 1.1.0): > > https://github.com/openssl/openssl/pull/5018 > > > And the 1.0.2 version is here: > > https://github.com/openssl/openssl/pull/5019 > > > I've also attached a patch file suitable for applying to 1.1.0g. > > This issue triggers a few other thoughts for your case: > > - I am wondering why you have configured your server for DTLSv1.0 only > given that 1.1.0g is perfectly capable of talking both DTLSv1.2 and > DTSLv1.0 > > - Your server application should probably be modified to ensure it is > capable of handling a stalled connection like this (e.g. by timing out > after a period if a connection is not achieved). Such stalled > connections can happen in DTLS due to packet loss. For example the > protocol version alert could be dropped at a network level. Alerts are > never retransmitted, so the server will wait for ever waiting for the > next message. > > - Do you control the client in this case? I wonder why the client is > configured for DTLSv1.2 only (rather than being able to handle both > DTLSv1.2 *and* DTLSv1.0). Is this a deliberate choice or a > mis-configuration? > > > Matt > > > > > yes, the SSL_get_error() gives 2. > > The alert is sent but ignored. > > > > Thanks, > > Grace > > > > On Wed, Jan 3, 2018 at 4:23 PM, Matt Caswell > > >> wrote: > > > > > > > >? ? ?On 03/01/18 10:40, Grace Priscilla Jero wrote: > >? ? ?> Hi, > >? ? ?> Can someone please respond to the below mail as we want to > confirm if it > >? ? ?> is an issue with our application or a bug in openSSL. > > > >? ? ?It isn't a known bug (which doesn't mean it isn't an unknown > bug!). > > > >? ? ?I think we're going to need some more information to help you > with this > >? ? ?issue. If I understand you correctly you have a server > application which > >? ? ?only supports DTLS 1.0 and it is that application which is > failing? > >? ? ?Which version of OpenSSL is this? All currently supported > versions of > >? ? ?OpenSSL have the capability to support DTLS1.2 so I'm not sure > why you > >? ? ?have this scenario. > > > >? ? ?You say that "SSL_accept continuously loops with error 2". Do > you mean > >? ? ?by that SSL_accept() returns an error and calling > SSL_get_error() gives > >? ? ?you SSL_ERROR_WANT_READ (value 2)? > > > >? ? ?"The ALERT is not processed": does this mean you are expecting > to see an > >? ? ?alert but it isn't sent? Or an alert is sent but it is ignored? > > > >? ? ?Perhaps a wireshark trace of the exchange would help us to > understand > >? ? ?what you are seeing. > > > >? ? ?Matt > > > > > >? ? ?> > >? ? ?> Thanks, > >? ? ?> Grace > >? ? ?> > >? ? ?> On Fri, Dec 15, 2017 at 3:23 PM, Grace Priscilla Jero > >? ? ?> > > >? ? ? > >? ? ?>>> wrote: > >? ? ?> > >? ? ?>? ? ?Hi All, > >? ? ?> > >? ? ?>? ? ?We are having an issue with DTLS on UDP. > >? ? ?> > >? ? ?>? ? ?The scenario is that, when a client of DTLS version 1.2 is > >? ? ?trying to > >? ? ?>? ? ?connect to a server which is at version DTLS 1.0 the SSL_accept > >? ? ?>? ? ?continuously loops with error 2. The ALERT is not processed.? > >? ? ?>? ? ?Is this a known bug? > >? ? ?> > >? ? ?>? ? ?Because of the loop, the application is unable to process new > >? ? ?changes.? > >? ? ?> > >? ? ?>? ? ?Thanks, > >? ? ?>? ? ?Grace > >? ? ?> > >? ? ?> > >? ? ?> > >? ? ?> > >? ? ?-- > >? ? ?openssl-users mailing list > >? ? ?To unsubscribe: > >? ? ?https://mta.openssl.org/mailman/listinfo/openssl-users > > >? ? ? > > > > > > > From joshi.sanjaya at gmail.com Wed Jan 10 19:43:24 2018 From: joshi.sanjaya at gmail.com (Sanjaya Joshi) Date: Thu, 11 Jan 2018 01:13:24 +0530 Subject: [openssl-users] Binding the socket to a source IP address before connect In-Reply-To: <11419.1515594303@obiwan.sandelman.ca> References: <11419.1515594303@obiwan.sandelman.ca> Message-ID: Hi, Thanks Michael. I'll check if your proposal fits my requirement. Regards, Sanjaya On Wed, Jan 10, 2018 at 7:55 PM, Michael Richardson wrote: > > Sanjaya Joshi wrote: > > Is there a BIO family of API that OpenSSL provides to bind to a > > specific source IP address before creating a socket connection (using > > for e.g. BIO_new_connect()) ? > > I think not... BIO_new_connect() allocates the BIO, and so there isn't any > state to set up before you call that. > > I've had to add a place to store the sockaddr to the DGRAM method in order > to > make DTLS work the way I want it, and it could be extended to TCP sockets I > think, but not using the flow that you are using. > > However, you can provide the FD to the SSL context using BIO_set_fd() > and SSL_set_bio(): > > BIO_set_fd(inbio, connectedfd, BIO_NOCLOSE); > SSL_set_bio(ssl, inbio, outbio); > > Then you can set up the connectedfd any way you want, calling bind() before > connect. That means that you might have to parse the host/IP + port > yourself, but getaddrinfo() can do that for you, and > int BIO_lookup(const char *host, const char *service, > enum BIO_lookup_type lookup_type, > int family, int socktype, BIO_ADDRINFO **res); > > wraps it all nicely for you. > > > My application does not need to rely on the kernel-provided source IP > > address and hence the need for this. > > Just remember to test with IPv6 Link-Local addresses, because they do > matter, and they are hard to get right from userspace. > (And if you aren't doing IPv6 testing, then you probably shouldn't be > creating new code) > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Wed Jan 10 20:07:04 2018 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Wed, 10 Jan 2018 14:07:04 -0600 Subject: [openssl-users] Confirmation of what I believe to be true from docs and observation In-Reply-To: References: Message-ID: <7a200b3c-0bc9-3b82-eadb-e8adb8c73b4f@akamai.com> On 01/10/2018 08:41 AM, Karl Denninger wrote: > > We start with a context that I load a dhparam file to (so I can take a > DH connection) along with an edh curve, then set an acceptable cipher > list for it to use. > Why not just use AUTO_DH (the only option for 1.1.0, IIRC)? > Assume I next manually load both the CA store (using > X509_STORE_add_cert as many times as necessary to load the > intermediate components and the root of trust) and then load the > cert/key pair (using SSL_CTX_use_certificate/SSL_CTX_use_PrivateKey) > > I then create some number of SSLs from that context to perform > communication with and all is well. > > Now I want to rekey that context for some reason.? It appears that > while I can add things to > Why do you need to rekey the context as opposed to making a new one? In general, making configuration changes to an SSL_CTX after it has been used to generate SSL objects is a risky proposition -- the locking model does not really account for doing synchronization properly, and there might be some latent race conditions.? In practice, some operations are currently safe, but there is no authoritative list of which ones, and at least my personal recommendation is to not try to rely on it. > the CA chain trying to load the same component that is already in > there returns a failure (somewhat-expected; that is, it does not > overwrite but rather adds, and if you try to add what's already there > you get an error back) and there's no call to CLEAR the certificate > validation chain -- if I want to *replace* the validation chain I have > to destroy the context and initialize a new one from scratch. > N.B. that the X509_STORE_add_cert behavior when presented with a duplicate certificate changed in commit c0452248ea1a59a41023a4765ef7d9825e80a62b (from returning an error to doing nothing and returning success); this will be in 1.1.1. As to the desired behavior, there does not seem to be an API to remove an entry from an X509_STORE.? With the above caveat about thread-safety in mind, couldn't you just make a call to SSL_CTX_set{1}_cert_store() to replace the X509_STORE without tearing down the whole SSL_CTX? > It appears, however, that I *can* load over the top of a certificate > and private key of the same type and that's acceptable.? In other > words, if I have an RSA key/cert pair in the context and I load > another one, the first one is replaced.? This *looks* to be working ok > as far as I can tell and it doesn't appear to leak memory doing that > but it's not explicitly stated that this is considered acceptable > (rather than destroying and re-creating the context.) > The leaf certificate and private key are stored as arrays (for different types of certificates) of pointers in the associated CERT structure, and the "set" routines do not currently check for and error out if there is already one set. > Is my understanding correct? > > Mostly ... but I am not sure that your desired workflow is wise. -Ben From karl at denninger.net Wed Jan 10 20:37:51 2018 From: karl at denninger.net (Karl Denninger) Date: Wed, 10 Jan 2018 14:37:51 -0600 Subject: [openssl-users] Confirmation of what I believe to be true from docs and observation In-Reply-To: <7a200b3c-0bc9-3b82-eadb-e8adb8c73b4f@akamai.com> References: <7a200b3c-0bc9-3b82-eadb-e8adb8c73b4f@akamai.com> Message-ID: <427c600e-1d9d-01da-75bc-707c0ea02517@denninger.net> On 1/10/2018 14:07, Benjamin Kaduk wrote: > On 01/10/2018 08:41 AM, Karl Denninger wrote: >> We start with a context that I load a dhparam file to (so I can take a >> DH connection) along with an edh curve, then set an acceptable cipher >> list for it to use. >> > Why not just use AUTO_DH (the only option for 1.1.0, IIRC)? That's a reasonable change (and I'll go ahead and make it); the dhparam was only there in the first place for those browsers and such that can't negotiate EC (which my cipher selection set prefers.) >> Assume I next manually load both the CA store (using >> X509_STORE_add_cert as many times as necessary to load the >> intermediate components and the root of trust) and then load the >> cert/key pair (using SSL_CTX_use_certificate/SSL_CTX_use_PrivateKey) >> >> I then create some number of SSLs from that context to perform >> communication with and all is well. >> >> Now I want to rekey that context for some reason.? It appears that >> while I can add things to >> > Why do you need to rekey the context as opposed to making a new one? I could make a new one (or more-specifically, destroy the existing one and re-initialize it), but that is more-complicated as the application in question is multi-threaded -- and it's not at all clear from the documentation if I destroy a context that has SSLs that have been generated from it will cause "bad things" to happen (like a deference on a freed object!) The reason I may want to rekey is that the cert/key pair used for that context may have changed.? The user's certificate may have expired for example (or been revoked) and I wish to reload it (and the matching key) without having to shut down the software and restart it. > In general, making configuration changes to an SSL_CTX after it has been > used to generate SSL objects is a risky proposition -- the locking model > does not really account for doing synchronization properly, and there > might be some latent race conditions.? In practice, some operations are > currently safe, but there is no authoritative list of which ones, and at > least my personal recommendation is to not try to rely on it. Assuming that there are SSL objects that are in use and I destroy and re-generate the CTX from which it was generated, is *THAT* safe?? Or do I need to flag all the in-use descendants and wait for them to be closed (or force them closed and release them) before I can safely destroy the context? >> the CA chain trying to load the same component that is already in >> there returns a failure (somewhat-expected; that is, it does not >> overwrite but rather adds, and if you try to add what's already there >> you get an error back) and there's no call to CLEAR the certificate >> validation chain -- if I want to *replace* the validation chain I have >> to destroy the context and initialize a new one from scratch. >> > N.B. that the X509_STORE_add_cert behavior when presented with a > duplicate certificate changed in commit > c0452248ea1a59a41023a4765ef7d9825e80a62b (from returning an error to > doing nothing and returning success); this will be in 1.1.1. > > As to the desired behavior, there does not seem to be an API to remove > an entry from an X509_STORE.? With the above caveat about thread-safety > in mind, couldn't you just make a call to SSL_CTX_set{1}_cert_store() to > replace the X509_STORE without tearing down the whole SSL_CTX? Yeah, I didn't see one either.? I'm not particularly concerned about the verification chain being able to be modified while "in-use"; that ought not happen except in an extreme circumstance (e.g. the intermediate cert's key is compromised and thus both it and the cert have to be regenerated and re-distributed.)? If it DOES happen when the end-entity cert and key are reloaded (as they've been signed from the new intermediate) they'll fail to validate against the old chain and the user will get plenty of notice that there's trouble. >> It appears, however, that I *can* load over the top of a certificate >> and private key of the same type and that's acceptable.? In other >> words, if I have an RSA key/cert pair in the context and I load >> another one, the first one is replaced.? This *looks* to be working ok >> as far as I can tell and it doesn't appear to leak memory doing that >> but it's not explicitly stated that this is considered acceptable >> (rather than destroying and re-creating the context.) >> > The leaf certificate and private key are stored as arrays (for different > types of certificates) of pointers in the associated CERT structure, and > the "set" routines do not currently check for and error out if there is > already one set. Yes, but do they replace the pointer and, if they do, do they decrement the reference counter on the existing one before replacing it so it will get freed??? If yes then all is ok but if not then I need to destroy the context otherwise I'm going to be leaking memory. >> Is my understanding correct? >> >> > Mostly ... but I am not sure that your desired workflow is wise. > > -Ben If it's safe to destroy a context with potential SSL options from it still in existence then it's pretty easy to do it the other way otherwise I have some work to do in order to make sure all the potential objects created from the parent have gone away before the old context is destroyed. Thanks in advance. -- Karl Denninger karl at denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4897 bytes Desc: S/MIME Cryptographic Signature URL: From bkaduk at akamai.com Wed Jan 10 21:27:08 2018 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Wed, 10 Jan 2018 15:27:08 -0600 Subject: [openssl-users] Confirmation of what I believe to be true from docs and observation In-Reply-To: <427c600e-1d9d-01da-75bc-707c0ea02517@denninger.net> References: <7a200b3c-0bc9-3b82-eadb-e8adb8c73b4f@akamai.com> <427c600e-1d9d-01da-75bc-707c0ea02517@denninger.net> Message-ID: On 01/10/2018 02:37 PM, Karl Denninger wrote: > On 1/10/2018 14:07, Benjamin Kaduk wrote: >> On 01/10/2018 08:41 AM, Karl Denninger wrote: >>> We start with a context that I load a dhparam file to (so I can take a >>> DH connection) along with an edh curve, then set an acceptable cipher >>> list for it to use. >>> >> Why not just use AUTO_DH (the only option for 1.1.0, IIRC)? > That's a reasonable change (and I'll go ahead and make it); the > dhparam was only there in the first place for those browsers and such > that can't negotiate EC (which my cipher selection set prefers.) >>> Assume I next manually load both the CA store (using >>> X509_STORE_add_cert as many times as necessary to load the >>> intermediate components and the root of trust) and then load the >>> cert/key pair (using SSL_CTX_use_certificate/SSL_CTX_use_PrivateKey) >>> >>> I then create some number of SSLs from that context to perform >>> communication with and all is well. >>> >>> Now I want to rekey that context for some reason.? It appears that >>> while I can add things to >>> >> Why do you need to rekey the context as opposed to making a new one? > I could make a new one (or more-specifically, destroy the existing one > and re-initialize it), but that is more-complicated as the application > in question is multi-threaded -- and it's not at all clear from the > documentation if I destroy a context that has SSLs that have been > generated from it will cause "bad things" to happen (like a deference > on a freed object!) > Each SSL holds a reference on its parent SSL_CTX (and another reference on its associated session_ctx, which starts out as the same SSL_CTX object); SSL_CTX_free() does not do any deallocation until the refcount drops to zero. So, no "bad things" will happen if you SSL_CTX_free() the handle you have in your application while SSL objects are still using that object. > The reason I may want to rekey is that the cert/key pair used for that > context may have changed.? The user's certificate may have expired for > example (or been revoked) and I wish to reload it (and the matching > key) without having to shut down the software and restart it. > >> In general, making configuration changes to an SSL_CTX after it has been >> used to generate SSL objects is a risky proposition -- the locking model >> does not really account for doing synchronization properly, and there >> might be some latent race conditions.? In practice, some operations are >> currently safe, but there is no authoritative list of which ones, and at >> least my personal recommendation is to not try to rely on it. > Assuming that there are SSL objects that are in use and I destroy and > re-generate the CTX from which it was generated, is *THAT* safe?? Or > do I need to flag all the in-use descendants and wait for them to be > closed (or force them closed and release them) before I can safely > destroy the context? You do not need to flag and wait, due to the reference counting on the SSL and SSL_CTX objects. >>> the CA chain trying to load the same component that is already in >>> there returns a failure (somewhat-expected; that is, it does not >>> overwrite but rather adds, and if you try to add what's already there >>> you get an error back) and there's no call to CLEAR the certificate >>> validation chain -- if I want to *replace* the validation chain I have >>> to destroy the context and initialize a new one from scratch. >>> >> N.B. that the X509_STORE_add_cert behavior when presented with a >> duplicate certificate changed in commit >> c0452248ea1a59a41023a4765ef7d9825e80a62b (from returning an error to >> doing nothing and returning success); this will be in 1.1.1. >> >> As to the desired behavior, there does not seem to be an API to remove >> an entry from an X509_STORE.? With the above caveat about thread-safety >> in mind, couldn't you just make a call to SSL_CTX_set{1}_cert_store() to >> replace the X509_STORE without tearing down the whole SSL_CTX? > Yeah, I didn't see one either.? I'm not particularly concerned about > the verification chain being able to be modified while "in-use"; that > ought not happen except in an extreme circumstance (e.g. the > intermediate cert's key is compromised and thus both it and the cert > have to be regenerated and re-distributed.)? If it DOES happen when > the end-entity cert and key are reloaded (as they've been signed from > the new intermediate) they'll fail to validate against the old chain > and the user will get plenty of notice that there's trouble. >>> It appears, however, that I *can* load over the top of a certificate >>> and private key of the same type and that's acceptable.? In other >>> words, if I have an RSA key/cert pair in the context and I load >>> another one, the first one is replaced.? This *looks* to be working ok >>> as far as I can tell and it doesn't appear to leak memory doing that >>> but it's not explicitly stated that this is considered acceptable >>> (rather than destroying and re-creating the context.) >>> >> The leaf certificate and private key are stored as arrays (for different >> types of certificates) of pointers in the associated CERT structure, and >> the "set" routines do not currently check for and error out if there is >> already one set. > Yes, but do they replace the pointer and, if they do, do they > decrement the reference counter on the existing one before replacing > it so it will get freed??? If yes then all is ok but if not then I > need to destroy the context otherwise I'm going to be leaking memory. The underlying implementation (ssl_set_cert()) does call X509_free() and EVP_PKEY_free() before doing the update, so there is no leak. >>> Is my understanding correct? >>> >>> >> Mostly ... but I am not sure that your desired workflow is wise. >> >> -Ben > If it's safe to destroy a context with potential SSL options from it > still in existence then it's pretty easy to do it the other way > otherwise I have some work to do in order to make sure all the > potential objects created from the parent have gone away before the > old context is destroyed. Yup, it's safe. Good luck! -Ben From matt at openssl.org Wed Jan 10 23:16:46 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 10 Jan 2018 23:16:46 +0000 Subject: [openssl-users] OpenSSL wins the Levchin prize Message-ID: <457054ae-e8ee-a8c5-67d4-d5e1d52ac70e@openssl.org> Today I have had great pleasure in attending the Real World Crypto 2018 conference in Z?rich in order to receive the Levchin prize on behalf of the OpenSSL team. More details are available in my blog post here: https://www.openssl.org/blog/blog/2018/01/10/levchin/ Matt From googleersatz at oliverniebuhr.de Wed Jan 10 23:36:49 2018 From: googleersatz at oliverniebuhr.de (Google Ersatz) Date: Thu, 11 Jan 2018 00:36:49 +0100 Subject: [openssl-users] OpenSSL wins the Levchin prize In-Reply-To: <457054ae-e8ee-a8c5-67d4-d5e1d52ac70e@openssl.org> References: <457054ae-e8ee-a8c5-67d4-d5e1d52ac70e@openssl.org> Message-ID: <20180110233649.7123027.44825.24013@oliverniebuhr.de> ?Good morning. I am just a normal User but I have seen countless Patches, Merges etc. on 1.0.2 and 1.1.0 since you publicly announced the planned overhaul.? Huge changes all over the place. So: Congratulations and well deserved!! And while I am at it: Again thank you very much to all paid and unpaid Contributors around the World!! :) :3 Greetings? Oliver Sent?from?a?Mobile?Device.?Encoding?Problems can?happen. ? Originalnachricht ? Von: Matt Caswell Gesendet: Donnerstag, 11. Januar 2018 00:17 An: openssl-announce at openssl.org; openssl-users at openssl.org; openssl-dev at openssl.org Antwort an: openssl-users at openssl.org Betreff: [openssl-users] OpenSSL wins the Levchin prize Today I have had great pleasure in attending the Real World Crypto 2018 conference in Z?rich in order to receive the Levchin prize on behalf of the OpenSSL team. More details are available in my blog post here: https://www.openssl.org/blog/blog/2018/01/10/levchin/ Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From grace.priscilla at gmail.com Thu Jan 11 09:18:41 2018 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Thu, 11 Jan 2018 14:48:41 +0530 Subject: [openssl-users] Issue on DTLS over UDP In-Reply-To: <69b03b1e-28f1-7037-8f98-827aff845250@openssl.org> References: <409506d7-ffaa-1a37-2598-e207b2f73556@openssl.org> <69b03b1e-28f1-7037-8f98-827aff845250@openssl.org> Message-ID: Thankyou Matt! On Thu, Jan 11, 2018 at 1:01 AM, Matt Caswell wrote: > > > On 10/01/18 09:24, Grace Priscilla Jero wrote: > > Thankyou Matt for the patch. > > It works fine now with the patch. In which release will you be including > > this patch? > > The patch is already merged into the 1.1.0 branch so it will be in the > next release (1.1.0h). > > Matt > > > > > > It is a negative scenario setup on configuration. > > Thanks, > > Grace > > > > > > On Fri, Jan 5, 2018 at 4:28 PM, Matt Caswell > > wrote: > > > > > > > > On 05/01/18 05:30, Grace Priscilla Jero wrote: > > > Hi Matt, > > > We are using openssl v 1.1.0g. > > > Attaching the pcap files. > > > > Thanks - that helped a lot and I have been able to recreate your > issue. > > > > The problem is this: > > > > - The server is DTLSv1.0 only > > - The client is DTLSv1.2 only > > - When the server selects DTLSv1.0 the client sends back a protocol > > version alert with a record version of DTLSv1.2 > > - The server is expecting incoming records of version DTLSv1.0, > because > > that is the version it selected. Anything else is silently discarded, > > including the incoming protocol version alert. > > > > Whether this behaviour is a "bug" or not is debatable. The spec is > quite > > unclear in this regards. The only thing relevant I can see is this: > > > > "Unlike TLS, DTLS is resilient in the face of invalid records (e.g., > > invalid formatting, length, MAC, etc.). In general, invalid records > > SHOULD be silently discarded, thus preserving the association; ..." > > > > An OpenSSL client (at least in 1.1.0 - I didn't check other > versions), > > will respond with a DTLSv1.0 alert record if it doesn't like the > > protocol version selected by the server, so this situation never > arises > > when an OpenSSL client is talking to an OpenSSL server. > > > > Probably the right thing for us to do is be more tolerant of record > > version number mismatches when the record type is alert. I have > created > > a patch to do that here (master and 1.1.0): > > > > https://github.com/openssl/openssl/pull/5018 > > > > > > And the 1.0.2 version is here: > > > > https://github.com/openssl/openssl/pull/5019 > > > > > > I've also attached a patch file suitable for applying to 1.1.0g. > > > > This issue triggers a few other thoughts for your case: > > > > - I am wondering why you have configured your server for DTLSv1.0 > only > > given that 1.1.0g is perfectly capable of talking both DTLSv1.2 and > > DTSLv1.0 > > > > - Your server application should probably be modified to ensure it is > > capable of handling a stalled connection like this (e.g. by timing > out > > after a period if a connection is not achieved). Such stalled > > connections can happen in DTLS due to packet loss. For example the > > protocol version alert could be dropped at a network level. Alerts > are > > never retransmitted, so the server will wait for ever waiting for the > > next message. > > > > - Do you control the client in this case? I wonder why the client is > > configured for DTLSv1.2 only (rather than being able to handle both > > DTLSv1.2 *and* DTLSv1.0). Is this a deliberate choice or a > > mis-configuration? > > > > > > Matt > > > > > > > > yes, the SSL_get_error() gives 2. > > > The alert is sent but ignored. > > > > > > Thanks, > > > Grace > > > > > > On Wed, Jan 3, 2018 at 4:23 PM, Matt Caswell > > > >> wrote: > > > > > > > > > > > > On 03/01/18 10:40, Grace Priscilla Jero wrote: > > > > Hi, > > > > Can someone please respond to the below mail as we want to > > confirm if it > > > > is an issue with our application or a bug in openSSL. > > > > > > It isn't a known bug (which doesn't mean it isn't an unknown > > bug!). > > > > > > I think we're going to need some more information to help you > > with this > > > issue. If I understand you correctly you have a server > > application which > > > only supports DTLS 1.0 and it is that application which is > > failing? > > > Which version of OpenSSL is this? All currently supported > > versions of > > > OpenSSL have the capability to support DTLS1.2 so I'm not sure > > why you > > > have this scenario. > > > > > > You say that "SSL_accept continuously loops with error 2". Do > > you mean > > > by that SSL_accept() returns an error and calling > > SSL_get_error() gives > > > you SSL_ERROR_WANT_READ (value 2)? > > > > > > "The ALERT is not processed": does this mean you are expecting > > to see an > > > alert but it isn't sent? Or an alert is sent but it is ignored? > > > > > > Perhaps a wireshark trace of the exchange would help us to > > understand > > > what you are seeing. > > > > > > Matt > > > > > > > > > > > > > > Thanks, > > > > Grace > > > > > > > > On Fri, Dec 15, 2017 at 3:23 PM, Grace Priscilla Jero > > > > > > > > > > > > > > grace.priscilla at gmail.com>>>> wrote: > > > > > > > > Hi All, > > > > > > > > We are having an issue with DTLS on UDP. > > > > > > > > The scenario is that, when a client of DTLS version 1.2 > is > > > trying to > > > > connect to a server which is at version DTLS 1.0 the > SSL_accept > > > > continuously loops with error 2. The ALERT is not > processed. > > > > Is this a known bug? > > > > > > > > Because of the loop, the application is unable to > process new > > > changes. > > > > > > > > Thanks, > > > > Grace > > > > > > > > > > > > > > > > > > > -- > > > openssl-users mailing list > > > To unsubscribe: > > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From grace.priscilla at gmail.com Thu Jan 11 09:21:22 2018 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Thu, 11 Jan 2018 14:51:22 +0530 Subject: [openssl-users] Information to detach a BIO from fd Message-ID: Hi All, We are having a scenario wherein we are having 2 BIOs for DTLS attached to the same fd. Each BIO has a different SSL associated with it. The messages are getting written to different BIO each time and we are trying to resolve it. Is there a API or any way to detach one of the BIO/SSL from the fd for DTLS? Thanks, Grace -------------- next part -------------- An HTML attachment was scrubbed... URL: From barati.j.prasad at gmail.com Thu Jan 11 09:35:41 2018 From: barati.j.prasad at gmail.com (Bharathi Prasad) Date: Thu, 11 Jan 2018 02:35:41 -0700 (MST) Subject: [openssl-users] How to enable Fixed Diffie Hellman key exchange mechanism Message-ID: <1515663341102-0.post@n7.nabble.com> Hello, I want to use static Diffie Hellman key exchange with RSA authentication (DH_RSA) in my application. I am currently using OpenSSL version 1.0.2n. I understand that from version 1.0.2 openSSL supports fixed DH. Here is what I have tried so far. Trial 1: I created DH server and client certificates as described in demo script in master branch demos/certs/mkcerts.sh. I need a certificate in PKCS12 file to import into my application. Since DH certificate do not have private key I used pkcs12 -nokeys option. This approach failed when I tried to read the certificate from my store. Trial 2. I tried to set DH certificates with SSL_CTX_use_certificate_file() in the client and server applications. After loading the certificate into my ssl context what should I do? Trial 3. I came across some articles where it was suggested that for static DH key exchange append DH parameters to the server certificate. So I appended my DH parameters (2048 key size) to my server certificate and created a pkcs12 file. Import certificate worked however when I tried to read back the certificate from store into x509 object I was unable to retrieve the DH parameters. I could not find a way to retrieve my DH parameters from the server certificate. Trial 4: I placed DH parameter file in my project folder and read the parameters using PEM_read_DHparams(). Then I tried to create DH key with DH_generate_key(); I could not call DH_compute_key as I do not have peer certificate. This configuration is done before I call ssl_connect. So my SSL object is NULL at this point of time. After this I do not know how to proceed. I cannot use SSL_CTX_set_tmp_dh as this api is used for ephemeral Diffie Hellman key exchange. Please let me know where I am going wrong. I need to enable static DH in my application. Regards Bharathi -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From mcr at sandelman.ca Thu Jan 11 13:00:40 2018 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 11 Jan 2018 08:00:40 -0500 Subject: [openssl-users] Information to detach a BIO from fd In-Reply-To: References: Message-ID: <26570.1515675640@obiwan.sandelman.ca> Grace Priscilla Jero wrote: > We are having a scenario wherein we are having 2 BIOs for DTLS > attached to the same fd. Each BIO has a different SSL associated with > it. The messages are getting written to different BIO each time and we > are trying to resolve it. > Is there a API or any way to detach one of the BIO/SSL from the fd for > DTLS? No. How did you get into that situation in the first place? My belief is that the DTLS API is suitable for (Secure)RTP only, and not for CoAP-type usage. (or other DTLS server end-point usage) According to some source code comments, you should have called connect() on the socket after the first connection was received, and then (or previously... there are race conditions either way), opened a new socket. I ran into this, and I wound up creating a new API, which is in a pull request: https://github.com/openssl/openssl/pull/5024 https://github.com/mcr/openssl/tree/dtls-listen-refactor Sadly, the new test case I wrote is not running consistently, which I'm still debugging. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From pratyush.parimal at gmail.com Thu Jan 11 15:28:42 2018 From: pratyush.parimal at gmail.com (pratyush parimal) Date: Thu, 11 Jan 2018 10:28:42 -0500 Subject: [openssl-users] Programmatically check private key and public key cert? In-Reply-To: References: Message-ID: Hi, Hope everyone is having a good new year so far! I'm trying to find a way to make sure that a private-key/public-key-cert pair I'm given, will absolutely work when I stick them into my SSL_CTX* object and try to use that for ssl. Short of trying to simulate a test ssl connection over localhost for testing them out, is there a way to ensure that? After googling, it seems that I may be able to verify that by comparing the modulus from the key and the cert. Does anyone know if that's sufficient, and how to do it programmatically? I was also wondering if I should just try to perform an encrypt-decrypt sequence using the pair I have, and use the success of that as confirmation that my ssl connection will work later, as far as the certs are concerned. Would that be the right way to go about it? What do you guys think? Thanks in advance! - Pratyush -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Thu Jan 11 15:33:58 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 11 Jan 2018 10:33:58 -0500 Subject: [openssl-users] How to enable Fixed Diffie Hellman key exchange mechanism In-Reply-To: <1515663341102-0.post@n7.nabble.com> References: <1515663341102-0.post@n7.nabble.com> Message-ID: <81F9E129-A05A-46E3-9974-633B2CD0F9F0@dukhovni.org> > On Jan 11, 2018, at 4:35 AM, Bharathi Prasad wrote: > > I want to use static Diffie Hellman key exchange with RSA authentication > (DH_RSA) in my application. > > I am currently using OpenSSL version 1.0.2n. I understand that from version > 1.0.2 openSSL supports fixed DH. Support for "fixed DH" ciphers has been withdrawn in OpenSSL 1.1.0. Also TLS 1.3 drops support for "fixed DH". You should not use "fixed DH" ciphers (i.e. any of DH_RSA, DH_DSS, ECDH_ECDSA, ECDH_RSA). RFC5246 says: If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension. Note that this implies that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for instance, an RSA key signed with a DSA key). This is a departure from TLS 1.1, which required that the algorithms be the same. Note that this also implies that the DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the algorithm used to sign the certificate. Fixed DH certificates MAY be signed with any hash/signature algorithm pair appearing in the extension. The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are historical. So "RSA authentication" is a misnomer with "fixed DH", the certificate is a DH or ECDH certificate. Both authentication and key exchange are via the same DH or ECDH computation. -- Viktor. From karl at denninger.net Thu Jan 11 15:41:04 2018 From: karl at denninger.net (Karl Denninger) Date: Thu, 11 Jan 2018 09:41:04 -0600 Subject: [openssl-users] Programmatically check private key and public key cert? In-Reply-To: References: Message-ID: On 1/11/2018 09:28, pratyush parimal wrote: > Hi, > > Hope everyone is having a good new year so far! > > I'm trying to find a way to make sure that a > private-key/public-key-cert pair I'm given, will absolutely work when > I stick? them into my SSL_CTX* object and try to use that for ssl. > Short of trying to simulate a test ssl connection over localhost for > testing them out, is there a way to ensure that? > > After googling, it seems that I may be able to verify that by > comparing the modulus from the key and the cert. Does anyone know if > that's sufficient, and how to do it programmatically? If you call SSL_CTX_check_private_key() on your context it will return "0" if the private key and certificate you have loaded do not match (and thus won't work.)? If you get a "1" back then provided you have a set of ciphers declared (or the defaults) that are compatible on both ends so the code can negotiate a cipher set then it should work. There is no guaranteed way to know if a connection will work from some other piece of code you don't control, however, because it's entirely possible for the other end to try to insist on (or only be able to support) a protocol you have disallowed (e.g. SSLv3) or for there to be no intersection between the cipher sets allowed by both sides and the certificate and key constraints (never mind certificate validation, if you are checking it.) > > I was also wondering if I should just try to perform an > encrypt-decrypt sequence using the pair I have, and use the success of > that as confirmation that my ssl connection will work later, as far as > the certs are concerned. Would that be the right way to go about it? > IMHO see above. -- Karl Denninger karl at denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4897 bytes Desc: S/MIME Cryptographic Signature URL: From openssl-users at dukhovni.org Thu Jan 11 17:45:18 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 11 Jan 2018 12:45:18 -0500 Subject: [openssl-users] Programmatically check private key and public key cert? In-Reply-To: References: Message-ID: <5F143169-B994-4454-A27A-7A59B4B6A262@dukhovni.org> > On Jan 11, 2018, at 10:28 AM, pratyush parimal wrote: > > After googling, it seems that I may be able to verify that by comparing the modulus > from the key and the cert. Does anyone know if that's sufficient, and how to do it > programmatically? It may be useful to note that ECDSA keys don't have a modulus, that's RSA-specific, so a more general approach is to compare public keys. A more broadly applicatble command-line test is: #! /bin/sh certfile=$1; shift keyfile=$1; shift certid=$(openssl x509 -in "$certfile" -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256 -binary | hexencode -ve '/1 "%02x"') keyid=$(openssl pkey -in "$keyfile" -pubout -outform DER | openssl dgst -sha256 -binary | hexencode -ve '/1 "%02x"') if [ "$certid" != "$keyid" ]; then echo "Certificate in $certfile does not match key in $keyfile" >&2 exit 1 fi Karl Denninger already explained how key/cert correspondence can be checked when loading the key and cert into an SSL_CTX. The certificate should have appropriate an appropriate keyUsage and/or extendedKeyUsage for the purpose at hand (TLS Server Authentication?). -- Viktor. From jb-openssl at wisemo.com Thu Jan 11 21:17:43 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 11 Jan 2018 22:17:43 +0100 Subject: [openssl-users] How to enable Fixed Diffie Hellman key exchange mechanism In-Reply-To: <1515663341102-0.post@n7.nabble.com> References: <1515663341102-0.post@n7.nabble.com> Message-ID: On 11/01/2018 10:35, Bharathi Prasad wrote: > Hello, > > I want to use static Diffie Hellman key exchange with RSA authentication > (DH_RSA) in my application. > > I am currently using OpenSSL version 1.0.2n. I understand that from version > 1.0.2 openSSL supports fixed DH. > > Here is what I have tried so far. > > Trial 1: I created DH server and client certificates as described in demo > script in master branch demos/certs/mkcerts.sh. > I need a certificate in PKCS12 file to import into my application. Since DH > certificate do not have private key I used pkcs12 -nokeys option. This > approach failed when I tried to read the certificate from my store. DH certificates DO have an associated private key.? A private DH key which will be the same for every connection (the matching public key is in the certificate). > > Trial 2. I tried to set DH certificates with SSL_CTX_use_certificate_file() > in the client and server applications. > After loading the certificate into my ssl context what should I do? > > Trial 3. I came across some articles where it was suggested that for static > DH key exchange append DH parameters to the server certificate. So I > appended my DH parameters (2048 key size) to my server certificate and > created a pkcs12 file. > > Import certificate worked however when I tried to read back the certificate > from store into x509 object I was unable to retrieve the DH parameters. > > I could not find a way to retrieve my DH parameters from the server > certificate. Start by doing openssl x509 -noout -text -in serverDHcert.pem to see if they are there, and in what field.? Then start looking for functions that retrieve that field from an X509 object.? In 1.0.2 that might be a function or a "public" field in the X509 structure. > Trial 4: I placed DH parameter file in my project folder and read the > parameters using PEM_read_DHparams(). Then I tried to create DH key with > DH_generate_key(); > > I could not call DH_compute_key as I do not have peer certificate. This > configuration is done before I call ssl_connect. So my SSL object is NULL at > this point of time. Only the TLS *server* would have a DH certificate.? The TLS client would have a random DH private key for the parameters received from the TLS server, sending the single-use client DH public key to the TLS server. The TLS server would combine it's private DH server key with the received client DH public key in DH_compute_key() called from inside the TLS code. The TLS client would combine it's random DH private key with the public DH server key from the received server certificate in a similar way to get the same shared secret and thus the same shared TLS master secret. > After this I do not know how to proceed. > > I cannot use SSL_CTX_set_tmp_dh as this api is used for ephemeral Diffie > Hellman key exchange. > > Please let me know where I am going wrong. I need to enable static DH in my > application. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From barati.j.prasad at gmail.com Fri Jan 12 06:57:55 2018 From: barati.j.prasad at gmail.com (Bharathi Prasad) Date: Thu, 11 Jan 2018 23:57:55 -0700 (MST) Subject: [openssl-users] How to enable Fixed Diffie Hellman key exchange mechanism In-Reply-To: <81F9E129-A05A-46E3-9974-633B2CD0F9F0@dukhovni.org> References: <1515663341102-0.post@n7.nabble.com> <81F9E129-A05A-46E3-9974-633B2CD0F9F0@dukhovni.org> Message-ID: <1515740275252-0.post@n7.nabble.com> Thank you for the reply. Let me rephrase my question. How to support fixed Diffie Hellman key agreement in my application. OpenSSL 1.0.2 supports fixed DH. We are currently referring to TLS 1.2 standard and hence need to extend support for fixed DH and ephemeral DH. I was able to enable EDH but not DH. Could you please give me pointers on how to extend support for fixed DH in my code. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From openssl-users at dukhovni.org Fri Jan 12 07:10:33 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 12 Jan 2018 02:10:33 -0500 Subject: [openssl-users] How to enable Fixed Diffie Hellman key exchange mechanism In-Reply-To: <1515740275252-0.post@n7.nabble.com> References: <1515663341102-0.post@n7.nabble.com> <81F9E129-A05A-46E3-9974-633B2CD0F9F0@dukhovni.org> <1515740275252-0.post@n7.nabble.com> Message-ID: > On Jan 12, 2018, at 1:57 AM, Bharathi Prasad wrote: > > Let me rephrase my question. > > How to support fixed Diffie Hellman key agreement in my application. > > OpenSSL 1.0.2 supports fixed DH. > We are currently referring to TLS 1.2 standard and hence need to extend > support for fixed DH and ephemeral DH. I was able to enable EDH but not DH. > > Could you please give me pointers on how to extend support for fixed DH in > my code. Once again, the best thing to do here is to NOT support fixed DH in TLS 1.2. These are not mandatory ciphersuites, and they proved in retrospect a bad idea. So just don't do it. You will encounter any interoperability issues by omitting support for these ciphersuites. Why do you feel a need to support fixed DH? -- Viktor. From grace.priscilla at gmail.com Fri Jan 12 07:49:16 2018 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Fri, 12 Jan 2018 13:19:16 +0530 Subject: [openssl-users] Information to detach a BIO from fd In-Reply-To: <26570.1515675640@obiwan.sandelman.ca> References: <26570.1515675640@obiwan.sandelman.ca> Message-ID: Hi Michael, Below is our scenario on DTLS. We have multiple connections to the same server. We have mapped one fd to the ssl in the server to receive all connections. Whenever a connect is initiated from any client we need to know if it is already connected client or a new client. We are doing this by - creating bio/ssl each time on the same fd - fetching the peer using BIO_dgram_get_peer after ssl_accept - Comparing it to the internally maintained list of peer - If it is a new peer we continue with handshake but if it is old peer we do the ssl_read. The problem is that there are 2 bio/ssl that gets created for the same fd and the peer end up writing to one of them and we don't get the message on the intended ssl. Hence we are checking for a way to detach and remove the ssl/bio that gets created in already connected case. Thanks, Grace On Thu, Jan 11, 2018 at 6:30 PM, Michael Richardson wrote: > > Grace Priscilla Jero wrote: > > We are having a scenario wherein we are having 2 BIOs for DTLS > > attached to the same fd. Each BIO has a different SSL associated with > > it. The messages are getting written to different BIO each time and > we > > are trying to resolve it. > > > Is there a API or any way to detach one of the BIO/SSL from the fd > for > > DTLS? > > No. How did you get into that situation in the first place? > My belief is that the DTLS API is suitable for (Secure)RTP only, and not > for > CoAP-type usage. (or other DTLS server end-point usage) > > According to some source code comments, you should have called connect() on > the socket after the first connection was received, and then (or > previously... there are race conditions either way), opened a new > socket. > > I ran into this, and I wound up creating a new API, which is in a pull > request: > https://github.com/openssl/openssl/pull/5024 > https://github.com/mcr/openssl/tree/dtls-listen-refactor > > Sadly, the new test case I wrote is not running consistently, which I'm > still > debugging. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.graczyk at telic.de Fri Jan 12 07:54:16 2018 From: j.graczyk at telic.de (Jan Graczyk) Date: Fri, 12 Jan 2018 07:54:16 +0000 Subject: [openssl-users] Information to detach a BIO from fd In-Reply-To: References: <26570.1515675640@obiwan.sandelman.ca> Message-ID: <0AD3F71B283ED7469D76E28693EC1CA5ECC86C@EXCHANGE.CEPAG.local> Hello Everyone, I am evaluating different SSL software stacks for a company product. Does anyone know how much is ROM memory footprint for OpenSSL? I would appreciate very much a help from you. Best Regards, Jan From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Grace Priscilla Jero Sent: Friday, January 12, 2018 8:49 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] Information to detach a BIO from fd Hi Michael, Below is our scenario on DTLS. We have multiple connections to the same server. We have mapped one fd to the ssl in the server to receive all connections. Whenever a connect is initiated from any client we need to know if it is already connected client or a new client. We are doing this by * creating bio/ssl each time on the same fd * fetching the peer using BIO_dgram_get_peer after ssl_accept * Comparing it to the internally maintained list of peer * If it is a new peer we continue with handshake but if it is old peer we do the ssl_read. The problem is that there are 2 bio/ssl that gets created for the same fd and the peer end up writing to one of them and we don't get the message on the intended ssl. Hence we are checking for a way to detach and remove the ssl/bio that gets created in already connected case. Thanks, Grace On Thu, Jan 11, 2018 at 6:30 PM, Michael Richardson > wrote: Grace Priscilla Jero > wrote: > We are having a scenario wherein we are having 2 BIOs for DTLS > attached to the same fd. Each BIO has a different SSL associated with > it. The messages are getting written to different BIO each time and we > are trying to resolve it. > Is there a API or any way to detach one of the BIO/SSL from the fd for > DTLS? No. How did you get into that situation in the first place? My belief is that the DTLS API is suitable for (Secure)RTP only, and not for CoAP-type usage. (or other DTLS server end-point usage) According to some source code comments, you should have called connect() on the socket after the first connection was received, and then (or previously... there are race conditions either way), opened a new socket. I ran into this, and I wound up creating a new API, which is in a pull request: https://github.com/openssl/openssl/pull/5024 https://github.com/mcr/openssl/tree/dtls-listen-refactor Sadly, the new test case I wrote is not running consistently, which I'm still debugging. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From grace.priscilla at gmail.com Fri Jan 12 12:03:43 2018 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Fri, 12 Jan 2018 17:33:43 +0530 Subject: [openssl-users] Fwd: Information to detach a BIO from fd In-Reply-To: References: <26570.1515675640@obiwan.sandelman.ca> Message-ID: Hi All, Below is our scenario on DTLS. We have multiple connections to the same server. We have mapped one fd to the ssl in the server to receive all connections. Whenever a connect is initiated from any client we need to know if it is already connected client or a new client. We are doing this by - creating bio/ssl each time a polling happens on the server fd - fetching the peer using BIO_dgram_get_peer after ssl_accept - Comparing it to the internally maintained list of peer - If it is a new peer we continue with handshake but if it is old peer we do the ssl_read. The problem is that there are 2 bio/ssl that gets created for the same fd(when there are 2 clients) and the peer end up writing to latest of them and we don't get the message on the intended ssl. Hence we are checking for a way to detach and remove the ssl/bio that gets created in already connected cases. Any help is appreciated. Any APIs available to close up the 2nd ssl associated with the fd. ssl_clear and ssl_free does not work. Thanks, Grace On Thu, Jan 11, 2018 at 6:30 PM, Michael Richardson wrote: > > Grace Priscilla Jero wrote: > > We are having a scenario wherein we are having 2 BIOs for DTLS > > attached to the same fd. Each BIO has a different SSL associated with > > it. The messages are getting written to different BIO each time and > we > > are trying to resolve it. > > > Is there a API or any way to detach one of the BIO/SSL from the fd > for > > DTLS? > > No. How did you get into that situation in the first place? > My belief is that the DTLS API is suitable for (Secure)RTP only, and not > for > CoAP-type usage. (or other DTLS server end-point usage) > > According to some source code comments, you should have called connect() on > the socket after the first connection was received, and then (or > previously... there are race conditions either way), opened a new > socket. > > I ran into this, and I wound up creating a new API, which is in a pull > request: > https://github.com/openssl/openssl/pull/5024 > https://github.com/mcr/openssl/tree/dtls-listen-refactor > > Sadly, the new test case I wrote is not running consistently, which I'm > still > debugging. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Fri Jan 12 13:15:18 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 12 Jan 2018 13:15:18 +0000 Subject: [openssl-users] Fwd: Information to detach a BIO from fd In-Reply-To: References: <26570.1515675640@obiwan.sandelman.ca> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Grace Priscilla Jero > Sent: Friday, January 12, 2018 07:04 > Whenever a connect is initiated from any client we need to know if it is already connected client or a new client. > We are doing this by? > ? creating bio/ssl each time a polling happens on the server fd > ? fetching the peer using?BIO_dgram_get_peer after ssl_accept? > ? Comparing it to the internally maintained list of peer Don't create the BIO immediately. Use getpeername on the socket descriptor and check that against the list. Only create a new SSL object and BIO if it's not an already-established client. -- Michael Wojcik Distinguished Engineer, Micro Focus From markjt at fredo.co.uk Fri Jan 12 14:20:54 2018 From: markjt at fredo.co.uk (markjt at fredo.co.uk) Date: Fri, 12 Jan 2018 14:20:54 -0000 Subject: [openssl-users] OpenSSL wins the Levchin prize In-Reply-To: <20180110233649.7123027.44825.24013@oliverniebuhr.de> References: <457054ae-e8ee-a8c5-67d4-d5e1d52ac70e@openssl.org>, <20180110233649.7123027.44825.24013@oliverniebuhr.de> Message-ID: <5A58C446.22045.98EC7FA@markjt.fredo.co.uk> List spamming? For this one message I think not: I have professionally benefitted pretty much through the entire history of OpenSSL and its predecessors and I strongly 2nd "Google Esatz"'s message. With sincere thanks to everyone involved in the open source encryption world, and the OpenSSl team in particular, Mark From johan.persson.192 at gmail.com Fri Jan 12 15:57:31 2018 From: johan.persson.192 at gmail.com (johan persson) Date: Fri, 12 Jan 2018 16:57:31 +0100 Subject: [openssl-users] tls handshake fail using cipher ECDHE-ECDSA-AES256-GCM-SHA384 Message-ID: I have problem doing handshake using "ECDHE-ECDSA-AES256-GCM-SHA384" cipher. OpenSSL 1.0.2h This is how I generate test certificates. openssl ecparam -out /data/ca.key -name secp256k1 -genkey openssl req -x509 -new -key /data/ca.key -out /data/ca.pem -outform PEM -days 3650 -subj '/C=SE/ST=S/L=M/O=V/CN=SERVER openssl ecparam -out /data/server.key -name secp256k1 -genkey openssl req -new -nodes -key /data/server.key -outform pem -out /data/server.req -subj '/C=SE/ST=S/L=M/O=V/CN=SERVER' openssl ecparam -out /data/client.key -name secp256k1 -genkey openssl req -new -nodes -key /data/client.key -outform pem -out /data/client.req -subj '/C=SE/ST=S/L=M/O=V/CN=CLIENT' openssl ca -batch -keyfile /data/ca.key -cert /data/ca.pem -in /data/server.req -out /data/server.pem -outdir /data/ openssl ca -batch -keyfile /data/ca.key -cert /data/ca.pem -in /data/client.req -out /data/client.pem -outdir /data/ Running the following test: openssl s_server -accept 10000 -cert server.pem -key server.key -CAfile ca.pem -debug -tlsextdebug openssl s_client -connect localhost:10000 -cert client.pem -key client.key -CAfile ca.pem -tls1_2 I get a handshake working ok with the cipher I want "ECDHE-ECDSA-AES256-GCM-SHA384", perfect!: Now, using my own tls server I only get "ECDH-ECDSA-AES256-GCM-SHA384" to work. I cannot use "ECDHE-ECDSA-AES256-GCM-SHA384" which I want. Anyone knows what I'm missing from the following setup?: #define VOC_TLS_CIPHERS "ECDHE-ECDSA-AES256-GCM-SHA384" << NOT WORKING //#define VOC_TLS_CIPHERS "ECDH-ECDSA-AES256-GCM-SHA384" << WORKING // Init for OpenSSL SSL_library_init(); OpenSSL_add_all_algorithms(); SSL_load_error_strings(); ctx_ = SSL_CTX_new(TLSv1_2_server_method()); if (ctx_ == NULL) { LOG(LOG_WARN, "Tls: %s: Failed to create TLS context", __FUNCTION__); return RET_FAIL; } (Load Ca cert, server and server private key) if (SSL_CTX_set_ecdh_auto(ctx_, 1)) { LOG(LOG_WARN, "Tls: %s: Failed to set ECDH auto pick", __FUNCTION__); return RET_FAIL; } if (!SSL_CTX_set_cipher_list(ctx_, VOC_TLS_CIPHERS)) { LOG(LOG_WARN, "Tls: %s: Failed to set cipher list: %s\n", __FUNCTION__, VOC_TLS_CIPHERS); return RET_FAIL; } ssl_ = SSL_new(ctx_); error on server side: Server has 1 from 0xb475ef98: 0xb6daa440:ECDHE-ECDSA-AES256-GCM-SHA384 Client sent 1 from 0xb3502308: 0xb6daa440:ECDHE-ECDSA-AES256-GCM-SHA384 rt=0 rte=0 dht=0 ecdht=0 re=0 ree=0 rs=0 ds=0 dhr=0 dhd=0 0:[00000080:00000040:00000140:000000D4]0xb6daa440:ECDHE- ECDSA-AES256-GCM-SHA384 2958031164:error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1417: -------------- next part -------------- An HTML attachment was scrubbed... URL: From grace.priscilla at gmail.com Sat Jan 13 01:52:30 2018 From: grace.priscilla at gmail.com (Priscilla Hero) Date: Sat, 13 Jan 2018 07:22:30 +0530 Subject: [openssl-users] Fwd: Information to detach a BIO from fd In-Reply-To: References: <26570.1515675640@obiwan.sandelman.ca> Message-ID: Hi Michael, Without doing ssl_accept on the ssl will getpeername work? Also using the existing ssl with ssl_accept for the first connection we don?t get the information of second peer. Thus we ended up creating new bio/ssl each time we get a request. Any suggestions? Thanks, Grace On 12-Jan-2018, at 6:45 PM, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Grace Priscilla Jero >> Sent: Friday, January 12, 2018 07:04 > > >> Whenever a connect is initiated from any client we need to know if it is already connected client or a new client. >> We are doing this by >> ? creating bio/ssl each time a polling happens on the server fd >> ? fetching the peer using BIO_dgram_get_peer after ssl_accept >> ? Comparing it to the internally maintained list of peer > > Don't create the BIO immediately. Use getpeername on the socket descriptor and check that against the list. Only create a new SSL object and BIO if it's not an already-established client. > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From d3ck0r at gmail.com Sat Jan 13 18:54:15 2018 From: d3ck0r at gmail.com (J Decker) Date: Sat, 13 Jan 2018 10:54:15 -0800 Subject: [openssl-users] Fwd: Information to detach a BIO from fd In-Reply-To: References: <26570.1515675640@obiwan.sandelman.ca> Message-ID: I'm not 100% sure what you're doing I'd imagine that if SSL was managing the fd's you wouldn't have this issue. You hvae to call accept() to get a new FD... and you'll only get that once, so when you accept() you should attach the bio and call ssl_accept(), no? On Fri, Jan 12, 2018 at 5:52 PM, Priscilla Hero wrote: > > > Hi Michael, > Without doing ssl_accept on the ssl will getpeername work? Also using the > existing ssl with ssl_accept for the first connection we don?t get the > information of second peer. Thus we ended up creating new bio/ssl each time > we get a request. > > Any suggestions? > > Thanks, > Grace > > On 12-Jan-2018, at 6:45 PM, Michael Wojcik > wrote: > > >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > Behalf Of Grace Priscilla Jero > >> Sent: Friday, January 12, 2018 07:04 > > > > > >> Whenever a connect is initiated from any client we need to know if it > is already connected client or a new client. > >> We are doing this by > >> ? creating bio/ssl each time a polling happens on the server fd > >> ? fetching the peer using BIO_dgram_get_peer after ssl_accept > >> ? Comparing it to the internally maintained list of peer > > > > Don't create the BIO immediately. Use getpeername on the socket > descriptor and check that against the list. Only create a new SSL object > and BIO if it's not an already-established client. > > > > -- > > Michael Wojcik > > Distinguished Engineer, Micro Focus > > > > > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcr at sandelman.ca Sat Jan 13 21:29:37 2018 From: mcr at sandelman.ca (Michael Richardson) Date: Sat, 13 Jan 2018 16:29:37 -0500 Subject: [openssl-users] Fwd: Information to detach a BIO from fd In-Reply-To: References: <26570.1515675640@obiwan.sandelman.ca> Message-ID: <22086.1515878977@obiwan.sandelman.ca> J Decker wrote: > I'm not 100% sure what you're doing I'd imagine that if SSL was > managing the fd's you wouldn't have this issue. You hvae to call > accept() to get a new FD... and you'll only get that once, so when you > accept() you should attach the bio and call ssl_accept(), no? accept(2) applies to TCP sockets only. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From mcr at sandelman.ca Sat Jan 13 21:33:46 2018 From: mcr at sandelman.ca (Michael Richardson) Date: Sat, 13 Jan 2018 16:33:46 -0500 Subject: [openssl-users] Fwd: Information to detach a BIO from fd In-Reply-To: References: <26570.1515675640@obiwan.sandelman.ca> Message-ID: <23181.1515879226@obiwan.sandelman.ca> Priscilla Hero wrote: > Hi Michael, Without doing ssl_accept on the ssl will getpeername work? ssl_accept() processes the packets on the socket. getpeername() on a (Unix) socket will always work. However, getpeername() on a UDP socket won't produce anything unless the socket was connect(2)'ed. In order to get the address of the remote system one has to get it when receiving the packet. That's why: https://github.com/mcr/openssl/commit/f764151782b4b32a752b4016336c0ceafa98ed5c retrieves the peer name from the BIO. > On 12-Jan-2018, at 6:45 PM, Michael Wojcik > wrote: >> Don't create the BIO immediately. Use getpeername on the socket >> descriptor and check that against the list. Only create a new SSL >> object and BIO if it's not an already-established client. That only works with TCP. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From mcr at sandelman.ca Sat Jan 13 21:42:35 2018 From: mcr at sandelman.ca (Michael Richardson) Date: Sat, 13 Jan 2018 16:42:35 -0500 Subject: [openssl-users] Information to detach a BIO from fd In-Reply-To: References: <26570.1515675640@obiwan.sandelman.ca> Message-ID: <25525.1515879755@obiwan.sandelman.ca> Grace Priscilla Jero wrote: > Below is our scenario on DTLS. > We have multiple connections to the same server. We have mapped one fd > to the ssl in the server to receive all connections. Are these connections from the same client (same 5-tuple), or are you just talking about multiple clients? > Whenever a connect is initiated from any client we need to know if it > is already connected client or a new client. We are doing this by > * creating bio/ssl each time on the same fd > * fetching the peer using BIO_dgram_get_peer after ssl_accept > * Comparing it to the internally maintained list of peer > * If it is a new peer we continue with handshake but if it is old peer > we do the ssl_read. I don't think this is going to work. A UDP/DTLS server has two choices: 1) read all the packets on a unconnected socket and demultiplex them into appropriate BIOs/SSL structures. I did not find an obvious way to do this, I think that a new BIO type would make this easiest. It also has the downside that it's hard to spread the load across multiple processes, although with the right locking multiple threads would likely work. 2) after each call to DTLSv1_listen(), set up a new fd that is bind()/connect()ed to the peer (by 5-tuple) so that all traffic from that peer arrives on the correct FD. AFAIK, there isn't anything to forbid two DTLS sessions between identical UDP sockets, as they could have differing session cookies, etc. > The problem is that there are 2 bio/ssl that gets created for the same > fd and the peer end up writing to one of them and we don't get the > message on the intended ssl. Hence we are checking for a way to detach > and remove the ssl/bio that gets created in already connected case. I don't think that is going to work. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From pratyush.parimal at gmail.com Sun Jan 14 11:07:04 2018 From: pratyush.parimal at gmail.com (pratyush parimal) Date: Sun, 14 Jan 2018 06:07:04 -0500 Subject: [openssl-users] SSL Cert serial number non-uniqueness impact In-Reply-To: References: Message-ID: Hi everyone, I read from several sources that the serial number of a cert MUST be unique within a CA. But could someone explain what would happen if the serial number was not unique? Would it cause SSL connections to fail in some manner? I think I'm a little unclear about the "purpose" of the serial number in the first place. Is it just something the CA uses to keep track of what/how many certificates it has issued, or does it play a part in the SSL connection itself? Thanks in advance! Pratyush -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jochen.Bern at binect.de Sun Jan 14 11:30:55 2018 From: Jochen.Bern at binect.de (Jochen Bern) Date: Sun, 14 Jan 2018 12:30:55 +0100 Subject: [openssl-users] SSL Cert serial number non-uniqueness impact In-Reply-To: References: Message-ID: <3c2c668a-8930-824f-e96e-412a0121315f@binect.de> On 01/14/2018 12:07 PM, pratyush parimal wrote: > I read from several sources that the serial number of a cert MUST be > unique within a CA. But could someone explain what would happen if the > serial number was not unique? Certificate Revocation Lists (CRLs) identify invalid certificates by means of a) the CA keypair that issued it (the pubkey being represented in the signature) and b) the serial number, *not* pubkey / DN / ..., of the invalid cert. If that's not unique, revoking one of the affected certs will have the effect of revoking them all. Regards, -- Jochen Bern Systemingenieur www.binect.de -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4278 bytes Desc: S/MIME Cryptographic Signature URL: From rsalz at akamai.com Sun Jan 14 14:04:11 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 14 Jan 2018 14:04:11 +0000 Subject: [openssl-users] SSL Cert serial number non-uniqueness impact In-Reply-To: <3c2c668a-8930-824f-e96e-412a0121315f@binect.de> References: <3c2c668a-8930-824f-e96e-412a0121315f@binect.de> Message-ID: <7E397C60-C5BD-4CEA-950F-5AEE62D43CD9@akamai.com> The combination of (issuer,serial#) is the only way to get a unique identifier for a certificate. Lots of software depends on certs being uniquely identifiable. What happens if that assertion is not true? Some things will break. What? Well, it depends on the software, and which certs are ?duplicates? and so on. There?s no way to know, really. Just don?t do it. For example, if cert-A has a keypair and cert-B has a keypair, then site-B could send a TLS chain with cert-A and while it would look correct, the connection would fail. This is silly if B is doing it, but it is a DoS attack if a man in the middle does it. From cryptoassetrecovery at gmail.com Sun Jan 14 15:26:51 2018 From: cryptoassetrecovery at gmail.com (Chris B) Date: Sun, 14 Jan 2018 10:26:51 -0500 Subject: [openssl-users] OpenSSL error message when decrypting Ethereum encrypted private key Message-ID: I'm trying to help someone recover his password for an older format ethereum encrypted private key (EPK). My plan has been to use his best guess at the password to brute force the actual password. The EPK is a 132 character string, and it looks something like this: U2FsdGV0X185M9YAa/27pmEvFzC5pqLI4xWrA6ouGVCx0EeJ9s8DzeGuBtYJPDCKDy0m80yvHdQYDMPa+Hwv2JPbuGJNoUMhFWpcQW1VF+EAy0tYb7Wtv2+IRWZzcpsE8e2a (That is: 128 ASCII digits and/or letters, plus three "+" and a "/".) This article ( https://www.reddit.com/r/Bitcoin/comments/3gwdge/importing_old_encrypted_private_keys/) seems to describe a very similar EPK. The author of that post decrypted their key with the following command: openssl enc -in FILE_OF_KEYS -a -d -salt -aes256 -pass pass:"PASSWORD_HERE" I have tried this same approach, but I'm getting an error: EVP_DecryptFinal_ex:wrong final block length Here's an example: /usr/bin/openssl enc -d -aes-256-cbc -a -in enc_private_key.txt -out recovered.key -pass pass:TheBig7ebowski And here's the output: bad decrypt 140220549330848:error:0606506D:digital envelope routines:EVP_DecryptFinal_ex:wrong final block length:evp_enc.c:581: I'm not sure how to interpret that output. I could interpret it as: o Your system for decrypting the password is perfect, but: this is not the right password. o There's something wrong with the EPK -- its length must be a multiple of the AES block length. o There's something wrong with the unencrypted private key -- its length must be a multiple of the AES block length. o Something else entirely Can anyone help me understand how to interpret this error message? Thanks, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sun Jan 14 15:39:09 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 14 Jan 2018 15:39:09 +0000 Subject: [openssl-users] OpenSSL error message when decrypting Ethereum encrypted private key In-Reply-To: References: Message-ID: <17E06F75-EBBA-4BE3-87CB-4F38E1EFDEE9@akamai.com> For CBC the encrypted text will be a multiple of the cipher size. So your use of CBC is wrong. The quoted post uses aes256; you were using aes-cbc -------------- next part -------------- An HTML attachment was scrubbed... URL: From cryptoassetrecovery at gmail.com Sun Jan 14 15:46:21 2018 From: cryptoassetrecovery at gmail.com (Chris B) Date: Sun, 14 Jan 2018 10:46:21 -0500 Subject: [openssl-users] OpenSSL error message when decrypting Ethereum encrypted private key In-Reply-To: <17E06F75-EBBA-4BE3-87CB-4F38E1EFDEE9@akamai.com> References: <17E06F75-EBBA-4BE3-87CB-4F38E1EFDEE9@akamai.com> Message-ID: Hi Rich, Thank you very much for the reply. I get the same error message using -aes256 as -aes-256-cbc /usr/bin/openssl enc -d -aes256 -a -in enc_private_key.txt -out recovered.key -pass pass:TheBig7ebowski bad decrypt 140383648536480:error:0606506D:digital envelope routines:EVP_DecryptFinal_ex:wrong final block length:evp_enc.c:581: Thanks, Chris On Sun, Jan 14, 2018 at 10:39 AM, Salz, Rich via openssl-users < openssl-users at openssl.org> wrote: > For CBC the encrypted text will be a multiple of the cipher size. So your > use of CBC is wrong. The quoted post uses aes256; you were using aes-cbc > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sun Jan 14 16:21:48 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 14 Jan 2018 11:21:48 -0500 Subject: [openssl-users] OpenSSL error message when decrypting Ethereum encrypted private key In-Reply-To: References: Message-ID: > On Jan 14, 2018, at 10:26 AM, Chris B wrote: > > I'm trying to help someone recover his password for an older format ethereum encrypted private key (EPK). My plan has been to use his best guess at the password to brute force the actual password. > > The EPK is a 132 character string, and it looks something like this: U2FsdGV0X185M9YAa/27pmEvFzC5pqLI4xWrA6ouGVCx0EeJ9s8DzeGuBtYJPDCKDy0m80yvHdQYDMPa+Hwv2JPbuGJNoUMhFWpcQW1VF+EAy0tYb7Wtv2+IRWZzcpsE8e2a > > (That is: 128 ASCII digits and/or letters, plus three "+" and a "/".) This input is base64 encoded: $ openssl base64 -d < > This article (https://www.reddit.com/r/Bitcoin/comments/3gwdge/importing_old_encrypted_private_keys/) > seems to describe a very similar EPK. In that sample, the base64-decoded data starts with "Salted__" as expected. > The author of that post decrypted their key with the following command: > > openssl enc -in FILE_OF_KEYS -a -d -salt -aes256 -pass pass:"PASSWORD_HERE" Hard to say whether that's correct, rather depends on the format of "FILE_OF_KEYS". You could try a dictionary attack on the actual 132-byte string, after base64-decoding, provided it is not corrupted. -- Viktor. From Michael.Wojcik at microfocus.com Sun Jan 14 20:42:58 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Sun, 14 Jan 2018 20:42:58 +0000 Subject: [openssl-users] Fwd: Information to detach a BIO from fd In-Reply-To: <23181.1515879226@obiwan.sandelman.ca> References: <26570.1515675640@obiwan.sandelman.ca> <23181.1515879226@obiwan.sandelman.ca> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Michael Richardson > Sent: Saturday, January 13, 2018 16:34 > >???? > On 12-Jan-2018, at 6:45 PM, Michael Wojcik >???? > wrote: >???? >> Don't create the BIO immediately. Use getpeername on the socket >???? >> descriptor and check that against the list. Only create a new SSL >???? >> object and BIO if it's not an already-established client. > > That only works with TCP. Yes, of course. I realized this myself when I saw the followup question. Post in haste, repent in leisure... Thanks for the correction. -- Michael Wojcik Distinguished Engineer, Micro Focus From cryptoassetrecovery at gmail.com Sun Jan 14 22:36:25 2018 From: cryptoassetrecovery at gmail.com (Chris B) Date: Sun, 14 Jan 2018 17:36:25 -0500 Subject: [openssl-users] OpenSSL error message when decrypting Ethereum encrypted private key In-Reply-To: References: Message-ID: >Any chance this is data corruption? Brilliant! You caught me. Although this key is encrypted I wasn't comfortable making it public on the interwebs. So, I randomly changed several of the characters. If I run openssl base64 -d... on the *actual* key it does indeed begin with Salted__: $ openssl base64 -d -in enc_private_key.txt | od -c 0000000 S a l t e d _ _ >You could try a dictionary attack on the actual 132-byte string, after base64-decoding, >provided it is not corrupted. This is basically what I was trying to do, although I was simply running a few hundred thousand strings that are related to the best guess password, rather using a dictionary attack. Is there a better command to proceed with a brute force attack than this one? /usr/bin/openssl enc -d -aes-256-cpc -a -in enc_private_key.txt -out recovered.key As I understand: - openssl enc -d => decrypt using openssl - -aes-256-cpc => use the AES 256 CPC algorithm - -a => base64 decrypt - -in => read the encrypted string from enc_private_key.txt - -out => write the unencrypted string to recovered.key I tried running openssl in two steps: first doing the base64 decoding, then decrypting with -aes256, which I believe is functionally the same as the command mentioned above: $ openssl base64 -d -in enc_private_key.txt | openssl enc -d -aes256 -out recovered.key enter aes-256-cbc decryption password: bad decrypt 139845090879392:error:0606506D:digital envelope routines:EVP_DecryptFinal_ex:wrong final block length:evp_enc.c:581: Which brings me back to the original question. Does anyone know how to interpret "EVP_DecryptFinal_ex:wrong final block length" Thanks! -Chris On Sun, Jan 14, 2018 at 11:21 AM, Viktor Dukhovni < openssl-users at dukhovni.org> wrote: > > > > On Jan 14, 2018, at 10:26 AM, Chris B > wrote: > > > > I'm trying to help someone recover his password for an older format > ethereum encrypted private key (EPK). My plan has been to use his best > guess at the password to brute force the actual password. > > > > The EPK is a 132 character string, and it looks something like this: > U2FsdGV0X185M9YAa/27pmEvFzC5pqLI4xWrA6ouGVCx0EeJ > 9s8DzeGuBtYJPDCKDy0m80yvHdQYDMPa+Hwv2JPbuGJNoUMhFWpcQW1VF+ > EAy0tYb7Wtv2+IRWZzcpsE8e2a > > > > (That is: 128 ASCII digits and/or letters, plus three "+" and a "/".) > > This input is base64 encoded: > > $ openssl base64 -d < U2FsdGV0X185M9YAa/27pmEvFzC5pqLI4xWrA6ouGVCx0EeJ9s8DzeGuBtYJPDCK > Dy0m80yvHdQYDMPa+Hwv2JPbuGJNoUMhFWpcQW1VF+EAy0tYb7Wtv2+IRWZzcpsE > 8e2a > END > 0000000 S a l t e t _ _ 9 3 326 \0 k 375 273 246 > 0000020 a / 027 0 271 246 242 310 343 025 253 003 252 . 031 P > 0000040 261 320 G 211 366 317 003 315 341 256 006 326 \t < 0 212 > 0000060 017 - & 363 L 257 035 324 030 \f 303 332 370 | / ? > 0000100 ** ? ** b M 241 C ! 025 j \ A m U 027 000 > 0000120 \0 313 K X o 265 255 277 o 210 E f s r 233 004 > 0000140 361 100 232 > > This does indeed look a lot like "openssl enc" output: > > $ echo foobar | openssl enc -aes256 -pass pass:foobar | od -c > 0000000 S a l t e d _ _ 263 f 243 \0 242 ~ 031 3 > 0000020 266 035 Y 310 367 300 366 264 247 : $ s 236 266 4 340 > 0000040 > > Except that for some reason the "d" in "Salted" is a "t". Funny that these > are the voiced and unvoiced variants of the same consonant, but note also > that the ASCII code for 'd' = 0x64 and 't' = 0x74, so this is a 1 bit > change. > Any chance this is data corruption? > > > > > This article (https://www.reddit.com/r/Bitcoin/comments/3gwdge/ > importing_old_encrypted_private_keys/) > > seems to describe a very similar EPK. > > In that sample, the base64-decoded data starts with "Salted__" as expected. > > > The author of that post decrypted their key with the following command: > > > > openssl enc -in FILE_OF_KEYS -a -d -salt -aes256 -pass > pass:"PASSWORD_HERE" > > Hard to say whether that's correct, rather depends on the format of > "FILE_OF_KEYS". > You could try a dictionary attack on the actual 132-byte string, after > base64-decoding, > provided it is not corrupted. > > -- > Viktor. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Sun Jan 14 23:03:37 2018 From: matt at openssl.org (Matt Caswell) Date: Sun, 14 Jan 2018 23:03:37 +0000 Subject: [openssl-users] OpenSSL error message when decrypting Ethereum encrypted private key In-Reply-To: References: Message-ID: On 14/01/18 15:26, Chris B wrote: > I'm trying to help someone recover his password for an older format > ethereum encrypted private key (EPK). My plan has been to use his best > guess at the password to brute force the actual password. > > The EPK is a 132 character string, and it looks something like this: > U2FsdGV0X185M9YAa/27pmEvFzC5pqLI4xWrA6ouGVCx0EeJ9s8DzeGuBtYJPDCKDy0m80yvHdQYDMPa+Hwv2JPbuGJNoUMhFWpcQW1VF+EAy0tYb7Wtv2+IRWZzcpsE8e2a > > (That is: 128 ASCII digits and/or letters, plus three "+" and a "/".) > > This article > (https://www.reddit.com/r/Bitcoin/comments/3gwdge/importing_old_encrypted_private_keys/) > seems to describe a very similar EPK. The author of that post decrypted > their key with the following command: > > openssl enc -in FILE_OF_KEYS -a -d -salt -aes256 -pass pass:"PASSWORD_HERE" > > I have tried this same approach, but I'm getting an error: > > EVP_DecryptFinal_ex:wrong final block length What version of OpenSSL are you using. The quoted article was written 2 years ago so definitely wasn't using OpenSSL 1.1.0. If you *are* using 1.1.0 then the default digest was changed between 1.0.2 and 1.1.0. Old OpenSSL "enc" output defaulted to md5. The current default is sha256: https://www.openssl.org/docs/faq.html#USER3 Try adding "-md md5" onto your command line. Matt > > Here's an example: > > /usr/bin/openssl enc -d -aes-256-cbc -a -in enc_private_key.txt -out > recovered.key -pass pass:TheBig7ebowski > > And here's the output: > > bad decrypt > > 140220549330848:error:0606506D:digital envelope > routines:EVP_DecryptFinal_ex:wrong final block length:evp_enc.c:581: > > I'm not sure how to interpret that output. I could interpret it as: > o Your system for decrypting the password is perfect, but: this is not > the right password. > o There's something wrong with the EPK -- its length must be a multiple > of the AES block length. > o There's something wrong with the unencrypted private key -- its length > must be a multiple of the AES block length. > o Something else entirely > > Can anyone help me understand how to interpret this error message? > > Thanks, > Chris > > From cryptoassetrecovery at gmail.com Sun Jan 14 23:26:20 2018 From: cryptoassetrecovery at gmail.com (Chris B) Date: Sun, 14 Jan 2018 18:26:20 -0500 Subject: [openssl-users] OpenSSL error message when decrypting Ethereum encrypted private key In-Reply-To: References: Message-ID: Hi Matt, >If you *are* using 1.1.0 then the default digest was changed between 1.0.2 and 1.1.0. Awesome thought, but I'm also using 1.0.2: $ openssl version OpenSSL 1.0.2k-fips 26 Jan 2017 (I also tried adding -md md5 to the previous command, but I got the same error message). Thanks, Chris On Sun, Jan 14, 2018 at 6:03 PM, Matt Caswell wrote: > > > On 14/01/18 15:26, Chris B wrote: > > I'm trying to help someone recover his password for an older format > > ethereum encrypted private key (EPK). My plan has been to use his best > > guess at the password to brute force the actual password. > > > > The EPK is a 132 character string, and it looks something like this: > > U2FsdGV0X185M9YAa/27pmEvFzC5pqLI4xWrA6ouGVCx0EeJ > 9s8DzeGuBtYJPDCKDy0m80yvHdQYDMPa+Hwv2JPbuGJNoUMhFWpcQW1VF+ > EAy0tYb7Wtv2+IRWZzcpsE8e2a > > > > (That is: 128 ASCII digits and/or letters, plus three "+" and a "/".) > > > > This article > > (https://www.reddit.com/r/Bitcoin/comments/3gwdge/ > importing_old_encrypted_private_keys/) > > seems to describe a very similar EPK. The author of that post decrypted > > their key with the following command: > > > > openssl enc -in FILE_OF_KEYS -a -d -salt -aes256 -pass > pass:"PASSWORD_HERE" > > > > I have tried this same approach, but I'm getting an error: > > > > EVP_DecryptFinal_ex:wrong final block length > > What version of OpenSSL are you using. The quoted article was written 2 > years ago so definitely wasn't using OpenSSL 1.1.0. If you *are* using > 1.1.0 then the default digest was changed between 1.0.2 and 1.1.0. Old > OpenSSL "enc" output defaulted to md5. The current default is sha256: > > https://www.openssl.org/docs/faq.html#USER3 > > Try adding "-md md5" onto your command line. > > Matt > > > > > > Here's an example: > > > > /usr/bin/openssl enc -d -aes-256-cbc -a -in enc_private_key.txt -out > > recovered.key -pass pass:TheBig7ebowski > > > > And here's the output: > > > > bad decrypt > > > > 140220549330848:error:0606506D:digital envelope > > routines:EVP_DecryptFinal_ex:wrong final block length:evp_enc.c:581: > > > > I'm not sure how to interpret that output. I could interpret it as: > > o Your system for decrypting the password is perfect, but: this is not > > the right password. > > o There's something wrong with the EPK -- its length must be a multiple > > of the AES block length. > > o There's something wrong with the unencrypted private key -- its length > > must be a multiple of the AES block length. > > o Something else entirely > > > > Can anyone help me understand how to interpret this error message? > > > > Thanks, > > Chris > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rolphil42 at gmail.com Mon Jan 15 13:22:09 2018 From: rolphil42 at gmail.com (Rol Phil) Date: Mon, 15 Jan 2018 13:22:09 +0000 Subject: [openssl-users] CMAC Authentication Message-ID: Hello all, I have been using to tag data with an example I had found. However when it comes to authenticate/decrypt a tag with given AES key I could not find examples. using cmac.h or evp.h. Can anybody help me please? Thanks all. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Mon Jan 15 13:40:33 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 15 Jan 2018 14:40:33 +0100 Subject: [openssl-users] CMAC Authentication In-Reply-To: References: Message-ID: On 15/01/2018 14:22, Rol Phil wrote: > Hello all, > > I have been using to tag data with an example I had > found. > However when it comes to authenticate/decrypt a tag with given AES key > I could not find examples. > ?using cmac.h or evp.h. > Can anybody help me please? > Thanks all. > For any MAC algorithm, the check is to calculate the MAC again and see if it is the same. If potential providers of bad data can see how long it takes to detect a wrong MAC algorithm, be sure to use a compare implementation tht takes the same amount of time no matter how the wrong MAC relates to the real MAC (so the normal memcmp() is wrong because it will reply quicker if the first byte(s) are wrong than if they are right).? The OpenSSL provides the a function CRYPTO_memcmp() that is good for this job. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From noloader at gmail.com Mon Jan 15 13:45:08 2018 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 15 Jan 2018 08:45:08 -0500 Subject: [openssl-users] CMAC Authentication In-Reply-To: References: Message-ID: On Mon, Jan 15, 2018 at 8:22 AM, Rol Phil wrote: > Hello all, > > I have been using to tag data with an example I had found. > However when it comes to authenticate/decrypt a tag with given AES key I > could not find examples. > using cmac.h or evp.h. > Can anybody help me please? CMAC is covered under EVP Signing and Verifying. See https://wiki.openssl.org/index.php/EVP_Signing_and_Verifying . Jeff From dnsands at sandia.gov Mon Jan 15 18:29:17 2018 From: dnsands at sandia.gov (Sands, Daniel) Date: Mon, 15 Jan 2018 18:29:17 +0000 Subject: [openssl-users] [EXTERNAL] Re: OpenSSL error message when decrypting Ethereum encrypted private key In-Reply-To: References: Message-ID: <1516040956.9330.9.camel@sandia.gov> On Sun, 2018-01-14 at 18:26 -0500, Chris B wrote: Hi Matt, >If you *are* using 1.1.0 then the default digest was changed between 1.0.2 and 1.1.0. Awesome thought, but I'm also using 1.0.2: $ openssl version OpenSSL 1.0.2k-fips 26 Jan 2017 (I also tried adding -md md5 to the previous command, but I got the same error message). Option #1 from the possibilities you mentioned below seems to be the most logical to me. If you use the wrong key, the padding data in the last block will also be decrypted to the wrong values, so the padding block check will fail. The padding is a necessary part of decryption because it needs to know how much plaintext is actually represented by that last block. > I'm not sure how to interpret that output. I could interpret it as: > o Your system for decrypting the password is perfect, but: this is not > the right password. > o There's something wrong with the EPK -- its length must be a multiple > of the AES block length. > o There's something wrong with the unencrypted private key -- its length > must be a multiple of the AES block length. > o Something else entirely -------------- next part -------------- An HTML attachment was scrubbed... URL: From cryptoassetrecovery at gmail.com Mon Jan 15 19:01:13 2018 From: cryptoassetrecovery at gmail.com (Chris B) Date: Mon, 15 Jan 2018 14:01:13 -0500 Subject: [openssl-users] [EXTERNAL] Re: OpenSSL error message when decrypting Ethereum encrypted private key In-Reply-To: <1516040956.9330.9.camel@sandia.gov> References: <1516040956.9330.9.camel@sandia.gov> Message-ID: Hi Daniel, >Option #1 from the possibilities you mentioned below seems to be the most logical to me. Thank you, that's very helpful. Thanks, Chris On Mon, Jan 15, 2018 at 1:29 PM, Sands, Daniel wrote: > On Sun, 2018-01-14 at 18:26 -0500, Chris B wrote: > > Hi Matt, > > >If you *are* using 1.1.0 then the default digest was changed between > 1.0.2 and 1.1.0. > Awesome thought, but I'm also using 1.0.2: > > $ openssl version > > OpenSSL 1.0.2k-fips 26 Jan 2017 > > (I also tried adding -md md5 to the previous command, but I got the same > error message). > > > Option #1 from the possibilities you mentioned below seems to be the most > logical to me. If you use the wrong key, the padding data in the last block > will also be decrypted to the wrong values, so the padding block check will > fail. The padding is a necessary part of decryption because it needs to > know how much plaintext is actually represented by that last block. > > > > I'm not sure how to interpret that output. I could interpret it as: > > o Your system for decrypting the password is perfect, but: this is not > > the right password. > > o There's something wrong with the EPK -- its length must be a multiple > > of the AES block length. > > o There's something wrong with the unencrypted private key -- its length > > must be a multiple of the AES block length. > > o Something else entirely > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From barati.j.prasad at gmail.com Tue Jan 16 04:14:15 2018 From: barati.j.prasad at gmail.com (Bharathi Prasad) Date: Mon, 15 Jan 2018 21:14:15 -0700 (MST) Subject: [openssl-users] How to enable Fixed Diffie Hellman key exchange mechanism In-Reply-To: References: <1515663341102-0.post@n7.nabble.com> <81F9E129-A05A-46E3-9974-633B2CD0F9F0@dukhovni.org> <1515740275252-0.post@n7.nabble.com> Message-ID: <1516076055379-0.post@n7.nabble.com> I understand your point and also agree with you. I am not in a position to explain the requirement. This is important and we need to provide the support. The system supports only DH and EDH. So could you please help me and give me pointers on how to implement fixed DH support. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From openssl-users at dukhovni.org Tue Jan 16 04:36:53 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 15 Jan 2018 23:36:53 -0500 Subject: [openssl-users] How to enable Fixed Diffie Hellman key exchange mechanism In-Reply-To: <1516076055379-0.post@n7.nabble.com> References: <1515663341102-0.post@n7.nabble.com> <81F9E129-A05A-46E3-9974-633B2CD0F9F0@dukhovni.org> <1515740275252-0.post@n7.nabble.com> <1516076055379-0.post@n7.nabble.com> Message-ID: <6C34E9C1-A99A-4AFB-824C-E4D5BC172CCC@dukhovni.org> > On Jan 15, 2018, at 11:14 PM, Bharathi Prasad wrote: > > I am not in a position to explain the requirement. This is important and we > need to provide the support. The system supports only DH and EDH. So could > you please help me and give me pointers on how to implement fixed DH > support. Are you sure the requirement is stated correctly? EDH is incompatible with fixed DH, with EDH you use RSA or ECDSA to authenticate the key exchange. As for using DH keys, they should just work, but you need to load the certificate before setting the private key, because the key type is ambiguous in the absence of the certificate, as there's a distinction between SSL_PKEY_DH_RSA and SSL_PKEY_DH_DSA, that is resolved by the certificate type. -- Viktor. From grace.priscilla at gmail.com Tue Jan 16 07:04:20 2018 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Tue, 16 Jan 2018 12:34:20 +0530 Subject: [openssl-users] Information to detach a BIO from fd In-Reply-To: <25525.1515879755@obiwan.sandelman.ca> References: <26570.1515675640@obiwan.sandelman.ca> <25525.1515879755@obiwan.sandelman.ca> Message-ID: Hi Michael, The connections are from different peers and we are unable to use same SSL. Also getpeername on the UDP does not work as we have enabled SSL for the sender peer socket. Any suggestions to resolve this? When we have 2 SSL associated to a fd through BIO, on which BIO does the openssl do the read? Can we restrict it to read from an SSL of user choice? We are just looking for an option to distinguish DTLS on UDP connections. We were'nt successful in doing it with DTLSv1_listen as it hangs on the SSL. Thanks, Grace On Sun, Jan 14, 2018 at 3:12 AM, Michael Richardson wrote: > > Grace Priscilla Jero wrote: > > Below is our scenario on DTLS. > > > We have multiple connections to the same server. We have mapped one > fd > > to the ssl in the server to receive all connections. > > Are these connections from the same client (same 5-tuple), or are you just > talking about multiple clients? > > > Whenever a connect is initiated from any client we need to know if it > > is already connected client or a new client. We are doing this by > > > * creating bio/ssl each time on the same fd > > > * fetching the peer using BIO_dgram_get_peer after ssl_accept > > > * Comparing it to the internally maintained list of peer > > > * If it is a new peer we continue with handshake but if it is old > peer > > we do the ssl_read. > > I don't think this is going to work. > > A UDP/DTLS server has two choices: > > 1) read all the packets on a unconnected socket and demultiplex them into > appropriate BIOs/SSL structures. I did not find an obvious way to do > this, I think that a new BIO type would make this easiest. > > It also has the downside that it's hard to spread the load across > multiple processes, although with the right locking multiple threads > would > likely work. > > 2) after each call to DTLSv1_listen(), set up a new fd that is > bind()/connect()ed to > the peer (by 5-tuple) so that all traffic from that peer arrives on the > correct FD. > AFAIK, there isn't anything to forbid two DTLS sessions between > identical > UDP sockets, as they could have differing session cookies, etc. > > > > The problem is that there are 2 bio/ssl that gets created for the > same > > fd and the peer end up writing to one of them and we don't get the > > message on the intended ssl. Hence we are checking for a way to > detach > > and remove the ssl/bio that gets created in already connected case. > > I don't think that is going to work. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From huy-cong.vu at wandercraft.eu Tue Jan 16 10:31:09 2018 From: huy-cong.vu at wandercraft.eu (Huy Cong Vu) Date: Tue, 16 Jan 2018 11:31:09 +0100 (CET) Subject: [openssl-users] Multiple reconnection in OpenSSL 1.1.0 Message-ID: <138033967.7809248.1516098669935.JavaMail.zimbra@wandercraft.eu> Hi everyone, Recently I have problem when trying to update my OpenSSL library from 1.0.1f to 1.1.0g. I have a server that runs 24/24 and receive connections from only 1 source, and 1 connection at a time, nothing really fancy, but it worked very well in OpenSSL 1.0.1f version. In 1.1.0g, the connection is establish and runs perfectly the 1st time. And the 2nd time the client try to connect, after the SSL connection is establish, SSL_read cannot return -1, and have no errors (checked with SSL_get_errors...) My server runs on Linux 14.04, while my client runs on Windows 7, both with OpenSSL 1.1.0. If anyone have an idea what happened, I would be glad to know, please tell me if you need any details. Here the principal code snipset (I don't have the certificate verification code snip here, but it was there, and it always works so I guess there no point repost it now): + Some initial configurations: SSL_CTX* ctx_in; const SSL_METHOD *method; OpenSSL_add_all_algorithms(); SSL_load_error_strings(); method = TLS_server_method(); ctx_in = SSL_CTX_new(method); //Setup trusted certs & list of clients CA SSL_CTX_set_verify(ctx_in, SSL_VERIFY_PEER, NULL); SSL_CTX_set_verify_depth(ctx_in, 1); //our certificate chain contain only 1 more root CA //Load issuer certificate from memory X509_STORE* store = SSL_CTX_get_cert_store(ctx_in); X509_STORE_add_cert(store, certinMem(caVerifClientReal); SSL_CTX_set_client_CA_list(ctx_in, NULL); SSL_CTX_add_client_CA(ctx_in, certinMem(pubClientReal)); //Setup curves parameters EC_KEY *ecdh = EC_KEY_new_by_curve_name (NID_X9_62_prime256v1); SSL_CTX_set_tmp_ecdh (ctx_in, ecdh); EC_KEY_free(ecdh); //Set options SSL_CTX_set_options(ctx_in, SSL_OP_SINGLE_ECDH_USE && SSL_MODE_AUTO_RETRY); ... + Main loop: char buf[1024]; struct sockaddr_in addr; //client socklen_t len = sizeof(addr); while (1) { //initialize buffer buf[0] = '\0'; int client = accept(server, reinterpret_cast(&addr), &len); if (-1 != client) { //set SSL security const char* const PREFERRED_CIPHERS = "ECDHE-RSA-AES256-SHA"; //define cipher suite used for SSL connection SSL_set_cipher_list(ssl, PREFERRED_CIPHERS); //set SSL socket SSL_set_fd(ssl, client); /* set connection socket to SSL state */ if (SSL_accept(ssl) == FAIL) //waits for a client to initiate the handshake {/* do SSL-protocol accept */ ERR_print_errors_fp(stderr); } else { verifCerts(ssl); int ret = -1; ret = SSL_do_handshake(ssl); //check connection if (ret <= 0) { ERR_print_errors_fp(stderr); } else { //wait on buffer int bytes = SSL_read(ssl, buf, sizeof(buf)); //here bytes return -1, and there is no error with SSL_get_errors } } sd = SSL_get_fd(ssl); /* get socket connection */ close(sd); /* close connection */ } Huy-Cong VU Platform hardware member Network administrator Wandercraft 09 72 58 77 03 From matt at openssl.org Tue Jan 16 11:04:45 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 16 Jan 2018 11:04:45 +0000 Subject: [openssl-users] Multiple reconnection in OpenSSL 1.1.0 In-Reply-To: <138033967.7809248.1516098669935.JavaMail.zimbra@wandercraft.eu> References: <138033967.7809248.1516098669935.JavaMail.zimbra@wandercraft.eu> Message-ID: On 16/01/18 10:31, Huy Cong Vu wrote: > OpenSSL_add_all_algorithms(); > SSL_load_error_strings(); You do not need to make the above two calls in 1.1.0. They are called automatically. > //Setup curves parameters > EC_KEY *ecdh = EC_KEY_new_by_curve_name (NID_X9_62_prime256v1); > SSL_CTX_set_tmp_ecdh (ctx_in, ecdh); > EC_KEY_free(ecdh); You do not need to do this in 1.1.0. Curve parameters are set up automatically. > > //Set options > SSL_CTX_set_options(ctx_in, SSL_OP_SINGLE_ECDH_USE && SSL_MODE_AUTO_RETRY); You are using logical && here instead of boolean |. This will mean that these options are not correctly set. In any case SSL_OP_SINGLE_ECDH_USE is not needed and is unused in 1.1.0 (it has the value 0). This is the default (and only) mode of operation any way for 1.1.0. > //wait on buffer > int bytes = SSL_read(ssl, buf, sizeof(buf)); > //here bytes return -1, and there is no error with SSL_get_errors Try calling ERR_print_errors_fp() here to see if you get any clues. Matt From wouter.verhelst at bosa.fgov.be Tue Jan 16 09:26:25 2018 From: wouter.verhelst at bosa.fgov.be (Wouter Verhelst) Date: Tue, 16 Jan 2018 10:26:25 +0100 Subject: [openssl-users] SSL Cert serial number non-uniqueness impact In-Reply-To: References: Message-ID: <15e000de-d0f2-babe-fa3e-9517be61ceb4@bosa.fgov.be> On 14/01/2018 12:07, pratyush parimal wrote: > Hi everyone, > > I read? from several sources that the serial number of a cert MUST be > unique within a CA. But could someone explain what would happen if the > serial number was not unique? The certificate itself will continue to work (the signature will be valid), but requesting status on the certificate (e.g., through OCSP or by doing a lookup in a CRL) will not work as expected as those use the serial number as an identifier. > Would it cause SSL connections to fail in some manner? No, but if the peer wants to request information on the used certificate from the CA to verify whether the certificate is still valid, it may end up receiving information about the wrong certificate. From hirgauandrei at gmail.com Tue Jan 16 13:11:52 2018 From: hirgauandrei at gmail.com (=?UTF-8?B?QW5kcmVpIEjDrnJnxIN1?=) Date: Tue, 16 Jan 2018 13:11:52 +0000 Subject: [openssl-users] Calling CMS_decrypt on the same CMS_ContentInfo instance as CMS_encrypt causes memory leak Message-ID: Hi, There seems to be an issue with CMS_decrypt. It seems that if we have code like this: CMS_ContentInfo* ci = CMS_encrypt(...); CMS_decrypt(ci, ...); CMS_ContentInfo_free(ci); we leak the X509 certificate's public key. If the call to CMS_decrypt is commented out, then no leak happens, as the key is freed by the call to CMS_ContentInfo_free. I created this issue[1] with a concrete example of this case. Is the expectation here that if you call CMS_decrypt on the same CMS_ContentInfo instance then you have to call EVP_PKEY_free on the public key twice? Does anyone have any thoughts on this? [1] https://github.com/openssl/openssl/issues/5052 From huy-cong.vu at wandercraft.eu Tue Jan 16 13:35:09 2018 From: huy-cong.vu at wandercraft.eu (Huy Cong Vu) Date: Tue, 16 Jan 2018 14:35:09 +0100 (CET) Subject: [openssl-users] Multiple reconnection in OpenSSL 1.1.0 In-Reply-To: References: <138033967.7809248.1516098669935.JavaMail.zimbra@wandercraft.eu> Message-ID: <46720088.8039284.1516109709660.JavaMail.zimbra@wandercraft.eu> On 16/01/18 10:31, Huy Cong Vu wrote: > OpenSSL_add_all_algorithms(); > SSL_load_error_strings(); You do not need to make the above two calls in 1.1.0. They are called automatically. > //Setup curves parameters > EC_KEY *ecdh = EC_KEY_new_by_curve_name (NID_X9_62_prime256v1); > SSL_CTX_set_tmp_ecdh (ctx_in, ecdh); > EC_KEY_free(ecdh); You do not need to do this in 1.1.0. Curve parameters are set up automatically. > > //Set options > SSL_CTX_set_options(ctx_in, SSL_OP_SINGLE_ECDH_USE && SSL_MODE_AUTO_RETRY); You are using logical && here instead of boolean |. This will mean that these options are not correctly set. In any case SSL_OP_SINGLE_ECDH_USE is not needed and is unused in 1.1.0 (it has the value 0). This is the default (and only) mode of operation any way for 1.1.0. > //wait on buffer > int bytes = SSL_read(ssl, buf, sizeof(buf)); > //here bytes return -1, and there is no error with SSL_get_errors Try calling ERR_print_errors_fp() here to see if you get any clues. Thanks for the advice, I got these as error: 1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:210 1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac:ssl/record/ssl3_record.c:375 Does it means my configuration is not correct, or not synchronized between client and server? Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From matt at openssl.org Tue Jan 16 13:57:28 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 16 Jan 2018 13:57:28 +0000 Subject: [openssl-users] Multiple reconnection in OpenSSL 1.1.0 In-Reply-To: <46720088.8039284.1516109709660.JavaMail.zimbra@wandercraft.eu> References: <138033967.7809248.1516098669935.JavaMail.zimbra@wandercraft.eu> <46720088.8039284.1516109709660.JavaMail.zimbra@wandercraft.eu> Message-ID: <7ee19a3a-f53c-b76d-6a6f-5ca925681196@openssl.org> On 16/01/18 13:35, Huy Cong Vu wrote: > Thanks for the advice, I got these as error: > 1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:210 > 1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac:ssl/record/ssl3_record.c:375 > > Does it means my configuration is not correct, or not synchronized between client and server? It means the data OpenSSL is trying to read looks incorrectly formatted. This should never normally happen with two correctly working endpoints. The first error will normally immediately result in an alert being sent and the function call failing - meaning that you'd never get to hit the second error. I can't see a way of getting both those errors in a single function call - which might suggest some earlier function call has failed and the error message is still on the error queue when you call SSL_read(). A couple of things to try: - Try calling ERR_print_errors_fp() *before* the call to SSL_read() as well, to verify there are no errors already in the queue - A wireshark trace of the communication between the two endpoints might be helpful to figure out what is going wrong Matt From sauldickinson at gmail.com Tue Jan 16 14:39:31 2018 From: sauldickinson at gmail.com (Saul Dickinson) Date: Tue, 16 Jan 2018 15:39:31 +0100 Subject: [openssl-users] Next LTS version Message-ID: Hi, Is there any more recent information available concerning the release strategy for future LTS versions (than the one on the website dated 6th September 2016)? Will 1.2.0 be the next LTS version? Or is this maybe dependent on the finalisation date for TLS 1.3? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Jan 16 14:47:43 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 16 Jan 2018 14:47:43 +0000 Subject: [openssl-users] Next LTS version In-Reply-To: References: Message-ID: <8FED46AF-1A5F-4BAE-BA4A-20ED5EBA3D04@akamai.com> We have had some discussions within the team about LTS, and there?s nothing to say yet. From: Saul Dickinson Reply-To: "sauldickinson at gmail.com" , openssl-users Date: Tuesday, January 16, 2018 at 9:39 AM To: openssl-users Subject: [openssl-users] Next LTS version Hi, Is there any more recent information available concerning the release strategy for future LTS versions (than the one on the website dated 6th September 2016)? Will 1.2.0 be the next LTS version? Or is this maybe dependent on the finalisation date for TLS 1.3? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From huy-cong.vu at wandercraft.eu Tue Jan 16 15:15:14 2018 From: huy-cong.vu at wandercraft.eu (Huy Cong Vu) Date: Tue, 16 Jan 2018 16:15:14 +0100 (CET) Subject: [openssl-users] Multiple reconnection in OpenSSL 1.1.0 In-Reply-To: <7ee19a3a-f53c-b76d-6a6f-5ca925681196@openssl.org> References: <138033967.7809248.1516098669935.JavaMail.zimbra@wandercraft.eu> <46720088.8039284.1516109709660.JavaMail.zimbra@wandercraft.eu> <7ee19a3a-f53c-b76d-6a6f-5ca925681196@openssl.org> Message-ID: <955888915.8171800.1516115714054.JavaMail.zimbra@wandercraft.eu> ----- Mail original ----- > De: "Matt Caswell" > ?: "openssl-users" > Envoy?: Mardi 16 Janvier 2018 14:57:28 > Objet: Re: [openssl-users] Multiple reconnection in OpenSSL 1.1.0 > On 16/01/18 13:35, Huy Cong Vu wrote: >> Thanks for the advice, I got these as error: >> 1408F10B:SSL routines:ssl3_get_record:wrong version >> number:ssl/record/ssl3_record.c:210 >> 1408F119:SSL routines:ssl3_get_record:decryption failed or bad record >> mac:ssl/record/ssl3_record.c:375 >> >> Does it means my configuration is not correct, or not synchronized between >> client and server? > > It means the data OpenSSL is trying to read looks incorrectly formatted. > This should never normally happen with two correctly working endpoints. > The first error will normally immediately result in an alert being sent > and the function call failing - meaning that you'd never get to hit the > second error. I can't see a way of getting both those errors in a single > function call - which might suggest some earlier function call has > failed and the error message is still on the error queue when you call > SSL_read(). They are not generated in a single function call. Sorry, I wans't clear. Like I said, I have a main loop of server that receive requests (once at a time) from the same client. The 1st connection is correct, as always, and all the later connections give one of these 2 errors. > > A couple of things to try: > > - Try calling ERR_print_errors_fp() *before* the call to SSL_read() as > well, to verify there are no errors already in the queue > - A wireshark trace of the communication between the two endpoints might > be helpful to figure out what is going wrong ERR_print_errors_fp() before call of SSL_read returns nothing, which should be a good new... By browsing Wireshark, I jump into a suspect packet from client that contains a RST flags after 1st connection: 797 61.057009 192.168.1.4 192.168.1.121 TCP 54 63862 ? 8042 [RST, ACK] Seq=3969 Ack=4619 Win=0 Len=0 Does this help? > > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users Huy-Cong VU Platform hardware member Network administrator Wandercraft 09 72 58 77 03 From matt at openssl.org Tue Jan 16 15:17:47 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 16 Jan 2018 15:17:47 +0000 Subject: [openssl-users] Multiple reconnection in OpenSSL 1.1.0 In-Reply-To: <955888915.8171800.1516115714054.JavaMail.zimbra@wandercraft.eu> References: <138033967.7809248.1516098669935.JavaMail.zimbra@wandercraft.eu> <46720088.8039284.1516109709660.JavaMail.zimbra@wandercraft.eu> <7ee19a3a-f53c-b76d-6a6f-5ca925681196@openssl.org> <955888915.8171800.1516115714054.JavaMail.zimbra@wandercraft.eu> Message-ID: <757e9c8c-b4db-cc95-1189-d8c18a5d0ef5@openssl.org> On 16/01/18 15:15, Huy Cong Vu wrote: >> - A wireshark trace of the communication between the two endpoints might >> be helpful to figure out what is going wrong > > ERR_print_errors_fp() before call of SSL_read returns nothing, which should be a good new... > By browsing Wireshark, I jump into a suspect packet from client that contains a RST flags after 1st connection: > 797 61.057009 192.168.1.4 192.168.1.121 TCP 54 63862 ? 8042 [RST, ACK] Seq=3969 Ack=4619 Win=0 Len=0 > > Does this help? Please can you attach the actual trace? Or send it direct to me if it is large. Thanks Matt From huy-cong.vu at wandercraft.eu Tue Jan 16 15:27:27 2018 From: huy-cong.vu at wandercraft.eu (Huy Cong Vu) Date: Tue, 16 Jan 2018 16:27:27 +0100 (CET) Subject: [openssl-users] Multiple reconnection in OpenSSL 1.1.0 In-Reply-To: <757e9c8c-b4db-cc95-1189-d8c18a5d0ef5@openssl.org> References: <138033967.7809248.1516098669935.JavaMail.zimbra@wandercraft.eu> <46720088.8039284.1516109709660.JavaMail.zimbra@wandercraft.eu> <7ee19a3a-f53c-b76d-6a6f-5ca925681196@openssl.org> <955888915.8171800.1516115714054.JavaMail.zimbra@wandercraft.eu> <757e9c8c-b4db-cc95-1189-d8c18a5d0ef5@openssl.org> Message-ID: <1494878272.8186281.1516116447649.JavaMail.zimbra@wandercraft.eu> Huy-Cong VU Platform hardware member Network administrator Wandercraft 09 72 58 77 03 ----- Mail original ----- > De: "Matt Caswell" > ?: "openssl-users" > Envoy?: Mardi 16 Janvier 2018 16:17:47 > Objet: Re: [openssl-users] Multiple reconnection in OpenSSL 1.1.0 > On 16/01/18 15:15, Huy Cong Vu wrote: >>> - A wireshark trace of the communication between the two endpoints might >>> be helpful to figure out what is going wrong >> >> ERR_print_errors_fp() before call of SSL_read returns nothing, which should be a >> good new... >> By browsing Wireshark, I jump into a suspect packet from client that contains a >> RST flags after 1st connection: >> 797 61.057009 192.168.1.4 192.168.1.121 TCP 54 63862 ? 8042 [RST, ACK] Seq=3969 >> Ack=4619 Win=0 Len=0 >> >> Does this help? > > Please can you attach the actual trace? Or send it direct to me if it is > large. Here is any traffic transfer between my clients and server from the beginning to the 1st failed SSL_read(): https://pastebin.com/raw/Bjixearh IP src: 192.168.1.4 IP dest: 192.168.1.121 I'm not sure the version I pasted have enough informations, if you want more, please show me how to do it in Wireshark. Thanks a lot > > Thanks > > Matt > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From matt at openssl.org Tue Jan 16 15:58:11 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 16 Jan 2018 15:58:11 +0000 Subject: [openssl-users] Multiple reconnection in OpenSSL 1.1.0 In-Reply-To: <1494878272.8186281.1516116447649.JavaMail.zimbra@wandercraft.eu> References: <138033967.7809248.1516098669935.JavaMail.zimbra@wandercraft.eu> <46720088.8039284.1516109709660.JavaMail.zimbra@wandercraft.eu> <7ee19a3a-f53c-b76d-6a6f-5ca925681196@openssl.org> <955888915.8171800.1516115714054.JavaMail.zimbra@wandercraft.eu> <757e9c8c-b4db-cc95-1189-d8c18a5d0ef5@openssl.org> <1494878272.8186281.1516116447649.JavaMail.zimbra@wandercraft.eu> Message-ID: <8c631555-5bf5-1e10-9c6d-81cb0c6f3b35@openssl.org> On 16/01/18 15:27, Huy Cong Vu wrote: > Here is any traffic transfer between my clients and server from the beginning to the 1st failed SSL_read(): > https://pastebin.com/raw/Bjixearh > > IP src: 192.168.1.4 > IP dest: 192.168.1.121 > > I'm not sure the version I pasted have enough informations, if you want more, please show me how to do it in Wireshark. It's difficult to read in that form - but enough I think. Most of this trace shows a "normal" connection and transfer of application data. The client (192.168.1.4:63862) connects to the server (192.168.1.121:8042) and sends its ClientHello. There then follows a client-auth handshake (both sides exchange Certificates) and TLSv1.2 is negotiated. The client and server then exchange a number of encrypted application data records. After a while we see the first connection being torn down: No. Time Source Destination Protocol Length Info 796 61.056981 192.168.1.121 192.168.1.4 TCP 60 8042 ? 63862 [FIN, ACK] Seq=4619 Ack=3969 Win=39936 Len=0 Frame 796: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0 Ethernet II, Src: PcsCompu_44:b5:3d (08:00:27:44:b5:3d), Dst: Micro-St_57:60:85 (d4:3d:7e:57:60:85) Destination: Micro-St_57:60:85 (d4:3d:7e:57:60:85) Source: PcsCompu_44:b5:3d (08:00:27:44:b5:3d) Type: IPv4 (0x0800) Padding: 000000000000 Internet Protocol Version 4, Src: 192.168.1.121, Dst: 192.168.1.4 Transmission Control Protocol, Src Port: 8042, Dst Port: 63862, Seq: 4619, Ack: 3969, Len: 0 No. Time Source Destination Protocol Length Info 797 61.057009 192.168.1.4 192.168.1.121 TCP 54 63862 ? 8042 [RST, ACK] Seq=3969 Ack=4619 Win=0 Len=0 Frame 797: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) on interface 0 Ethernet II, Src: Micro-St_57:60:85 (d4:3d:7e:57:60:85), Dst: PcsCompu_44:b5:3d (08:00:27:44:b5:3d) Destination: PcsCompu_44:b5:3d (08:00:27:44:b5:3d) Source: Micro-St_57:60:85 (d4:3d:7e:57:60:85) Type: IPv4 (0x0800) Internet Protocol Version 4, Src: 192.168.1.4, Dst: 192.168.1.121 Transmission Control Protocol, Src Port: 63862, Dst Port: 8042, Seq: 3969, Ack: 4619, Len: 0 Next we see a new TLS connection being established and an unencrypted ClientHello coming in (from a different port - 63868): Frame 1107: 172 bytes on wire (1376 bits), 172 bytes captured (1376 bits) on interface 0 Ethernet II, Src: Micro-St_57:60:85 (d4:3d:7e:57:60:85), Dst: PcsCompu_44:b5:3d (08:00:27:44:b5:3d) Destination: PcsCompu_44:b5:3d (08:00:27:44:b5:3d) Source: Micro-St_57:60:85 (d4:3d:7e:57:60:85) Type: IPv4 (0x0800) Internet Protocol Version 4, Src: 192.168.1.4, Dst: 192.168.1.121 Transmission Control Protocol, Src Port: 63868, Dst Port: 8042, Seq: 1, Ack: 1, Len: 118 Data (118 bytes) 0000 16 03 01 00 71 01 00 00 6d 03 03 c0 57 4d fc 23 ....q...m...WM.# 0010 5b 02 67 2c 02 ae 59 f1 40 e8 29 5d 29 aa c8 bf [.g,..Y. at .)])... 0020 41 4b 14 a2 26 08 e7 c1 91 40 c2 00 00 04 c0 14 AK..&.... at ...... 0030 00 ff 01 00 00 40 00 0b 00 04 03 00 01 02 00 0a ..... at .......... 0040 00 04 00 02 00 17 00 23 00 00 00 16 00 00 00 17 .......#........ 0050 00 00 00 0d 00 20 00 1e 06 01 06 02 06 03 05 01 ..... .......... 0060 05 02 05 03 04 01 04 02 04 03 03 01 03 02 03 03 ................ 0070 02 01 02 02 02 03 But the server responds with this: Frame 1109: 111 bytes on wire (888 bits), 111 bytes captured (888 bits) on interface 0 Ethernet II, Src: PcsCompu_44:b5:3d (08:00:27:44:b5:3d), Dst: Micro-St_57:60:85 (d4:3d:7e:57:60:85) Destination: Micro-St_57:60:85 (d4:3d:7e:57:60:85) Source: PcsCompu_44:b5:3d (08:00:27:44:b5:3d) Type: IPv4 (0x0800) Internet Protocol Version 4, Src: 192.168.1.121, Dst: 192.168.1.4 Transmission Control Protocol, Src Port: 8042, Dst Port: 63868, Seq: 1, Ack: 119, Len: 57 Data (57 bytes) 0000 15 03 03 00 34 a0 b5 dc 18 cb e2 21 8b 97 6d 9d ....4......!..m. 0010 48 d0 e4 81 09 c2 1b b4 8c 2e 90 59 11 f7 f7 e8 H..........Y.... 0020 86 7b 1a 81 b9 f5 37 7b b7 00 f4 bb 4a 93 8c 9a .{....7{....J... 0030 52 9f 1e 56 a9 6c 18 ca 66 R..V.l..f The hex 15 at the beginning tells us that this is an alert message. It is for TLSv1.2 (03 03) and a length of 52 decimal bytes == 00 34 hex. This is wrong! An unencrypted alert always has a length of 2 bytes - which means this is an *encrypted* alert!! The server should not be encrypting anything at this stage in the handshake. It looks to me like the server is confused and thinks it is still talking to the first client. Did you reuse the SSL object from one connection to the next? Your code sample looks like maybe you did. Don't do that! Create a new SSL object for each connection. Or if you *must* reuse the SSL object (I can't think why) then call SSL_clear() on it. Matt From huy-cong.vu at wandercraft.eu Tue Jan 16 16:22:33 2018 From: huy-cong.vu at wandercraft.eu (Huy Cong Vu) Date: Tue, 16 Jan 2018 17:22:33 +0100 (CET) Subject: [openssl-users] Multiple reconnection in OpenSSL 1.1.0 In-Reply-To: <8c631555-5bf5-1e10-9c6d-81cb0c6f3b35@openssl.org> References: <138033967.7809248.1516098669935.JavaMail.zimbra@wandercraft.eu> <46720088.8039284.1516109709660.JavaMail.zimbra@wandercraft.eu> <7ee19a3a-f53c-b76d-6a6f-5ca925681196@openssl.org> <955888915.8171800.1516115714054.JavaMail.zimbra@wandercraft.eu> <757e9c8c-b4db-cc95-1189-d8c18a5d0ef5@openssl.org> <1494878272.8186281.1516116447649.JavaMail.zimbra@wandercraft.eu> <8c631555-5bf5-1e10-9c6d-81cb0c6f3b35@openssl.org> Message-ID: <1247193521.8240430.1516119753361.JavaMail.zimbra@wandercraft.eu> ----- Mail original ----- > De: "Matt Caswell" > ?: "openssl-users" > Envoy?: Mardi 16 Janvier 2018 16:58:11 > Objet: Re: [openssl-users] Multiple reconnection in OpenSSL 1.1.0 > On 16/01/18 15:27, Huy Cong Vu wrote: >> Here is any traffic transfer between my clients and server from the beginning to >> the 1st failed SSL_read(): >> https://pastebin.com/raw/Bjixearh >> >> IP src: 192.168.1.4 >> IP dest: 192.168.1.121 >> >> I'm not sure the version I pasted have enough informations, if you want more, >> please show me how to do it in Wireshark. > > It's difficult to read in that form - but enough I think. > > Most of this trace shows a "normal" connection and transfer of > application data. The client (192.168.1.4:63862) connects to the server > (192.168.1.121:8042) and sends its ClientHello. There then follows a > client-auth handshake (both sides exchange Certificates) and TLSv1.2 is > negotiated. The client and server then exchange a number of encrypted > application data records. > > After a while we see the first connection being torn down: > > No. Time Source Destination > Protocol Length Info > 796 61.056981 192.168.1.121 192.168.1.4 TCP > 60 8042 ? 63862 [FIN, ACK] Seq=4619 Ack=3969 Win=39936 Len=0 > > Frame 796: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on > interface 0 > Ethernet II, Src: PcsCompu_44:b5:3d (08:00:27:44:b5:3d), Dst: > Micro-St_57:60:85 (d4:3d:7e:57:60:85) > Destination: Micro-St_57:60:85 (d4:3d:7e:57:60:85) > Source: PcsCompu_44:b5:3d (08:00:27:44:b5:3d) > Type: IPv4 (0x0800) > Padding: 000000000000 > Internet Protocol Version 4, Src: 192.168.1.121, Dst: 192.168.1.4 > Transmission Control Protocol, Src Port: 8042, Dst Port: 63862, Seq: > 4619, Ack: 3969, Len: 0 > > No. Time Source Destination > Protocol Length Info > 797 61.057009 192.168.1.4 192.168.1.121 TCP > 54 63862 ? 8042 [RST, ACK] Seq=3969 Ack=4619 Win=0 Len=0 > > Frame 797: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) on > interface 0 > Ethernet II, Src: Micro-St_57:60:85 (d4:3d:7e:57:60:85), Dst: > PcsCompu_44:b5:3d (08:00:27:44:b5:3d) > Destination: PcsCompu_44:b5:3d (08:00:27:44:b5:3d) > Source: Micro-St_57:60:85 (d4:3d:7e:57:60:85) > Type: IPv4 (0x0800) > Internet Protocol Version 4, Src: 192.168.1.4, Dst: 192.168.1.121 > Transmission Control Protocol, Src Port: 63862, Dst Port: 8042, Seq: > 3969, Ack: 4619, Len: 0 > > > Next we see a new TLS connection being established and an unencrypted > ClientHello coming in (from a different port - 63868): > > Frame 1107: 172 bytes on wire (1376 bits), 172 bytes captured (1376 > bits) on interface 0 > Ethernet II, Src: Micro-St_57:60:85 (d4:3d:7e:57:60:85), Dst: > PcsCompu_44:b5:3d (08:00:27:44:b5:3d) > Destination: PcsCompu_44:b5:3d (08:00:27:44:b5:3d) > Source: Micro-St_57:60:85 (d4:3d:7e:57:60:85) > Type: IPv4 (0x0800) > Internet Protocol Version 4, Src: 192.168.1.4, Dst: 192.168.1.121 > Transmission Control Protocol, Src Port: 63868, Dst Port: 8042, Seq: 1, > Ack: 1, Len: 118 > Data (118 bytes) > > 0000 16 03 01 00 71 01 00 00 6d 03 03 c0 57 4d fc 23 ....q...m...WM.# > 0010 5b 02 67 2c 02 ae 59 f1 40 e8 29 5d 29 aa c8 bf [.g,..Y. at .)])... > 0020 41 4b 14 a2 26 08 e7 c1 91 40 c2 00 00 04 c0 14 AK..&.... at ...... > 0030 00 ff 01 00 00 40 00 0b 00 04 03 00 01 02 00 0a ..... at .......... > 0040 00 04 00 02 00 17 00 23 00 00 00 16 00 00 00 17 .......#........ > 0050 00 00 00 0d 00 20 00 1e 06 01 06 02 06 03 05 01 ..... .......... > 0060 05 02 05 03 04 01 04 02 04 03 03 01 03 02 03 03 ................ > 0070 02 01 02 02 02 03 > > > But the server responds with this: > > Frame 1109: 111 bytes on wire (888 bits), 111 bytes captured (888 bits) > on interface 0 > Ethernet II, Src: PcsCompu_44:b5:3d (08:00:27:44:b5:3d), Dst: > Micro-St_57:60:85 (d4:3d:7e:57:60:85) > Destination: Micro-St_57:60:85 (d4:3d:7e:57:60:85) > Source: PcsCompu_44:b5:3d (08:00:27:44:b5:3d) > Type: IPv4 (0x0800) > Internet Protocol Version 4, Src: 192.168.1.121, Dst: 192.168.1.4 > Transmission Control Protocol, Src Port: 8042, Dst Port: 63868, Seq: 1, > Ack: 119, Len: 57 > Data (57 bytes) > > 0000 15 03 03 00 34 a0 b5 dc 18 cb e2 21 8b 97 6d 9d ....4......!..m. > 0010 48 d0 e4 81 09 c2 1b b4 8c 2e 90 59 11 f7 f7 e8 H..........Y.... > 0020 86 7b 1a 81 b9 f5 37 7b b7 00 f4 bb 4a 93 8c 9a .{....7{....J... > 0030 52 9f 1e 56 a9 6c 18 ca 66 R..V.l..f > > The hex 15 at the beginning tells us that this is an alert message. It > is for TLSv1.2 (03 03) and a length of 52 decimal bytes == 00 34 hex. > > This is wrong! An unencrypted alert always has a length of 2 bytes - > which means this is an *encrypted* alert!! The server should not be > encrypting anything at this stage in the handshake. > > It looks to me like the server is confused and thinks it is still > talking to the first client. Did you reuse the SSL object from one > connection to the next? Your code sample looks like maybe you did. Don't > do that! Create a new SSL object for each connection. Or if you *must* > reuse the SSL object (I can't think why) then call SSL_clear() on it. Ok the call for SSL_clear() apparently works. Thanks a lot. To make the code clean, I will re-instantiate SSL object for each connection. I do not have any specific reasons to keep SSL object alive after each connection. It just that I do not want to re-inialize the context. In the old version, it works very well without it.... > > Matt > > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From matt at openssl.org Tue Jan 16 16:49:02 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 16 Jan 2018 16:49:02 +0000 Subject: [openssl-users] Multiple reconnection in OpenSSL 1.1.0 In-Reply-To: <1247193521.8240430.1516119753361.JavaMail.zimbra@wandercraft.eu> References: <138033967.7809248.1516098669935.JavaMail.zimbra@wandercraft.eu> <46720088.8039284.1516109709660.JavaMail.zimbra@wandercraft.eu> <7ee19a3a-f53c-b76d-6a6f-5ca925681196@openssl.org> <955888915.8171800.1516115714054.JavaMail.zimbra@wandercraft.eu> <757e9c8c-b4db-cc95-1189-d8c18a5d0ef5@openssl.org> <1494878272.8186281.1516116447649.JavaMail.zimbra@wandercraft.eu> <8c631555-5bf5-1e10-9c6d-81cb0c6f3b35@openssl.org> <1247193521.8240430.1516119753361.JavaMail.zimbra@wandercraft.eu> Message-ID: <63dbb29a-4d83-127a-3907-f6e7d0a86690@openssl.org> On 16/01/18 16:22, Huy Cong Vu wrote: > Ok the call for SSL_clear() apparently works. Thanks a lot. > To make the code clean, I will re-instantiate SSL object for each connection. I do not have any specific reasons to keep SSL object alive after each connection. It just that I do not want to re-inialize the context. In the old version, it works very well without it.... Interesting. There has been no change in the API in this regards. You have never been "allowed" to reuse an SSL object without first calling SSL_clear() - that's the whole point of that function (and its been around since forever). It sounds like you were "lucky" before :-) Matt From aerowolf at gmail.com Tue Jan 16 17:16:08 2018 From: aerowolf at gmail.com (Kyle Hamilton) Date: Tue, 16 Jan 2018 09:16:08 -0800 Subject: [openssl-users] SSL Cert serial number non-uniqueness impact In-Reply-To: <15e000de-d0f2-babe-fa3e-9517be61ceb4@bosa.fgov.be> References: <15e000de-d0f2-babe-fa3e-9517be61ceb4@bosa.fgov.be> Message-ID: It's important to note that NSS-based applications (such as Firefox) will actually categorically refuse to connect to a site with an Issuer/serial collision with another certificate it has seen before. So yes, it can cause some applications to fail their SSL connections. -Kyle H On Tue, Jan 16, 2018 at 1:26 AM, Wouter Verhelst wrote: > On 14/01/2018 12:07, pratyush parimal wrote: >> Hi everyone, >> >> I read from several sources that the serial number of a cert MUST be >> unique within a CA. But could someone explain what would happen if the >> serial number was not unique? > > The certificate itself will continue to work (the signature will be > valid), but requesting status on the certificate (e.g., through OCSP or > by doing a lookup in a CRL) will not work as expected as those use the > serial number as an identifier. > >> Would it cause SSL connections to fail in some manner? > No, but if the peer wants to request information on the used certificate > from the CA to verify whether the certificate is still valid, it may end > up receiving information about the wrong certificate. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From sauldickinson at gmail.com Wed Jan 17 09:27:17 2018 From: sauldickinson at gmail.com (Saul Dickinson) Date: Wed, 17 Jan 2018 10:27:17 +0100 Subject: [openssl-users] Next LTS version In-Reply-To: <8FED46AF-1A5F-4BAE-BA4A-20ED5EBA3D04@akamai.com> References: <8FED46AF-1A5F-4BAE-BA4A-20ED5EBA3D04@akamai.com> Message-ID: Thanks Rich. That means there's not even any indication of when there might be something to say? Even just an indication of when the decision might be taken would be helpful at this stage. On 16 January 2018 at 15:47, Salz, Rich wrote: > We have had some discussions within the team about LTS, and there?s > nothing to say yet. > > > > *From: *Saul Dickinson > *Reply-To: *"sauldickinson at gmail.com" , > openssl-users > *Date: *Tuesday, January 16, 2018 at 9:39 AM > *To: *openssl-users > *Subject: *[openssl-users] Next LTS version > > > > Hi, > > Is there any more recent information available concerning the release > strategy for future LTS versions (than the one on the website dated 6th > September 2016)? > > Will 1.2.0 be the next LTS version? Or is this maybe dependent on the > finalisation date for TLS 1.3? > > > > Thanks. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Jan 17 09:57:58 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 17 Jan 2018 09:57:58 +0000 Subject: [openssl-users] Next LTS version In-Reply-To: References: <8FED46AF-1A5F-4BAE-BA4A-20ED5EBA3D04@akamai.com> Message-ID: On 17/01/18 09:27, Saul Dickinson wrote: > Thanks Rich. That means there's not even any indication of when there > might be something to say? > > Even just an indication of when the decision might be taken would be > helpful at this stage. We are committed to specifying a release as LTS at least every four years. We released 1.0.2 on 22nd January 2015. So basically by this time next year we will have specified a new LTS. I hope we will have made that decision a lot earlier than that but can't give you a timeframe at the moment. Matt > > On 16 January 2018 at 15:47, Salz, Rich > wrote: > > We have had some discussions within the team about LTS, and there?s > nothing to say yet.____ > > __?__ > > *From: *Saul Dickinson > > *Reply-To: *"sauldickinson at gmail.com > " >, openssl-users > > > *Date: *Tuesday, January 16, 2018 at 9:39 AM > *To: *openssl-users > > *Subject: *[openssl-users] Next LTS version____ > > __?__ > > Hi,____ > > Is there any more recent information available concerning the > release strategy for future LTS versions (than the one on the > website dated 6th September 2016)?____ > > Will 1.2.0 be the next LTS version? Or is this maybe dependent on > the finalisation date for TLS 1.3?____ > > __?__ > > Thanks. ____ > > __?__ > > > > From huy-cong.vu at wandercraft.eu Wed Jan 17 11:23:21 2018 From: huy-cong.vu at wandercraft.eu (Huy Cong Vu) Date: Wed, 17 Jan 2018 12:23:21 +0100 (CET) Subject: [openssl-users] Multiple reconnection in OpenSSL 1.1.0 In-Reply-To: <63dbb29a-4d83-127a-3907-f6e7d0a86690@openssl.org> References: <138033967.7809248.1516098669935.JavaMail.zimbra@wandercraft.eu> <7ee19a3a-f53c-b76d-6a6f-5ca925681196@openssl.org> <955888915.8171800.1516115714054.JavaMail.zimbra@wandercraft.eu> <757e9c8c-b4db-cc95-1189-d8c18a5d0ef5@openssl.org> <1494878272.8186281.1516116447649.JavaMail.zimbra@wandercraft.eu> <8c631555-5bf5-1e10-9c6d-81cb0c6f3b35@openssl.org> <1247193521.8240430.1516119753361.JavaMail.zimbra@wandercraft.eu> <63dbb29a-4d83-127a-3907-f6e7d0a86690@openssl.org> Message-ID: <1232445217.8881228.1516188201629.JavaMail.zimbra@wandercraft.eu> ----- Mail original ----- > De: "Matt Caswell" > ?: "openssl-users" > Envoy?: Mardi 16 Janvier 2018 17:49:02 > Objet: Re: [openssl-users] Multiple reconnection in OpenSSL 1.1.0 > On 16/01/18 16:22, Huy Cong Vu wrote: >> Ok the call for SSL_clear() apparently works. Thanks a lot. >> To make the code clean, I will re-instantiate SSL object for each connection. I >> do not have any specific reasons to keep SSL object alive after each >> connection. It just that I do not want to re-inialize the context. In the old >> version, it works very well without it.... > > Interesting. There has been no change in the API in this regards. You > have never been "allowed" to reuse an SSL object without first calling > SSL_clear() - that's the whole point of that function (and its been > around since forever). It sounds like you were "lucky" before :-) > Maybe, but it lasts for a very long time :) Anyway, thanks a lot for your help mate. > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users Huy-Cong VU Platform hardware member Network administrator Wandercraft 09 72 58 77 03 From cryptoassetrecovery at gmail.com Thu Jan 18 18:36:38 2018 From: cryptoassetrecovery at gmail.com (Chris B) Date: Thu, 18 Jan 2018 13:36:38 -0500 Subject: [openssl-users] [EXTERNAL] Re: OpenSSL error message when decrypting Ethereum encrypted private key In-Reply-To: References: <1516040956.9330.9.camel@sandia.gov> Message-ID: Thank you to everyone that has weighed in on my question. Unfortunately, I have yet to find an answer that I'm fully satisfied with. I'm trying a different approach: I would like to create a sample encrypted Ethereum private key that shares the same 132 character PEM format as the string I'm trying to decrypt. I can then attempt to decrypt that string with an incorrect password, and see if I get the EVP_DecryptFinal_ex:wrong final block length error. Does that make sense? Here's my basic approach. I'm starting with Vincent Kobel's excellent "Create a Full Ethereum Wallet, Keypair and Address" article ( https://kobl.one/blog/create-full-ethereum-keypair-and-address/) He creates a 132-character PEM formatted unencrypted private key with this command: openssl ecparam -name secp256k1 -genkey -noout Unless I have completely failed at reading the man page correctly, there's no way to assign a password from the ecparam command. I write the 132 character unencrypted private key (not the -----BEGIN/END EC PRIVATE KEY----- characters) to a file named sample_pk.pem and I encrypt it with openssl: openssl enc -e -aes-256-cbc -a -in sample_pk.pem -out sample_epk.pem -pass pass:secret I now have a 256 character encrypted private string. (Note, the string length is 256 characters whether I use AES-128 or AES-256. That's probably obvious to all of you, but it wasn't to me). If I decrypt that string with the correct password openssl enc -d -aes256 -a -in sample_epk.pem -out recovered.key -pass pass:secret I get my original unencrypted private key back. Excellent! However, If I decrypt that string with an incorrect password: openssl enc -d -aes256 -a -in sample_epk.pem -out recovered.key -pass pass:secr3t I get a new error message: EVP_DecryptFinal_ex:bad decrypt And, that message does not match the EVP_DecryptFinal_ex:wrong final block length error message I was hoping to get. I think that all that I have proven with this exercise is that the original unencrypted private key was: - not a 132 character PEM formatted unencrypted private key - and/or - it was not encrypted using the -aes-256-cbc encryption algorithm So, on to the question! Can anyone help me figure out how to create an Ethereum private key such that when it is encrypted it is a 132 character long PEM formatted string? Alternately, is there a process for taking an encrypted string, and "backing in" to the details of how it was created? (ie what algorithm, etc?) Thanks, Chris On Mon, Jan 15, 2018 at 2:01 PM, Chris B wrote: > Hi Daniel, > > >Option #1 from the possibilities you mentioned below seems to be the > most logical to me. > Thank you, that's very helpful. > > Thanks, > Chris > > On Mon, Jan 15, 2018 at 1:29 PM, Sands, Daniel wrote: > >> On Sun, 2018-01-14 at 18:26 -0500, Chris B wrote: >> >> Hi Matt, >> >> >If you *are* using 1.1.0 then the default digest was changed between >> 1.0.2 and 1.1.0. >> Awesome thought, but I'm also using 1.0.2: >> >> $ openssl version >> >> OpenSSL 1.0.2k-fips 26 Jan 2017 >> >> (I also tried adding -md md5 to the previous command, but I got the same >> error message). >> >> >> Option #1 from the possibilities you mentioned below seems to be the most >> logical to me. If you use the wrong key, the padding data in the last block >> will also be decrypted to the wrong values, so the padding block check will >> fail. The padding is a necessary part of decryption because it needs to >> know how much plaintext is actually represented by that last block. >> >> >> > I'm not sure how to interpret that output. I could interpret it as: >> > o Your system for decrypting the password is perfect, but: this is not >> > the right password. >> > o There's something wrong with the EPK -- its length must be a multiple >> > of the AES block length. >> > o There's something wrong with the unencrypted private key -- its length >> > must be a multiple of the AES block length. >> > o Something else entirely >> >> >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neel5481 at gmail.com Fri Jan 19 08:27:41 2018 From: neel5481 at gmail.com (neel patel) Date: Fri, 19 Jan 2018 13:57:41 +0530 Subject: [openssl-users] Revoke certificate and append to existing crl file Message-ID: Hi, I am using openssl C API. I have created openssl certificates so i have .crt and .key file. If I want to append those certificates in existing certificate revocation list then how can we do that ? I have tried with below code. #include #include #include #include #include #include #include #include #include #include #include #include #include #define DB_NUMBER 6 #define DB_name 5 #define DB_serial 3 #define DB_rev_date 2 static X509* load_cert(const char* usercert) { /* read usercert from file */ X509* x = NULL; BIO* bio = BIO_new(BIO_s_file()); assert(bio != NULL); assert(BIO_read_filename(bio, usercert) > 0); x = PEM_read_bio_X509_AUX(bio, NULL, NULL, NULL); BIO_free(bio); assert(x != NULL); return x; } int main() { int i; ASN1_UTCTIME* tm = NULL; char* rev_str = NULL; BIGNUM* bn = NULL; char* row[DB_NUMBER]; for (i = 0; i < DB_NUMBER; i++) row[i] = NULL; X509* x = load_cert("../client.crt"); row[DB_name] = X509_NAME_oneline(X509_get_subject_name(x), NULL, 0); bn = ASN1_INTEGER_to_BN(X509_get_serialNumber(x), NULL); assert(bn != NULL); if (BN_is_zero(bn)) row[DB_serial] = BUF_strdup("00"); else row[DB_serial] = BN_bn2hex(bn); BN_free(bn); printf("Serial Number is: %s\n", row[DB_serial]); printf("---- Now Updating CRL file with expired client certificates --------\n"); char *crl_file_path = "../root_mod.crl"; FILE *fp_crl_file = NULL; X509_CRL *x_crl = NULL; BIGNUM* serial = NULL; /* Get the CA crl */ fp_crl_file = fopen(crl_file_path, "r"); if (!fp_crl_file) { printf("---- Error while opening CRL file --------\n"); exit(1); } x_crl = PEM_read_X509_CRL(fp_crl_file, NULL, NULL, NULL); if (!x_crl) { printf("---- Error while reading X509 CRL file --------\n"); exit(1); } fclose(fp_crl_file); X509_REVOKED* r = X509_REVOKED_new(); assert(r != NULL); assert(BN_hex2bn(&serial, row[DB_serial]) > 0); ASN1_INTEGER* tmpser = BN_to_ASN1_INTEGER(serial, NULL); BN_free(serial); serial = NULL; assert(tmpser != NULL); i = X509_REVOKED_set_serialNumber(r, tmpser); ASN1_INTEGER_free(tmpser); X509_CRL_add0_revoked(x_crl, r); return 0; } Is is possible to add revoked certificate serial number to CRL file ? OR Do I need to regenerate the CRL file from list of revoked certificate serial numbers ( e.g. index.txt ). Let us know your thoughts. Thanks, Neel -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Gladewitz at dbfz.de Fri Jan 19 14:12:28 2018 From: Robert.Gladewitz at dbfz.de (Gladewitz, Robert) Date: Fri, 19 Jan 2018 14:12:28 +0000 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed Message-ID: Dear OpenSSL Team, I have some problems with new Cisco CAPF certs and freeradius tls authentification. The point is, that freeradius users see the problem on openssl implemtiation. (69) eap_tls: Continuing EAP-TLS (69) eap_tls: Peer indicated complete TLS record size will be 1432 bytes (69) eap_tls: Got complete TLS record (1432 bytes) (69) eap_tls: [eaptls verify] = length included (69) eap_tls: TLS_accept: SSLv3/TLS write server done (69) eap_tls: <<< recv TLS 1.0 Handshake [length 03c2], Certificate (69) eap_tls: Creating attributes from certificate OIDs (69) eap_tls: TLS-Cert-Serial := "1009" (69) eap_tls: TLS-Cert-Expiration := "380111125719Z" (69) eap_tls: TLS-Cert-Subject := "/C=DE/ST=Sachsen/L=Leipzig/O=DBFZ Deutsches Biomasseforschungszentrum gGmbH/OU=IT/CN=CAPF-91d43ef6" (69) eap_tls: TLS-Cert-Issuer := "/C=DE/ST=Sachsen/L=Leipzig/O=DBFZ Deutsches Biomasseforschungszentrum gemeinnuetzige GmbH/OU=IT/CN=DBFZ CA INTERN ROOT/emailAddress=support at dbfz.de " (69) eap_tls: TLS-Cert-Common-Name := "CAPF-91d43ef6" (69) eap_tls: ERROR: SSL says error 26 : unsupported certificate purpose (69) eap_tls: >>> send TLS 1.0 Alert [length 0002], fatal unsupported_certificate (69) eap_tls: ERROR: TLS Alert write:fatal:unsupported certificate tls: TLS_accept: Error in error (69) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed (69) eap_tls: ERROR: System call (I/O) error (-1) (69) eap_tls: ERROR: TLS receive handshake failed during operation (69) eap_tls: ERROR: [eaptls process] = fail This means, that the check of ca certificate is failed. So, bu I do not see, why. If i check the certificate by command openssl -verify, all sems to be right. # openssl verify -verbose -CAfile /etc/freeradius/3.0/certs.8021x.ciscophone/cacert.capf.pem SEP64A0E714844E-L1.pem # SEP64A0E714844E-L1.pem: OK The openssl version is Debian based 1.1.0g-2. But the same error is happening on 1.1.0f also. Older freeradius version 2 on Debian 8/openssl 1.0.1t-1+deb8u7 working fine without this problem (by using the same certificates) The ca certificate are signed by an intern ca. Can anyone see the error?? Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cacert.capf.pem Type: application/octet-stream Size: 4193 bytes Desc: cacert.capf.pem URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SEP64A0E714844E-L1.pem Type: application/octet-stream Size: 1346 bytes Desc: SEP64A0E714844E-L1.pem URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6245 bytes Desc: not available URL: From pravesh.rai at gmail.com Fri Jan 19 15:40:17 2018 From: pravesh.rai at gmail.com (Pravesh Rai) Date: Fri, 19 Jan 2018 21:10:17 +0530 Subject: [openssl-users] tls handshake fail using cipher ECDHE-ECDSA-AES256-GCM-SHA384 In-Reply-To: References: Message-ID: Following link might give you, some clue about the problem: https://stackoverflow.com/questions/30446431/wrong-cipher-suite-or-no-connection-with-openssl-server Regards, PR On Fri, Jan 12, 2018 at 9:27 PM, johan persson wrote: > I have problem doing handshake using "ECDHE-ECDSA-AES256-GCM-SHA384" > cipher. > OpenSSL 1.0.2h > > This is how I generate test certificates. > openssl ecparam -out /data/ca.key -name secp256k1 -genkey > openssl req -x509 -new -key /data/ca.key -out /data/ca.pem -outform PEM > -days 3650 -subj '/C=SE/ST=S/L=M/O=V/CN=SERVER > openssl ecparam -out /data/server.key -name secp256k1 -genkey > openssl req -new -nodes -key /data/server.key -outform pem -out > /data/server.req -subj '/C=SE/ST=S/L=M/O=V/CN=SERVER' > openssl ecparam -out /data/client.key -name secp256k1 -genkey > openssl req -new -nodes -key /data/client.key -outform pem -out > /data/client.req -subj '/C=SE/ST=S/L=M/O=V/CN=CLIENT' > openssl ca -batch -keyfile /data/ca.key -cert /data/ca.pem -in > /data/server.req -out /data/server.pem -outdir /data/ > openssl ca -batch -keyfile /data/ca.key -cert /data/ca.pem -in > /data/client.req -out /data/client.pem -outdir /data/ > > > Running the following test: > openssl s_server -accept 10000 -cert server.pem -key server.key -CAfile > ca.pem -debug -tlsextdebug > openssl s_client -connect localhost:10000 -cert client.pem -key client.key > -CAfile ca.pem -tls1_2 > > I get a handshake working ok with the cipher I want > "ECDHE-ECDSA-AES256-GCM-SHA384", perfect!: > > > Now, using my own tls server I only get "ECDH-ECDSA-AES256-GCM-SHA384" to > work. I cannot use "ECDHE-ECDSA-AES256-GCM-SHA384" which I want. > Anyone knows what I'm missing from the following setup?: > > #define VOC_TLS_CIPHERS "ECDHE-ECDSA-AES256-GCM-SHA384" << NOT WORKING > //#define VOC_TLS_CIPHERS "ECDH-ECDSA-AES256-GCM-SHA384" << WORKING > > // Init for OpenSSL > SSL_library_init(); > OpenSSL_add_all_algorithms(); > SSL_load_error_strings(); > > ctx_ = SSL_CTX_new(TLSv1_2_server_method()); > if (ctx_ == NULL) > { > LOG(LOG_WARN, "Tls: %s: Failed to create TLS context", __FUNCTION__); > return RET_FAIL; > } > > (Load Ca cert, server and server private key) > > if (SSL_CTX_set_ecdh_auto(ctx_, 1)) { > LOG(LOG_WARN, "Tls: %s: Failed to set ECDH auto pick", __FUNCTION__); > return RET_FAIL; > } > > if (!SSL_CTX_set_cipher_list(ctx_, VOC_TLS_CIPHERS)) { > LOG(LOG_WARN, "Tls: %s: Failed to set cipher list: %s\n", > __FUNCTION__, VOC_TLS_CIPHERS); > return RET_FAIL; > } > > ssl_ = SSL_new(ctx_); > > error on server side: > > Server has 1 from 0xb475ef98: > 0xb6daa440:ECDHE-ECDSA-AES256-GCM-SHA384 > Client sent 1 from 0xb3502308: > 0xb6daa440:ECDHE-ECDSA-AES256-GCM-SHA384 > rt=0 rte=0 dht=0 ecdht=0 re=0 ree=0 rs=0 ds=0 dhr=0 dhd=0 > 0:[00000080:00000040:00000140:000000D4]0xb6daa440:ECDHE-ECDS > A-AES256-GCM-SHA384 > 2958031164:error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared > cipher:s3_srvr.c:1417: > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Jan 19 17:34:57 2018 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 19 Jan 2018 17:34:57 +0000 Subject: [openssl-users] Blog post; changing in email, crypto policy, etc Message-ID: There?s a new blog post at https://www.openssl.org/blog/blog/2018/01/18/f2f-london/ It contains some important policy changes we decided at our meeting last month. This includes: - Closing the openssl-dev mailing list; use GitHub for issues - New mailing list openssl-project for project discussions - New policy for accepting crypto algorithms, formats, and protocols. - .. several others Please read the posting; the changes described in it affect everyone who uses OpenSSL. Thanks for your interest, and all your efforts to help improve the project! From fm at frank4dd.com Sat Jan 20 02:29:58 2018 From: fm at frank4dd.com (Frank Migge) Date: Sat, 20 Jan 2018 11:29:58 +0900 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: Message-ID: <5A62A9A6.3000708@frank4dd.com> Hi Robert, >> error 26 : unsupported certificate purpose It seems the cert gets declined because of a problem with cert extensions. "keyUsage" or "extendedKeyUsage" are typical candidates. In your case, the leaf certificate "CAPF-91d43ef6" has two extensions: Object 00: X509v3 Key Usage Digital Signature, Key Encipherment Object 01: X509v3 Extended Key Usage TLS Web Server Authentication, TLS Web Client Authentication, IPSec End System I would check if an extension is now missing/newly required, or no longer recognized. Try check for differences in the openssl.cnf and freeradius config files between the old Debian system and the new one. Some EAP TLS guides (incl. Cisco) also list extensions "nonRepudiation" and "dataEncipherment", but this is just a guess since you mentioned it works on the old system. >> I have some problems with new Cisco CAPF certs What is the authenticating device? Cisco IP phone? Cheers, Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From fm at frank4dd.com Sat Jan 20 03:09:38 2018 From: fm at frank4dd.com (Frank Migge) Date: Sat, 20 Jan 2018 12:09:38 +0900 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: <5A62A9A6.3000708@frank4dd.com> References: <5A62A9A6.3000708@frank4dd.com> Message-ID: <5A62B2F2.4000903@frank4dd.com> I got it wrong. The failing cert from your log is actually the intermediate, which has five extensions: >> Object 00: X509v3 Subject Key Identifier: 58:A4:EB:D9:DD:CE:A2:99:72:3B:E1:20:19:1D:40:C1:F9:D5:C2:28 >> Object 01: X509v3 Authority Key Identifier: keyid:E2:E9:20:42:29:83:C4:77:8C:87:AB:FA:4B:A1:A9:C4:CE:00:BD:39 >> Object 02: X509v3 Basic Constraints: CA:TRUE, pathlen:0 >> Object 03: X509v3 Key Usage: Digital Signature, Certificate Sign, CRL Sign >> Object 04: X509v3 Extended Key Usage: TLS Web Server Authentication This is were I would check first. I am not fully sure, but believe that Extended Key Usage should *not* be there. Frank > Frank Migge > Saturday, January 20, 2018 11:29 AM > Hi Robert, > >>> error 26 : unsupported certificate purpose > > It seems the cert gets declined because of a problem with cert > extensions. "keyUsage" or "extendedKeyUsage" are typical candidates. In > your case, the leaf certificate "CAPF-91d43ef6" has two extensions: > > Object 00: X509v3 Key Usage > Digital Signature, Key Encipherment > > Object 01: X509v3 Extended Key Usage > TLS Web Server Authentication, TLS Web Client Authentication, IPSec End System > > I would check if an extension is now missing/newly required, or no > longer recognized. Try check for differences in the openssl.cnf and > freeradius config files between the old Debian system and the new one. > > Some EAP TLS guides (incl. Cisco) also list extensions "nonRepudiation" and "dataEncipherment", but this is just a guess since you mentioned it works on the old system. > >>> I have some problems with new Cisco CAPF certs > > What is the authenticating device? Cisco IP phone? > > Cheers, > Frank > Gladewitz, Robert via openssl-users > Friday, January 19, 2018 11:12 PM > > Dear OpenSSL Team, > > > > I have some problems with new Cisco CAPF certs and freeradius tls > authentification. The point is, that freeradius users see the problem > on openssl implemtiation. > > > > > > (69) eap_tls: Continuing EAP-TLS > > (69) eap_tls: Peer indicated complete TLS record size will be 1432 bytes > > (69) eap_tls: Got complete TLS record (1432 bytes) > > (69) eap_tls: [eaptls verify] = length included > > (69) eap_tls: TLS_accept: SSLv3/TLS write server done > > (69) eap_tls: <<< recv TLS 1.0 Handshake [length 03c2], Certificate > > (69) eap_tls: Creating attributes from certificate OIDs > > (69) eap_tls: TLS-Cert-Serial := "1009" > > (69) eap_tls: TLS-Cert-Expiration := "380111125719Z" > > (69) eap_tls: TLS-Cert-Subject := "/C=DE/ST=Sachsen/L=Leipzig/O=DBFZ > Deutsches Biomasseforschungszentrum gGmbH/OU=IT/CN=CAPF-91d43ef6" > > (69) eap_tls: TLS-Cert-Issuer := "/C=DE/ST=Sachsen/L=Leipzig/O=DBFZ > Deutsches Biomasseforschungszentrum gemeinnuetzige GmbH/OU=IT/CN=DBFZ > CA INTERN ROOT/emailAddress=support at dbfz.de > " > > (69) eap_tls: TLS-Cert-Common-Name := "CAPF-91d43ef6" > > (69) eap_tls: ERROR: SSL says error 26 : unsupported certificate purpose > > (69) eap_tls: >>> send TLS 1.0 Alert [length 0002], fatal > unsupported_certificate > > (69) eap_tls: ERROR: TLS Alert write:fatal:unsupported certificate > > tls: TLS_accept: Error in error > > (69) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): > error:1417C086:SSL routines:tls_process_client_certificate:certificate > verify failed > > (69) eap_tls: ERROR: System call (I/O) error (-1) > > (69) eap_tls: ERROR: TLS receive handshake failed during operation > > (69) eap_tls: ERROR: [eaptls process] = fail > > > > > > This means, that the check of ca certificate is failed. So, bu I do > not see, why. If i check the certificate by command openssl ?verify, > all sems to be right. > > # openssl verify -verbose -CAfile > /etc/freeradius/3.0/certs.8021x.ciscophone/cacert.capf.pem > SEP64A0E714844E-L1.pem > > # SEP64A0E714844E-L1.pem: OK > > > > > > The openssl version is Debian based 1.1.0g-2. But the same error is > happening on 1.1.0f also. > > > > Older freeradius version 2 on Debian 8/openssl 1.0.1t-1+deb8u7 working > fine without this problem (by using the same certificates) > > > > The ca certificate are signed by an intern ca. Can anyone see the error?? > > > > Robert > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sat Jan 20 04:34:27 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 19 Jan 2018 23:34:27 -0500 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: <5A62B2F2.4000903@frank4dd.com> References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> Message-ID: <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> > On Jan 19, 2018, at 10:09 PM, Frank Migge wrote: > > >> Object 04: X509v3 Extended Key Usage: TLS Web Server Authentication > > This is were I would check first. > > I am not fully sure, but believe that Extended Key Usage should *not* be there. Indeed the intermediate CA should either not have an extendedKeyUsage, or that keyUsage should include the desired "purpose". The handling of the purpose of intermediate certificates was made more uniform in OpenSSL 1.1.0 (whether the certificate is from the cert store or the remote peer is no longer material). This and related changes can affect whether a chain is still valid with 1.1.0 and beyond. -- Viktor. From Robert.Gladewitz at dbfz.de Sat Jan 20 10:53:25 2018 From: Robert.Gladewitz at dbfz.de (Gladewitz, Robert) Date: Sat, 20 Jan 2018 10:53:25 +0000 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: <5A62A9A6.3000708@frank4dd.com> References: <5A62A9A6.3000708@frank4dd.com> Message-ID: <335f3fe9cfa54f3abc44b6520aefd101@dbfz.de> Hello Frank. Thank your for helping ?. The CAPF certificates in cisco CUCM Systems have some functions, for example phone proxy services. Usually, you create a certificate reqest on CUCM (Callmanager) and you will signed by you internal ca. Also it is possible, that the CUCM callmanager signed by self. (On both, the problem are happening) I use a signed ca certificate for CAPF, with is signed by my internal root ca, wich is bases on openssl. So, for new phone, the CUCM callmanager generate and sign the phone client certificate, wich is downloaded from the phone and used for check configuration signing und in our problem case use as a client certificate for 802.1x tls authentification. In freeradius, the CAPF CA certificate is installed as a CA certificatge for check the clients certs in tls authentification processes. In freeradius2 anything is working fine and the phone client certificates is verify without any error. The interesst think is, that the error is display for the ca (CAPF) certificate, not for the client certificates. So, i check the attributes and extensions: X509v3 extensions: X509v3 Subject Key Identifier: 58:A4:EB:D9:DD:CE:A2:99:72:3B:E1:20:19:1D:40:C1:F9:D5:C2:28 X509v3 Authority Key Identifier: keyid:E2:E9:20:42:29:83:C4:77:8C:87:AB:FA:4B:A1:A9:C4:CE:00:BD:39 X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign X509v3 Extended Key Usage: critical TLS Web Server Authentication For my interpretation, anything ist ok. May the TLS Web Server Authentication is not usual, but it is mandodary by cisco. On the way, we use the minimal mandodary requirements from cisco. Vg Robert Von: Frank Migge [mailto:fm at frank4dd.com] Gesendet: Samstag, 20. Januar 2018 03:30 An: Gladewitz, Robert ; openssl-users at openssl.org Betreff: Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed Hi Robert, error 26 : unsupported certificate purpose It seems the cert gets declined because of a problem with cert extensions. "keyUsage" or "extendedKeyUsage" are typical candidates. In your case, the leaf certificate "CAPF-91d43ef6" has two extensions: Object 00: X509v3 Key Usage Digital Signature, Key Encipherment Object 01: X509v3 Extended Key Usage TLS Web Server Authentication, TLS Web Client Authentication, IPSec End System I would check if an extension is now missing/newly required, or no longer recognized. Try check for differences in the openssl.cnf and freeradius config files between the old Debian system and the new one. Some EAP TLS guides (incl. Cisco) also list extensions "nonRepudiation" and "dataEncipherment", but this is just a guess since you mentioned it works on the old system. I have some problems with new Cisco CAPF certs What is the authenticating device? Cisco IP phone? Cheers, Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cacert.capf.pem Type: application/octet-stream Size: 4193 bytes Desc: cacert.capf.pem URL: From michael at stroeder.com Sat Jan 20 10:59:29 2018 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Sat, 20 Jan 2018 11:59:29 +0100 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> Message-ID: Viktor Dukhovni wrote: >> On Jan 19, 2018, at 10:09 PM, Frank Migge wrote: >> >>>> Object 04: X509v3 Extended Key Usage: TLS Web Server Authentication >> >> This is were I would check first. >> >> I am not fully sure, but believe that Extended Key Usage should *not* be there. > > Indeed the intermediate CA should either not have an extendedKeyUsage, or that > keyUsage should include the desired "purpose". Full ack. But unfortunately M$ implemented this requirement to add such a value to Extended Key Usage of intermediate CA certs violating X.509 and RFC 5280. And now all PKI lemmings are following this crap. => use your own CA Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From Robert.Gladewitz at dbfz.de Sat Jan 20 11:42:13 2018 From: Robert.Gladewitz at dbfz.de (Gladewitz, Robert) Date: Sat, 20 Jan 2018 11:42:13 +0000 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> Message-ID: <77198a8e88cd4572a57d47bfde2da004@dbfz.de> Hello Vikor, hmm, we have only a self signed root ca and the CAPF ist directly minor. And the extended key usage is mandodary by cisco. You mean, the only solution are, the the root ca also have the same extendedKeyUsage? Robert -----Urspr?ngliche Nachricht----- Von: openssl-users [mailto:openssl-users-bounces at openssl.org] Im Auftrag von Viktor Dukhovni Gesendet: Samstag, 20. Januar 2018 05:34 An: openssl-users at openssl.org Betreff: Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed > On Jan 19, 2018, at 10:09 PM, Frank Migge wrote: > > >> Object 04: X509v3 Extended Key Usage: TLS Web Server Authentication > > This is were I would check first. > > I am not fully sure, but believe that Extended Key Usage should *not* be there. Indeed the intermediate CA should either not have an extendedKeyUsage, or that keyUsage should include the desired "purpose". The handling of the purpose of intermediate certificates was made more uniform in OpenSSL 1.1.0 (whether the certificate is from the cert store or the remote peer is no longer material). This and related changes can affect whether a chain is still valid with 1.1.0 and beyond. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From Robert.Gladewitz at dbfz.de Sat Jan 20 11:50:05 2018 From: Robert.Gladewitz at dbfz.de (Gladewitz, Robert) Date: Sat, 20 Jan 2018 11:50:05 +0000 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> Message-ID: Hello Michael, So, i think there is a lot of problems for many infrastrucure in the feature, if all software use functions based on openssl >1.1.0. But a am using a own root ca based on creation time in openssl 1.0.0. What ca i do, when cisco need the Extended Key Usage? Robert -----Urspr?ngliche Nachricht----- Von: openssl-users [mailto:openssl-users-bounces at openssl.org] Im Auftrag von Michael Str?der Gesendet: Samstag, 20. Januar 2018 11:59 An: openssl-users at openssl.org; Viktor Dukhovni Betreff: Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed Viktor Dukhovni wrote: >> On Jan 19, 2018, at 10:09 PM, Frank Migge wrote: >> >>>> Object 04: X509v3 Extended Key Usage: TLS Web Server Authentication >> >> This is were I would check first. >> >> I am not fully sure, but believe that Extended Key Usage should *not* be there. > > Indeed the intermediate CA should either not have an extendedKeyUsage, > or that keyUsage should include the desired "purpose". Full ack. But unfortunately M$ implemented this requirement to add such a value to Extended Key Usage of intermediate CA certs violating X.509 and RFC 5280. And now all PKI lemmings are following this crap. => use your own CA Ciao, Michael. From Robert.Gladewitz at dbfz.de Sat Jan 20 19:18:50 2018 From: Robert.Gladewitz at dbfz.de (Gladewitz, Robert) Date: Sat, 20 Jan 2018 19:18:50 +0000 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: <5A633BCF.7090903@frank4dd.com> References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <87562fb3aec8434398d206e3703d7750@dbfz.de> <5A633BCF.7090903@frank4dd.com> Message-ID: Hallo Frank, this are bad news. The Cisco CAPF CA certifiace need TLS Web Server Authentification. https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/212214-Tech-Note-on-CAPF-Certificate-Signed-by.html You mean, i sign the cert request new with adding anyExtendedKeyUsage will be work? Ir kann the root ca add the same extendedKeyUsage and resign byself? Robert Von: Frank Migge [mailto:fm at frank4dd.com] Gesendet: Samstag, 20. Januar 2018 13:54 An: Gladewitz, Robert Betreff: Re: AW: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed Hi Robert, Lets see if I get it right. Please correct me if I am misinterpreting. If an extended key usage extension such as "TLS Web Server Authentication" is set in the intermediate, its purpose conflicts with the signing purpose of an (intermediate) CA cert. RFC8250 mentions that extended key usage extension (EKU) is only meant for end entity certificates (e.g. client or server certs). If both key key usage extensions (KU) and EKU extensions exist, both need to be checked for a consistent purpose. The EKU above could create a conflict of purpose with the KU before. In that case, the RFC requires the cert not to be used at all. In simpler words: CA certificates can't/shouldn't be also used as client or server certs, and vice versa. However, it seems that Cisco is doing exactly that, trying to achieve both functions in a single cert. This RFC violation(?) may work in a closed Cisco-world, but could fail against other products, such as FreeRadius/OpenSSL. That it used to work with an older Debian under OpenSSL 1.0.1 may have been luck. Victor mentioned that some changes to chain verification happened in versions 1.1.0 and beyond. What could be done? RFC 5280 mentions a "work-around". If the CAPF cert could be created outside of Cisco, replacing existing or adding the specific EKU called "anyExtendedKeyUsage", so it could act as a "wildcard"? Not sure if it would fix it (or breaks the Cisco side instead), and if indeed above problem is your issue, but it may be worth a try. Frank Gladewitz, Robert Saturday, January 20, 2018 8:29 PM Hello Frank, why it is wron for an ca cert? Robert Von: Frank Migge [mailto:fm at frank4dd.com] Gesendet: Samstag, 20. Januar 2018 04:10 An: openssl-users at openssl.org Cc: Gladewitz, Robert Betreff: Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed I got it wrong. The failing cert from your log is actually the intermediate, which has five extensions: >> Object 00: X509v3 Subject Key Identifier: 58:A4:EB:D9:DD:CE:A2:99:72:3B:E1:20:19:1D:40:C1:F9:D5:C2:28 >> Object 01: X509v3 Authority Key Identifier: keyid:E2:E9:20:42:29:83:C4:77:8C:87:AB:FA:4B:A1:A9:C4:CE:00:BD:39 >> Object 02: X509v3 Basic Constraints: CA:TRUE, pathlen:0 >> Object 03: X509v3 Key Usage: Digital Signature, Certificate Sign, CRL Sign >> Object 04: X509v3 Extended Key Usage: TLS Web Server Authentication This is were I would check first. I am not fully sure, but believe that Extended Key Usage should *not* be there. Frank Frank Migge Saturday, January 20, 2018 12:09 PM I got it wrong. The failing cert from your log is actually the intermediate, which has five extensions: >> Object 00: X509v3 Subject Key Identifier: 58:A4:EB:D9:DD:CE:A2:99:72:3B:E1:20:19:1D:40:C1:F9:D5:C2:28 >> Object 01: X509v3 Authority Key Identifier: keyid:E2:E9:20:42:29:83:C4:77:8C:87:AB:FA:4B:A1:A9:C4:CE:00:BD:39 >> Object 02: X509v3 Basic Constraints: CA:TRUE, pathlen:0 >> Object 03: X509v3 Key Usage: Digital Signature, Certificate Sign, CRL Sign >> Object 04: X509v3 Extended Key Usage: TLS Web Server Authentication This is were I would check first. I am not fully sure, but believe that Extended Key Usage should *not* be there. Frank Frank Migge Saturday, January 20, 2018 11:29 AM Hi Robert, error 26 : unsupported certificate purpose It seems the cert gets declined because of a problem with cert extensions. "keyUsage" or "extendedKeyUsage" are typical candidates. In your case, the leaf certificate "CAPF-91d43ef6" has two extensions: Object 00: X509v3 Key Usage Digital Signature, Key Encipherment Object 01: X509v3 Extended Key Usage TLS Web Server Authentication, TLS Web Client Authentication, IPSec End System I would check if an extension is now missing/newly required, or no longer recognized. Try check for differences in the openssl.cnf and freeradius config files between the old Debian system and the new one. Some EAP TLS guides (incl. Cisco) also list extensions "nonRepudiation" and "dataEncipherment", but this is just a guess since you mentioned it works on the old system. I have some problems with new Cisco CAPF certs What is the authenticating device? Cisco IP phone? Cheers, Frank Gladewitz, Robert via openssl-users Friday, January 19, 2018 11:12 PM Dear OpenSSL Team, I have some problems with new Cisco CAPF certs and freeradius tls authentification. The point is, that freeradius users see the problem on openssl implemtiation. (69) eap_tls: Continuing EAP-TLS (69) eap_tls: Peer indicated complete TLS record size will be 1432 bytes (69) eap_tls: Got complete TLS record (1432 bytes) (69) eap_tls: [eaptls verify] = length included (69) eap_tls: TLS_accept: SSLv3/TLS write server done (69) eap_tls: <<< recv TLS 1.0 Handshake [length 03c2], Certificate (69) eap_tls: Creating attributes from certificate OIDs (69) eap_tls: TLS-Cert-Serial := "1009" (69) eap_tls: TLS-Cert-Expiration := "380111125719Z" (69) eap_tls: TLS-Cert-Subject := "/C=DE/ST=Sachsen/L=Leipzig/O=DBFZ Deutsches Biomasseforschungszentrum gGmbH/OU=IT/CN=CAPF-91d43ef6" (69) eap_tls: TLS-Cert-Issuer := "/C=DE/ST=Sachsen/L=Leipzig/O=DBFZ Deutsches Biomasseforschungszentrum gemeinnuetzige GmbH/OU=IT/CN=DBFZ CA INTERN ROOT/emailAddress=support at dbfz.de" (69) eap_tls: TLS-Cert-Common-Name := "CAPF-91d43ef6" (69) eap_tls: ERROR: SSL says error 26 : unsupported certificate purpose (69) eap_tls: >>> send TLS 1.0 Alert [length 0002], fatal unsupported_certificate (69) eap_tls: ERROR: TLS Alert write:fatal:unsupported certificate tls: TLS_accept: Error in error (69) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed (69) eap_tls: ERROR: System call (I/O) error (-1) (69) eap_tls: ERROR: TLS receive handshake failed during operation (69) eap_tls: ERROR: [eaptls process] = fail This means, that the check of ca certificate is failed. So, bu I do not see, why. If i check the certificate by command openssl ?verify, all sems to be right. # openssl verify -verbose -CAfile /etc/freeradius/3.0/certs.8021x.ciscophone/cacert.capf.pem SEP64A0E714844E-L1.pem # SEP64A0E714844E-L1.pem: OK The openssl version is Debian based 1.1.0g-2. But the same error is happening on 1.1.0f also. Older freeradius version 2 on Debian 8/openssl 1.0.1t-1+deb8u7 working fine without this problem (by using the same certificates) The ca certificate are signed by an intern ca. Can anyone see the error?? Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sat Jan 20 23:21:08 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 20 Jan 2018 18:21:08 -0500 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: <77198a8e88cd4572a57d47bfde2da004@dbfz.de> References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> Message-ID: <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> > On Jan 20, 2018, at 6:42 AM, Gladewitz, Robert via openssl-users wrote: > > Hello Vikor, > > hmm, we have only a self signed root ca and the CAPF ist directly minor. And the extended key usage is mandodary by cisco. > > You mean, the only solution are, the the root ca also have the same extendedKeyUsage? The intermediate CA you posted: Subject: C = DE, ST = Sachsen, L = Leipzig, O = DBFZ Deutsches Biomasseforschungszentrum gGmbH, OU = IT, CN = CAPF-91d43ef6 has extensions: X509v3 extensions: X509v3 Subject Key Identifier: ... X509v3 Authority Key Identifier: ... X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign X509v3 Extended Key Usage: critical TLS Web Server Authentication The last of these limits the CA to just "TLS Web Server Authentication". The leaf certificate has: X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication, IPSec End System which works if you're authenticating it as a "TLS server" (the "Web" part is irrelevant), but fails when used for a "TLS client" or "IPSec End System", because those purposes are not included in the issuing CA certificate. Presumably the problem in this case is that this CA is being used to validate a "TLS client" certificate. You'll need an intermediate CA that either has no "X509v3 Extended Key Usage" or has one that includes both "TLS Web Server Authentication" and "TLS Web Client Authentication". -- Viktor. From Robert.Gladewitz at dbfz.de Sun Jan 21 12:34:26 2018 From: Robert.Gladewitz at dbfz.de (Gladewitz, Robert) Date: Sun, 21 Jan 2018 12:34:26 +0000 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> Message-ID: Hello Viktor, thanks for all this hepl. I i understand your right, than I need to add "TLS Web Client Authentication" to the CAPF certificate. But I have i question. In Freeradius i use the CAPF cert only as an ca cert, not as a server or client cert. The only funktion is, to ckeck the client cert is signed from CAPF. For only check this, the ca need "TLS Web Client Authentication"?? Regards Robert -----Urspr?ngliche Nachricht----- Von: Viktor Dukhovni [mailto:openssl-users at dukhovni.org] Gesendet: Sonntag, 21. Januar 2018 00:21 An: Gladewitz, Robert ; openssl-users at openssl.org Betreff: Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed > On Jan 20, 2018, at 6:42 AM, Gladewitz, Robert via openssl-users wrote: > > Hello Vikor, > > hmm, we have only a self signed root ca and the CAPF ist directly minor. And the extended key usage is mandodary by cisco. > > You mean, the only solution are, the the root ca also have the same extendedKeyUsage? The intermediate CA you posted: Subject: C = DE, ST = Sachsen, L = Leipzig, O = DBFZ Deutsches Biomasseforschungszentrum gGmbH, OU = IT, CN = CAPF-91d43ef6 has extensions: X509v3 extensions: X509v3 Subject Key Identifier: ... X509v3 Authority Key Identifier: ... X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign X509v3 Extended Key Usage: critical TLS Web Server Authentication The last of these limits the CA to just "TLS Web Server Authentication". The leaf certificate has: X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication, IPSec End System which works if you're authenticating it as a "TLS server" (the "Web" part is irrelevant), but fails when used for a "TLS client" or "IPSec End System", because those purposes are not included in the issuing CA certificate. Presumably the problem in this case is that this CA is being used to validate a "TLS client" certificate. You'll need an intermediate CA that either has no "X509v3 Extended Key Usage" or has one that includes both "TLS Web Server Authentication" and "TLS Web Client Authentication". -- Viktor. From openssl-users at dukhovni.org Sun Jan 21 18:31:40 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 21 Jan 2018 13:31:40 -0500 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> Message-ID: > On Jan 21, 2018, at 7:34 AM, Gladewitz, Robert via openssl-users wrote: > > If I understand your right, then I need to add "TLS Web Client Authentication" > to the CAPF certificate. Or better still, remove the "ExtendedKeyUsage" extension from the CA certificate and thus specify neither "TLS Web Client Authentication", nor ""TLS Web Server Authentication". When you "tag" a CA certificate with a given list of "purpose" OIDs, it is then not considered valid for the purposes that are not listed. > But I have a question. In Freeradius I use the CAPF cert only as a CA > cert, not as a server or client cert. The only function is to check > the client cert is signed from CAPF. For only check this, the CA need > "TLS Web Client Authentication"?? OpenSSL interprets the "extendedKeyUsage" extension in CA certificates as a restriction on the allowed extended key usages of leaf certificates that can be issued by that CA. You should typically not specify extended key usage for CA certificates at all, unless you mean to restrict them to specific purposes. -- Viktor. From noloader at gmail.com Sun Jan 21 19:40:25 2018 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 21 Jan 2018 14:40:25 -0500 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> Message-ID: On Sun, Jan 21, 2018 at 1:31 PM, Viktor Dukhovni wrote: > > ... > OpenSSL interprets the "extendedKeyUsage" extension in CA certificates > as a restriction on the allowed extended key usages of leaf certificates > that can be issued by that CA. > > You should typically not specify extended key usage for CA certificates > at all, unless you mean to restrict them to specific purposes. The behavior is inconsistent with RFC 5280: 4.2.1.12. Extended Key Usage This extension indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension. In general, this extension will appear only in end entity certificates. This extension is defined as follows ... Jeff From openssl-users at dukhovni.org Sun Jan 21 22:59:03 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 21 Jan 2018 17:59:03 -0500 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> Message-ID: <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> > On Jan 21, 2018, at 2:40 PM, Jeffrey Walton wrote: > >> OpenSSL interprets the "extendedKeyUsage" extension in CA certificates >> as a restriction on the allowed extended key usages of leaf certificates >> that can be issued by that CA. >> >> You should typically not specify extended key usage for CA certificates >> at all, unless you mean to restrict them to specific purposes. > > The behavior is inconsistent with RFC 5280: > > 4.2.1.12. Extended Key Usage > > This extension indicates one or more purposes for which the certified > public key may be used, in addition to or in place of the basic > purposes indicated in the key usage extension. In general, this > extension will appear only in end entity certificates. This > extension is defined as follows ... We're well aware of this, but this is the de-facto behaviour of multiple implementations. This is an area in which RFC5280 fails to match the real world. -- Viktor. From noloader at gmail.com Sun Jan 21 23:04:58 2018 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 21 Jan 2018 18:04:58 -0500 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> Message-ID: On Sun, Jan 21, 2018 at 5:59 PM, Viktor Dukhovni wrote: > > >> On Jan 21, 2018, at 2:40 PM, Jeffrey Walton wrote: >> >>> OpenSSL interprets the "extendedKeyUsage" extension in CA certificates >>> as a restriction on the allowed extended key usages of leaf certificates >>> that can be issued by that CA. >>> >>> You should typically not specify extended key usage for CA certificates >>> at all, unless you mean to restrict them to specific purposes. >> >> The behavior is inconsistent with RFC 5280: >> >> 4.2.1.12. Extended Key Usage >> >> This extension indicates one or more purposes for which the certified >> public key may be used, in addition to or in place of the basic >> purposes indicated in the key usage extension. In general, this >> extension will appear only in end entity certificates. This >> extension is defined as follows ... > > We're well aware of this, but this is the de-facto behaviour of > multiple implementations. This is an area in which RFC5280 fails > to match the real world. Apparently everyone did not get the memo :) Maybe OpenSSL should allow users to choose between IETF issuing policies and CA/Browser BR issuing policies. Jeff From openssl-users at dukhovni.org Sun Jan 21 23:23:14 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 21 Jan 2018 18:23:14 -0500 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> Message-ID: <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> > On Jan 21, 2018, at 6:04 PM, Jeffrey Walton wrote: > > Maybe OpenSSL should allow users to choose between IETF issuing > policies and CA/Browser BR issuing policies. The sensible thing at this point is to publish an update to RFC5280 that accepts reality. -- Viktor. From noloader at gmail.com Sun Jan 21 23:26:51 2018 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 21 Jan 2018 18:26:51 -0500 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> Message-ID: On Sun, Jan 21, 2018 at 6:23 PM, Viktor Dukhovni wrote: > > >> On Jan 21, 2018, at 6:04 PM, Jeffrey Walton wrote: >> >> Maybe OpenSSL should allow users to choose between IETF issuing >> policies and CA/Browser BR issuing policies. > > The sensible thing at this point is to publish an update to RFC5280 > that accepts reality. +1. Add a Key-Interception usage while you're at it. Its a widespread practice too. Jeff From rsalz at akamai.com Sun Jan 21 23:38:41 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 21 Jan 2018 23:38:41 +0000 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> Message-ID: <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> ? The sensible thing at this point is to publish an update to RFC5280 that accepts reality. Yes, and there?s an IETF place to do that if anyone is interested; see the LAMPS working group. From Robert.Gladewitz at dbfz.de Mon Jan 22 06:39:21 2018 From: Robert.Gladewitz at dbfz.de (Gladewitz, Robert) Date: Mon, 22 Jan 2018 06:39:21 +0000 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> Message-ID: <9377dd8b9de041429dd593c6f1b9937e@dbfz.de> Thank you all for all the answers. The problem is that Cisco prescribes the attributes. https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/212214-Tech-Note-on-CAPF-Certificate-Signed-by.html CAPF CSR: Attributes: Requested Extensions: X509v3 Extended Key Usage: TLS Web Server Authentication, IPSec End System X509v3 Key Usage: Digital Signature, Certificate Sign -----Urspr?ngliche Nachricht----- Von: openssl-users [mailto:openssl-users-bounces at openssl.org] Im Auftrag von Salz, Rich via openssl-users Gesendet: Montag, 22. Januar 2018 00:39 An: openssl-users at openssl.org Betreff: Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed ? The sensible thing at this point is to publish an update to RFC5280 that accepts reality. Yes, and there?s an IETF place to do that if anyone is interested; see the LAMPS working group. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6245 bytes Desc: not available URL: From Robert.Gladewitz at dbfz.de Mon Jan 22 06:40:22 2018 From: Robert.Gladewitz at dbfz.de (Gladewitz, Robert) Date: Mon, 22 Jan 2018 06:40:22 +0000 Subject: [openssl-users] =?iso-8859-1?q?R=FCckruf=3A__TLS_Error_in_FreeRad?= =?iso-8859-1?q?ius_-_eap=5Ftls=3A_ERROR=3A_Failed_in_=5F=5FFUNCTION=5F=5F?= =?iso-8859-1?q?_=28SSL=5Fread=29=3A_error=3A1417C086=3ASSL_routines=3Atls?= =?iso-8859-1?q?=5Fprocess=5Fclient=5Fcertificate=3Acertificate_verify_fai?= =?iso-8859-1?q?led?= Message-ID: Gladewitz, Robert m?chte die Nachricht "[openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed" zur?ckrufen. From Robert.Gladewitz at dbfz.de Mon Jan 22 06:44:21 2018 From: Robert.Gladewitz at dbfz.de (Gladewitz, Robert) Date: Mon, 22 Jan 2018 06:44:21 +0000 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> Message-ID: Thank you all for all the answers. The problem is that Cisco prescribes the attributes. https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/212214-Tech-Note-on-CAPF-Certificate-Signed-by.html CAPF CSR: Attributes: Requested Extensions: X509v3 Extended Key Usage: TLS Web Server Authentication, IPSec End System X509v3 Key Usage: Digital Signature, Certificate Sign Unfortunately, the Cisco CUCM telephone systems do not seem to accept certificates without these attributes :-(. If I understand everything correctly, would the only (and unclean) workaround be adding "TLS Web Client Authentication" to solve my problem? Robert -----Urspr?ngliche Nachricht----- Von: openssl-users [mailto:openssl-users-bounces at openssl.org] Im Auftrag von Salz, Rich via openssl-users Gesendet: Montag, 22. Januar 2018 00:39 An: openssl-users at openssl.org Betreff: Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed ? The sensible thing at this point is to publish an update to RFC5280 that accepts reality. Yes, and there?s an IETF place to do that if anyone is interested; see the LAMPS working group. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6245 bytes Desc: not available URL: From noloader at gmail.com Mon Jan 22 06:47:29 2018 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 22 Jan 2018 01:47:29 -0500 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> Message-ID: On Mon, Jan 22, 2018 at 1:44 AM, Gladewitz, Robert via openssl-users wrote: > > Thank you all for all the answers. > The problem is that Cisco prescribes the attributes. > ... > > Unfortunately, the Cisco CUCM telephone systems do not seem to accept certificates without these attributes :-(. > > If I understand everything correctly, would the only (and unclean) workaround be adding "TLS Web Client Authentication" to solve my problem? > I think you have a couple of choices. First, you can downgrade to a version of OpenSSL that follows the RFC. Second, you can patch OpenSSL to follow the RFC. Third, you can implement the verify_callback and override the errant behavior. Jeff From Robert.Gladewitz at dbfz.de Mon Jan 22 06:57:45 2018 From: Robert.Gladewitz at dbfz.de (Gladewitz, Robert) Date: Mon, 22 Jan 2018 06:57:45 +0000 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> Message-ID: Hello Jeff, That will be difficult. By complience policy, our servers are on Debian / Cent of the current stable version. Even patches code should not be used :-) Does you already know when a version of OpenSSL will be released that follows this RFC? Robert -----Urspr?ngliche Nachricht----- Von: Jeffrey Walton [mailto:noloader at gmail.com] Gesendet: Montag, 22. Januar 2018 07:47 An: Gladewitz, Robert ; OpenSSL Users Betreff: Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed On Mon, Jan 22, 2018 at 1:44 AM, Gladewitz, Robert via openssl-users wrote: > > Thank you all for all the answers. > The problem is that Cisco prescribes the attributes. > ... > > Unfortunately, the Cisco CUCM telephone systems do not seem to accept certificates without these attributes :-(. > > If I understand everything correctly, would the only (and unclean) workaround be adding "TLS Web Client Authentication" to solve my problem? > I think you have a couple of choices. First, you can downgrade to a version of OpenSSL that follows the RFC. Second, you can patch OpenSSL to follow the RFC. Third, you can implement the verify_callback and override the errant behavior. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6245 bytes Desc: not available URL: From guru at unixarea.de Mon Jan 22 07:25:56 2018 From: guru at unixarea.de (Matthias Apitz) Date: Mon, 22 Jan 2018 08:25:56 +0100 Subject: [openssl-users] =?utf-8?q?R=C3=BCckruf=3A__TLS_Error_in_FreeRadiu?= =?utf-8?q?s_-_eap=5Ftls=3A_ERROR=3A_Failed_in_=5F=5FFUNCTION=5F=5F_=28SSL?= =?utf-8?q?=5Fread=29=3A_error=3A1417C086=3ASSL_routines=3Atls=5Fprocess?= =?utf-8?q?=5Fclient=5Fcertificate=3Acertificate_verify_failed?= In-Reply-To: References: Message-ID: <20180122072556.GA2535@c720-r314251> El d?a lunes, enero 22, 2018 a las 06:40:22a. m. +0000, Gladewitz, Robert via openssl-users escribi?: > Gladewitz, Robert m?chte die Nachricht "[openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed" zur?ckrufen. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users Nice idea recall an email which was sent to a mailing-list :-) -- Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/ ? +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From openssl-users at dukhovni.org Mon Jan 22 15:59:30 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 22 Jan 2018 10:59:30 -0500 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> Message-ID: <83866E67-4CA2-433D-990B-13220CDFF7C9@dukhovni.org> > On Jan 22, 2018, at 1:47 AM, Jeffrey Walton wrote: > > I think you have a couple of choices. > > First, you can downgrade to a version of OpenSSL that follows the RFC. > Second, you can patch OpenSSL to follow the RFC. Third, you can > implement the verify_callback and override the errant behavior. None of this is necessary. The OP indicates that the *leaf* certificate has certain required extended key usages, but there is no indication that the same applies to the intermediate CA. The solution is to use a CA chain in which NONE of the CA certificates have an extended key usage extension. ONLY the leaf certificate should have that extension. CA certificates should have extended key usage specified when intended to only issue leaf certificates that are to be used ONLY for the listed purposes. General-purpose CAs should not have extended key usage. -- Viktor. From openssl-users at dukhovni.org Mon Jan 22 16:01:09 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 22 Jan 2018 11:01:09 -0500 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> Message-ID: > On Jan 22, 2018, at 1:57 AM, Gladewitz, Robert via openssl-users wrote: > > Does you already know when a version of OpenSSL will be released that follows this RFC? The RFC is out of touch with real-world practice by multiple implementations. There are no plans to "follow the RFC". -- Viktor. From Robert.Gladewitz at dbfz.de Mon Jan 22 17:07:09 2018 From: Robert.Gladewitz at dbfz.de (Gladewitz, Robert) Date: Mon, 22 Jan 2018 17:07:09 +0000 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> Message-ID: <338b72764d06403ba52b8cddd67b602f@dbfz.de> Hello Viktor, the problem is, that i cant change the cisco implementation :-(. Cisco tell me, the capf implemtation is following all rfc documents. If you are right, i cant use any freeradius implementation, because there are based on openssl. There is no option in freeradius, to ignore some think like this. For my understanding, CA certificate may have these exteded keys - it's just something out of the ordinary. So, you mean, there is no chance to get this correct rfc interpretation to openssl?? Cisco: https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-co mmunications-manager-callmanager/212214-Tech-Note-on-CAPF-Certificate-Signed -by.pdf https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-co mmunications-manager-callmanager/212214-Tech-Note-on-CAPF-Certificate-Signed -by.html Regards Robert -----Urspr?ngliche Nachricht----- Von: openssl-users [mailto:openssl-users-bounces at openssl.org] Im Auftrag von Viktor Dukhovni Gesendet: Montag, 22. Januar 2018 17:01 An: openssl-users at openssl.org Betreff: Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed > On Jan 22, 2018, at 1:57 AM, Gladewitz, Robert via openssl-users wrote: > > Does you already know when a version of OpenSSL will be released that follows this RFC? The RFC is out of touch with real-world practice by multiple implementations. There are no plans to "follow the RFC". -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6245 bytes Desc: not available URL: From rsalz at akamai.com Mon Jan 22 17:09:20 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 22 Jan 2018 17:09:20 +0000 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: <338b72764d06403ba52b8cddd67b602f@dbfz.de> References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> Message-ID: <88FC194F-1EF5-4CBE-B061-86461D735A53@akamai.com> Perhaps ask what other FreeRadius users do, on one of their support forums? I doubt you are the first to run into this. From openssl-users at dukhovni.org Mon Jan 22 19:50:10 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 22 Jan 2018 14:50:10 -0500 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: <338b72764d06403ba52b8cddd67b602f@dbfz.de> References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> Message-ID: > On Jan 22, 2018, at 12:07 PM, Gladewitz, Robert via openssl-users wrote: > > the problem is, that i cant change the cisco implementation :-(. YOU DO NOT need to change the Cisco implementation. > Cisco tell me, the capf implemtation is following all rfc documents. Nothing Cisco is telling you requires your issuing CA to have an extended key usage listing just "TLS Web Server Authentication". > If you are right, > i cant use any freeradius implementation, because there are based on > openssl. There is no option in freeradius, to ignore some think like this. Your problem is a misconfigured CA certificate. Make sure your *CA* certificate has no extended key usage specified, OR has *all* the key usages specified that are required by any leaf certificate it will issue. > For my understanding, CA certificate may have these exteded keys - it's just > something out of the ordinary. The extended key usages on the CA are interpreted to LIMIT the key usages of certificates it can issue. You can certainly use this extension, but then expect the CA to be invalid for key usages you did not list. > So, you mean, there is no chance to get this correct rfc interpretation > to openssl? "Correct" is in the eye of the beholder. The RFC5280 alternative to using the extended key usage (X.509 policy) is a complex mess. Many implementations do the sensible thing and overload the extended key usage instead. OpenSSL is among these and this is unlikely to change. -- Viktor. From Robert.Gladewitz at dbfz.de Mon Jan 22 20:21:55 2018 From: Robert.Gladewitz at dbfz.de (Gladewitz, Robert) Date: Mon, 22 Jan 2018 20:21:55 +0000 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> Message-ID: Hello Viktor, Sorry, I did not mean to upset you. Somehow I seem to have misunderstood something. The CAPF certificate is the CA certificate he goes for? Cisco states that this certificate requires both CA and the extended key "TLS Web Server Authentification"? Viktor, can you please write me directly?? Robert -----Urspr?ngliche Nachricht----- Von: openssl-users [mailto:openssl-users-bounces at openssl.org] Im Auftrag von Viktor Dukhovni Gesendet: Montag, 22. Januar 2018 20:50 An: openssl-users at openssl.org Betreff: Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed > On Jan 22, 2018, at 12:07 PM, Gladewitz, Robert via openssl-users wrote: > > the problem is, that i cant change the cisco implementation :-(. YOU DO NOT need to change the Cisco implementation. > Cisco tell me, the capf implemtation is following all rfc documents. Nothing Cisco is telling you requires your issuing CA to have an extended key usage listing just "TLS Web Server Authentication". > If you are right, > i cant use any freeradius implementation, because there are based on > openssl. There is no option in freeradius, to ignore some think like this. Your problem is a misconfigured CA certificate. Make sure your *CA* certificate has no extended key usage specified, OR has *all* the key usages specified that are required by any leaf certificate it will issue. > For my understanding, CA certificate may have these exteded keys - > it's just something out of the ordinary. The extended key usages on the CA are interpreted to LIMIT the key usages of certificates it can issue. You can certainly use this extension, but then expect the CA to be invalid for key usages you did not list. > So, you mean, there is no chance to get this correct rfc > interpretation to openssl? "Correct" is in the eye of the beholder. The RFC5280 alternative to using the extended key usage (X.509 policy) is a complex mess. Many implementations do the sensible thing and overload the extended key usage instead. OpenSSL is among these and this is unlikely to change. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From noloader at gmail.com Mon Jan 22 20:42:22 2018 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 22 Jan 2018 15:42:22 -0500 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> Message-ID: On Mon, Jan 22, 2018 at 2:50 PM, Viktor Dukhovni wrote: > > >> On Jan 22, 2018, at 12:07 PM, Gladewitz, Robert via openssl-users wrote: >> >> the problem is, that i cant change the cisco implementation :-(. > > YOU DO NOT need to change the Cisco implementation. > >> Cisco tell me, the capf implemtation is following all rfc documents. > > Nothing Cisco is telling you requires your issuing CA to have an > extended key usage listing just "TLS Web Server Authentication". > >> If you are right, >> i cant use any freeradius implementation, because there are based on >> openssl. There is no option in freeradius, to ignore some think like this. > > Your problem is a misconfigured CA certificate. Make sure your *CA* > certificate has no extended key usage specified, OR has *all* the key > usages specified that are required by any leaf certificate it will issue. This is wrong. The CA is not misconfigured. >> For my understanding, CA certificate may have these exteded keys - it's just >> something out of the ordinary. > > The extended key usages on the CA are interpreted to LIMIT the key usages > of certificates it can issue. You can certainly use this extension, but > then expect the CA to be invalid for key usages you did not list. This is wrong. The KU and EKU bits are not interpreted that way. Here's the standards OpenSSL claims to implement: https://www.openssl.org/docs/standards.html. Jeff From openssl-users at dukhovni.org Mon Jan 22 22:02:35 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 22 Jan 2018 17:02:35 -0500 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> Message-ID: <3E309BC2-2ABB-4E0D-98E0-06573846794D@dukhovni.org> > On Jan 22, 2018, at 3:42 PM, Jeffrey Walton wrote: > >> Your problem is a misconfigured CA certificate. Make sure your *CA* >> certificate has no extended key usage specified, OR has *all* the key >> usages specified that are required by any leaf certificate it will issue. > > This is wrong. The CA is not misconfigured. You might say so, and yet, with more than just OpenSSL, the CA is not suitable for issuing leaf certificates that are not included in its extended key usage. This is a de facto standard. >>> For my understanding, CA certificate may have these exteded keys - it's just >>> something out of the ordinary. >> >> The extended key usages on the CA are interpreted to LIMIT the key usages >> of certificates it can issue. You can certainly use this extension, but >> then expect the CA to be invalid for key usages you did not list. > > This is wrong. The KU and EKU bits are not interpreted that way. They plainly *are* interpreted in that way, just not by RFC5280, but that's not the point. > Here's the standards OpenSSL claims to implement: > https://www.openssl.org/docs/standards.html. So do many others, and yet when the RFC is impractical, a more practical alternative is implemented. -- Viktor. From openssl-users at dukhovni.org Mon Jan 22 22:11:01 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 22 Jan 2018 17:11:01 -0500 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> Message-ID: <6940C476-5830-42BB-8D53-78F92BD99333@dukhovni.org> > On Jan 22, 2018, at 3:21 PM, Gladewitz, Robert via openssl-users wrote: > > Sorry, I did not mean to upset you. I am not at all upset, just trying to be clear. > Somehow I seem to have misunderstood something. Yes. Your CA has an EKU extension. It should either not be present, or list *all* the purposes for which the CA will issue leaf certificates. If you're right (I don't think this is actually true) that the CA must have "TLS Web Server Authentication" in its EKU (why?), then it must also have at least "TLS Web Client Authentication", to allow the CA to be used to authenticate TLS clients. > The CAPF certificate is the CA certificate he goes for? > Cisco states that this certificate requires both CA and > the extended key "TLS Web Server Authentification"? I bet that only the leaf certificate needs "TLS Web Server Authentification", but if for some reason the CA certificate also needs "TLS Web Server Authentification" then you'll need to also include "TLS Web Client Authentification" (in the CA certificate). -- Viktor. From uri at ll.mit.edu Mon Jan 22 22:15:01 2018 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 22 Jan 2018 22:15:01 +0000 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: <3E309BC2-2ABB-4E0D-98E0-06573846794D@dukhovni.org> References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> <3E309BC2-2ABB-4E0D-98E0-06573846794D@dukhovni.org> Message-ID: <43AC28A2-62B8-4E19-8512-2B30D6CCDE98@ll.mit.edu> > Here's the standards OpenSSL claims to implement: > https://www.openssl.org/docs/standards.html. So do many others, and yet when the RFC is impractical, a more practical alternative is implemented. I did not see RFC 5280 in the list of the implemented/supported standards. (Yes I know, theoretically 5280 obsoletes and supersedes 3280 and 4630, but support of it isn?t claimed?) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5211 bytes Desc: not available URL: From rsalz at akamai.com Tue Jan 23 02:01:05 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 23 Jan 2018 02:01:05 +0000 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: <43AC28A2-62B8-4E19-8512-2B30D6CCDE98@ll.mit.edu> References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> <3E309BC2-2ABB-4E0D-98E0-06573846794D@dukhovni.org> <43AC28A2-62B8-4E19-8512-2B30D6CCDE98@ll.mit.edu> Message-ID: > Here's the standards OpenSSL claims to implement: Read the whole text. It doesn?t say anything like ?claims to implement.? From noloader at gmail.com Tue Jan 23 02:17:40 2018 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 22 Jan 2018 21:17:40 -0500 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> <3E309BC2-2ABB-4E0D-98E0-06573846794D@dukhovni.org> <43AC28A2-62B8-4E19-8512-2B30D6CCDE98@ll.mit.edu> Message-ID: On Mon, Jan 22, 2018 at 9:01 PM, Salz, Rich via openssl-users wrote: > > > Here's the standards OpenSSL claims to implement: > > Read the whole text. It doesn?t say anything like ?claims to implement.? My bad. Here's the corrected text: This page is a partial list of the specifications that are relevant to OpenSSL I don't see CA/Browser Forums listed, but I do see RFC 3280 listed. And there are no notes on issuing polices, which is the matter at hand. No reasonable person would expect OpenSSL to cite 61 RFCs, including the IETF's PKIX RFCs, and not use PKIX issuing policies. I'm befuddled someone thought and others agreed it was OK to break a worldwide standard. The purpose of the standard is to ensure interoperability. The break is a throwback to the verify=false days for folks who needs things to "just work". Jeff From rsalz at akamai.com Tue Jan 23 02:27:14 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 23 Jan 2018 02:27:14 +0000 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> <3E309BC2-2ABB-4E0D-98E0-06573846794D@dukhovni.org> <43AC28A2-62B8-4E19-8512-2B30D6CCDE98@ll.mit.edu> Message-ID: ? I don't see CA/Browser Forums listed, but I do see RFC 3280 listed. The page also says it?s ?casually maintained.? Feel free to create a PR on openssl/web repo. :) IETF RFC?s aren?t perfect; that?s why there are errata. Dragging this all the way to ?we?re ignoring the words? is not nor accurate. Someone who wants to argue that OpenSSL is doing the wrong thing here, should go to the IETF LAMPS WG and raise the issue. From noloader at gmail.com Tue Jan 23 02:39:15 2018 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 22 Jan 2018 21:39:15 -0500 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> <3E309BC2-2ABB-4E0D-98E0-06573846794D@dukhovni.org> <43AC28A2-62B8-4E19-8512-2B30D6CCDE98@ll.mit.edu> Message-ID: On Mon, Jan 22, 2018 at 9:27 PM, Salz, Rich wrote: > ? I don't see CA/Browser Forums listed, but I do see RFC 3280 listed. > > The page also says it?s ?casually maintained.? Feel free to create a PR on openssl/web repo. :) > > IETF RFC?s aren?t perfect; that?s why there are errata. Dragging this all the way to ?we?re ignoring the words? is not nor accurate. Someone who wants to argue that OpenSSL is doing the wrong thing here, should go to the IETF LAMPS WG and raise the issue. If OpenSSL want to change the standard so that it aligns with the project's implementation then the project should go to LAMP. Otherwise, the project is acting without authority. OpenSSL cannot arbitrarily decide to do something else on a suggestion or a whim. You know, this issue could have been side stepped by providing both behaviors, making one default, and allowing the user to make the choice. Instead, the project wrapped its arms around the solution that broke interop. I can't help but wonder, doesn't anyone think these decisions through? Thank god Andy has not broken AES interop by whitening AES keys because some people think it is a good idea. Jeff From rsalz at akamai.com Tue Jan 23 02:55:26 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 23 Jan 2018 02:55:26 +0000 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> <3E309BC2-2ABB-4E0D-98E0-06573846794D@dukhovni.org> <43AC28A2-62B8-4E19-8512-2B30D6CCDE98@ll.mit.edu> Message-ID: I think this discussion is getting a little hot and bothered. Have a good night. From openssl-users at dukhovni.org Tue Jan 23 03:04:05 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 22 Jan 2018 22:04:05 -0500 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> <3E309BC2-2ABB-4E0D-98E0-06573846794D@dukhovni.org> <43AC28A2-62B8-4E19-8512-2B30D6CCDE98@ll.mit.edu> Message-ID: > On Jan 22, 2018, at 9:39 PM, Jeffrey Walton wrote: > > If OpenSSL want to change the standard so that it aligns with the > project's implementation then the project should go to LAMP. > Otherwise, the project is acting without authority. OpenSSL cannot > arbitrarily decide to do something else on a suggestion or a whim. There is no "authority", nor is there an "Internet police". > You know, this issue could have been side stepped by providing both > behaviors, making one default, and allowing the user to make the > choice. Instead, the project wrapped its arms around the solution that > broke interop. Actually, IIRC Mozilla's NSS and Microsoft's CAPI do the same thing. So it is unclear where exactly we're breaking "interop". > I can't help but wonder, doesn't anyone think these decisions through? This was thought through and discussed. I brought to the team's attention: http://www-archive.mozilla.org/projects/security/pki/nss/tech-notes/tn3.html The following table shows the OIDs recognized in the extended key usage extension, and how they map to cert types and key usages for CA and non-CA certs. extended key usage OID non-CA cert CA cert ----------------------------------- -------------- ---------------- SEC_OID_EXT_KEY_USAGE_EMAIL_PROTECT EMAIL_CA EMAIL_CA SEC_OID_EXT_KEY_USAGE_SERVER_AUTH SSL_SERVER SSL_CA SEC_OID_EXT_KEY_USAGE_CLIENT_AUTH SSL_CLIENT SSL_CA SEC_OID_EXT_KEY_USAGE_CODE_SIGN OBJECT_SIGNING OBJECT_SIGNING_CA SEC_OID_EXT_KEY_USAGE_TIME_STAMP TIME_STAMP TIME_STAMP SEC_OID_OCSP_RESPONDER OCSP_RESPONDER OCSP_RESPONDER For CA certs in the cert chain, the requirements are: Cert Usage Requried Key Usage Required Cert Type -------------------- -------------------- ----------------------- SSLServerWithStepUp: GOVT_APPROVED AND CERT_SIGN; SSL_CA; SSLClient: CERT_SIGN; SSL_CA; SSLServer: CERT_SIGN; SSL_CA; SSLCA: CERT_SIGN; SSL_CA; EmailSigner: CERT_SIGN; EMAIL_CA or SSL_CA EmailRecipient: CERT_SIGN; EMAIL_CA or SSL_CA ObjectSigner: CERT_SIGN; OBJECT_SIGNING_CA; UsageAnyCA: CERT_SIGN; OBJECT_SIGNING_CA OR EMAIL_CA OR SSL_CA; When NSS is asked to verify the validity of a certificate chain, it verifies the validity of that cert chain for a particular purpose, known as a SECCertUsage, as of a specific date and time. The list of known SECCertUsages is short: certUsageSSLClient ........... An SSL client authentication cert certUsageSSLServer ........... An ordinary SSL server cert certUsageSSLServerWithStepUp.. An SSL server cert that allows export clients to use strong crypto. certUsageSSLCA ............... An intermediate or root CA cert allowed to issue SSL client or SSL server certs or other intermediate SSL CA certs. certUsageEmailSigner ......... Used to verify S/MIME email signatures certUsageEmailRecipient ...... Used to encrypt S/MIME emails. certUsageObjectSigner ........ Used to verify signatures on files of executable code, e.g. jar files. certUsageStatusResponder ..... Used by an OCSP responder certUsageVerifyCA ............ A CA of any kind. and: https://www.ietf.org/mail-archive/web/pkix/current/msg32409.html Frequently Asked Questions RFC 5280 reads "In general, this extension will appear only in end entity certificates". Is it non-standard to have EKU in intermediate certificates, and will client software break when receiving such a certificate chain? o Inclusion of EKU in CA certificates is generally allowed. NSS and CryptoAPI both treat the EKU extension in intermediate certificates as a constraint on the permitted EKU OIDs in end-entity certificates. Browsers and certificate client software have been using EKU in intermediate certificates, and it has been common for enterprise subordinate CAs in Windows environments to use EKU in their intermediate certificates to constrain certificate issuance. Therefore, it is unlikely that using EKU in intermediate certificates would break other client software. o The use of the EKU extension in intermediate certificates was discussed at length in the mozilla.dev.security.policy forum. We considered other options, such as standardizing a set of Policy OIDs or un-deprecating NetscapeCertType. The discussion included the concern that one interpretation of RFC 5280 is that this use of EKU is non-standard, but it was decided that the RFCs are not clear, and perhaps conflicting, in regards to EKUs in CA certificates. In the discussion it was pointed out that other major browsers and client software already support this use of EKU but do not recognize NetscapeCertType; and we also recognized the difficulties involved in standardizing a set of Policy OIDs. The conclusion of the discussion was that EKU is the best tool for technically constraining the types of certificates that an intermediate certificate may sign. I am sorry to hear that you're saddened by my lack of fealty to RFC5280, but I find real-world considerations more compelling. The OP in this thread has perfectly reasonable work-arounds, the main obstacle seems to be a language barrier more than anything else. Over and out. -- Viktor. From noloader at gmail.com Tue Jan 23 03:15:41 2018 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 22 Jan 2018 22:15:41 -0500 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> <3E309BC2-2ABB-4E0D-98E0-06573846794D@dukhovni.org> <43AC28A2-62B8-4E19-8512-2B30D6CCDE98@ll.mit.edu> Message-ID: On Mon, Jan 22, 2018 at 10:04 PM, Viktor Dukhovni wrote: > > >> On Jan 22, 2018, at 9:39 PM, Jeffrey Walton wrote: >> >> If OpenSSL want to change the standard so that it aligns with the >> project's implementation then the project should go to LAMP. >> Otherwise, the project is acting without authority. OpenSSL cannot >> arbitrarily decide to do something else on a suggestion or a whim. > > There is no "authority", nor is there an "Internet police". "Authority" as in governance and policies and procedures. >> You know, this issue could have been side stepped by providing both >> behaviors, making one default, and allowing the user to make the >> choice. Instead, the project wrapped its arms around the solution that >> broke interop. > > Actually, IIRC Mozilla's NSS and Microsoft's CAPI do the same thing. > So it is unclear where exactly we're breaking "interop". > >> I can't help but wonder, doesn't anyone think these decisions through? > > This was thought through and discussed. I brought to the team's > attention: > > http://www-archive.mozilla.org/projects/security/pki/nss/tech-notes/tn3.html Apples and oranges. Browsers use the CA/B baseline requirements. What does it have to do the the IETF, the RFCs and PKIX? > I am sorry to hear that you're saddened by my lack of fealty to > RFC5280, but I find real-world considerations more compelling. > The OP in this thread has perfectly reasonable work-arounds, > the main obstacle seems to be a language barrier more than > anything else. Yeah, the real world decision just decision just derailed the use of crypto, not improve upon it. I've seen this so many times in the past. It is the result of allowing engineers drive requirements. Jeff From openssl-users at dukhovni.org Tue Jan 23 04:24:20 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 22 Jan 2018 23:24:20 -0500 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> <3E309BC2-2ABB-4E0D-98E0-06573846794D@dukhovni.org> <43AC28A2-62B8-4E19-8512-2B30D6CCDE98@ll.mit.edu> Message-ID: <0530F8C1-3E0F-4500-B067-1F306924C5DB@dukhovni.org> > On Jan 22, 2018, at 10:15 PM, Jeffrey Walton wrote: > >> I am sorry to hear that you're saddened by my lack of fealty to >> RFC5280, but I find real-world considerations more compelling. >> The OP in this thread has perfectly reasonable work-arounds, >> the main obstacle seems to be a language barrier more than >> anything else. > > Yeah, the real world decision just decision just derailed the use of > crypto, not improve upon it. > > I've seen this so many times in the past. It is the result of allowing > engineers drive requirements. For the record: The only change in OpenSSL 1.1.0 is that the EKU-based policy that oddly applied only to untrusted certificates in 1.0.2 and earlier now applies consistently whether the certificate comes from the trust store or the remote peer. I can demonstrate the issue with the OP's chain when only the root CA is in the trust store: $ openssl verify -CAfile ca2.pem -untrusted ca1.pem -purpose sslclient SEP64A0E714844E-L1.pem SEP64A0E714844E-L1.pem: C = DE, ST = Sachsen, L = Leipzig, O = DBFZ Deutsches Biomasseforschungszentrum gGmbH, OU = IT, CN = CAPF-91d43ef6 error 26 at 1 depth lookup:unsupported certificate purpose The "ca1.pem" file is the OP's intermediate CA, and the "ca2.pem" file is the OP's root CA. Repeating the same test with the purpose changed to "sslserver" works as expected: $ openssl verify -CAfile ca2.pem -untrusted ca1.pem -purpose sslserver SEP64A0E714844E-L1.pem SEP64A0E714844E-L1.pem: OK The only change in 1.1.0 is fixing a bug that resulted in inconsistent handling of intermediate CAs depending on whether they were processed from the list provided by the peer or from the trust store. Restricting CA purpose based on EKU dates back to before 1.0.0. You may not care, but others may find this information useful. Really over and out this time... -- -- Viktor. From grace.priscilla at gmail.com Tue Jan 23 10:22:20 2018 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Tue, 23 Jan 2018 15:52:20 +0530 Subject: [openssl-users] Information to detach a BIO from fd In-Reply-To: References: <26570.1515675640@obiwan.sandelman.ca> <25525.1515879755@obiwan.sandelman.ca> Message-ID: Hi All, We resolved the issue by using SSL_peek which does not clear the bio after read and we could also get the peer information after calling this API. This helped us differentiate the peer connections. Thanks for the multiple suggestions provided. Thanks, Grace On Tue, Jan 16, 2018 at 12:34 PM, Grace Priscilla Jero < grace.priscilla at gmail.com> wrote: > Hi Michael, > The connections are from different peers and we are unable to use same > SSL. > Also getpeername on the UDP does not work as we have enabled SSL for the > sender peer socket. > Any suggestions to resolve this? > > When we have 2 SSL associated to a fd through BIO, on which BIO does the > openssl do the read? > Can we restrict it to read from an SSL of user choice? > > We are just looking for an option to distinguish DTLS on UDP connections. > We were'nt successful in doing it with DTLSv1_listen as it hangs on the SSL. > > Thanks, > Grace > > On Sun, Jan 14, 2018 at 3:12 AM, Michael Richardson > wrote: > >> >> Grace Priscilla Jero wrote: >> > Below is our scenario on DTLS. >> >> > We have multiple connections to the same server. We have mapped one >> fd >> > to the ssl in the server to receive all connections. >> >> Are these connections from the same client (same 5-tuple), or are you just >> talking about multiple clients? >> >> > Whenever a connect is initiated from any client we need to know if >> it >> > is already connected client or a new client. We are doing this by >> >> > * creating bio/ssl each time on the same fd >> >> > * fetching the peer using BIO_dgram_get_peer after ssl_accept >> >> > * Comparing it to the internally maintained list of peer >> >> > * If it is a new peer we continue with handshake but if it is old >> peer >> > we do the ssl_read. >> >> I don't think this is going to work. >> >> A UDP/DTLS server has two choices: >> >> 1) read all the packets on a unconnected socket and demultiplex them into >> appropriate BIOs/SSL structures. I did not find an obvious way to do >> this, I think that a new BIO type would make this easiest. >> >> It also has the downside that it's hard to spread the load across >> multiple processes, although with the right locking multiple threads >> would >> likely work. >> >> 2) after each call to DTLSv1_listen(), set up a new fd that is >> bind()/connect()ed to >> the peer (by 5-tuple) so that all traffic from that peer arrives on the >> correct FD. >> AFAIK, there isn't anything to forbid two DTLS sessions between >> identical >> UDP sockets, as they could have differing session cookies, etc. >> >> >> > The problem is that there are 2 bio/ssl that gets created for the >> same >> > fd and the peer end up writing to one of them and we don't get the >> > message on the intended ssl. Hence we are checking for a way to >> detach >> > and remove the ssl/bio that gets created in already connected case. >> >> I don't think that is going to work. >> >> -- >> ] Never tell me the odds! | ipv6 mesh >> networks [ >> ] Michael Richardson, Sandelman Software Works | network >> architect [ >> ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on >> rails [ >> >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Tue Jan 23 12:27:10 2018 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Tue, 23 Jan 2018 15:27:10 +0300 Subject: [openssl-users] [openssl-dev] Blog post; changing in email, crypto policy, etc In-Reply-To: <1782817.M3ba5i8hfn@pintsize.usersys.redhat.com> References: <1782817.M3ba5i8hfn@pintsize.usersys.redhat.com> Message-ID: Hello, On Tue, Jan 23, 2018 at 3:00 PM, Hubert Kario wrote: > On Friday, 19 January 2018 18:34:57 CET Salz, Rich via openssl-dev wrote: > > There?s a new blog post at > > https://www.openssl.org/blog/blog/2018/01/18/f2f-london/ > > > We decided to increase our use of GitHub. In addition to asking that all > bug > > reports and enhancement requests be reported as issues, we now want all > > major code proposals to be discussed as issues before a large pull > request > > shows up. This will let the community discuss the feature, offer input on > > design and such, before having code to look at. We hope this will let us > > all first look at the bigger picture, before getting bogged down in the > > weeds of line-by-line code reviews. > > does that mean I have to subscribe to all notifications from the openssl > github project to notice them? that's really suboptimal > Totally agree. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Gladewitz at dbfz.de Tue Jan 23 12:31:56 2018 From: Robert.Gladewitz at dbfz.de (Gladewitz, Robert) Date: Tue, 23 Jan 2018 12:31:56 +0000 Subject: [openssl-users] WG: TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: <0530F8C1-3E0F-4500-B067-1F306924C5DB@dukhovni.org> References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> <3E309BC2-2ABB-4E0D-98E0-06573846794D@dukhovni.org> <43AC28A2-62B8-4E19-8512-2B30D6CCDE98@ll.mit.edu> <0530F8C1-3E0F-4500-B067-1F306924C5DB@dukhovni.org> Message-ID: Dear helpful people, The problem is now solved by a workaround based on a new CAPF certificate. That is that. Concerning the discussion here, i (representing my supervisor) would like to pinpoint 2 facts that arouse: First and foremost the attached cacert.capf.pem is based on a Cisco __System generated__ CSR and results in a certificate with the attributes: X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign X509v3 Extended Key Usage: critical TLS Web Server Authentication This very certificate is than used by the Cisco __system__ to issue telephone/end-entity certificates in the likes of the attached SEPxxxxxxx-L1.pem. These end-entity certificates have the following attributes: X509v3 Key Usage Digital Signature, Key Encipherment X509v3 Extended Key Usage TLS Web Server Authentication, TLS Web Client Authentication, IPSec End System This is just wrong and we know that. But the Cisco System does it anyway. Despite being wrong it is also absolutely irrelevant, because FreeRADIUS retrieves the OpenSSL rejection of the cacert.capf.pem before any end-entity certifcate is ever seen. We now have a very plain cacert.capf.pem. It only shows the following attributes: X509v3 Key Usage: critical Certificate Sign, CRL Sign and things work. So to sum up: there is a mistake, that we know of, but really it is not in our hands to change it. And we do not need to change it, because it is of no concern to the problem at hand. Secondly the presented cacert.capf.pem is (by itself) a valid certificate. It does not present a mistake. We should also not need to change it - but we do. Why? Having read all the discussion i do not know why. It is a CA certificate and Cisco somehow restricts this CA certificate to a certain chosen purpose. It is also ok to issue an intermediate CA certificate with pathlen=5 and then issue right beneath it a intermediate CA certificate with pathlen=0 instead of 4 to further restrict. Restriction is a tool to reach more secure environments. The keyUsage attributes are a way to use the tool of restriction. OpenSSL should not interfere at this point. This is my take on this topic. I do thank you very much for your help and effort. Even if some of you see the topic different, i like the fact that we discussed this really vividly. Robert -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6245 bytes Desc: not available URL: From noloader at gmail.com Tue Jan 23 14:05:36 2018 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 23 Jan 2018 09:05:36 -0500 Subject: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed Message-ID: On Sun, Jan 21, 2018 at 6:38 PM, Salz, Rich via openssl-users wrote: > ? The sensible thing at this point is to publish an update to RFC5280 > that accepts reality. > > Yes, and there?s an IETF place to do that if anyone is interested; see the LAMPS working group. Related, the subject came up recently on the PKIX mailing list: "Next edition of X.509", https://www.ietf.org/mail-archive/web/pkix/current/msg33478.html . https://www.ietf.org/mail-archive/web/pkix/current/msg33489.html was a proposal to modify the text. The modifications appear to propose KU and EKU cast a wider net to accommodate IoT gadgets. https://www.ietf.org/mail-archive/web/pkix/current/msg33490.html was a comment to avoid the modification. The objection stated to an OID for the new usages to accommodate the use cases. Another thread of interest from SAAG is "Considerations about the need to resume PKIX work", https://mailarchive.ietf.org/arch/msg/saag/BJWLw-XZvq_fgCYDldCDLVamNbg There does not seem to be a lot of interest in revising PKIX. I persoanlly find it disappointing because it seems like it is the wild, wild west to me. Jeff From rsalz at akamai.com Tue Jan 23 14:22:13 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 23 Jan 2018 14:22:13 +0000 Subject: [openssl-users] [openssl-dev] Blog post; changing in email, crypto policy, etc In-Reply-To: <1782817.M3ba5i8hfn@pintsize.usersys.redhat.com> References: <1782817.M3ba5i8hfn@pintsize.usersys.redhat.com> Message-ID: <8A96BA0F-A92C-45AE-A780-A84597827C4B@akamai.com> You should be able to just watch the openssl repo (the eyeball/watch notice in the upper-right side) On 1/23/18, 7:00 AM, "Hubert Kario" wrote: On Friday, 19 January 2018 18:34:57 CET Salz, Rich via openssl-dev wrote: > There?s a new blog post at > https://www.openssl.org/blog/blog/2018/01/18/f2f-london/ > We decided to increase our use of GitHub. In addition to asking that all bug > reports and enhancement requests be reported as issues, we now want all > major code proposals to be discussed as issues before a large pull request > shows up. This will let the community discuss the feature, offer input on > design and such, before having code to look at. We hope this will let us > all first look at the bigger picture, before getting bogged down in the > weeds of line-by-line code reviews. does that mean I have to subscribe to all notifications from the openssl github project to notice them? that's really suboptimal -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic From rsalz at akamai.com Tue Jan 23 14:36:26 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 23 Jan 2018 14:36:26 +0000 Subject: [openssl-users] [openssl-dev] Blog post; changing in email, crypto policy, etc In-Reply-To: <2187057.qOMJW3ZjMn@pintsize.usersys.redhat.com> References: <1782817.M3ba5i8hfn@pintsize.usersys.redhat.com> <8A96BA0F-A92C-45AE-A780-A84597827C4B@akamai.com> <2187057.qOMJW3ZjMn@pintsize.usersys.redhat.com> Message-ID: ? this feature sends notifications about _all_ conversations happening. For me, I get the actual comments that are posted. Don?t you? On the mailing list, you have to explicitly mark/junk conversation threads in your mail program. You would still have to do that here. I don?t understand what you see as different? From mark at openssl.org Tue Jan 23 14:45:32 2018 From: mark at openssl.org (Mark J Cox) Date: Tue, 23 Jan 2018 14:45:32 +0000 Subject: [openssl-users] Fwd: Simplifying the security policy In-Reply-To: References: Message-ID: At our face to face we took a look at the security policy and noticed that it contained a lot of background details of why we decided on the policy that we did (in light mostly of the issues back in 2014) as well as a bit of repeated and redundant information. We've taken some time to simplify it, clean it up, and remove the redundant sections with the intention of not changing any of the actual policy. This passed an OMC vote and is now updated here: https://www.openssl.org/policies/secpolicy.html Also as a reminder, last week we also explained a slight increase in the pre-disclosure time: https://www.openssl.org/blog/blog/2018/01/18/f2f-london/ Detailed changes: - removed introductory wordy paragraphs - how to report issues is already covered on another page so just replace with link - consolidate who we tell about issues into new 'triage' section (it was in 3 different places) explain why we work with those folks - take out most of the background section. Where the background forms part of our reasons for doing something include them in a new section 'principles' at the end with the same wording. -- removed "the more people you tell" leak statement -- consolidated how we benefit from prenotifying people into earlier section -- removed competitive phrases -- removed why we don't run our own prenotification list and who we've tired to use in the past - no changes to severity wording - simplify prenotification section wording without changing what we do or who we tell Mark From bhat.jayalakshmi at gmail.com Tue Jan 23 16:48:21 2018 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Tue, 23 Jan 2018 22:18:21 +0530 Subject: [openssl-users] AES-CTR-256 test suite for FIPS Message-ID: Hi All, We are using DRBG using AES-CTR-256 in FIPS mode. I could find test suite/file that takes CAVP test request and generating the response for DRBG using AES-CTR-256. However I am not finding any test suite/file that validates AES-CTR 128/192/256 bits. Please can any one let me know while test suite/file to validate AES-CTR. Regards Jayalakshmi -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Jan 23 17:43:30 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 23 Jan 2018 12:43:30 -0500 Subject: [openssl-users] WG: TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> <3E309BC2-2ABB-4E0D-98E0-06573846794D@dukhovni.org> <43AC28A2-62B8-4E19-8512-2B30D6CCDE98@ll.mit.edu> <0530F8C1-3E0F-4500-B067-1F306924C5DB@dukhovni.org> Message-ID: > On Jan 23, 2018, at 7:31 AM, Gladewitz, Robert via openssl-users wrote: > > Despite being wrong it is also absolutely irrelevant, because FreeRADIUS > retrieves the OpenSSL rejection of the cacert.capf.pem before any end-entity > certifcate is ever seen. This is almost certainly not the case. Why would FreeRADIUS be validating a stand-alone CA certificate that is not part of a chain from a leaf certificate to a trust anchor? The chain is validated for a particular purpose, presumably "TLS client" (the error message in the subject line of this thread is about the processing of a client certificate). > We now have a very plain cacert.capf.pem. It only shows the following > attributes: > X509v3 Key Usage: critical > Certificate Sign, CRL Sign > and things work. Great! This confirms that the issue was the restricted EKU of the intermediate CA certificate. > So to sum up: there is a mistake, that we know of, but really it is not in > our hands to change it. And we do not need to change it, because it is of no > concern to the problem at hand. The previous CA certificate was explicitly not suitable for verifying TLS clients, based on the de facto interpretation of EKU in CA certificates in OpenSSL and various other TLS libraries. So the issue was very much a "concern to the problem at hand". > Secondly the presented cacert.capf.pem is (by itself) a valid certificate. It is a valid intermediate CA certificate, that is (de facto) constrained to be used only for verifying for TLS server certificates, and NOT TLS client certificates. > It does not present a mistake. We should also not need to change it - but we > do. Why? You had to change it because you want to use this CA to issue TLS client certificates, and so its EKU needs to either be absent or to explicitly permit TLS client authentication. > Having read all the discussion i do not know why. Mostly because despite my best attempts to explain the above, perhaps a language barrier, and/or my inability to explain the issue sufficiently clearly, is preventing the reasons from being communicated effectively. > It is a CA certificate and Cisco somehow restricts this CA certificate to > a certain chosen purpose. Perhaps you mean that default software settings create such a certificate. If so, please raise this as a bug with the software vendor. As you've already seen deploying a CA without an EKU works, so the previous EKU is not in fact a requirement. > OpenSSL should not interfere at this point. OpenSSL implements a widely practiced de facto CA certificate "purpose" policy based on the optional EKU extension in the CA certificate. If you don't to restrict the purposes for which a CA can issue EE certificates (directly or indirectly), then DO NOT include an EKU in the CA certificate. If you do want to limit the CA to issue only certificates for particular purposes, then include all (and only) those purposes in the EKU. Good luck. And thanks for reporting this, this discussion should help other users to quickly resolve similar issues in the future. -- Viktor. From noloader at gmail.com Tue Jan 23 20:07:51 2018 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 23 Jan 2018 15:07:51 -0500 Subject: [openssl-users] WG: TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> <3E309BC2-2ABB-4E0D-98E0-06573846794D@dukhovni.org> <43AC28A2-62B8-4E19-8512-2B30D6CCDE98@ll.mit.edu> <0530F8C1-3E0F-4500-B067-1F306924C5DB@dukhovni.org> Message-ID: On Tue, Jan 23, 2018 at 12:43 PM, Viktor Dukhovni wrote: > > >> On Jan 23, 2018, at 7:31 AM, Gladewitz, Robert via openssl-users wrote: >> >> Despite being wrong it is also absolutely irrelevant, because FreeRADIUS >> retrieves the OpenSSL rejection of the cacert.capf.pem before any end-entity >> certifcate is ever seen. > > This is almost certainly not the case. Why would FreeRADIUS be validating > a stand-alone CA certificate that is not part of a chain from a leaf > certificate to a trust anchor? The chain is validated for a particular > purpose, presumably "TLS client" (the error message in the subject line of > this thread is about the processing of a client certificate). > >> We now have a very plain cacert.capf.pem. It only shows the following >> attributes: >> X509v3 Key Usage: critical >> Certificate Sign, CRL Sign >> and things work. > > Great! This confirms that the issue was the restricted EKU of the > intermediate CA certificate. > >> So to sum up: there is a mistake, that we know of, but really it is not in >> our hands to change it. And we do not need to change it, because it is of no >> concern to the problem at hand. > > The previous CA certificate was explicitly not suitable for verifying TLS > clients, based on the de facto interpretation of EKU in CA certificates in > OpenSSL and various other TLS libraries. So the issue was very much a > "concern to the problem at hand". > >> Secondly the presented cacert.capf.pem is (by itself) a valid certificate. > > It is a valid intermediate CA certificate, that is (de facto) constrained > to be used only for verifying for TLS server certificates, and NOT TLS > client certificates. > >> It does not present a mistake. We should also not need to change it - but we >> do. Why? > > You had to change it because you want to use this CA to issue TLS client > certificates, and so its EKU needs to either be absent or to explicitly > permit TLS client authentication. > > >> Having read all the discussion i do not know why. > > Mostly because despite my best attempts to explain the above, perhaps > a language barrier, and/or my inability to explain the issue sufficiently > clearly, is preventing the reasons from being communicated effectively. > >> It is a CA certificate and Cisco somehow restricts this CA certificate to >> a certain chosen purpose. > > Perhaps you mean that default software settings create such a certificate. > If so, please raise this as a bug with the software vendor. As you've > already seen deploying a CA without an EKU works, so the previous EKU is > not in fact a requirement. > >> OpenSSL should not interfere at this point. > > OpenSSL implements a widely practiced de facto CA certificate "purpose" > policy based on the optional EKU extension in the CA certificate. If > you don't to restrict the purposes for which a CA can issue EE certificates > (directly or indirectly), then DO NOT include an EKU in the CA certificate. > If you do want to limit the CA to issue only certificates for particular > purposes, then include all (and only) those purposes in the EKU. > > Good luck. And thanks for reporting this, this discussion should > help other users to quickly resolve similar issues in the future. Your arguments are fallacious. How the browsers do things does not constitute the "de facto" standard. Your just begging the claim. The docs have _not_ changed: https://www.openssl.org/docs/standards.html. Jeff From openssl-users at dukhovni.org Tue Jan 23 20:33:38 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 23 Jan 2018 15:33:38 -0500 Subject: [openssl-users] WG: TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> <3E309BC2-2ABB-4E0D-98E0-06573846794D@dukhovni.org> <43AC28A2-62B8-4E19-8512-2B30D6CCDE98@ll.mit.edu> <0530F8C1-3E0F-4500-B067-1F306924C5DB@dukhovni.org> Message-ID: <2BD5DBA8-F429-40FE-9A20-ABB7F05B8FBF@dukhovni.org> > On Jan 23, 2018, at 3:07 PM, Jeffrey Walton wrote: > > Your arguments are fallacious. How the browsers do things does not > constitute the "de facto" standard. Your just begging the claim. You're trolling. I'm no longer playing along, better things to do... -- Viktor. From rsalz at akamai.com Tue Jan 23 20:45:50 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 23 Jan 2018 20:45:50 +0000 Subject: [openssl-users] WG: TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> <3E309BC2-2ABB-4E0D-98E0-06573846794D@dukhovni.org> <43AC28A2-62B8-4E19-8512-2B30D6CCDE98@ll.mit.edu> <0530F8C1-3E0F-4500-B067-1F306924C5DB@dukhovni.org> Message-ID: <3DCFB8F8-9566-4517-8C81-CDDA1F1DAB85@akamai.com> ? The docs have _not_ changed: https://www.openssl.org/docs/standards.html. Nor is there any need for that page to change. READ WHAT IT SAYS. From noloader at gmail.com Tue Jan 23 21:23:17 2018 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 23 Jan 2018 16:23:17 -0500 Subject: [openssl-users] WG: TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: <3DCFB8F8-9566-4517-8C81-CDDA1F1DAB85@akamai.com> References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> <3E309BC2-2ABB-4E0D-98E0-06573846794D@dukhovni.org> <43AC28A2-62B8-4E19-8512-2B30D6CCDE98@ll.mit.edu> <0530F8C1-3E0F-4500-B067-1F306924C5DB@dukhovni.org> <3DCFB8F8-9566-4517-8C81-CDDA1F1DAB85@akamai.com> Message-ID: On Tue, Jan 23, 2018 at 3:45 PM, Salz, Rich wrote: > ? The docs have _not_ changed: https://www.openssl.org/docs/standards.html. > > Nor is there any need for that page to change. READ WHAT IT SAYS. I'm surprised you are arguing against clear documentation on behaviors. Jeff From rsalz at akamai.com Tue Jan 23 21:33:51 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 23 Jan 2018 21:33:51 +0000 Subject: [openssl-users] WG: TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> <3E309BC2-2ABB-4E0D-98E0-06573846794D@dukhovni.org> <43AC28A2-62B8-4E19-8512-2B30D6CCDE98@ll.mit.edu> <0530F8C1-3E0F-4500-B067-1F306924C5DB@dukhovni.org> <3DCFB8F8-9566-4517-8C81-CDDA1F1DAB85@akamai.com> Message-ID: <31A001F9-EE58-44A1-A2B2-B9AA5BEF3A8B@akamai.com> On Tue, Jan 23, 2018 at 3:45 PM, Salz, Rich wrote: > ? The docs have _not_ changed: https://www.openssl.org/docs/standards.html. > > Nor is there any need for that page to change. READ WHAT IT SAYS. ? I'm surprised you are arguing against clear documentation on behaviors. There is no need to be surprised, because I am not doing that. The webpage says ?here?s a casually-maintained list of related standards or other useful information.? What on that webpage is wrong? You seem to be very very VERY upset by how OpenSSL implements one particular part of RFC 5280. Viktor has shown that it?s not just us, it?s other code as well. The original poster was able to live with OpenSSL?s implementation. You don?t like that code. So be it. From noloader at gmail.com Tue Jan 23 21:41:08 2018 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 23 Jan 2018 16:41:08 -0500 Subject: [openssl-users] WG: TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: <31A001F9-EE58-44A1-A2B2-B9AA5BEF3A8B@akamai.com> References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> <3E309BC2-2ABB-4E0D-98E0-06573846794D@dukhovni.org> <43AC28A2-62B8-4E19-8512-2B30D6CCDE98@ll.mit.edu> <0530F8C1-3E0F-4500-B067-1F306924C5DB@dukhovni.org> <3DCFB8F8-9566-4517-8C81-CDDA1F1DAB85@akamai.com> <31A001F9-EE58-44A1-A2B2-B9AA5BEF3A8B@akamai.com> Message-ID: On Tue, Jan 23, 2018 at 4:33 PM, Salz, Rich wrote: > On Tue, Jan 23, 2018 at 3:45 PM, Salz, Rich wrote: > > ? The docs have _not_ changed: https://www.openssl.org/docs/standards.html. > > > > Nor is there any need for that page to change. READ WHAT IT SAYS. > > ? I'm surprised you are arguing against clear documentation on behaviors. > > There is no need to be surprised, because I am not doing that. > > The webpage says ?here?s a casually-maintained list of related standards or other useful information.? What on that webpage is wrong? > > You seem to be very very VERY upset by how OpenSSL implements one particular part of RFC 5280. Viktor has shown that it?s not just us, it?s other code as well. The original poster was able to live with OpenSSL?s implementation. You don?t like that code. So be it. If that's your survey of the situation then it is wrong. No wonder Henson and Marquess left the project. I would get tired of the games, too. Jeff From rsalz at akamai.com Wed Jan 24 00:47:49 2018 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 24 Jan 2018 00:47:49 +0000 Subject: [openssl-users] WG: TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> <3E309BC2-2ABB-4E0D-98E0-06573846794D@dukhovni.org> <43AC28A2-62B8-4E19-8512-2B30D6CCDE98@ll.mit.edu> <0530F8C1-3E0F-4500-B067-1F306924C5DB@dukhovni.org> <3DCFB8F8-9566-4517-8C81-CDDA1F1DAB85@akamai.com> <31A001F9-EE58-44A1-A2B2-B9AA5BEF3A8B@akamai.com> Message-ID: > > You seem to be very very VERY upset by how OpenSSL implements one particular part of RFC 5280. Viktor has shown that it?s not just us, it?s other code as well. The original poster was able to live with OpenSSL?s implementation. You don?t like that code. So be it. > If that's your survey of the situation then it is wrong. Okay, please post a correction. From Robert.Gladewitz at dbfz.de Wed Jan 24 06:33:41 2018 From: Robert.Gladewitz at dbfz.de (Gladewitz, Robert) Date: Wed, 24 Jan 2018 06:33:41 +0000 Subject: [openssl-users] WG: TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> <3E309BC2-2ABB-4E0D-98E0-06573846794D@dukhovni.org> <43AC28A2-62B8-4E19-8512-2B30D6CCDE98@ll.mit.edu> <0530F8C1-3E0F-4500-B067-1F306924C5DB@dukhovni.org> Message-ID: <05cd87f1537740f6bb0d0e09ed046066@dbfz.de> Hallo Voktor, I had contact with the Freeradius group in this regard. At first we also assumed that something is wrong with the client certificate. But in TLS Freeradius uses the OpenSSL standard functions to identify and verify the client certificate. Exactly here only the CA certificate including the certificate chain is checked - then only in the second step, whether the certificate sent by the client belongs to the CA certificate. Yes, the language barriers are problematic - thanks anyway for your help. Nevertheless, a problem remains open for the Cisco CUCM users. If these use the certificate internally signed by Cisco, the attributes are set as in the discussion and can not be subsequently adapted in our case. This means that for these users only the change to a non openssl based application remains - really sad. Robert -----Urspr?ngliche Nachricht----- Von: openssl-users [mailto:openssl-users-bounces at openssl.org] Im Auftrag von Viktor Dukhovni Gesendet: Dienstag, 23. Januar 2018 18:44 An: openssl-users at openssl.org Betreff: Re: [openssl-users] WG: TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed > On Jan 23, 2018, at 7:31 AM, Gladewitz, Robert via openssl-users wrote: > > Despite being wrong it is also absolutely irrelevant, because > FreeRADIUS retrieves the OpenSSL rejection of the cacert.capf.pem > before any end-entity certifcate is ever seen. This is almost certainly not the case. Why would FreeRADIUS be validating a stand-alone CA certificate that is not part of a chain from a leaf certificate to a trust anchor? The chain is validated for a particular purpose, presumably "TLS client" (the error message in the subject line of this thread is about the processing of a client certificate). > We now have a very plain cacert.capf.pem. It only shows the following > attributes: > X509v3 Key Usage: critical > Certificate Sign, CRL Sign and things work. Great! This confirms that the issue was the restricted EKU of the intermediate CA certificate. > So to sum up: there is a mistake, that we know of, but really it is > not in our hands to change it. And we do not need to change it, > because it is of no concern to the problem at hand. The previous CA certificate was explicitly not suitable for verifying TLS clients, based on the de facto interpretation of EKU in CA certificates in OpenSSL and various other TLS libraries. So the issue was very much a "concern to the problem at hand". > Secondly the presented cacert.capf.pem is (by itself) a valid certificate. It is a valid intermediate CA certificate, that is (de facto) constrained to be used only for verifying for TLS server certificates, and NOT TLS client certificates. > It does not present a mistake. We should also not need to change it - > but we do. Why? You had to change it because you want to use this CA to issue TLS client certificates, and so its EKU needs to either be absent or to explicitly permit TLS client authentication. > Having read all the discussion i do not know why. Mostly because despite my best attempts to explain the above, perhaps a language barrier, and/or my inability to explain the issue sufficiently clearly, is preventing the reasons from being communicated effectively. > It is a CA certificate and Cisco somehow restricts this CA certificate > to a certain chosen purpose. Perhaps you mean that default software settings create such a certificate. If so, please raise this as a bug with the software vendor. As you've already seen deploying a CA without an EKU works, so the previous EKU is not in fact a requirement. > OpenSSL should not interfere at this point. OpenSSL implements a widely practiced de facto CA certificate "purpose" policy based on the optional EKU extension in the CA certificate. If you don't to restrict the purposes for which a CA can issue EE certificates (directly or indirectly), then DO NOT include an EKU in the CA certificate. If you do want to limit the CA to issue only certificates for particular purposes, then include all (and only) those purposes in the EKU. Good luck. And thanks for reporting this, this discussion should help other users to quickly resolve similar issues in the future. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6245 bytes Desc: not available URL: From openssl-users at dukhovni.org Wed Jan 24 07:10:53 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 24 Jan 2018 02:10:53 -0500 Subject: [openssl-users] WG: TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: <05cd87f1537740f6bb0d0e09ed046066@dbfz.de> References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> <3E309BC2-2ABB-4E0D-98E0-06573846794D@dukhovni.org> <43AC28A2-62B8-4E19-8512-2B30D6CCDE98@ll.mit.edu> <0530F8C1-3E0F-4500-B067-1F306924C5DB@dukhovni.org> <05cd87f1537740f6bb0d0e09ed046066@dbfz.de> Message-ID: > On Jan 24, 2018, at 1:33 AM, Gladewitz, Robert via openssl-users wrote: > > Nevertheless, a problem remains open for the Cisco CUCM users. If these use > the certificate internally signed by Cisco, the attributes are set as in the > discussion and can not be subsequently adapted in our case. This means that > for these users only the change to a non openssl based application remains - > really sad. Can you be a bit more explicit as to why these users cannot deploy a certificate chain via an alternate CA that does not have a problem EKU (just as you did)? Is it not possible to replace the intermediate CA certificate with one that either has no EKU or has a more complete EKU that lists both "serverAuth" and "clientAuth" (shorter OpenSSL names for the EKUs under discussion). There are surely some Cisco Engineers reading this list. Ideally someone from Cisco will reach out to the OpenSSL team (say myself) and we can help them update the product to avoid compatibility issues. I've posted a feedback comment at: https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/212214-Tech-Note-on-CAPF-Certificate-Signed-by.html#anc7 Perhaps they'll reach out. -- Viktor. From Robert.Gladewitz at dbfz.de Wed Jan 24 08:01:37 2018 From: Robert.Gladewitz at dbfz.de (Gladewitz, Robert) Date: Wed, 24 Jan 2018 08:01:37 +0000 Subject: [openssl-users] WG: TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed In-Reply-To: References: <5A62A9A6.3000708@frank4dd.com> <5A62B2F2.4000903@frank4dd.com> <815B2FC3-FF96-4887-A2EE-C83704FC0E6D@dukhovni.org> <77198a8e88cd4572a57d47bfde2da004@dbfz.de> <6B50AF0F-0905-4460-9F63-37D79A1F8385@dukhovni.org> <500FD9C3-852B-48C5-A26D-4C9E7C36CCF1@dukhovni.org> <1EE9CC61-C699-4BA9-B3DD-48CF7FA35C9B@dukhovni.org> <8C6E2FB1-0924-4019-9AB2-C692B0713106@akamai.com> <338b72764d06403ba52b8cddd67b602f@dbfz.de> <3E309BC2-2ABB-4E0D-98E0-06573846794D@dukhovni.org> <43AC28A2-62B8-4E19-8512-2B30D6CCDE98@ll.mit.edu> <0530F8C1-3E0F-4500-B067-1F306924C5DB@dukhovni.org> <05cd87f1537740f6bb0d0e09ed046066@dbfz.de> Message-ID: Hello Viktor, By default, many users use the CAPF certificates that themselves issue the CUCM devices. This means that the call managers will sign their own Reqest. For the users only the download of the CAPF certificates remains - a change of the iku is not possible any more. Replacing the CAPF certificates is no small expense. There seem to be many problems and dependencies. Our service provider needed more than two days to implement this cleanly with us. In addition, there are the risks that authentication at the infrastructure switches will fail and make phone calls throughout the enterprise no longer possible. Robert -----Urspr?ngliche Nachricht----- Von: openssl-users [mailto:openssl-users-bounces at openssl.org] Im Auftrag von Viktor Dukhovni Gesendet: Mittwoch, 24. Januar 2018 08:11 An: openssl-users at openssl.org Betreff: Re: [openssl-users] WG: TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed > On Jan 24, 2018, at 1:33 AM, Gladewitz, Robert via openssl-users wrote: > > Nevertheless, a problem remains open for the Cisco CUCM users. If > these use the certificate internally signed by Cisco, the attributes > are set as in the discussion and can not be subsequently adapted in > our case. This means that for these users only the change to a non > openssl based application remains - really sad. Can you be a bit more explicit as to why these users cannot deploy a certificate chain via an alternate CA that does not have a problem EKU (just as you did)? Is it not possible to replace the intermediate CA certificate with one that either has no EKU or has a more complete EKU that lists both "serverAuth" and "clientAuth" (shorter OpenSSL names for the EKUs under discussion). There are surely some Cisco Engineers reading this list. Ideally someone from Cisco will reach out to the OpenSSL team (say myself) and we can help them update the product to avoid compatibility issues. I've posted a feedback comment at: https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-co mmunications-manager-callmanager/212214-Tech-Note-on-CAPF-Certificate-Signed -by.html#anc7 Perhaps they'll reach out. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6245 bytes Desc: not available URL: From emreba at NETAS.com.tr Thu Jan 25 06:30:14 2018 From: emreba at NETAS.com.tr (Emre BAYRAM) Date: Thu, 25 Jan 2018 06:30:14 +0000 Subject: [openssl-users] Building/Running fips enabled Openssl application Message-ID: Hi there, To add our application openssl fips capabilities we did the followings . We have openssl-1.0.2n version and openssl-fips.2.0.16 version Firtsly : When we are compiling openssl and fips we run this commands : ./config ?shared --with-fipsdir=/root/openssl_files/ssl/fips2.0 -D_GNU_SOURCE Make Make install ./config fips --openssldir=/root/openssl_files/ssl --with-fipsdir=/root/openssl_files/ssl/fips2.0 -D_GNU_SOURCE Make Make install Secondly (openssl Test) : After that we test it with: OPENSSL_FIPS=1 ./openssl md5 It didn?t work as we expected ./openssl md5 It worked as we expected Thirdly (combine with our app): As you see above we install the opensl at this specific path ?/root/openssl_files/ssl? then we copy all files to application?s resource folder then we compile our application with openssl static libraries (*.a). Compile command : LIBS = -lpthread ./lib/libssl.a ./lib/libcrypto.a -ldl ./lib/libsrtp.a ./ice/libre.a INCLUDES = -I./$(OPENSSL_SRC_DIR_NAME)/include \ -I./$(OPENSSL_SRC_DIR_NAME)/crypto \ -I./$(OPENSSL_SRC_DIR_NAME)/crypto/include \ ? CFLAGS = -g -Wall gcc $(INCLUDES) $(CFLAGS) -o Our app uses openssl as static library ( ! ) . We call this function ?FIPS_mode_set(1)? in our source code to enable fips mode and then we run our app, we get the following error message ?139847561533096:error:2D06B06F:FIPS routines:DSA_BUILTIN_PARAMGEN2:fingerprint does not match nonpic relocated:fips.c:232:? . Are we wrong about compiling the openssl ? or compiling our app ? and is there anyway to enable fips mode without adding code line ? Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.?nin g?r??lerini yans?tmayabilir. ------------------------------------------------------- This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. -------------- next part -------------- An HTML attachment was scrubbed... URL: From osmelkov at gmail.com Thu Jan 25 09:59:00 2018 From: osmelkov at gmail.com (Oleg Smelkoff) Date: Thu, 25 Jan 2018 02:59:00 -0700 (MST) Subject: [openssl-users] error 20 at 0 depth lookup:unable to get local issuer certificate error Message-ID: <1516874340833-0.post@n7.nabble.com> Hi All! I've encountered same problem such in this topic: http://openssl.6102.n7.nabble.com/Getting-crazy-with-quot-error-20-at-0-depth-lookup-unable-to-get-local-issuer-certificate-error-quot-td21109.html#none but it wasn't help me I have 2 chains, and try to verify EE-certificates with CApath or CAfile (it doesn't matter) A.crt -> B.crt -> C1.crt -> D1.crt - works A.crt -> B.crt -> C2.crt -> D2.crt - doesn't work (error 20 at 0 depth lookup:unable to get local issuer certificate) Please, pay attention that first two certificates in chain are the same As well as the author of mentioned topic I checked following things of C and D certificates: 1. Child's issuer = parent's subject (as well as their hashes) 2. Key usage of all parents certificates contains "Certificate Sign" 3. Serial in AKI section is the same as issuer's Serial Number 4. Authority Key Identifier = issuer's Subject Key identifier As I tought, reason of that problem was incorrect AKID of EE-certificate, cause AKID has to identify the issuer of the issuer, BUT successful verification of my first chain disproves this! It has the same structure and dependencies: D2(failed): X509v3 Authority Key Identifier: *keyid:AF:6E:6E:56:1A:20:C9:9A:C2:D8:40:BD:32:F7:1E:0C:D5:4C:52:EB* DirName:/1.2.643.100.1=1069659052760/1.2.643.3.131.1.1=006659140843/C=RU/ST=66 \xD0\xA1\xD0\xB2\xD0\xB5\xD1\x80\xD0\xB4\xD0\xBB\xD0\xBE\xD0\xB2\xD1\x81\xD0\xBA\xD0\xB0\xD1\x8F \xD0\xBE\xD0\xB1\xD0\xBB\xD0\xB0\xD1\x81\xD1\x82\xD1\x8C *serial:37:B8:F5:1B:00:03:00:00:07:DD* C2(issuer of D2): Serial Number: *37:b8:f5:1b:00:03:00:00:07:dd * X509v3 Subject Key Identifier: *AF:6E:6E:56:1A:20:C9:9A:C2:D8:40:BD:32:F7:1E:0C:D5:4C:52:EB* D1(succeed): X509v3 Authority Key Identifier: *keyid:F3:9C:00:71:98:C6:B3:78:C4:D3:E8:C6:2A:7E:AA:DB:1D:16:B4:9C* DirName:/1.2.643.3.131.1.1=007710474375/1.2.643.100.1=1047702026701/emailAddress=dit at minsvyaz.ru/street=125375 \xD0\xB3. \xD0\x9C\xD0\xBE\xD1\x81\xD0\xBA\xD0\xB2\xD0\xB0 \xD1\x83\xD0\xBB. \xD0\xA2\xD0\xB2\xD0\xB5\xD1\x80\xD1\x81\xD0\xBA\xD0\xB0\xD1\x8F \xD0\xB4.7 *serial:4C:8A:31:03:00:03:00:00:08:11* C1(issuer of D1): Serial Number: *4c:8a:31:03:00:03:00:00:08:11* X509v3 Subject Key Identifier: *F3:9C:00:71:98:C6:B3:78:C4:D3:E8:C6:2A:7E:AA:DB:1D:16:B4:9C* Both of C1 and C2 has the same AKI section: X509v3 Authority Key Identifier: keyid:11:88:69:5E:EF:C8:E9:73:DB:7A:57:35:BC:D2:01:F3:05:FE:A7:D1 DirName:/emailAddress=dit at minsvyaz.ru/C=RU/ST=77 \xD0\xB3. \xD0\x9C\xD0\xBE\xD1\x81\xD0\xBA\xD0\xB2\xD0\xB0/L=\xD0\x9C\xD0\xBE\xD1\x81\xD0\xBA\xD0\xB2\xD0\xB0 serial:EB:C1:05:54:00:00:00:00:00:59 Could you help me, please. I'm really stucked at this problem :( I also attach all certificates A: -----BEGIN CERTIFICATE----- MIIFGTCCBMigAwIBAgIQNGgeQMtB7zOpoLfIdpKaKTAIBgYqhQMCAgMwggFKMR4w HAYJKoZIhvcNAQkBFg9kaXRAbWluc3Z5YXoucnUxCzAJBgNVBAYTAlJVMRwwGgYD VQQIDBM3NyDQsy4g0JzQvtGB0LrQstCwMRUwEwYDVQQHDAzQnNC+0YHQutCy0LAx PzA9BgNVBAkMNjEyNTM3NSDQsy4g0JzQvtGB0LrQstCwLCDRg9C7LiDQotCy0LXR gNGB0LrQsNGPLCDQtC4gNzEsMCoGA1UECgwj0JzQuNC90LrQvtC80YHQstGP0LfR jCDQoNC+0YHRgdC40LgxGDAWBgUqhQNkARINMTA0NzcwMjAyNjcwMTEaMBgGCCqF AwOBAwEBEgwwMDc3MTA0NzQzNzUxQTA/BgNVBAMMONCT0L7Qu9C+0LLQvdC+0Lkg 0YPQtNC+0YHRgtC+0LLQtdGA0Y/RjtGJ0LjQuSDRhtC10L3RgtGAMB4XDTEyMDcy MDEyMzExNFoXDTI3MDcxNzEyMzExNFowggFKMR4wHAYJKoZIhvcNAQkBFg9kaXRA bWluc3Z5YXoucnUxCzAJBgNVBAYTAlJVMRwwGgYDVQQIDBM3NyDQsy4g0JzQvtGB 0LrQstCwMRUwEwYDVQQHDAzQnNC+0YHQutCy0LAxPzA9BgNVBAkMNjEyNTM3NSDQ sy4g0JzQvtGB0LrQstCwLCDRg9C7LiDQotCy0LXRgNGB0LrQsNGPLCDQtC4gNzEs MCoGA1UECgwj0JzQuNC90LrQvtC80YHQstGP0LfRjCDQoNC+0YHRgdC40LgxGDAW BgUqhQNkARINMTA0NzcwMjAyNjcwMTEaMBgGCCqFAwOBAwEBEgwwMDc3MTA0NzQz NzUxQTA/BgNVBAMMONCT0L7Qu9C+0LLQvdC+0Lkg0YPQtNC+0YHRgtC+0LLQtdGA 0Y/RjtGJ0LjQuSDRhtC10L3RgtGAMGMwHAYGKoUDAgITMBIGByqFAwICIwEGByqF AwICHgEDQwAEQI+lv3kQI8jWka1kMVdbvpvFioP0Pyn3Knmp+2XD6KgPWnXEIlSR X8g/IYracDr51YsNc2KE3C7mkH6hA3M3ofujggGCMIIBfjCBxgYFKoUDZHAEgbww gbkMI9Cf0JDQmtCcIMKr0JrRgNC40L/RgtC+0J/RgNC+IEhTTcK7DCDQn9CQ0Jog wqvQk9C+0LvQvtCy0L3QvtC5INCj0KbCuww20JfQsNC60LvRjtGH0LXQvdC40LUg 4oSWIDE0OS8zLzIvMi05OTkg0L7RgiAwNS4wNy4yMDEyDDjQl9Cw0LrQu9GO0YfQ tdC90LjQtSDihJYgMTQ5LzcvMS80LzItNjAzINC+0YIgMDYuMDcuMjAxMjAuBgUq hQNkbwQlDCPQn9CQ0JrQnCDCq9Ca0YDQuNC/0YLQvtCf0YDQviBIU03CuzBDBgNV HSAEPDA6MAgGBiqFA2RxATAIBgYqhQNkcQIwCAYGKoUDZHEDMAgGBiqFA2RxBDAI BgYqhQNkcQUwBgYEVR0gADAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQUi5g7iRhR6O+cAni46sjUILJVyV0wCAYGKoUDAgIDA0EA23Re ec/Y27rpMi+iFbgWCazGY3skBTq5ZGsQKOUxCe4mO7UBDACiWqdA0nvqiQMXeHgq o//fO9pxuIHtymwyMg== -----END CERTIFICATE----- B: -----BEGIN CERTIFICATE----- MIIGrDCCBlugAwIBAgILAOvBBVQAAAAAAFkwCAYGKoUDAgIDMIIBSjEeMBwGCSqG SIb3DQEJARYPZGl0QG1pbnN2eWF6LnJ1MQswCQYDVQQGEwJSVTEcMBoGA1UECAwT Nzcg0LMuINCc0L7RgdC60LLQsDEVMBMGA1UEBwwM0JzQvtGB0LrQstCwMT8wPQYD VQQJDDYxMjUzNzUg0LMuINCc0L7RgdC60LLQsCwg0YPQuy4g0KLQstC10YDRgdC6 0LDRjywg0LQuIDcxLDAqBgNVBAoMI9Cc0LjQvdC60L7QvNGB0LLRj9C30Ywg0KDQ vtGB0YHQuNC4MRgwFgYFKoUDZAESDTEwNDc3MDIwMjY3MDExGjAYBggqhQMDgQMB ARIMMDA3NzEwNDc0Mzc1MUEwPwYDVQQDDDjQk9C+0LvQvtCy0L3QvtC5INGD0LTQ vtGB0YLQvtCy0LXRgNGP0Y7RidC40Lkg0YbQtdC90YLRgDAeFw0xNjAzMTYxMjAy NTFaFw0yNzA3MTIxMjAyNTFaMIIBITEaMBgGCCqFAwOBAwEBEgwwMDc3MTA0NzQz NzUxGDAWBgUqhQNkARINMTA0NzcwMjAyNjcwMTEeMBwGCSqGSIb3DQEJARYPZGl0 QG1pbnN2eWF6LnJ1MTwwOgYDVQQJDDMxMjUzNzUg0LMuINCc0L7RgdC60LLQsCDR g9C7LiDQotCy0LXRgNGB0LrQsNGPINC0LjcxLDAqBgNVBAoMI9Cc0LjQvdC60L7Q vNGB0LLRj9C30Ywg0KDQvtGB0YHQuNC4MRUwEwYDVQQHDAzQnNC+0YHQutCy0LAx HDAaBgNVBAgMEzc3INCzLiDQnNC+0YHQutCy0LAxCzAJBgNVBAYTAlJVMRswGQYD VQQDDBLQo9CmIDEg0JjQoSDQk9Cj0KYwYzAcBgYqhQMCAhMwEgYHKoUDAgIjAQYH KoUDAgIeAQNDAARAx70Y7WYQ4ODtdiSSx3MJnr1GQBEIExiPO/LWj1TRKES1OcDI YgtdOBGVYSvbsStl10jkAOG0OpnGsd2by4m+LaOCA0MwggM/MA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFBGIaV7vyOlz23pXNbzSAfMF/qfRMAsGA1UdDwQEAwIB hjCCAYsGA1UdIwSCAYIwggF+gBSLmDuJGFHo75wCeLjqyNQgslXJXaGCAVKkggFO MIIBSjEeMBwGCSqGSIb3DQEJARYPZGl0QG1pbnN2eWF6LnJ1MQswCQYDVQQGEwJS VTEcMBoGA1UECAwTNzcg0LMuINCc0L7RgdC60LLQsDEVMBMGA1UEBwwM0JzQvtGB 0LrQstCwMT8wPQYDVQQJDDYxMjUzNzUg0LMuINCc0L7RgdC60LLQsCwg0YPQuy4g 0KLQstC10YDRgdC60LDRjywg0LQuIDcxLDAqBgNVBAoMI9Cc0LjQvdC60L7QvNGB 0LLRj9C30Ywg0KDQvtGB0YHQuNC4MRgwFgYFKoUDZAESDTEwNDc3MDIwMjY3MDEx GjAYBggqhQMDgQMBARIMMDA3NzEwNDc0Mzc1MUEwPwYDVQQDDDjQk9C+0LvQvtCy 0L3QvtC5INGD0LTQvtGB0YLQvtCy0LXRgNGP0Y7RidC40Lkg0YbQtdC90YLRgIIQ NGgeQMtB7zOpoLfIdpKaKTBZBgNVHR8EUjBQMCagJKAihiBodHRwOi8vcm9zdGVs ZWNvbS5ydS9jZHAvZ3VjLmNybDAmoCSgIoYgaHR0cDovL3JlZXN0ci1wa2kucnUv Y2RwL2d1Yy5jcmwwJgYFKoUDZG8EHQwb0JrRgNC40L/RgtC+LdCf0YDQviBDU1Ag My42MCUGA1UdIAQeMBwwCAYGKoUDZHEBMAgGBiqFA2RxAjAGBgRVHSAAMIHGBgUq hQNkcASBvDCBuQwj0J/QkNCa0JwgwqvQmtGA0LjQv9GC0L7Qn9GA0L4gSFNNwrsM INCf0JDQmiDCq9CT0L7Qu9C+0LLQvdC+0Lkg0KPQpsK7DDbQl9Cw0LrQu9GO0YfQ tdC90LjQtSDihJYgMTQ5LzMvMi8yLTk5OSDQvtGCIDA1LjA3LjIwMTIMONCX0LDQ utC70Y7Rh9C10L3QuNC1IOKEliAxNDkvNy8xLzQvMi02MDMg0L7RgiAwNi4wNy4y MDEyMAgGBiqFAwICAwNBAKVYokUvb7XAMPJF38ZPKO2BFBldmGEfqsfmsiO35Y52 kTkx512H3YLqWMrOLjIfVMJhc+DTCNeXWY6bhK4/DRU= -----END CERTIFICATE----- C1: -----BEGIN CERTIFICATE----- MIIH1zCCB4agAwIBAgIKTIoxAwADAAAIETAIBgYqhQMCAgMwggEhMRowGAYIKoUD A4EDAQESDDAwNzcxMDQ3NDM3NTEYMBYGBSqFA2QBEg0xMDQ3NzAyMDI2NzAxMR4w HAYJKoZIhvcNAQkBFg9kaXRAbWluc3Z5YXoucnUxPDA6BgNVBAkMMzEyNTM3NSDQ sy4g0JzQvtGB0LrQstCwINGD0LsuINCi0LLQtdGA0YHQutCw0Y8g0LQuNzEsMCoG A1UECgwj0JzQuNC90LrQvtC80YHQstGP0LfRjCDQoNC+0YHRgdC40LgxFTATBgNV BAcMDNCc0L7RgdC60LLQsDEcMBoGA1UECAwTNzcg0LMuINCc0L7RgdC60LLQsDEL MAkGA1UEBhMCUlUxGzAZBgNVBAMMEtCj0KYgMSDQmNChINCT0KPQpjAeFw0xNjEy MDExMDU2MDBaFw0yNjEyMDExMTA2MDBaMIIBbDEYMBYGBSqFA2QBEg0xMDI3NzAw MDcxNTMwMRowGAYIKoUDA4EDAQESDDAwNzcwNDIxMTIwMTELMAkGA1UEBhMCUlUx GDAWBgNVBAgMDzc3INCc0L7RgdC60LLQsDEVMBMGA1UEBwwM0JzQvtGB0LrQstCw MTkwNwYDVQQJDDDQkdCw0YDRi9C60L7QstGB0LrQuNC5INC/0LXRgC4sINC0LiA0 LCDRgdGC0YAuIDIxMDAuBgNVBAsMJ9Cj0LTQvtGB0YLQvtCy0LXRgNGP0Y7RidC4 0Lkg0YbQtdC90YLRgDFnMGUGA1UECgxe0J7QsdGJ0LXRgdGC0LLQviDRgSDQvtCz 0YDQsNC90LjRh9C10L3QvdC+0Lkg0L7RgtCy0LXRgtGB0YLQstC10L3QvdC+0YHR gtGM0Y4gItCi0LDQutGB0LrQvtC8IjEgMB4GA1UEAwwX0J7QntCeICLQotCw0LrR gdC60L7QvCIwYzAcBgYqhQMCAhMwEgYHKoUDAgIjAQYHKoUDAgIeAQNDAARAI2Eo W/uf7LDxoLQvD/N+aiV4rGcGbWp+YO/+KZiR0kmRU0p2zpRLVMpSaOs2V1fVwKLI Zq4PELFV1DxH/MP9Q6OCBE0wggRJMAsGA1UdDwQEAwIBhjAdBgNVHQ4EFgQU85wA cZjGs3jE0+jGKn6q2x0WtJwwEgYDVR0TAQH/BAgwBgEB/wIBADAlBgNVHSAEHjAc MAYGBFUdIAAwCAYGKoUDZHEBMAgGBiqFA2RxAjA2BgUqhQNkbwQtDCsi0JrRgNC4 0L/RgtC+0J/RgNC+IENTUCIgKNCy0LXRgNGB0LjRjyA0LjApMBAGCSsGAQQBgjcV AQQDAgEAMIIBhgYDVR0jBIIBfTCCAXmAFBGIaV7vyOlz23pXNbzSAfMF/qfRoYIB UqSCAU4wggFKMR4wHAYJKoZIhvcNAQkBFg9kaXRAbWluc3Z5YXoucnUxCzAJBgNV BAYTAlJVMRwwGgYDVQQIDBM3NyDQsy4g0JzQvtGB0LrQstCwMRUwEwYDVQQHDAzQ nNC+0YHQutCy0LAxPzA9BgNVBAkMNjEyNTM3NSDQsy4g0JzQvtGB0LrQstCwLCDR g9C7LiDQotCy0LXRgNGB0LrQsNGPLCDQtC4gNzEsMCoGA1UECgwj0JzQuNC90LrQ vtC80YHQstGP0LfRjCDQoNC+0YHRgdC40LgxGDAWBgUqhQNkARINMTA0NzcwMjAy NjcwMTEaMBgGCCqFAwOBAwEBEgwwMDc3MTA0NzQzNzUxQTA/BgNVBAMMONCT0L7Q u9C+0LLQvdC+0Lkg0YPQtNC+0YHRgtC+0LLQtdGA0Y/RjtGJ0LjQuSDRhtC10L3R gtGAggsA68EFVAAAAAAAWTBhBgNVHR8EWjBYMCqgKKAmhiRodHRwOi8vcm9zdGVs ZWNvbS5ydS9jZHAvdmd1YzFfNC5jcmwwKqAooCaGJGh0dHA6Ly9yZWVzdHItcGtp LnJ1L2NkcC92Z3VjMV80LmNybDByBggrBgEFBQcBAQRmMGQwMAYIKwYBBQUHMAKG JGh0dHA6Ly9yb3N0ZWxlY29tLnJ1L2NkcC92Z3VjMV80LmNydDAwBggrBgEFBQcw AoYkaHR0cDovL3JlZXN0ci1wa2kucnUvY2RwL3ZndWMxXzQuY3J0MIIBMwYFKoUD ZHAEggEoMIIBJAwrItCa0YDQuNC/0YLQvtCf0YDQviBDU1AiICjQstC10YDRgdC4 0Y8gMy42KQxTItCj0LTQvtGB0YLQvtCy0LXRgNGP0Y7RidC40Lkg0YbQtdC90YLR gCAi0JrRgNC40L/RgtC+0J/RgNC+INCj0KYiINCy0LXRgNGB0LjQuCAxLjUMT9Ch 0LXRgNGC0LjRhNC40LrQsNGCINGB0L7QvtGC0LLQtdGC0YHRgtCy0LjRjyDihJYg 0KHQpC8xMjQtMjczOCDQvtGCIDAxLjA3LjIwMTUMT9Ch0LXRgNGC0LjRhNC40LrQ sNGCINGB0L7QvtGC0LLQtdGC0YHRgtCy0LjRjyDihJYg0KHQpC8xMjgtMjc2OCDQ vtGCIDMxLjEyLjIwMTUwCAYGKoUDAgIDA0EAfHo7cQrmbd+zpThemGuW5vTYi3ys pvM1qTBSWDsohYXYVJbbnLKdUWGU1PN+wdFeGd5NtzfTu7DM2ESu3FCjAQ== -----END CERTIFICATE----- D1: -----BEGIN CERTIFICATE----- MIIIfTCCCCygAwIBAgIQBSCpesQMzIDmEX7oOsNlwzAIBgYqhQMCAgMwggFsMRgw FgYFKoUDZAESDTEwMjc3MDAwNzE1MzAxGjAYBggqhQMDgQMBARIMMDA3NzA0MjEx MjAxMQswCQYDVQQGEwJSVTEYMBYGA1UECAwPNzcg0JzQvtGB0LrQstCwMRUwEwYD VQQHDAzQnNC+0YHQutCy0LAxOTA3BgNVBAkMMNCR0LDRgNGL0LrQvtCy0YHQutC4 0Lkg0L/QtdGALiwg0LQuIDQsINGB0YLRgC4gMjEwMC4GA1UECwwn0KPQtNC+0YHR gtC+0LLQtdGA0Y/RjtGJ0LjQuSDRhtC10L3RgtGAMWcwZQYDVQQKDF7QntCx0YnQ tdGB0YLQstC+INGBINC+0LPRgNCw0L3QuNGH0LXQvdC90L7QuSDQvtGC0LLQtdGC 0YHRgtCy0LXQvdC90L7RgdGC0YzRjiAi0KLQsNC60YHQutC+0LwiMSAwHgYDVQQD DBfQntCe0J4gItCi0LDQutGB0LrQvtC8IjAeFw0xNzAyMDExMjUzMDNaFw0xODAy MDExMzAzMDNaMIIB9jEZMBcGCSqGSIb3DQEJARYKc2FzQGF0aS5zdTEaMBgGCCqF AwOBAwEBEgwwMDc4MDI4NjYxNTcxFjAUBgUqhQNkAxILMDY1Mjk5MTk4MDMxGDAW BgUqhQNkARINMTE0Nzg0NzI1NTgzMDEwMC4GA1UEDAwn0JPQldCd0JXQoNCQ0JvQ rNCd0KvQmSDQlNCY0KDQldCa0KLQntCgMSEwHwYDVQQKDBjQntCe0J4gItCQ0KLQ mC3QlNCe0JrQmCIxXTBbBgNVBAkMVNC/0YAt0LrRgiDQotCe0KDQldCX0JAsINCU 0J7QnCAzOSwg0JrQntCg0J/Qo9ChIDEg0JvQmNCiINCQLCDQn9Ce0JzQldCp0JXQ ndCY0JUgMy3QnTEpMCcGA1UEBwwg0LMg0KHQkNCd0JrQoi3Qn9CV0KLQldCg0JHQ o9Cg0JMxLTArBgNVBAgMJDc4INCzLiDQodCw0L3QutGCLdCf0LXRgtC10YDQsdGD 0YDQszELMAkGA1UEBhMCUlUxNjA0BgNVBCoMLdCQ0JvQldCa0KHQkNCd0JTQoCDQ ktCe0JvQrNCU0JXQnNCQ0KDQntCS0JjQpzEVMBMGA1UEBAwM0JLQmNCb0KzQlNCV MSEwHwYDVQQDDBjQntCe0J4gItCQ0KLQmC3QlNCe0JrQmCIwYzAcBgYqhQMCAhMw EgYHKoUDAgIkAAYHKoUDAgIeAQNDAARAwF9C9QRWHrdxf8ZMm3/+Ipn+0PPua+td ClphTcBwuwC5CWZ1XGI2sCa/+b6UKUknvmtZBHZ+EfhNQakFflGZr6OCBBgwggQU MB8GCSsGAQQBgjcVBwQSMBAGCCqFAwICLgAIAgEBAgEAMIIBXAYDVR0jBIIBUzCC AU+AFPOcAHGYxrN4xNPoxip+qtsdFrScoYIBKaSCASUwggEhMRowGAYIKoUDA4ED AQESDDAwNzcxMDQ3NDM3NTEYMBYGBSqFA2QBEg0xMDQ3NzAyMDI2NzAxMR4wHAYJ KoZIhvcNAQkBFg9kaXRAbWluc3Z5YXoucnUxPDA6BgNVBAkMMzEyNTM3NSDQsy4g 0JzQvtGB0LrQstCwINGD0LsuINCi0LLQtdGA0YHQutCw0Y8g0LQuNzEsMCoGA1UE Cgwj0JzQuNC90LrQvtC80YHQstGP0LfRjCDQoNC+0YHRgdC40LgxFTATBgNVBAcM DNCc0L7RgdC60LLQsDEcMBoGA1UECAwTNzcg0LMuINCc0L7RgdC60LLQsDELMAkG A1UEBhMCUlUxGzAZBgNVBAMMEtCj0KYgMSDQmNChINCT0KPQpoIKTIoxAwADAAAI ETAdBgNVHQ4EFgQUOSt9b81QhkfU3mI3Q2VTAi57wPwwDgYDVR0PAQH/BAQDAgP4 MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHSAEFjAUMAgGBiqF A2RxATAIBgYqhQNkcQIwggEUBgUqhQNkcASCAQkwggEFDCsi0JrRgNC40L/RgtC+ 0J/RgNC+IENTUCIgKNCy0LXRgNGB0LjRjyA0LjApDCwi0JrRgNC40L/RgtC+0J/R gNC+INCj0KYiICjQstC10YDRgdC40Y8gMi4wKQxX0KHQtdGA0YLQuNGE0LjQutCw 0YIg0YHQvtC+0YLQstC10YLRgdGC0LLQuNGPINCh0KQvMTI0LTI4NjQg0L7RgiAy MCDQvNCw0YDRgtCwIDIwMTYg0LMuDE/QodC10YDRgtC40YTQuNC60LDRgiDRgdC+ 0L7RgtCy0LXRgtGB0YLQstC40Y8g0KHQpC8xMjgtMjk4MyDQvtGCIDE4LjExLjIw MTYg0LMuMCMGBSqFA2RvBBoMGCLQmtGA0LjQv9GC0L7Qn9GA0L4gQ1NQIjBSBgNV HR8ESzBJMEegRaBDhkFodHRwOi8vY3JsLnRheGNvbS5ydS9mMzljMDA3MTk4YzZi Mzc4YzRkM2U4YzYyYTdlYWFkYjFkMTZiNDljLmNybDCBkgYIKwYBBQUHAQEEgYUw gYIwMQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMjAudGF4Y29tLnJ1L29jc3Avb2Nz cC5zcmYwTQYIKwYBBQUHMAKGQWh0dHA6Ly9jcmwudGF4Y29tLnJ1L2YzOWMwMDcx OThjNmIzNzhjNGQzZThjNjJhN2VhYWRiMWQxNmI0OWMuY3J0MAgGBiqFAwICAwNB AFVLUBvs3iRZuQiDcLVmlSYRM5P5b+RTbAAsT7mwJ9Zt/0wy8TjWSZ9v00Mt6s4v 62yBNWuCdWYrxj5ZupGe/Tg= -----END CERTIFICATE----- C2: -----BEGIN CERTIFICATE----- MIIHtzCCB2agAwIBAgIKN7j1GwADAAAH3TAIBgYqhQMCAgMwggEhMRowGAYIKoUD A4EDAQESDDAwNzcxMDQ3NDM3NTEYMBYGBSqFA2QBEg0xMDQ3NzAyMDI2NzAxMR4w HAYJKoZIhvcNAQkBFg9kaXRAbWluc3Z5YXoucnUxPDA6BgNVBAkMMzEyNTM3NSDQ sy4g0JzQvtGB0LrQstCwINGD0LsuINCi0LLQtdGA0YHQutCw0Y8g0LQuNzEsMCoG A1UECgwj0JzQuNC90LrQvtC80YHQstGP0LfRjCDQoNC+0YHRgdC40LgxFTATBgNV BAcMDNCc0L7RgdC60LLQsDEcMBoGA1UECAwTNzcg0LMuINCc0L7RgdC60LLQsDEL MAkGA1UEBhMCUlUxGzAZBgNVBAMMEtCj0KYgMSDQmNChINCT0KPQpjAeFw0xNjEx MDIxMzI0MDBaFw0yNjExMDIxMzM0MDBaMIIBTDEYMBYGBSqFA2QBEg0xMDY5NjU5 MDUyNzYwMRowGAYIKoUDA4EDAQESDDAwNjY1OTE0MDg0MzELMAkGA1UEBhMCUlUx MzAxBgNVBAgMKjY2INCh0LLQtdGA0LTQu9C+0LLRgdC60LDRjyDQvtCx0LvQsNGB 0YLRjDEhMB8GA1UEBwwY0JXQutCw0YLQtdGA0LjQvdCx0YPRgNCzMS8wLQYDVQQJ DCbRg9C7LiDQn9C10YDQstC+0LzQsNC50YHQutCw0Y8sINC0LiAxNTEwMC4GA1UE Cwwn0KPQtNC+0YHRgtC+0LLQtdGA0Y/RjtGJ0LjQuSDRhtC10L3RgtGAMSIwIAYD VQQKDBnQntCe0J4gItCc0J7QodCi0JjQndCk0J4iMSgwJgYDVQQDDB/Qn9C+0LTR h9C40L3QtdC90L3Ri9C5INCj0KYgMi4wMGMwHAYGKoUDAgITMBIGByqFAwICIwEG ByqFAwICHgEDQwAEQCAeNYx2wmrF27FTyRagEYihHd3l+8aDqPae3mcnlXl6XywB rtNOTv6bIH4EhesiusiRvmvzCx5qJ7yU4xCN6VCjggRNMIIESTALBgNVHQ8EBAMC AYYwHQYDVR0OBBYEFK9ublYaIMmawthAvTL3HgzVTFLrMBIGA1UdEwEB/wQIMAYB Af8CAQAwJQYDVR0gBB4wHDAGBgRVHSAAMAgGBiqFA2RxATAIBgYqhQNkcQIwggEz BgUqhQNkcASCASgwggEkDCsi0JrRgNC40L/RgtC+0J/RgNC+IENTUCIgKNCy0LXR gNGB0LjRjyAzLjYpDFMi0KPQtNC+0YHRgtC+0LLQtdGA0Y/RjtGJ0LjQuSDRhtC1 0L3RgtGAICLQmtGA0LjQv9GC0L7Qn9GA0L4g0KPQpiIg0LLQtdGA0YHQuNC4IDEu NQxP0KHQtdGA0YLQuNGE0LjQutCw0YIg0YHQvtC+0YLQstC10YLRgdGC0LLQuNGP IOKEliDQodCkLzEyNC0yNzM4INC+0YIgMDEuMDcuMjAxNQxP0KHQtdGA0YLQuNGE 0LjQutCw0YIg0YHQvtC+0YLQstC10YLRgdGC0LLQuNGPIOKEliDQodCkLzEyOC0y NzY4INC+0YIgMzEuMTIuMjAxNTA2BgUqhQNkbwQtDCsi0JrRgNC40L/RgtC+0J/R gNC+IENTUCIgKNCy0LXRgNGB0LjRjyAzLjkpMBAGCSsGAQQBgjcVAQQDAgEAMIIB hgYDVR0jBIIBfTCCAXmAFBGIaV7vyOlz23pXNbzSAfMF/qfRoYIBUqSCAU4wggFK MR4wHAYJKoZIhvcNAQkBFg9kaXRAbWluc3Z5YXoucnUxCzAJBgNVBAYTAlJVMRww GgYDVQQIDBM3NyDQsy4g0JzQvtGB0LrQstCwMRUwEwYDVQQHDAzQnNC+0YHQutCy 0LAxPzA9BgNVBAkMNjEyNTM3NSDQsy4g0JzQvtGB0LrQstCwLCDRg9C7LiDQotCy 0LXRgNGB0LrQsNGPLCDQtC4gNzEsMCoGA1UECgwj0JzQuNC90LrQvtC80YHQstGP 0LfRjCDQoNC+0YHRgdC40LgxGDAWBgUqhQNkARINMTA0NzcwMjAyNjcwMTEaMBgG CCqFAwOBAwEBEgwwMDc3MTA0NzQzNzUxQTA/BgNVBAMMONCT0L7Qu9C+0LLQvdC+ 0Lkg0YPQtNC+0YHRgtC+0LLQtdGA0Y/RjtGJ0LjQuSDRhtC10L3RgtGAggsA68EF VAAAAAAAWTBhBgNVHR8EWjBYMCqgKKAmhiRodHRwOi8vcm9zdGVsZWNvbS5ydS9j ZHAvdmd1YzFfNC5jcmwwKqAooCaGJGh0dHA6Ly9yZWVzdHItcGtpLnJ1L2NkcC92 Z3VjMV80LmNybDByBggrBgEFBQcBAQRmMGQwMAYIKwYBBQUHMAKGJGh0dHA6Ly9y b3N0ZWxlY29tLnJ1L2NkcC92Z3VjMV80LmNydDAwBggrBgEFBQcwAoYkaHR0cDov L3JlZXN0ci1wa2kucnUvY2RwL3ZndWMxXzQuY3J0MAgGBiqFAwICAwNBAP6WX0KR Sha1QVWkVQ+aLO2vs87eBzXRInO1R2YOHnFEc5a9VOLe8z4LuTpEdxqIgIRKv11w 4RaGMUe7diNjMMY= -----END CERTIFICATE----- D2: -----BEGIN CERTIFICATE----- MIIJYDCCCQ+gAwIBAgIQCQfZSDAAx4DnEYOBal0xqzAIBgYqhQMCAgMwggFMMRgw FgYFKoUDZAESDTEwNjk2NTkwNTI3NjAxGjAYBggqhQMDgQMBARIMMDA2NjU5MTQw ODQzMQswCQYDVQQGEwJSVTEzMDEGA1UECAwqNjYg0KHQstC10YDQtNC70L7QstGB 0LrQsNGPINC+0LHQu9Cw0YHRgtGMMSEwHwYDVQQHDBjQldC60LDRgtC10YDQuNC9 0LHRg9GA0LMxLzAtBgNVBAkMJtGD0LsuINCf0LXRgNCy0L7QvNCw0LnRgdC60LDR jywg0LQuIDE1MTAwLgYDVQQLDCfQo9C00L7RgdGC0L7QstC10YDRj9GO0YnQuNC5 INGG0LXQvdGC0YAxIjAgBgNVBAoMGdCe0J7QniAi0JzQntCh0KLQmNCd0KTQniIx KDAmBgNVBAMMH9Cf0L7QtNGH0LjQvdC10L3QvdGL0Lkg0KPQpiAyLjAwHhcNMTcw ODE1MDYyMzM4WhcNMTgwODE1MDYzMzM4WjCCAaoxIDAeBgkqhkiG9w0BCQEWEWNr QHNtYXprYS5wZXJtLnJ1MRowGAYIKoUDA4EDAQESDDAwNTkwNTA1MjE5NTEWMBQG BSqFA2QDEgswMjg5OTA4MjE5OTEYMBYGBSqFA2QBEg0xMTc1OTU4MDE5NzA5MRkw FwYDVQQMDBDQlNC40YDQtdC60YLQvtGAMQowCAYDVQQLEwEwMRYwFAYDVQQKDA3Q ntCe0J4gJ9Ch0JonMSwwKgYDVQQJDCPRg9C7LtCd0L7RgNC40LvRjNGB0LrQsNGP LCDQtC44LTIwNzETMBEGA1UEBwwK0J/QtdGA0LzRjDElMCMGA1UECAwcNTkg0J/Q tdGA0LzRgdC60LjQuSDQutGA0LDQuTELMAkGA1UEBhMCUlUxLjAsBgNVBCoMJdCh 0LXRgNCz0LXQuSDQktC70LDQtNC40LzQuNGA0L7QstC40YcxFTATBgNVBAQMDNCg 0LXQvdGG0L7QsjE7MDkGA1UEAwwy0KDQtdC90YbQvtCyINCh0LXRgNCz0LXQuSDQ ktC70LDQtNC40LzQuNGA0L7QstC40YcwYzAcBgYqhQMCAhMwEgYHKoUDAgIkAAYH KoUDAgIeAQNDAARAd+g9OFdrHY+7M/A/e5AH/u9Mq/JMwTub4DfWygPXCwfmINjV 8LHUFm+j8UdxV2obGO8K5UR6ZY25q0o7zJKK/aOCBWcwggVjMA4GA1UdDwEB/wQE AwIE8DA6BgNVHSUEMzAxBggrBgEFBQcDAgYIKwYBBQUHAwQGByqFAwICIgYGBiqF A2RxAgYKKwYBBAGCNwoGAjAdBgNVHSAEFjAUMAgGBiqFA2RxATAIBgYqhQNkcQIw HQYDVR0OBBYEFJwfT06tiM97gvUHQMd64r7GUj32MIIBhwYDVR0jBIIBfjCCAXqA FK9ublYaIMmawthAvTL3HgzVTFLroYIBVKSCAVAwggFMMRgwFgYFKoUDZAESDTEw Njk2NTkwNTI3NjAxGjAYBggqhQMDgQMBARIMMDA2NjU5MTQwODQzMQswCQYDVQQG EwJSVTEzMDEGA1UECAwqNjYg0KHQstC10YDQtNC70L7QstGB0LrQsNGPINC+0LHQ u9Cw0YHRgtGMMSEwHwYDVQQHDBjQldC60LDRgtC10YDQuNC90LHRg9GA0LMxLzAt BgNVBAkMJtGD0LsuINCf0LXRgNCy0L7QvNCw0LnRgdC60LDRjywg0LQuIDE1MTAw LgYDVQQLDCfQo9C00L7RgdGC0L7QstC10YDRj9GO0YnQuNC5INGG0LXQvdGC0YAx IjAgBgNVBAoMGdCe0J7QniAi0JzQntCh0KLQmNCd0KTQniIxKDAmBgNVBAMMH9Cf 0L7QtNGH0LjQvdC10L3QvdGL0Lkg0KPQpiAyLjCCCje49RsAAwAAB90wSgYJKwYB BAGCNxUKBD0wOzAKBggrBgEFBQcDAjAKBggrBgEFBQcDBDAJBgcqhQMCAiIGMAgG BiqFA2RxAjAMBgorBgEEAYI3CgYCMIIBNAYFKoUDZHAEggEpMIIBJQwrItCa0YDQ uNC/0YLQvtCf0YDQviBDU1AiICjQstC10YDRgdC40Y8gMy45KQxUItCj0LTQvtGB 0YLQvtCy0LXRgNGP0Y7RidC40Lkg0YbQtdC90YLRgCAi0JrRgNC40L/RgtC+0J/R gNC+INCj0KYiINCy0LXRgNGB0LjQuCAyLjAiDE/QodC10YDRgtC40YTQuNC60LDR giDRgdC+0L7RgtCy0LXRgtGB0YLQstC40Y8g4oSWINCh0KQvMTE0LTI1Mzgg0L7R giAxNS4wMS4yMDE1DE/QodC10YDRgtC40YTQuNC60LDRgiDRgdC+0L7RgtCy0LXR gtGB0YLQstC40Y8g4oSWINCh0KQvMTI4LTI4ODEg0L7RgiAxMi4wNC4yMDE2MDYG BSqFA2RvBC0MKyLQmtGA0LjQv9GC0L7Qn9GA0L4gQ1NQIiAo0LLQtdGA0YHQuNGP IDMuOSkwYgYHKoUDAgIxAgRXMFUwRRYYaHR0cDovL21vc3QtaW5mby5ydS9mbDIv DCXQmNChICLQrdCfINCc0L7RgdGC0LjQvdGE0L4g0KTQmyB2Mi4wAwIF4AQMhhZI EBBIvlKdz2HqMDQGCSsGAQQBgjcVBwQnMCUGHSqFAwICMgEJg+eiDoKnsB6FgYJ0 h4XGAYKgc9FeAgEBAgEAMHEGA1UdHwRqMGgwMaAvoC2GK2Z0cDovL25hbG9nLm1v c3QtaW5mby5ydS9jYV9tb3N0aW5mb18yMC5jcmwwM6AxoC+GLWh0dHA6Ly9tb3N0 LWluZm8ucnUvcHVibGljL2NhX21vc3RpbmZvXzIwLmNybDCBggYIKwYBBQUHAQEE djB0MDgGCCsGAQUFBzABhixodHRwOi8vd3d3Lm9jc3AyMC5tb3N0LWluZm8ucnUv b2NzcC9vY3NwLnNyZjA4BggrBgEFBQcwAoYsaHR0cDovL21vc3QtaW5mby5ydS9w dWJsaWMvY2FfbW9zdGluZm8yMC5jcnQwCAYGKoUDAgIDA0EAmvKwV/eLCwJ5v59N +XoEws6PfEWWYrQzgsZ4kdzIJ679n6ep96SJYyvRa82BBukx9J7oG0Kmx8j2gKE2 xJOkvw== -----END CERTIFICATE----- -- Oleg Smelkov osmelkov at gmail.com -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From rsalz at akamai.com Thu Jan 25 11:43:32 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 25 Jan 2018 11:43:32 +0000 Subject: [openssl-users] Building/Running fips enabled Openssl application Message-ID: The current FIPS only supports dynamic libraries. You should try to get the email disclaimer removed when you post to a public email list. From: Emre BAYRAM Reply-To: openssl-users Date: Thursday, January 25, 2018 at 1:30 AM To: openssl-users Subject: [openssl-users] Building/Running fips enabled Openssl application Hi there, To add our application openssl fips capabilities we did the followings . We have openssl-1.0.2n version and openssl-fips.2.0.16 version Firtsly : When we are compiling openssl and fips we run this commands : ./config ?shared --with-fipsdir=/root/openssl_files/ssl/fips2.0 -D_GNU_SOURCE Make Make install ./config fips --openssldir=/root/openssl_files/ssl --with-fipsdir=/root/openssl_files/ssl/fips2.0 -D_GNU_SOURCE Make Make install Secondly (openssl Test) : After that we test it with: OPENSSL_FIPS=1 ./openssl md5 It didn?t work as we expected ./openssl md5 It worked as we expected Thirdly (combine with our app): As you see above we install the opensl at this specific path ?/root/openssl_files/ssl? then we copy all files to application?s resource folder then we compile our application with openssl static libraries (*.a). Compile command : LIBS = -lpthread ./lib/libssl.a ./lib/libcrypto.a -ldl ./lib/libsrtp.a ./ice/libre.a INCLUDES = -I./$(OPENSSL_SRC_DIR_NAME)/include \ -I./$(OPENSSL_SRC_DIR_NAME)/crypto \ -I./$(OPENSSL_SRC_DIR_NAME)/crypto/include \ ? CFLAGS = -g -Wall gcc $(INCLUDES) $(CFLAGS) -o Our app uses openssl as static library ( ! ) . We call this function ?FIPS_mode_set(1)? in our source code to enable fips mode and then we run our app, we get the following error message ?139847561533096:error:2D06B06F:FIPS routines:DSA_BUILTIN_PARAMGEN2:fingerprint does not match nonpic relocated:fips.c:232:? . Are we wrong about compiling the openssl ? or compiling our app ? and is there anyway to enable fips mode without adding code line ? Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.?nin g?r??lerini yans?tmayabilir. ------------------------------------------------------- This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.reix at atos.net Thu Jan 25 14:07:10 2018 From: tony.reix at atos.net (REIX, Tony) Date: Thu, 25 Jan 2018 14:07:10 +0000 Subject: [openssl-users] Release Strategy Message-ID: Hi, We (ATOS BullFreeware project) are building and delivering OpenSSL on AIX. However, there are different providers of OpenSSL on AIX (IBM AIX project, Perzl, Bull Freeware, IBM AIX Toolbox), and we have some compatibility issues when mixing RPMs depending on OpenSSL and built with different versions or by different providers of OpenSSL. The information on page: https://www.openssl.org/policies/releasestrat.html is very interesting and useful. However, last modification was made the 6th September 2016 , quite old. Would it be possible to update this ? That would help us to understand the compatibility between the different versions of OpenSSL and build some compatibility plan. Thanks/Regards Cordialement, Tony Reix ATOS / Bull SAS ATOS Expert IBM Coop Architect & Technical Leader Office : +33 (0) 4 76 29 72 67 1 rue de Provence - 38432 ?chirolles - France www.atos.net From tony.reix at atos.net Thu Jan 25 14:07:10 2018 From: tony.reix at atos.net (REIX, Tony) Date: Thu, 25 Jan 2018 14:07:10 +0000 Subject: [openssl-users] Release Strategy Message-ID: Hi, We (ATOS BullFreeware project) are building and delivering OpenSSL on AIX. However, there are different providers of OpenSSL on AIX (IBM AIX project, Perzl, Bull Freeware, IBM AIX Toolbox), and we have some compatibility issues when mixing RPMs depending on OpenSSL and built with different versions or by different providers of OpenSSL. The information on page: https://www.openssl.org/policies/releasestrat.html is very interesting and useful. However, last modification was made the 6th September 2016 , quite old. Would it be possible to update this ? That would help us to understand the compatibility between the different versions of OpenSSL and build some compatibility plan. Thanks/Regards Cordialement, Tony Reix ATOS / Bull SAS ATOS Expert IBM Coop Architect & Technical Leader Office : +33 (0) 4 76 29 72 67 1 rue de Provence - 38432 ?chirolles - France www.atos.net From matt at openssl.org Thu Jan 25 14:34:31 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 25 Jan 2018 14:34:31 +0000 Subject: [openssl-users] Release Strategy In-Reply-To: References: Message-ID: <05ca6070-46f9-b431-df2e-467036c9865b@openssl.org> On 25/01/18 14:07, REIX, Tony wrote: > Hi, > > We (ATOS BullFreeware project) are building and delivering OpenSSL on > AIX. However, there are different providers of OpenSSL on AIX (IBM > AIX project, Perzl, Bull Freeware, IBM AIX Toolbox), and we have some > compatibility issues when mixing RPMs depending on OpenSSL and built > with different versions or by different providers of OpenSSL. > > The information on page: > https://www.openssl.org/policies/releasestrat.html is very > interesting and useful. However, last modification was made the 6th > September 2016 , quite old. Would it be possible to update this ? > That would help us to understand the compatibility between the > different versions of OpenSSL and build some compatibility plan. We are currently discussing our release plans for 1.1.1. I expect that to ultimately turn into updates to that page. See the thread on openssl-project starting here: https://mta.openssl.org/pipermail/openssl-project/2018-January/000184.html Matt From xemdetia at 808inorganic.com Thu Jan 25 15:34:33 2018 From: xemdetia at 808inorganic.com (xemdetia .) Date: Thu, 25 Jan 2018 10:34:33 -0500 Subject: [openssl-users] FIPS 3.0 Canister Status Message-ID: Hey all, Back in 2016 there was a news post found https://www.openssl.org/blog/blog/2016/07/20/fips/ about the OpenSSL 1.1.x FIPS canister. I had also read about an relatively sensible schedule: https://www.safelogic.com/openssl-1-1-update/ I haven't heard anything since, and it would be exciting if when 1.1.1 comes out that we have a canister that fits into it. Did SafeLogic pull out? I did see that on the wiki that their information was redacted. Thanks, xemdetia -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Thu Jan 25 15:45:34 2018 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Thu, 25 Jan 2018 16:45:34 +0100 Subject: [openssl-users] FIPS 3.0 Canister Status In-Reply-To: References: Message-ID: <80f6207b-687c-3950-72da-fa7097fb1f10@ncp-e.com> You might be interested in the following two blog posts: https://www.openssl.org/blog/blog/2017/07/25/fips/ https://www.openssl.org/blog/blog/2017/08/17/fips/ Matthias On 25.01.2018 16:34, xemdetia . wrote: > Hey all, > > Back in 2016 there was a news post found > https://www.openssl.org/blog/blog/2016/07/20/fips/ about the OpenSSL > 1.1.x FIPS canister. I had also read about an relatively sensible > schedule: https://www.safelogic.com/openssl-1-1-update/ > > I haven't heard anything since, and it would be exciting if when 1.1.1 > comes out that we have a canister that fits into it. Did SafeLogic > pull out? I did see that on the wiki that their information was redacted. > > Thanks, > xemdetia > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Thu Jan 25 17:24:53 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 25 Jan 2018 12:24:53 -0500 Subject: [openssl-users] error 20 at 0 depth lookup:unable to get local issuer certificate error In-Reply-To: <1516874340833-0.post@n7.nabble.com> References: <1516874340833-0.post@n7.nabble.com> Message-ID: <14962D98-017C-446E-AE84-B8C8BB5C97AA@dukhovni.org> > On Jan 25, 2018, at 4:59 AM, Oleg Smelkoff wrote: > > As I tought, reason of that problem was incorrect AKID of EE-certificate, > cause AKID has to identify the issuer of the issuer, That is indeed the problem, but your statement above is not accurate. In the AKID extension the following rules apply: (See https://tools.ietf.org/html/rfc5280#section-4.2.1.1) 1. The "keyIdentifier" (keyid), if present, must match the subject key ID of the issuing CA's certificate (not the issuer of the issuer) 2. The "authorityCertSerialNumber", if present, must match the serial number of issuing CA's certificate (not the issuer of the issuer) 3. The "authorityCertIssuer" (DirName), if present, must match the issuer DN of the issuing CA's certificate. It is part 3 that is perhaps confusing you a bit, because it is also the subject DN of the issuing CA's issuer. > Could you help me, please. I'm really stucked at this problem :( The above requirements are not met by D2, because C2's issuer: OBJECT :INN NUMERICSTRING :007710474375 OBJECT :OGRN NUMERICSTRING :1047702026701 OBJECT :emailAddress IA5STRING :dit at minsvyaz.ru OBJECT :streetAddress UTF8STRING :125375 ?. ?????? ??. ???????? ?.7 OBJECT :organizationName UTF8STRING :??????????? ?????? OBJECT :localityName UTF8STRING :?????? OBJECT :stateOrProvinceName UTF8STRING :77 ?. ?????? OBJECT :countryName PRINTABLESTRING :RU OBJECT :commonName UTF8STRING :?? 1 ?? ??? Does not match D2's AKID DirName: OBJECT :OGRN NUMERICSTRING :1069659052760 OBJECT :INN NUMERICSTRING :006659140843 OBJECT :countryName PRINTABLESTRING :RU OBJECT :stateOrProvinceName UTF8STRING :66 ???????????? ??????? OBJECT :localityName UTF8STRING :???????????? OBJECT :streetAddress UTF8STRING :??. ????????????, ?. 15 OBJECT :organizationalUnitName UTF8STRING :?????????????? ????? OBJECT :organizationName UTF8STRING :??? "????????" OBJECT :commonName UTF8STRING :??????????? ?? 2.0 While D1's AKID DirName is: OBJECT :INN NUMERICSTRING :007710474375 OBJECT :OGRN NUMERICSTRING :1047702026701 OBJECT :emailAddress IA5STRING :dit at minsvyaz.ru OBJECT :streetAddress UTF8STRING :125375 ?. ?????? ??. ???????? ?.7 OBJECT :organizationName UTF8STRING :??????????? ?????? OBJECT :localityName UTF8STRING :?????? OBJECT :stateOrProvinceName UTF8STRING :77 ?. ?????? OBJECT :countryName PRINTABLESTRING :RU OBJECT :commonName UTF8STRING :?? 1 ?? ??? which does match the C1's and C2's common issuer DN, that is, B's subject DN. -- Viktor. From rsalz at akamai.com Thu Jan 25 17:50:13 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 25 Jan 2018 17:50:13 +0000 Subject: [openssl-users] FIPS 3.0 Canister Status In-Reply-To: <80f6207b-687c-3950-72da-fa7097fb1f10@ncp-e.com> References: <80f6207b-687c-3950-72da-fa7097fb1f10@ncp-e.com> Message-ID: <89222CDD-C0E3-4F8E-A44D-B2B5EFF7467F@akamai.com> And also the last paragraph of our most recent blog entry, which says this: We also decided that the primary focus of the next feature release after 1.1.1 will be FIPS. We know that FIPS is very important to some, not all, members of our community and we are committed to addressing this. We don?t have much more information to share, and we know there has been some confusion and misleading communication out there. But we do want to make this strong, definitive statement: OpenSSL will implement a FIPS solution, and we expect it will be completed much sooner than previous timetables indicated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at iclou.ch Fri Jan 26 15:13:18 2018 From: mail at iclou.ch (clou) Date: Fri, 26 Jan 2018 16:13:18 +0100 Subject: [openssl-users] mail encryption with ecdsa cert Message-ID: <22248452-7E06-44C5-9BAB-4BAA49F78F5F@iclou.ch> openssl 1.1.0.f ecdsa 512 certificate openssl cms -sign works perfect and sending an email. For encryption and sending an email I just get an email with an attachment smime.p7m. I use the following encryption command openssl cms -encrypt \ -recip cert.pem \ -subject 'openssl encrypt' \ -to email \ -from email \ -in msg.txt \ -keyopt ecdh_kdf_md:sha256 \ | \ sendmail email Any idea how I need do encrypt (or encrypt and sign) in order to get a proper email? Thanks a lot! -------------- next part -------------- An HTML attachment was scrubbed... URL: From aerowolf at gmail.com Fri Jan 26 17:20:40 2018 From: aerowolf at gmail.com (Kyle Hamilton) Date: Fri, 26 Jan 2018 09:20:40 -0800 Subject: [openssl-users] mail encryption with ecdsa cert In-Reply-To: <22248452-7E06-44C5-9BAB-4BAA49F78F5F@iclou.ch> References: <22248452-7E06-44C5-9BAB-4BAA49F78F5F@iclou.ch> Message-ID: On the algorithmic side of things, the ECDSA algorithm cannot encrypt. It is signing-only. In order to use Elliptical Curves to encrypt, you would have to use the "Elliptical Curve Diffie-Hellman" algorithm to perform a key agreement. This requires that both the sender and the recipient have EC keys which are marked in their certificates as being for the purpose "keyAgreement". Your command line only specifies the recipient certificate, not the sending certificate. You can't do an ecdh_kdf_md:sha256 operation without the sender's certificate and private key. I hope this helps! -Kyle H On Fri, Jan 26, 2018 at 7:13 AM, clou wrote: > openssl 1.1.0.f > ecdsa 512 certificate > > openssl cms -sign works perfect and sending an email. > > For encryption and sending an email I just get an email with an attachment > smime.p7m. > > I use the following encryption command > > openssl cms -encrypt \ > -recip cert.pem \ > -subject 'openssl encrypt' \ > -to email \ > -from email \ > -in msg.txt \ > -keyopt ecdh_kdf_md:sha256 \ > | \ > sendmail email > > > Any idea how I need do encrypt (or encrypt and sign) in order to get a > proper email? > > Thanks a lot! > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From jb-openssl at wisemo.com Fri Jan 26 17:46:28 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 26 Jan 2018 18:46:28 +0100 Subject: [openssl-users] mail encryption with ecdsa cert In-Reply-To: References: <22248452-7E06-44C5-9BAB-4BAA49F78F5F@iclou.ch> Message-ID: Doesn't S/MIME permit the half-ephemeral ECDH algorithm where the recipient's static ECDH certificate is combined with a per message ephemeral ECDH key? On 26/01/2018 18:20, Kyle Hamilton wrote: > On the algorithmic side of things, the ECDSA algorithm cannot encrypt. > It is signing-only. > > In order to use Elliptical Curves to encrypt, you would have to use > the "Elliptical Curve Diffie-Hellman" algorithm to perform a key > agreement. This requires that both the sender and the recipient have > EC keys which are marked in their certificates as being for the > purpose "keyAgreement". > > Your command line only specifies the recipient certificate, not the > sending certificate. You can't do an ecdh_kdf_md:sha256 operation > without the sender's certificate and private key. > > I hope this helps! > > -Kyle H > > > > On Fri, Jan 26, 2018 at 7:13 AM, clou wrote: >> openssl 1.1.0.f >> ecdsa 512 certificate >> >> openssl cms -sign works perfect and sending an email. >> >> For encryption and sending an email I just get an email with an attachment >> smime.p7m. >> >> I use the following encryption command >> >> openssl cms -encrypt \ >> -recip cert.pem \ >> -subject 'openssl encrypt' \ >> -to email \ >> -from email \ >> -in msg.txt \ >> -keyopt ecdh_kdf_md:sha256 \ >> | \ >> sendmail email >> >> >> Any idea how I need do encrypt (or encrypt and sign) in order to get a >> proper email? >> >> Thanks a lot! >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From openssl-users at dukhovni.org Fri Jan 26 17:55:56 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 26 Jan 2018 12:55:56 -0500 Subject: [openssl-users] mail encryption with ecdsa cert In-Reply-To: <22248452-7E06-44C5-9BAB-4BAA49F78F5F@iclou.ch> References: <22248452-7E06-44C5-9BAB-4BAA49F78F5F@iclou.ch> Message-ID: <7F66C9D7-C9F0-4348-A6C0-5CF3092ED0DD@dukhovni.org> > On Jan 26, 2018, at 10:13 AM, clou wrote: > > openssl cms -sign works perfect and sending an email. > > For encryption and sending an email I just get an email with an attachment smime.p7m. > > I use the following encryption command > > openssl cms -encrypt \ > -recip cert.pem \ > -subject 'openssl encrypt' \ > -to email \ > -from email \ > -in msg.txt \ > -keyopt ecdh_kdf_md:sha256 \ > | \ > sendmail email > > > Any idea how I need do encrypt (or encrypt and sign) in order to get a proper email? This requires a pipeline of two cms(1) commands, one to sign and other to encrypt (S/MIME is generally a sign-then-encrypt encapsulation). The inner signed content would be the just the payload no mail headers. And yes, ECDSA is supported with CMS. -- Viktor. From mail at iclou.ch Fri Jan 26 19:49:11 2018 From: mail at iclou.ch (clou) Date: Fri, 26 Jan 2018 20:49:11 +0100 Subject: [openssl-users] mail encryption with ecdsa cert In-Reply-To: <7F66C9D7-C9F0-4348-A6C0-5CF3092ED0DD@dukhovni.org> References: <22248452-7E06-44C5-9BAB-4BAA49F78F5F@iclou.ch> <7F66C9D7-C9F0-4348-A6C0-5CF3092ED0DD@dukhovni.org> Message-ID: <48F1C8CF-D503-4DB2-833B-659C52DE673E@iclou.ch> On 26 Jan 2018, at 18:55, Viktor Dukhovni wrote: > > This requires a pipeline of two cms(1) commands, one to sign and other > to encrypt (S/MIME is generally a sign-then-encrypt encapsulation). > The inner signed content would be the just the payload no mail headers. openssl cms -sign \ -in msg.txt \ -inkey key.pem \ -signer pub.pem \ -text \ | \ openssl cms -encrypt \ -recip pub.pem \ -subject 'openssl signed and encrypt' \ -to email \ -from email \ | \ sendmail email With this I still get the same result, an smime.p7m attachment which can not be opened. Please note, using the same certificate/key in OSX mail app for sign and encrypt works perfect. Any help is very much appreciate as I already spent 3 evening with reading/&fiddling around with the different parameters :-) Thanks so much! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at iclou.ch Sun Jan 28 10:58:42 2018 From: mail at iclou.ch (clou) Date: Sun, 28 Jan 2018 11:58:42 +0100 Subject: [openssl-users] mail encryption with ecdsa cert In-Reply-To: References: <22248452-7E06-44C5-9BAB-4BAA49F78F5F@iclou.ch> Message-ID: > On 26 Jan 2018, at 18:20, Kyle Hamilton wrote: > > In order to use Elliptical Curves to encrypt, you would have to use > the "Elliptical Curve Diffie-Hellman" algorithm to perform a key > agreement. This requires that both the sender and the recipient have > EC keys which are marked in their certificates as being for the > purpose "keyAgreement?. I have made sure that keyAgreement is in. I get the following error Error: PKCS7_RECIP_INFO_set:encryption not supported for this key type Key gen happens like this /usr/local/bin/openssl ecparam -name secp521r1 -out secp521r1.pem /usr/local/bin/openssl req -x509 -nodes -days 3650 -newkey ec:secp521r1.pem -keyout email-key.pem -out email.ch.pem Which type of key do I need to generate? (for email signing and encryption). Thanks a lot for any help ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From pratyush.parimal at gmail.com Mon Jan 29 03:05:13 2018 From: pratyush.parimal at gmail.com (pratyush parimal) Date: Sun, 28 Jan 2018 22:05:13 -0500 Subject: [openssl-users] Correct way to free SSL_CTX* ? Message-ID: Hi all, I'm trying to write an application in which I create an instance of SSL_CTX* using SSL_CTX_new(), and set the following things in it: (1) An EVP_PKEY* : 1a> created with PEM_read_bio_PrivateKey(). 1b> set in the ctx using SSL_CTX_use_PrivateKey(). (2) A number of X509* instances (cuz chained certs) : 2a> all created with PEM_read_bio_X509(). 2b> set in the ctx using SSL_CTX_use_certificate() or SSL_CTX_add_extra_chain_cert(). At the end, I use SSL_CTX_free() to free up the ctx. According to the man page for SSL_CTX_free(): "SSL_CTX_free() decrements the reference count of ctx, and removes the SSL_CTX object pointed to by ctx and frees up the allocated memory if the the reference count has reached 0. It also calls the free()ing procedures for indirectly affected items, if applicable: the session cache, the list of ciphers, the list of Client CAs, the certificates and keys. " ... which tells me that freeing the SSL_CTX should free up its memory as well as the things I set inside of it (unless I'm interpreting it super wrong?) like " ... certificates and keys". The problem is, when run my application under valgrind, I keep seeing memory leaks for both steps (1a) and (2a). I tried to get rid of them, by using EVP_PKEY_free() after I'm done setting in step (1b). This works, and the leak for step (1a) goes away. When I try to do the same for step (2), i.e. calling X509_free() after every successful "set" call, I get a coredump (backtrace is attached: bt_1.txt), coming out of SSL_CTX_free, suggesting that I did something wrong. Which brings me to my question, does anyone know the correct way to free memory in SSL_CTX ? Or, what's wrong with my steps? The application doesn't even perform SSL yet, I'm just trying to create/destroy SSL_CTX objects without leaks first. Any help would be appreciated! Thanks in advance, -Pratyush. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- Leak when I don't free the X509* objects manually. Line test_ssl_leak.cpp:241 actually has a call to PEM_read_bio_X509. ==27639== ==27639== HEAP SUMMARY: ==27639== in use at exit: 163,236 bytes in 2,948 blocks ==27639== total heap usage: 5,063 allocs, 2,115 frees, 398,442 bytes allocated ==27639== ==27639== 3,659 (184 direct, 3,475 indirect) bytes in 1 blocks are definitely lost in loss record 278 of 282 ==27639== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==27639== by 0x5105E77: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0) ==27639== by 0x51E1443: asn1_item_ex_combine_new (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0) ==27639== by 0x51E3EB0: ASN1_item_ex_d2i (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0) ==27639== by 0x51E449A: ASN1_item_d2i (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0) ==27639== by 0x51F33AD: PEM_ASN1_read_bio (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0) ==27639== by 0x4173B8: makeDataSSLCtx(std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, bool) (test_ssl_leak.cpp:241) ==27639== by 0x417BE0: test_ssl_leak() (test_ssl_leak.cpp:487) ==27639== by 0x4083CE: main (test2.cpp:53) ==27639== ==27639== LEAK SUMMARY: ==27639== definitely lost: 184 bytes in 1 blocks ==27639== indirectly lost: 3,475 bytes in 94 blocks ==27639== possibly lost: 0 bytes in 0 blocks ==27639== still reachable: 159,577 bytes in 2,853 blocks ==27639== suppressed: 0 bytes in 0 blocks ==27639== Reachable blocks (those to which a pointer was found) are not shown. ==27639== To see them, rerun with: --leak-check=full --show-leak-kinds=all ========================================================================================================================== Core dump after I do call X509_free after a successful call to SSL_CTX_use_certificate() or SSL_CTX_add_extra_chain_cert() #0 ASN1_STRING_free (a=0x40) at asn1_lib.c:428 #1 0x00007f53f2fa5675 in ASN1_primitive_free (pval=, it=) at tasn_fre.c:244 #2 0x00007f53f2fa5aaf in ASN1_template_free (pval=0x1627060, tt=tt at entry=0x7f53f3295970 ) at tasn_fre.c:191 #3 0x00007f53f2fa57e2 in asn1_item_combine_free (pval=pval at entry=0x7ffe273ef1a8, it=0x7f53f328eb20 , combine=combine at entry=0) at tasn_fre.c:166 #4 0x00007f53f2fa59f5 in ASN1_item_free (val=0x1627050, it=) at tasn_fre.c:72 #5 0x00007f53f2f81041 in sk_pop_free (st=0x1628520, func=0x405380 ) at stack.c:327 #6 0x00007f53f32e8da7 in SSL_CTX_free (a=0x16249d0) at ssl_lib.c:2152 #7 0x0000000000417d69 in std::unique_ptr::reset (this=0x7ffe273ef220, __p=0x16249d0) at /usr/include/c++/5/bits/unique_ptr.h:344 #8 0x0000000000417c33 in test_ssl_leak () at ../src/test_ssl_leak.cpp:492 #9 0x00000000004083cf in main () at ../src/test2.cpp:53 From d3ck0r at gmail.com Mon Jan 29 03:20:02 2018 From: d3ck0r at gmail.com (J Decker) Date: Sun, 28 Jan 2018 19:20:02 -0800 Subject: [openssl-users] Correct way to free SSL_CTX* ? In-Reply-To: References: Message-ID: On Sun, Jan 28, 2018 at 7:05 PM, pratyush parimal < pratyush.parimal at gmail.com> wrote: > Hi all, > > I'm trying to write an application in which I create an instance of > SSL_CTX* using SSL_CTX_new(), and set the following things in it: > > (1) An EVP_PKEY* : > 1a> created with PEM_read_bio_PrivateKey(). > 1b> set in the ctx using SSL_CTX_use_PrivateKey(). > after setting key, free key > > (2) A number of X509* instances (cuz chained certs) : > 2a> all created with PEM_read_bio_X509(). > 2b> set in the ctx using SSL_CTX_use_certificate() or > SSL_CTX_add_extra_chain_cert(). > after setting certs, free certs. > > At the end, I use SSL_CTX_free() to free up the ctx. According to the man > page for SSL_CTX_free(): > > "SSL_CTX_free() decrements the reference count of ctx, and removes the > SSL_CTX object pointed to by ctx and frees up the allocated memory if the > the reference count has reached 0. > It also calls the free()ing procedures for indirectly affected > items, if applicable: the session cache, the list of ciphers, the list of > Client CAs, the certificates and keys. " > > ... which tells me that freeing the SSL_CTX should free up its memory as > well as the things I set inside of it (unless I'm interpreting it super > wrong?) like " ... certificates and keys". > The problem is, when run my application under valgrind, I keep seeing > memory leaks for both steps (1a) and (2a). > > I tried to get rid of them, by using EVP_PKEY_free() after I'm done > setting in step (1b). This works, and the leak for step (1a) goes away. > When I try to do the same for step (2), i.e. calling X509_free() after > every successful "set" call, I get a coredump (backtrace is attached: > bt_1.txt), coming out of SSL_CTX_free, suggesting that I did something > wrong. > > > Which brings me to my question, does anyone know the correct way to free > memory in SSL_CTX ? Or, what's wrong with my steps? The application doesn't > even perform SSL yet, I'm just trying to create/destroy SSL_CTX objects > without leaks first. Any help would be appreciated! > > > Thanks in advance, > -Pratyush. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pratyush.parimal at gmail.com Mon Jan 29 05:09:44 2018 From: pratyush.parimal at gmail.com (pratyush parimal) Date: Mon, 29 Jan 2018 00:09:44 -0500 Subject: [openssl-users] Correct way to free SSL_CTX* ? In-Reply-To: References: Message-ID: Hi all, I think I found the way to fix the memory leak in my application. Just floating it here in case it helps out someone else. The answer was on the wiki page for SSL_CTX_add_extra_chain_cert(): "The *x509* certificate provided to SSL_CTX_add_extra_chain_cert() will be freed by the library when the *SSL_CTX* is destroyed. An application *should not* free the *x509* object." The trick was to realize that the cert added via SSL_CTX_use_certificate() can be (and should be, I think) free'd manually right after this call. Otherwise you've got a memory leak on your hands. But the certs added using SSL_CTX_add_extra_chain_cert() should not be free'd up manually - those are cleaned up SSL_CTX_free later at the end of the application. After doing this, the memory leak and the crash both went away. Thanks, -Pratyush. On Sun, Jan 28, 2018 at 10:20 PM, J Decker wrote: > > > On Sun, Jan 28, 2018 at 7:05 PM, pratyush parimal < > pratyush.parimal at gmail.com> wrote: > >> Hi all, >> >> I'm trying to write an application in which I create an instance of >> SSL_CTX* using SSL_CTX_new(), and set the following things in it: >> >> (1) An EVP_PKEY* : >> 1a> created with PEM_read_bio_PrivateKey(). >> 1b> set in the ctx using SSL_CTX_use_PrivateKey(). >> > after setting key, free key > >> >> (2) A number of X509* instances (cuz chained certs) : >> 2a> all created with PEM_read_bio_X509(). >> 2b> set in the ctx using SSL_CTX_use_certificate() or >> SSL_CTX_add_extra_chain_cert(). >> > after setting certs, free certs. > >> >> At the end, I use SSL_CTX_free() to free up the ctx. According to the man >> page for SSL_CTX_free(): >> >> "SSL_CTX_free() decrements the reference count of ctx, and removes the >> SSL_CTX object pointed to by ctx and frees up the allocated memory if the >> the reference count has reached 0. >> It also calls the free()ing procedures for indirectly affected >> items, if applicable: the session cache, the list of ciphers, the list of >> Client CAs, the certificates and keys. " >> >> ... which tells me that freeing the SSL_CTX should free up its memory as >> well as the things I set inside of it (unless I'm interpreting it super >> wrong?) like " ... certificates and keys". >> The problem is, when run my application under valgrind, I keep seeing >> memory leaks for both steps (1a) and (2a). >> >> I tried to get rid of them, by using EVP_PKEY_free() after I'm done >> setting in step (1b). This works, and the leak for step (1a) goes away. >> When I try to do the same for step (2), i.e. calling X509_free() after >> every successful "set" call, I get a coredump (backtrace is attached: >> bt_1.txt), coming out of SSL_CTX_free, suggesting that I did something >> wrong. >> >> >> Which brings me to my question, does anyone know the correct way to free >> memory in SSL_CTX ? Or, what's wrong with my steps? The application doesn't >> even perform SSL yet, I'm just trying to create/destroy SSL_CTX objects >> without leaks first. Any help would be appreciated! >> >> >> Thanks in advance, >> -Pratyush. >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From murugesh.pitchaiah at gmail.com Mon Jan 29 06:14:37 2018 From: murugesh.pitchaiah at gmail.com (murugesh pitchaiah) Date: Mon, 29 Jan 2018 11:44:37 +0530 Subject: [openssl-users] Correct way to free SSL_CTX* ? In-Reply-To: References: Message-ID: Hi Pratyush, Whenever you set a certificate to CTX, the reference count will get incremented: CRYPTO_add(&x->references, 1, CRYPTO_LOCK_X509); In addition, inside your application any usage of a certificate may cause this reference count to be incremented. As you can seen in man page - one call to ctx free will just decrement the reference count by one. Only the count is 0, it starts freeing whole memory. So you need to watch for these reference counts, to avoid leak. Also when you fix leak properly hope the back trace should be gone. X509_free - can also be used to decrement the reference count. Regards, Murugesh P. On 1/29/18, pratyush parimal wrote: > Hi all, > > I'm trying to write an application in which I create an instance of > SSL_CTX* using SSL_CTX_new(), and set the following things in it: > > (1) An EVP_PKEY* : > 1a> created with PEM_read_bio_PrivateKey(). > 1b> set in the ctx using SSL_CTX_use_PrivateKey(). > > (2) A number of X509* instances (cuz chained certs) : > 2a> all created with PEM_read_bio_X509(). > 2b> set in the ctx using SSL_CTX_use_certificate() or > SSL_CTX_add_extra_chain_cert(). > > At the end, I use SSL_CTX_free() to free up the ctx. According to the man > page for SSL_CTX_free(): > > "SSL_CTX_free() decrements the reference count of ctx, and removes the > SSL_CTX object pointed to by ctx and frees up the allocated memory if the > the reference count has reached 0. > It also calls the free()ing procedures for indirectly affected > items, if applicable: the session cache, the list of ciphers, the list of > Client CAs, the certificates and keys. " > > ... which tells me that freeing the SSL_CTX should free up its memory as > well as the things I set inside of it (unless I'm interpreting it super > wrong?) like " ... certificates and keys". > The problem is, when run my application under valgrind, I keep seeing > memory leaks for both steps (1a) and (2a). > > I tried to get rid of them, by using EVP_PKEY_free() after I'm done setting > in step (1b). This works, and the leak for step (1a) goes away. > When I try to do the same for step (2), i.e. calling X509_free() after > every successful "set" call, I get a coredump (backtrace is attached: > bt_1.txt), coming out of SSL_CTX_free, suggesting that I did something > wrong. > > > Which brings me to my question, does anyone know the correct way to free > memory in SSL_CTX ? Or, what's wrong with my steps? The application doesn't > even perform SSL yet, I'm just trying to create/destroy SSL_CTX objects > without leaks first. Any help would be appreciated! > > > Thanks in advance, > -Pratyush. > From bfussell at cisco.com Tue Jan 30 22:31:33 2018 From: bfussell at cisco.com (Barry Fussell (bfussell)) Date: Tue, 30 Jan 2018 22:31:33 +0000 Subject: [openssl-users] Windows fuzz test Message-ID: <27bc07a2fb2a4f7daa0ac6b48b640819@XCH-ALN-004.cisco.com> Is anyone else encountering extremely long test times for the fuzz testing on windows builds ? 32-bit or 64-bit it doesn't matter. The minimum test time is around 90 minutes. Thanks, Barry Fussell -------------- next part -------------- An HTML attachment was scrubbed... URL: