From rajuvishnu52 at gmail.com Thu Dec 1 07:49:14 2016 From: rajuvishnu52 at gmail.com (vishnu raju) Date: Thu, 01 Dec 2016 07:49:14 +0000 Subject: [openssl-users] Openssl connects with Des-Cbc-sha in tls1. 2 Message-ID: Hi all, I am getting connection success in a tls1.2 connection with Des-Cbc-sha cipher. But upto my knowledge this cipher is depreciated on tls1.2. Thanks for your help. Regards, Vishnu -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Thu Dec 1 12:26:09 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 1 Dec 2016 13:26:09 +0100 Subject: [openssl-users] Openssl connects with Des-Cbc-sha in tls1. 2 In-Reply-To: References: Message-ID: On 01/12/2016 08:49, vishnu raju wrote: > Hi all, > I am getting connection success in a tls1.2 connection with > Des-Cbc-sha cipher. But upto my knowledge this cipher is depreciated > on tls1.2. > Thanks for your help. > It is not disabled, just scheduled for future disabling as far as the TLS 1.2 standard/RFC is concerned. In OpenSSL its use is controlled by the "cipher list" setting, which is a runtime setting made by the client and server software. For single-DES (not triple DES), this would indicate that both ends are configured insecurely since single DES has been considered weak almost since the invention of SSL/TLS. For Triple-DES (DES3), some recent OpenSSL versions reclassified it to a lower grade because of the well-known (since the beginning) danger of encrypting too much data with a single key, a danger that was recently highlighted under the name SWEET32. Triple DES can be enabled or disabled via an appropriate "cipher list" setting regardless of OpenSSL version. 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 brian at virtru.com Thu Dec 1 17:39:31 2016 From: brian at virtru.com (Brian Jost) Date: Thu, 1 Dec 2016 10:39:31 -0700 Subject: [openssl-users] French Declaration Message-ID: I see that it was discussed many years ago about getting a French Declaration for openssl. Was this ever successful? If so is there a place I can download the declaration as it seems to be required when submitting to the iOS appstore. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Dec 1 17:56:48 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 1 Dec 2016 17:56:48 +0000 Subject: [openssl-users] French Declaration In-Reply-To: References: Message-ID: > I see that it was discussed many years ago about getting a French Declaration for openssl. Was this ever successful? If so is there a place I can download the declaration as it seems to be required when submitting to the iOS appstore. The OpenSSL project has never pursued or obtained any such document. From pl at artisanlogiciel.net Thu Dec 1 18:41:33 2016 From: pl at artisanlogiciel.net (pl) Date: Thu, 1 Dec 2016 19:41:33 +0100 Subject: [openssl-users] French Declaration In-Reply-To: References: Message-ID: <425a579a-7d6b-142c-821c-d32d52fdd290@artisanlogiciel.net> On 01/12/2016 18:56, Salz, Rich wrote: >> I see that it was discussed many years ago about getting a French Declaration for openssl. Was this ever successful? If so is there a place I can download the declaration as it seems to be required when submitting to the iOS appstore. > The OpenSSL project has never pursued or obtained any such document. I am not sure of what 'French Declaration means' at least Loic Dachary did request for one 'autorisation de fourniture en vue de l'utilisation g?n?rale et d'importation et exportation' for fsfe long time ago; information in french can be found here http://fsffrance.org/dcssi/dcssi.fr.html but .. is quite old. This covers 'D?cret n?2001-1192 du 13 d?cembre 2001 relatif au contr?le ? l'exportation, ? l'importation et au transfert de biens et technologies ? double usage'. ( This very moment i prefer being a developer than a lawer ). This is for information only, i won't be of any further help on that topic. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From peter.sylvester at edelweb.fr Thu Dec 1 19:12:42 2016 From: peter.sylvester at edelweb.fr (Peter Sylvester Edelweb) Date: Thu, 1 Dec 2016 19:12:42 +0000 Subject: [openssl-users] French Declaration In-Reply-To: <425a579a-7d6b-142c-821c-d32d52fdd290@artisanlogiciel.net> References: <425a579a-7d6b-142c-821c-d32d52fdd290@artisanlogiciel.net> Message-ID: <064119cd-29fe-0c57-1e93-fe8ecb6291b4@edelweb.fr> Hi There are news since about a year. https://www.ssi.gouv.fr/administration/reglementation/controle-reglementaire-sur-la-cryptographie/ There is a downloadable editable PDF to prepare the declaration. Anyway, you normally do not declare all functionality of the openssl library if you use it in a product. It may be as simple as "to hash passwords we use the SHAnnn functions as implemented by openssl". I used to make such declarations about 15 years ago. Peter From brian at virtru.com Thu Dec 1 19:29:02 2016 From: brian at virtru.com (Brian Jost) Date: Thu, 1 Dec 2016 12:29:02 -0700 Subject: [openssl-users] French Declaration In-Reply-To: <064119cd-29fe-0c57-1e93-fe8ecb6291b4@edelweb.fr> References: <425a579a-7d6b-142c-821c-d32d52fdd290@artisanlogiciel.net> <064119cd-29fe-0c57-1e93-fe8ecb6291b4@edelweb.fr> Message-ID: Ok thanks, so there isn't a generic declaration that applications using openssl standard encryption like GCM can use? Each application will have to get self declared? On Thu, Dec 1, 2016 at 12:12 PM, Peter Sylvester Edelweb < peter.sylvester at edelweb.fr> wrote: > Hi > > There are news since about a year. > > https://www.ssi.gouv.fr/administration/reglementation/ > controle-reglementaire-sur-la-cryptographie/ > There is a downloadable editable PDF to prepare the declaration. > > Anyway, you normally do not declare all functionality of the openssl > library if you use it in a product. > > It may be as simple as "to hash passwords we use the SHAnnn functions as > implemented by openssl". > > I used to make such declarations about 15 years ago. > > > Peter > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.sylvester at edelweb.fr Thu Dec 1 19:44:02 2016 From: peter.sylvester at edelweb.fr (Peter Sylvester Edelweb) Date: Thu, 1 Dec 2016 19:44:02 +0000 Subject: [openssl-users] French Declaration In-Reply-To: References: <425a579a-7d6b-142c-821c-d32d52fdd290@artisanlogiciel.net> <064119cd-29fe-0c57-1e93-fe8ecb6291b4@edelweb.fr> Message-ID: <41540709-73db-edd3-42af-0f70b64d6878@edelweb.fr> Two points: - you use function xyz of openssl (is the implementation safe?) - the purpose of using this in your application is "saving peanuts". what are peanuts? /P On 12/01/2016 08:29 PM, Brian Jost wrote: Ok thanks, so there isn't a generic declaration that applications using openssl standard encryption like GCM can use? Each application will have to get self declared? On Thu, Dec 1, 2016 at 12:12 PM, Peter Sylvester Edelweb > wrote: Hi There are news since about a year. https://www.ssi.gouv.fr/administration/reglementation/controle-reglementaire-sur-la-cryptographie/ There is a downloadable editable PDF to prepare the declaration. Anyway, you normally do not declare all functionality of the openssl library if you use it in a product. It may be as simple as "to hash passwords we use the SHAnnn functions as implemented by openssl". I used to make such declarations about 15 years ago. Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajuvishnu52 at gmail.com Fri Dec 2 05:20:52 2016 From: rajuvishnu52 at gmail.com (vishnu raju) Date: Fri, 2 Dec 2016 10:50:52 +0530 Subject: [openssl-users] Openssl connects with Des-Cbc-sha in tls1. 2 In-Reply-To: References: Message-ID: Thank You so much, Jacob Regards, Vishnu Raju. On Thu, Dec 1, 2016 at 5:56 PM, Jakob Bohm wrote: > On 01/12/2016 08:49, vishnu raju wrote: > >> Hi all, >> I am getting connection success in a tls1.2 connection with Des-Cbc-sha >> cipher. But upto my knowledge this cipher is depreciated on tls1.2. >> Thanks for your help. >> >> It is not disabled, just scheduled for future disabling as far > as the TLS 1.2 standard/RFC is concerned. > > In OpenSSL its use is controlled by the "cipher list" setting, > which is a runtime setting made by the client and server software. > > For single-DES (not triple DES), this would indicate that both ends > are configured insecurely since single DES has been considered weak > almost since the invention of SSL/TLS. > > For Triple-DES (DES3), some recent OpenSSL versions reclassified it > to a lower grade because of the well-known (since the beginning) > danger of encrypting too much data with a single key, a danger that > was recently highlighted under the name SWEET32. Triple DES can > be enabled or disabled via an appropriate "cipher list" setting > regardless of OpenSSL version. > > 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 > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedor_qd at mail.ru Fri Dec 2 10:51:54 2016 From: fedor_qd at mail.ru (Fiodar Stryzhniou) Date: Fri, 2 Dec 2016 13:51:54 +0300 Subject: [openssl-users] purpose dir crypto/dso Message-ID: <8fxCy2fLdvHd.YFtJRjJ3@smtp.mail.ru> Hi! This directory should build when each dir in crypto/ builded as separate dll, isn't it? This directory contain module loader, right? I googled with "crypto/dso purpose" without luck. Fiodar Stryzhniou From richard.c.paterson at sas.com Fri Dec 2 15:14:23 2016 From: richard.c.paterson at sas.com (Richard Paterson) Date: Fri, 2 Dec 2016 15:14:23 +0000 Subject: [openssl-users] Roadmap: the future of 1.1? Message-ID: Hi, We're at a point where we're deciding between two paths re OpenSSL; * Continue with OpenSSL 1.0.2 (LTS until December 2019) and struggle with getting EC to work * Move to OpenSSL 1.1.0 (supported until August 2018) whose new API makes it much more friendly to use. https://www.openssl.org/policies/releasestrat.html This page doesn't currently mention what the future "trunk" version of OpenSSL will be after 1.1.0. Will there be a 1.1.1, or a 1.2.0 appearing in the next couple of years? You've said no 1.0.3, so I assume at some point a 1.1.n or 1.n.n release will become the new LTS. In short, if we go to 1.1.0, are we going to have to swap back to 1.0.2 come August 2018, or will there be a 1.1.1 (or something) in place? Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Dec 2 16:54:16 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 2 Dec 2016 16:54:16 +0000 Subject: [openssl-users] Roadmap: the future of 1.1? In-Reply-To: References: Message-ID: <2c87bb30-e3ba-ac69-ec0b-f969d2b93fce@openssl.org> On 02/12/16 15:14, Richard Paterson wrote: > Hi, > > > > We?re at a point where we?re deciding between two paths re OpenSSL; > > ? Continue with OpenSSL 1.0.2 (LTS until December 2019) and > struggle with getting EC to work > > ? Move to OpenSSL 1.1.0 (supported until August 2018) whose new > API makes it much more friendly to use. > > > > https://www.openssl.org/policies/releasestrat.html > > This page doesn?t currently mention what the future ?trunk? version of > OpenSSL will be after 1.1.0. Will there be a 1.1.1, or a 1.2.0 appearing > in the next couple of years? You?ve said no 1.0.3, so I assume at some > point a 1.1.n or 1.n.n release will become the new LTS. > > > > In short, if we go to 1.1.0, are we going to have to swap back to 1.0.2 > come August 2018, or will there be a 1.1.1 (or something) in place? The next release will be 1.1.1. See: https://www.openssl.org/blog/blog/2016/10/24/f2f-roadmap/ It will be well before August 2018. Basically the plan is always that you can choose between the latest release or the LTS release. We will always plan to produce another "latest" release before the previous one goes out of support. If for some reason we were unable to do that then I'm sure we would simply extend the support period of the latest release out a bit until there was one. Matt From matt at openssl.org Fri Dec 2 17:01:23 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 2 Dec 2016 17:01:23 +0000 Subject: [openssl-users] Roadmap: the future of 1.1? In-Reply-To: References: Message-ID: <9cb3f8a8-8c79-439f-d702-472525c48d80@openssl.org> On 02/12/16 15:14, Richard Paterson wrote: > You?ve said no 1.0.3, so I assume at some > point a 1.1.n or 1.n.n release will become the new LTS. I realised that I didn't answer this bit of the question. Our policy is that we will designate a new LTS release at least every four years (with support for an LTS release lasting five years). It has yet to be decided which release will be the next LTS and what version number it will be, but it is safe to say that it will be >= 1.1.1 Matt From silvioprog at gmail.com Sat Dec 3 16:18:14 2016 From: silvioprog at gmail.com (silvioprog) Date: Sat, 3 Dec 2016 13:18:14 -0300 Subject: [openssl-users] Doubt about OpenSSL library initialization in an HTTP client application Message-ID: Hello all, I'm trying to speed up the initialization of a legacy HTTP client application. Debugging that code, I found the following functions being called each application startup: initialization SSL_library_init() SSL_load_error_strings() OpenSSL_add_all_algorithms() RAND_screen() however, the execution of RAND_screen() spends about 3 seconds. The first idea was commenting this line, but I don't know if I really can do that. After some "googling" I found someone doing something like this: initialization SSL_library_init() SSL_load_error_strings() OpenSSL_add_all_algorithms() //RAND_screen() unsigned char c; RAND_bytes(&c, 1); anyway I don't know if it is really necessary, so I just commented RAND_screen() line and without add this call to RAND_bytes(). So I have a question: do I really need to call some function like RAND_* at each application initialization? This project has that same initialization: https://github.com/svn2github/Ararat-Synapse/blob/master/trunk/ssl_openssl_lib.pas#L2001 . -- Silvio Cl?cio -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sat Dec 3 17:34:42 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 3 Dec 2016 17:34:42 +0000 Subject: [openssl-users] Doubt about OpenSSL library initialization in an HTTP client application In-Reply-To: References: Message-ID: <6dc4353f78a643eb8563ac3278c720c4@usma1ex-dag1mb1.msg.corp.akamai.com> What version of openssl are you using? Current versions do not call RAND_screen or other long-term heap-walking on Windows. You absolutely *must* properly initialize the random number generator. If you fail to do that, attackers can guess the keys that you use. You will be providing only the illusion of security. Please pass this along to that other app. What it, and you, are doing is horrible. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Sat Dec 3 18:42:39 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Sat, 3 Dec 2016 13:42:39 -0500 Subject: [openssl-users] Doubt about OpenSSL library initialization in an HTTP client application In-Reply-To: References: Message-ID: > I'm trying to speed up the initialization of a legacy HTTP client > application. Debugging that code, I found the following functions being > called each application startup: > > initialization > SSL_library_init() > SSL_load_error_strings() > OpenSSL_add_all_algorithms() > RAND_screen() > > however, the execution of RAND_screen() spends about 3 seconds. Also see https://wiki.openssl.org/index.php/Library_Initialization and https://wiki.openssl.org/index.php/Random_Numbers#Windows_Issues. The short of it is, you should stop relying on auto-initialization of the RNG, and seed it yourself with a call to `RAND_add`. Jeff From silvioprog at gmail.com Sun Dec 4 03:00:25 2016 From: silvioprog at gmail.com (silvioprog) Date: Sun, 4 Dec 2016 00:00:25 -0300 Subject: [openssl-users] Doubt about OpenSSL library initialization in an HTTP client application In-Reply-To: <6dc4353f78a643eb8563ac3278c720c4@usma1ex-dag1mb1.msg.corp.akamai.com> References: <6dc4353f78a643eb8563ac3278c720c4@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Thanks for replying! I found two libraries at application's directory: libeay32.dll and ssleay32.dll, both with file version 0.9.8.14 and product version 0.9.8n. I totally agree about properly initializing the random number generator, however I don't know how to do that yet. That code I'm using is a third party Pascal binding for the OpenSSL C library, and I've noticed that many other packages was based on that implementation too (eg: https://github.com/graemeg/freepascal/blob/master/packages/openssl/src/openssl.pas#L4442 - it seems based on an old LibOpenSsl version). The application I'm fixing uses the same file this link above, and I can edit it without problems. I removed the line RAND_screen and now the application initializes fast, but I'm not sure if it will turn my application vulnerable. If I get to solve it I will try some patch sharing it to the authors of these bindings. On Sat, Dec 3, 2016 at 2:34 PM, Salz, Rich wrote: > What version of openssl are you using? Current versions do not call > RAND_screen or other long-term heap-walking on Windows. > > > > You absolutely **must** properly initialize the random number generator. > If you fail to do that, attackers can guess the keys that you use. You > will be providing only the illusion of security. > > > > Please pass this along to that other app. What it, and you, are doing is > horrible. > > > > -- > > Senior Architect, Akamai Technologies > > Member, OpenSSL Dev Team > > IM: richsalz at jabber.at Twitter: RichSalz > -- Silvio Cl?cio -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvioprog at gmail.com Sun Dec 4 03:01:29 2016 From: silvioprog at gmail.com (silvioprog) Date: Sun, 4 Dec 2016 00:01:29 -0300 Subject: [openssl-users] Doubt about OpenSSL library initialization in an HTTP client application In-Reply-To: References: Message-ID: Thanks for sharing the links, I'm going to check them. The original code call RAND_screen() only once in the app initialization, so can I replace it by RAND_add()? (I'm newbie on SSL) I've noticed the application is just a HTTP client consuming some web services via HTTPS. It doesn't call explicitly any OpenSSL random function, so I think it uses the default OpenSSL configurations. On Sat, Dec 3, 2016 at 3:42 PM, Jeffrey Walton wrote: [...] > Also see https://wiki.openssl.org/index.php/Library_Initialization and > https://wiki.openssl.org/index.php/Random_Numbers#Windows_Issues. > > The short of it is, you should stop relying on auto-initialization of > the RNG, and seed it yourself with a call to `RAND_add`. > > Jeff -- Silvio Cl?cio -------------- next part -------------- An HTML attachment was scrubbed... URL: From ritesh.worx at gmail.com Tue Dec 6 02:07:00 2016 From: ritesh.worx at gmail.com (Ritesh Patani) Date: Mon, 5 Dec 2016 18:07:00 -0800 Subject: [openssl-users] Compiling openssl libcrypto for specific folders Message-ID: Hello there, 1. I am trying to compile openssl libcrypto for selective ciphers only! specifically excluding all key exchange rsa, echd, dh etc. and just compile libcrypto with selected block/stream ciphers. What's the easiest/best way to do this? I tried "no-" option to "Configure" but that doesn't seem to be available for all ciphers. For e.g. i couldn't do "no-rsa" and configuration failed with "unsupported option". Tried this with Openssl 1.1.0c 2. Looks like no speed test available for poly/chacha.. Thanks -RR -------------- next part -------------- An HTML attachment was scrubbed... URL: From aowtea at gmail.com Fri Dec 9 03:29:16 2016 From: aowtea at gmail.com (Aow Tea) Date: Fri, 9 Dec 2016 11:29:16 +0800 Subject: [openssl-users] Does OpenSSL support the extension 'subject directory attributes'? Message-ID: Dear everyone, I am using PyOpenSSL which is the thin wrapper of OpenSSL to add the extension 'subject directory attributes' to a certificate by a Python program. The extension names 'subjectDirAttrs' and 'subjectDirectoryAttributes' have been tried but the error occurs: "OpenSSL.crypto.Error: [('X509 V3 routines', 'DO_EXT_NCONF', 'unknown extension name'), ('X509 V3 routines', 'X509V3_EXT_nconf', 'error in extension')]". As PyOpenSSL is the wrapper of OpenSSL, can anyone make it clear that whether OpenSSL supports the extension 'subject directory attributes' and what is the proper name in programming if OpenSSL supports it? The other question is the error is reported as follows when I add the extension 'certificate policies' to a certificate by PyOpenSSL. "OpenSSL.crypto.Error: [('X509 V3 routines', 'DO_EXT_NCONF', 'no config database'), ('X509 V3 routines', 'X509V3_EXT_nconf', 'error in extension')]" What is the config database? Does it refer to /usr/local/ssl/openssl.cnf? How to use it to add the extension 'certificate policies' to a certificate by PyOpenSSL? Many thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaja_mohideen.rasool at nokia.com Sat Dec 10 13:09:38 2016 From: kaja_mohideen.rasool at nokia.com (Rasool, Kaja Mohideen (Nokia - IN)) Date: Sat, 10 Dec 2016 13:09:38 +0000 Subject: [openssl-users] TLS Heartbeat Message-ID: <9D777EB87E64DD4394E1B0A02E55122EB3BC31E0@SG70XWXCHMBA04.zap.alcatel-lucent.com> Hi, I'm trying to develop a server (Java - Netty NIO Library + OpenSSL) / client (C + OpenSSL) applications. A. I started off writing my server using Netty+OpenSSL and used some python scripts available in web (https://gist.github.com/takeshixx/10107280) to test whether TLS Heartbeat with OpenSSL is fine. Strangely I found that OpenSSL responds to heartbeat only if the length of TLSPlainText.length is greater than 4096. This I have observed from testing, yet to see the OpenSSL code which imposes this limitation. B. Then I started to write my client that uses SSL_heartbeat macro - but I didn't find any way to mention how much payload/padding to be used in the heartbeat message. I need clarity on 1. Whether the limitation observed in (A) above is correct? If so, is there any way to change it. 2. How to provide inputs like payload/padding to be used to work-around the limitation (A) ? Many thanks in advance, With regards, R Kaja Mohideen -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sat Dec 10 16:04:48 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 10 Dec 2016 16:04:48 +0000 Subject: [openssl-users] TLS Heartbeat In-Reply-To: <9D777EB87E64DD4394E1B0A02E55122EB3BC31E0@SG70XWXCHMBA04.zap.alcatel-lucent.com> References: <9D777EB87E64DD4394E1B0A02E55122EB3BC31E0@SG70XWXCHMBA04.zap.alcatel-lucent.com> Message-ID: <280a21dbff7c4e27b2bfaf85c7385c12@usma1ex-dag1mb1.msg.corp.akamai.com> Heartbeats? Yuk, why. Most likely, TCP is buffering things until you get a big enough data packet. I don?t know how to address that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaja_mohideen.rasool at nokia.com Sun Dec 11 02:25:29 2016 From: kaja_mohideen.rasool at nokia.com (Rasool, Kaja Mohideen (Nokia - IN)) Date: Sun, 11 Dec 2016 02:25:29 +0000 Subject: [openssl-users] TLS Heartbeat In-Reply-To: <280a21dbff7c4e27b2bfaf85c7385c12@usma1ex-dag1mb1.msg.corp.akamai.com> References: <9D777EB87E64DD4394E1B0A02E55122EB3BC31E0@SG70XWXCHMBA04.zap.alcatel-lucent.com> <280a21dbff7c4e27b2bfaf85c7385c12@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <9D777EB87E64DD4394E1B0A02E55122EB3BC34E4@SG70XWXCHMBA04.zap.alcatel-lucent.com> Ok, maybe, TCP is doing it. Is there any other API using which I can specify the payload length & number of bytes for padding to send a TLS Heartbeat request? Then, I can use that API to send out a big enough heartbeat request so my server recognize & responds to it. // Kaja From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich Sent: Saturday, December 10, 2016 9:35 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] TLS Heartbeat Heartbeats? Yuk, why. Most likely, TCP is buffering things until you get a big enough data packet. I don't know how to address that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aerowolf at gmail.com Sun Dec 11 07:28:34 2016 From: aerowolf at gmail.com (Kyle Hamilton) Date: Sat, 10 Dec 2016 23:28:34 -0800 Subject: [openssl-users] TLS Heartbeat In-Reply-To: <280a21dbff7c4e27b2bfaf85c7385c12@usma1ex-dag1mb1.msg.corp.akamai.com> References: <9D777EB87E64DD4394E1B0A02E55122EB3BC31E0@SG70XWXCHMBA04.zap.alcatel-lucent.com> <280a21dbff7c4e27b2bfaf85c7385c12@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: disable O_NAGLE on the socket? -Kyle H On Sat, Dec 10, 2016 at 8:04 AM, Salz, Rich wrote: > Heartbeats? Yuk, why. > > > > Most likely, TCP is buffering things until you get a big enough data > packet. I don?t know how to address that. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Sun Dec 11 07:44:05 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 11 Dec 2016 02:44:05 -0500 Subject: [openssl-users] TLS Heartbeat In-Reply-To: <9D777EB87E64DD4394E1B0A02E55122EB3BC34E4@SG70XWXCHMBA04.zap.alcatel-lucent.com> References: <9D777EB87E64DD4394E1B0A02E55122EB3BC31E0@SG70XWXCHMBA04.zap.alcatel-lucent.com> <280a21dbff7c4e27b2bfaf85c7385c12@usma1ex-dag1mb1.msg.corp.akamai.com> <9D777EB87E64DD4394E1B0A02E55122EB3BC34E4@SG70XWXCHMBA04.zap.alcatel-lucent.com> Message-ID: On Sat, Dec 10, 2016 at 9:25 PM, Rasool, Kaja Mohideen (Nokia - IN) wrote: > Ok, maybe, TCP is doing it. Is there any other API using which I can specify > the payload length & number of bytes for padding to send a TLS Heartbeat > request? Then, I can use that API to send out a big enough heartbeat request > so my server recognize & responds to it. Maybe related, see https://www.igvita.com/2013/12/16/optimizing-nginx-tls-time-to-first-byte/. It shows how to measure and adjust for some throughput improvements. From 643121067 at qq.com Sun Dec 11 16:34:48 2016 From: 643121067 at qq.com (=?ISO-8859-1?B?ZGR4?=) Date: Mon, 12 Dec 2016 00:34:48 +0800 Subject: [openssl-users] Is it possible to change the name of export functions from the static library ? Message-ID: I complied an OpenSSL static library for my windows application , which utilize another ssl static library : BoringSSL too. As expected , the linker complains about LNK2005 errors . Is it possible to rename the export functions in the libssl.lib and libcrypto.lib , as well as the OpenSSL public headers ? I would like to add a prefix to them so that both libraries ( Openssl and Boringssl ) can be static linked into my windows binary. Regards ! Fabio -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Sun Dec 11 18:48:32 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Sun, 11 Dec 2016 18:48:32 +0000 Subject: [openssl-users] TLS Heartbeat In-Reply-To: References: <9D777EB87E64DD4394E1B0A02E55122EB3BC31E0@SG70XWXCHMBA04.zap.alcatel-lucent.com> <280a21dbff7c4e27b2bfaf85c7385c12@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Kyle Hamilton > Sent: Sunday, December 11, 2016 02:29 > To: openssl-users > Subject: Re: [openssl-users] TLS Heartbeat > > disable O_NAGLE on the socket? Do you mean enable TCP_NODELAY? That's the standard (POSIX / SUSv3) option that disables the Nagle algorithm. Using it is generally a sign of poorly-written software, created by someone who couldn't take the time to learn how TCP works. But then given the OP's description of the original problem, disabling the Nagle algorithm is likely not the most egregious design decision here. I'll echo Rich's sentiment: If you're using TLS heartbeat, You're Doing It Wrong. Also, note that Nagle / Delayed ACK interaction should only delay transmission for up to 200ms. The OP didn't provide any actual useful information about what the "problem" is, so we don't know whether the heartbeats would have been transmitted after 200ms. If they're not being transmitted for some other reason (e.g. receive window advertised as closed), then disabling Nagle won't make any difference. Michael Wojcik Distinguished Engineer, Micro Focus From kaja_mohideen.rasool at nokia.com Mon Dec 12 04:53:23 2016 From: kaja_mohideen.rasool at nokia.com (Rasool, Kaja Mohideen (Nokia - IN)) Date: Mon, 12 Dec 2016 04:53:23 +0000 Subject: [openssl-users] TLS Heartbeat In-Reply-To: References: <9D777EB87E64DD4394E1B0A02E55122EB3BC31E0@SG70XWXCHMBA04.zap.alcatel-lucent.com> <280a21dbff7c4e27b2bfaf85c7385c12@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <9D777EB87E64DD4394E1B0A02E55122EB3BC37EC@SG70XWXCHMBA04.zap.alcatel-lucent.com> Yes. We're thinking of using TLS Heartbeats as cheaper KeepAlive option in idle connections. -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Michael Wojcik Sent: Monday, December 12, 2016 12:19 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] TLS Heartbeat > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Kyle Hamilton > Sent: Sunday, December 11, 2016 02:29 > To: openssl-users > Subject: Re: [openssl-users] TLS Heartbeat > > disable O_NAGLE on the socket? Do you mean enable TCP_NODELAY? That's the standard (POSIX / SUSv3) option that disables the Nagle algorithm. Using it is generally a sign of poorly-written software, created by someone who couldn't take the time to learn how TCP works. But then given the OP's description of the original problem, disabling the Nagle algorithm is likely not the most egregious design decision here. I'll echo Rich's sentiment: If you're using TLS heartbeat, You're Doing It Wrong. Also, note that Nagle / Delayed ACK interaction should only delay transmission for up to 200ms. The OP didn't provide any actual useful information about what the "problem" is, so we don't know whether the heartbeats would have been transmitted after 200ms. If they're not being transmitted for some other reason (e.g. receive window advertised as closed), then disabling Nagle won't make any difference. Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From sairanga at cisco.com Mon Dec 12 09:37:43 2016 From: sairanga at cisco.com (Sairam Rangaswamy -X (sairanga - ARICENT TECHNOLOGIES MAURIITIUS LIMITED at Cisco)) Date: Mon, 12 Dec 2016 09:37:43 +0000 Subject: [openssl-users] convert from PEM to DER format or vice versa Message-ID: <6539900d3d2c4ec1be12c6762f3de7b2@XCH-RTP-012.cisco.com> As I understand, the X509 certificates from CA or self-signed can be created in either PEM or DER format. Is there a way to programmatically convert the PEM format file to DER or DER to PEM? Is there a single API or set of APIs available from openssl libraries? Regards, R. Sairam Sairam Rangaswamy Architect sairanga at cisco.com | Mobile +919880302240 | Office +918041068409 [cid:image002.jpg at 01D25489.7A99ACB0] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 3608 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 138 bytes Desc: image003.png URL: From youca04 at gmail.com Mon Dec 12 10:56:29 2016 From: youca04 at gmail.com (Carl Young) Date: Mon, 12 Dec 2016 10:56:29 +0000 Subject: [openssl-users] convert from PEM to DER format or vice versa In-Reply-To: <6539900d3d2c4ec1be12c6762f3de7b2@XCH-RTP-012.cisco.com> References: <6539900d3d2c4ec1be12c6762f3de7b2@XCH-RTP-012.cisco.com> Message-ID: Please download the source code and refer to apps/x509.c - this handles the conversion command, such as: openssl x509 -in xxx.pem -inform pem -out xxx.cer -outform DER the function you will look for is i2d_X509_bio On 12 December 2016 at 09:37, Sairam Rangaswamy -X (sairanga - ARICENT TECHNOLOGIES MAURIITIUS LIMITED at Cisco) wrote: > As I understand, the X509 certificates from CA or self-signed can be > created in either > > PEM or DER format. > > > > Is there a way to programmatically convert the PEM format file to DER or > DER to PEM? > > Is there a single API or set of APIs available from openssl libraries? > > > > Regards, > > R. Sairam > > *Sairam Rangaswamy* > > Architect > > sairanga at cisco.com | Mobile +919880302240 <+91%2098803%2002240> | Office > +918041068409 <+91%2080%204106%208409> > > > > > > > > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 138 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 3608 bytes Desc: not available URL: From rsalz at akamai.com Mon Dec 12 12:48:24 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 12 Dec 2016 12:48:24 +0000 Subject: [openssl-users] TLS Heartbeat In-Reply-To: <9D777EB87E64DD4394E1B0A02E55122EB3BC37EC@SG70XWXCHMBA04.zap.alcatel-lucent.com> References: <9D777EB87E64DD4394E1B0A02E55122EB3BC31E0@SG70XWXCHMBA04.zap.alcatel-lucent.com> <280a21dbff7c4e27b2bfaf85c7385c12@usma1ex-dag1mb1.msg.corp.akamai.com> <9D777EB87E64DD4394E1B0A02E55122EB3BC37EC@SG70XWXCHMBA04.zap.alcatel-lucent.com> Message-ID: <364fbe1474c74a31857bfb3f5f05fc6a@usma1ex-dag1mb1.msg.corp.akamai.com> > Yes. We're thinking of using TLS Heartbeats as cheaper KeepAlive option in > idle connections. Use TCP keepalive if really needed. That keeps your application level free to reap truly idle connections if/when it wants to. From jb-openssl at wisemo.com Mon Dec 12 15:28:17 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 12 Dec 2016 16:28:17 +0100 Subject: [openssl-users] Is it possible to change the name of export functions from the static library ? In-Reply-To: References: Message-ID: On 11/12/2016 17:34, ddx wrote: > I complied an OpenSSL static library for my windows application , > which utilize another ssl static library : BoringSSL too. As expected > , the linker complains about LNK2005 errors . > > > Is it possible to rename the export functions in the libssl.lib and > libcrypto.lib , as well as the OpenSSL public headers ? > I would like to add a prefix to them so that both libraries ( Openssl > and Boringssl ) can be static linked into my windows binary. > > You really should ask Google, since their BoringSSL is a modified copy of OpenSSL, they should be providing a way to prefix all identifiers with some Google prefix. But why do you need both these derivatives of SSLeay?, are you sure one of them won't provide all the needed functions? Anyway, your best bet if your really need this is to do a global search/replace in your copy of the source code before building the library. This can be scripted with perl, which is needed during the regular build process anyway (unlike e.g. Python). 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 jb-openssl at wisemo.com Mon Dec 12 15:31:37 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 12 Dec 2016 16:31:37 +0100 Subject: [openssl-users] convert from PEM to DER format or vice versa In-Reply-To: <6539900d3d2c4ec1be12c6762f3de7b2@XCH-RTP-012.cisco.com> References: <6539900d3d2c4ec1be12c6762f3de7b2@XCH-RTP-012.cisco.com> Message-ID: <0fca6a35-8320-53ae-c55b-33e88d6ed8b6@wisemo.com> On 12/12/2016 10:37, Sairam Rangaswamy -X (sairanga - ARICENT TECHNOLOGIES MAURIITIUS LIMITED at Cisco) wrote: > > As I understand, the X509 certificates from CA or self-signed can be > created in either > > PEM or DER format. > > Is there a way to programmatically convert the PEM format file to DER > or DER to PEM? > > Is there a single API or set of APIs available from openssl libraries? > > It's simple Base64 conversion. The PEM file is the DER file Base64 encoded and decorated with 4 fixed lines that mark it as a certificate (two blank lines and two lines with a lot of dashes). No need to use the i2d_X509/d2i_X509 functions that convert to and from an internal OpenSSL data structure 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 silvioprog at gmail.com Mon Dec 12 17:46:12 2016 From: silvioprog at gmail.com (silvioprog) Date: Mon, 12 Dec 2016 14:46:12 -0300 Subject: [openssl-users] Doubt about OpenSSL library initialization in an HTTP client application In-Reply-To: References: Message-ID: Finally I think I solved this problem! :-) This is the patch I'm going to send to the `ssl_openssl_lib` authors: http://pastebin.com/VgSpnwxB . In short, I just removed the RAND_screen() call, generated a random buffer using RAND_bytes() (based on https://wiki.openssl.org/index.php/Random_Numbers#Software) seeding via RAND_add(). Thanks a lot for the help, dudes! :-) On Sun, Dec 4, 2016 at 12:01 AM, silvioprog wrote: > Thanks for sharing the links, I'm going to check them. > > The original code call RAND_screen() only once in the app initialization, > so can I replace it by RAND_add()? (I'm newbie on SSL) > > I've noticed the application is just a HTTP client consuming some web > services via HTTPS. It doesn't call explicitly any OpenSSL random function, > so I think it uses the default OpenSSL configurations. > > On Sat, Dec 3, 2016 at 3:42 PM, Jeffrey Walton wrote: > [...] > >> Also see https://wiki.openssl.org/index.php/Library_Initialization and >> https://wiki.openssl.org/index.php/Random_Numbers#Windows_Issues. >> >> The short of it is, you should stop relying on auto-initialization of >> the RNG, and seed it yourself with a call to `RAND_add`. >> >> Jeff > > -- Silvio Cl?cio -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvioprog at gmail.com Mon Dec 12 17:48:18 2016 From: silvioprog at gmail.com (silvioprog) Date: Mon, 12 Dec 2016 14:48:18 -0300 Subject: [openssl-users] Doubt about OpenSSL library initialization in an HTTP client application In-Reply-To: References: Message-ID: Oops, I meant: "In short, I just replaced the RAND_screen() call to the RAND_poll(), generated a random buffer using RAND_bytes() (based on https://wiki.openssl.org/index.php/Random_Numbers#Software) seeding it via RAND_add()" On Mon, Dec 12, 2016 at 2:46 PM, silvioprog wrote: [...] > In short, I just removed the RAND_screen() call, generated a random buffer > using RAND_bytes() (based on https://wiki.openssl.org/ > index.php/Random_Numbers#Software) seeding via RAND_add(). > -- Silvio Cl?cio -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Dec 12 18:04:17 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 12 Dec 2016 18:04:17 +0000 Subject: [openssl-users] Doubt about OpenSSL library initialization in an HTTP client application In-Reply-To: References: Message-ID: > "In short, I just replaced the RAND_screen() call to the RAND_poll(), generated a random buffer using RAND_bytes()?(based on?https://wiki.openssl.org/index.php/Random_Numbers#Software) seeding it via RAND_add()" You fed RAND_bytes output back into RAND_add? That's silly. From silvioprog at gmail.com Mon Dec 12 18:24:23 2016 From: silvioprog at gmail.com (silvioprog) Date: Mon, 12 Dec 2016 15:24:23 -0300 Subject: [openssl-users] Doubt about OpenSSL library initialization in an HTTP client application In-Reply-To: References: Message-ID: On Mon, Dec 12, 2016 at 3:04 PM, Salz, Rich wrote: > > "In short, I just replaced the RAND_screen() call to the RAND_poll(), > generated a random buffer using RAND_bytes() (based on > https://wiki.openssl.org/index.php/Random_Numbers#Software) seeding it > via RAND_add()" > > You fed RAND_bytes output back into RAND_add? That's silly. Yes. Is it unnecessary? My steps are: ... - RAND_scree() + RAND_poll() + RAND_bytes(buf, 128); + RAND_add(buf, length(buf), length(buf)); ... (I noticed I sent wrong patch, the correct one declare the RAND_bytes func ^^' ) -- Silvio Cl?cio -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Dec 12 18:28:04 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 12 Dec 2016 18:28:04 +0000 Subject: [openssl-users] Doubt about OpenSSL library initialization in an HTTP client application In-Reply-To: References: Message-ID: > > You fed RAND_bytes output back into RAND_add?? That's silly. > Yes. Is it unnecessary? My steps are: It is a bad idea. It is pointless. Don't do it. From silvioprog at gmail.com Mon Dec 12 18:33:34 2016 From: silvioprog at gmail.com (silvioprog) Date: Mon, 12 Dec 2016 15:33:34 -0300 Subject: [openssl-users] Doubt about OpenSSL library initialization in an HTTP client application In-Reply-To: References: Message-ID: On Mon, Dec 12, 2016 at 3:28 PM, Salz, Rich wrote: > > > You fed RAND_bytes output back into RAND_add? That's silly. > > Yes. Is it unnecessary? My steps are: > > It is a bad idea. It is pointless. Don't do it. So what is the correct way, 1 or 2? 1) RAND_poll() /* RAND_bytes is unnecessary */ /* RAND_add is unnecessary */ 2) RAND_poll() RAND_bytes(buf, 128); /* RAND_add is unnecessary */ :-S -- Silvio Cl?cio -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvioprog at gmail.com Mon Dec 12 18:44:19 2016 From: silvioprog at gmail.com (silvioprog) Date: Mon, 12 Dec 2016 15:44:19 -0300 Subject: [openssl-users] Doubt about OpenSSL library initialization in an HTTP client application In-Reply-To: References: Message-ID: On Mon, Dec 12, 2016 at 3:33 PM, silvioprog wrote: [...] > So what is the correct way, 1 or 2? > *"which is ..." -- Silvio Cl?cio -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Dec 12 18:48:01 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 12 Dec 2016 18:48:01 +0000 Subject: [openssl-users] Doubt about OpenSSL library initialization in an HTTP client application In-Reply-To: References: Message-ID: <95acbf4b3217451aa680488164b9919c@usma1ex-dag1mb1.msg.corp.akamai.com> Seed the RNG, via RAND_poll. When or if you need random bytes, call RAND_bytes. If you just need crypto keys, call the appropriate keygen API. Done. -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Mon Dec 12 18:53:25 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 12 Dec 2016 13:53:25 -0500 Subject: [openssl-users] Doubt about OpenSSL library initialization in an HTTP client application In-Reply-To: References: Message-ID: > So what is the correct way, 1 or 2? > > 1) > > RAND_poll() > /* RAND_bytes is unnecessary */ > /* RAND_add is unnecessary */ > > 2) > > RAND_poll() > RAND_bytes(buf, 128); > /* RAND_add is unnecessary */ On Windows, you call CryptGenRandom to obtain your seed for the OpenSSL PRNG. On Linux, you use one of the random devices, like /dev/srandom, /dev/random, or /dev/urandom. Windows Phone and Windows Store apps add a twist, like requiring calls to BCryptGenRandom. There's no way to wrote portable code when you factor in Windows Phone and Windows Store. It will be a #define mess. Jeff From silvioprog at gmail.com Mon Dec 12 19:01:00 2016 From: silvioprog at gmail.com (silvioprog) Date: Mon, 12 Dec 2016 16:01:00 -0300 Subject: [openssl-users] Doubt about OpenSSL library initialization in an HTTP client application In-Reply-To: References: Message-ID: On Mon, Dec 12, 2016 at 3:53 PM, Jeffrey Walton wrote: > > So what is the correct way, 1 or 2? > > > > 1) > > > > RAND_poll() > > /* RAND_bytes is unnecessary */ > > /* RAND_add is unnecessary */ > > > > 2) > > > > RAND_poll() > > RAND_bytes(buf, 128); > > /* RAND_add is unnecessary */ > > On Windows, you call CryptGenRandom to obtain your seed for the > OpenSSL PRNG. On Linux, you use one of the random devices, like > /dev/srandom, /dev/random, or /dev/urandom. > > Windows Phone and Windows Store apps add a twist, like requiring calls > to BCryptGenRandom. There's no way to wrote portable code when you > factor in Windows Phone and Windows Store. It will be a #define mess. > > Jeff Perfect! So I just need to call RAND_poll(), because it seems already choosing that funcs above. :-) https://github.com/openssl/openssl/blob/master/crypto/rand/rand_win.c#L49 https://github.com/openssl/openssl/blob/master/crypto/rand/rand_unix.c#L161 Thanks a lot dude! -- Silvio Cl?cio -------------- next part -------------- An HTML attachment was scrubbed... URL: From liugev6 at gmail.com Mon Dec 12 19:29:55 2016 From: liugev6 at gmail.com (gev6 liu) Date: Tue, 13 Dec 2016 03:29:55 +0800 Subject: [openssl-users] openssl-users Digest, Vol 25, Issue 8 In-Reply-To: References: Message-ID: text / plain?;???=?utf-8? liuge 2016-12-13 2:45 GMT+08:00 : > Send openssl-users mailing list submissions to > openssl-users at openssl.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mta.openssl.org/mailman/listinfo/openssl-users > or, via email, send a message with subject or body 'help' to > openssl-users-request at openssl.org > > You can reach the person managing the list at > openssl-users-owner at openssl.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openssl-users digest..." > > > Today's Topics: > > 1. Re: Doubt about OpenSSL library initialization in an HTTP > client application (silvioprog) > 2. Re: Doubt about OpenSSL library initialization in an HTTP > client application (Salz, Rich) > 3. Re: Doubt about OpenSSL library initialization in an HTTP > client application (silvioprog) > 4. Re: Doubt about OpenSSL library initialization in an HTTP > client application (Salz, Rich) > 5. Re: Doubt about OpenSSL library initialization in an HTTP > client application (silvioprog) > 6. Re: Doubt about OpenSSL library initialization in an HTTP > client application (silvioprog) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 12 Dec 2016 14:48:18 -0300 > From: silvioprog > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Doubt about OpenSSL library > initialization in an HTTP client application > Message-ID: > gmail.com> > Content-Type: text/plain; charset="utf-8" > > Oops, > > I meant: > > "In short, I just replaced the RAND_screen() call to the RAND_poll(), > generated a random buffer using RAND_bytes() (based on > https://wiki.openssl.org/index.php/Random_Numbers#Software) seeding it via > RAND_add()" > > On Mon, Dec 12, 2016 at 2:46 PM, silvioprog wrote: > [...] > > > In short, I just removed the RAND_screen() call, generated a random > buffer > > using RAND_bytes() (based on https://wiki.openssl.org/ > > index.php/Random_Numbers#Software) seeding via RAND_add(). > > > > -- > Silvio Cl?cio > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20161212/dd45a901/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Mon, 12 Dec 2016 18:04:17 +0000 > From: "Salz, Rich" > To: "openssl-users at openssl.org" > Subject: Re: [openssl-users] Doubt about OpenSSL library > initialization in an HTTP client application > Message-ID: > akamai.com> > Content-Type: text/plain; charset="utf-8" > > > "In short, I just replaced the RAND_screen() call to the RAND_poll(), > generated a random buffer using RAND_bytes()?(based on? > https://wiki.openssl.org/index.php/Random_Numbers#Software) seeding it > via RAND_add()" > > You fed RAND_bytes output back into RAND_add? That's silly. > > ------------------------------ > > Message: 3 > Date: Mon, 12 Dec 2016 15:24:23 -0300 > From: silvioprog > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Doubt about OpenSSL library > initialization in an HTTP client application > Message-ID: > gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Mon, Dec 12, 2016 at 3:04 PM, Salz, Rich wrote: > > > > "In short, I just replaced the RAND_screen() call to the RAND_poll(), > > generated a random buffer using RAND_bytes() (based on > > https://wiki.openssl.org/index.php/Random_Numbers#Software) seeding it > > via RAND_add()" > > > > You fed RAND_bytes output back into RAND_add? That's silly. > > > Yes. Is it unnecessary? My steps are: > > ... > - RAND_scree() > + RAND_poll() > + RAND_bytes(buf, 128); > + RAND_add(buf, length(buf), length(buf)); > ... > > (I noticed I sent wrong patch, the correct one declare the RAND_bytes func > ^^' ) > > -- > Silvio Cl?cio > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20161212/2c812462/attachment-0001.html> > > ------------------------------ > > Message: 4 > Date: Mon, 12 Dec 2016 18:28:04 +0000 > From: "Salz, Rich" > To: "openssl-users at openssl.org" > Subject: Re: [openssl-users] Doubt about OpenSSL library > initialization in an HTTP client application > Message-ID: > akamai.com> > Content-Type: text/plain; charset="utf-8" > > > > You fed RAND_bytes output back into RAND_add?? That's silly. > > > Yes. Is it unnecessary? My steps are: > > It is a bad idea. It is pointless. Don't do it. > > > > ------------------------------ > > Message: 5 > Date: Mon, 12 Dec 2016 15:33:34 -0300 > From: silvioprog > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Doubt about OpenSSL library > initialization in an HTTP client application > Message-ID: > mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Mon, Dec 12, 2016 at 3:28 PM, Salz, Rich wrote: > > > > > You fed RAND_bytes output back into RAND_add? That's silly. > > > Yes. Is it unnecessary? My steps are: > > > > It is a bad idea. It is pointless. Don't do it. > > > So what is the correct way, 1 or 2? > > 1) > > RAND_poll() > /* RAND_bytes is unnecessary */ > /* RAND_add is unnecessary */ > > 2) > > RAND_poll() > RAND_bytes(buf, 128); > /* RAND_add is unnecessary */ > > :-S > > -- > Silvio Cl?cio > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20161212/2a763b1a/attachment-0001.html> > > ------------------------------ > > Message: 6 > Date: Mon, 12 Dec 2016 15:44:19 -0300 > From: silvioprog > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Doubt about OpenSSL library > initialization in an HTTP client application > Message-ID: > gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Mon, Dec 12, 2016 at 3:33 PM, silvioprog wrote: > [...] > > > So what is the correct way, 1 or 2? > > > > *"which is ..." > > -- > Silvio Cl?cio > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20161212/a77612b1/attachment.html> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > openssl-users mailing list > openssl-users at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-users > > > ------------------------------ > > End of openssl-users Digest, Vol 25, Issue 8 > ******************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From norm.green at gemtalksystems.com Tue Dec 13 21:09:19 2016 From: norm.green at gemtalksystems.com (Norm Green) Date: Tue, 13 Dec 2016 13:09:19 -0800 Subject: [openssl-users] AECDH problem: works in 1.0.2, fails in 1.1 Message-ID: I have a simple C program that works in 1.0.2 but fails with the same code in 1.1. Here's the psuedo code for the client and server: Server: const SSL_METHOD *meth = TLSv1_2_server_method(); SSL_CTX *ctx = SSL_CTX_new(meth); SSL_CTX_set_ecdh_auto(ctx, 1); SSL_CTX_set_mode(ctx, SSL_MODE_AUTO_RETRY); SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, NULL); SSL_CTX_set_cipher_list(ctx, "AECDH"); SSL_CTX_set_options(ctx, SSL_OP_SINGLE_DH_USE); SSL *ssl = SSL_new(ctx); SSL_accept(ssl); Client: const SSL_METHOD *meth = TLSv1_2_client_method(); SSL_CTX *ctx = SSL_CTX_new(meth); SSL_CTX_set_mode(ctx, SSL_MODE_AUTO_RETRY); SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, NULL); SSL_CTX_set_cipher_list(ctx, "AECDH"); SSL *ssl = SSL_new(ctx); SSL_connect(ssl); In 1.1, the client gets this error from SSL_connect() SSL_connect returned SSL_ERROR_SSL Details: error:141640B5:SSL routines:tls_construct_client_hello:no ciphers available ssl/statem/statem_clnt.c at 815 What do I need to do to make AECDH work in 1.1 ? Norm Green From matt at openssl.org Tue Dec 13 23:48:52 2016 From: matt at openssl.org (Matt Caswell) Date: Tue, 13 Dec 2016 23:48:52 +0000 Subject: [openssl-users] AECDH problem: works in 1.0.2, fails in 1.1 In-Reply-To: References: Message-ID: <37b323b4-7ecb-8e4c-3e39-0d10fbd3d6c5@openssl.org> On 13/12/16 21:09, Norm Green wrote: > I have a simple C program that works in 1.0.2 but fails with the same > code in 1.1. > Here's the psuedo code for the client and server: > > Server: > const SSL_METHOD *meth = TLSv1_2_server_method(); > SSL_CTX *ctx = SSL_CTX_new(meth); > SSL_CTX_set_ecdh_auto(ctx, 1); > SSL_CTX_set_mode(ctx, SSL_MODE_AUTO_RETRY); > SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, NULL); > SSL_CTX_set_cipher_list(ctx, "AECDH"); > SSL_CTX_set_options(ctx, SSL_OP_SINGLE_DH_USE); > SSL *ssl = SSL_new(ctx); > SSL_accept(ssl); > > > Client: > const SSL_METHOD *meth = TLSv1_2_client_method(); > SSL_CTX *ctx = SSL_CTX_new(meth); > SSL_CTX_set_mode(ctx, SSL_MODE_AUTO_RETRY); > SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, NULL); > SSL_CTX_set_cipher_list(ctx, "AECDH"); > SSL *ssl = SSL_new(ctx); > SSL_connect(ssl); > > > In 1.1, the client gets this error from SSL_connect() > > SSL_connect returned SSL_ERROR_SSL > Details: error:141640B5:SSL routines:tls_construct_client_hello:no > ciphers available > ssl/statem/statem_clnt.c at 815 > > > What do I need to do to make AECDH work in 1.1 ? AECDH is in security level 0 but the default security level is 1. Read about security levels here: https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_security_level.html You need to set the security level to 0 either through a call to SSL_CTX_set_security_level() or similar; or via the cipherstring using "AECDH:@SECLEVEL=0". See: https://www.openssl.org/docs/manmaster/man1/ciphers.html Matt From linuxkid.zeuz at gmail.com Wed Dec 14 01:47:18 2016 From: linuxkid.zeuz at gmail.com (Anibal F. Martinez Cortina) Date: Tue, 13 Dec 2016 22:47:18 -0300 Subject: [openssl-users] Signing an XML file Message-ID: Hello everyone, I'm trying to sign an XML file, need to do so with pkcs#7. Is there some equivalent to PHP's openssl_sign_pkcs7 function for C/C++ users? In particular, I'm using Qt as framework, but have also got OpenSSL libs and headers installed. The target platform is Microsoft Windows (x32) Kind regards, Anibal.- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Dec 14 01:54:57 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 14 Dec 2016 01:54:57 +0000 Subject: [openssl-users] Signing an XML file In-Reply-To: References: Message-ID: <523c0ba6452e4e46bd3ee0984189feaa@usma1ex-dag1mb1.msg.corp.akamai.com> > Is there some equivalent to PHP's openssl_sign_pkcs7 function for C/C++ users? Look at the apps/pkcs7.c file as a starting point. Get the command line doing what you want, and then work through the code to pull out only the bits you need. From linuxkid.zeuz at gmail.com Wed Dec 14 04:10:45 2016 From: linuxkid.zeuz at gmail.com (Anibal F. Martinez Cortina) Date: Wed, 14 Dec 2016 01:10:45 -0300 Subject: [openssl-users] Signing an XML file In-Reply-To: <523c0ba6452e4e46bd3ee0984189feaa@usma1ex-dag1mb1.msg.corp.akamai.com> References: <523c0ba6452e4e46bd3ee0984189feaa@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: 2016-12-13 22:54 GMT-03:00 Salz, Rich : > > Is there some equivalent to PHP's openssl_sign_pkcs7 function for C/C++ > users? > > Look at the apps/pkcs7.c file as a starting point. Get the command line > doing what you want, and then work through the code to pull out only the > bits you need. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > Got it, after some more reading, I've managed to pull: A Valid X509 structure with the PEM file. A Valid EVP_PKEY structure with the KEY file. Created a BIO with BIO_new(BIO_s_mem()) and used BIO_read_filename with it. Now I get to the part where I need to call PKCS7_sign() right? If so, I'm missing something, because: PKCS7_sign(cert,key,NULL,fileBIO,NULL) produces NULL as a result. Any hints? -------------- next part -------------- An HTML attachment was scrubbed... URL: From yangjun9772 at gmail.com Wed Dec 14 07:30:26 2016 From: yangjun9772 at gmail.com (=?UTF-8?B?5p2o5L+K?=) Date: Wed, 14 Dec 2016 15:30:26 +0800 Subject: [openssl-users] It reported verify error:num=20:unable to get local issuer certificate in my embedded linux device, when I used the openssl command Message-ID: Hi openssl-er, I'm newbie in the openssl. Recently, I ported the openssl to my embedded linux device and ran the openssl command. But there was an error occured. I had done google search a lot, but I didn't find the answer. My issue is strange, my test steps like below: 1. copy the openssl, libs, cacert.pem to the embedded linux platform. 2. run the command: /tmp #:./openssl s_client -connect curl.haxx.se:443 -CAfile /tmp/cacert.pem 3. the error log is ------log ---------------- CONNECTED(00000003) depth=0 CN = anja.haxx.se verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = anja.haxx.se verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/CN=anja.haxx.se i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3 --- Server certificate ---------------------------------- 4. my openssl version -d and version is /tmp # ./openssl version OpenSSL 1.1.0c 10 Nov 2016 /tmp # ./openssl version -d OPENSSLDIR: "/home/georgeyang/workspace/speech_code/openssl/openssl/final" 5. In my PC, I found this command worked well. It could return the ok value. Although the openssl version is 1.0.1f. So I think my cacert.pem is right. 6. I also used other command like: /tmp # ./openssl s_client -connect curl.haxx.se:443 -CApath /tmp/cacert.pem /tmp # ./openssl s_client -CApath /home/georgeyang/workspace/speech_code/openssl/openssl/final/ -connect curl.haxx.se:443 /tmp # ./openssl s_client -connect curl.haxx.se:443 -servername curl.haxx.se -key /etc/ssl/private/ssl-cert-snakeoil.key -CAfile /etc/ssl/certs/cacert.pem But they are all NG. In google, they all said -CAfile or -CApath could help, But it doesn't work for me. >"< Please help Thx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Dec 14 07:51:14 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 14 Dec 2016 08:51:14 +0100 Subject: [openssl-users] It reported verify error:num=20:unable to get local issuer certificate in my embedded linux device, when I used the openssl command In-Reply-To: References: Message-ID: On 14/12/2016 08:30, ?? wrote: > Hi openssl-er, > > I'm newbie in the openssl. > Recently, I ported the openssl to my embedded linux device and ran the > openssl command. > But there was an error occured. > I had done google search a lot, but I didn't find the answer. > My issue is strange, my test steps like below: > 1. copy the openssl, libs, cacert.pem to the embedded linux platform. > Does cacert.pem contain the CA certificate that issued the certificate for https://curl.haxx.se ? In general, the argument to -CAfile should be the concatenation of the PEM format CA root certificates that your embedded platform wants to trust as issuing trustworthy certificates for servers you will connect to. Alternatively, the argument to -CApath should point to a directory (traditionally named "/etc/ssl/certs") containing: One PEM file with each such trusted CA certificate The symlinks generated by the c_rehash script (these map simple checksums of the certificate names to the file names containing CA certificates with names with those checksums, this reduces memory consumption but increases disk read operations). If your embedded file system does not support symlinks, you can instead rename the PEM files to the names of the symlinks that c_rehash generates on a more full-blown development computer. > 2. run the command: > /tmp #:./openssl s_client -connect curl.haxx.se:443 > -CAfile /tmp/cacert.pem > > 3. the error log is > ------log ---------------- > CONNECTED(00000003) > depth=0 CN = anja.haxx.se > verify error:num=20:unable to get local issuer certificate > verify return:1 > depth=0 CN = anja.haxx.se > verify error:num=21:unable to verify the first certificate > verify return:1 > --- > Certificate chain > 0 s:/CN=anja.haxx.se > i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 > 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 > i:/O=Digital Signature Trust Co./CN=DST Root CA X3 > --- > Server certificate > ---------------------------------- > > 4. my openssl version -d and version is > /tmp # ./openssl version > OpenSSL 1.1.0c 10 Nov 2016 > /tmp # ./openssl version -d > OPENSSLDIR: "/home/georgeyang/workspace/speech_code/openssl/openssl/final" > > 5. In my PC, I found this command worked well. It could return the ok > value. > Although the openssl version is 1.0.1f. > So I think my cacert.pem is right. > > 6. I also used other command like: > /tmp # ./openssl s_client -connect curl.haxx.se:443 > -CApath /tmp/cacert.pem > /tmp # ./openssl s_client -CApath > /home/georgeyang/workspace/speech_code/openssl/openssl/final/ -connect > curl.haxx.se:443 > /tmp # ./openssl s_client -connect curl.haxx.se:443 > -servername curl.haxx.se > -key /etc/ssl/private/ssl-cert-snakeoil.key > -CAfile /etc/ssl/certs/cacert.pem > But they are all NG. > > In google, they all said -CAfile or -CApath could help, But it doesn't > work for me. >"< > Please help > 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 ajaygargnsit at gmail.com Wed Dec 14 08:09:27 2016 From: ajaygargnsit at gmail.com (Ajay Garg) Date: Wed, 14 Dec 2016 13:39:27 +0530 Subject: [openssl-users] Is there a way to get the numeric-value for a openssl-cipher-suite Message-ID: Hi All. I am using the following script at myu laptop, to test for the available cipher-suites : #################################################### #!/usr/bin/env bash # OpenSSL requires the port number. SERVER=server.ip.com:12345 DELAY=1 ciphers=$(openssl ciphers 'ALL:eNULL' | sed -e 's/:/ /g') echo Obtaining cipher list from $(openssl version). for cipher in ${ciphers[@]} do # echo -n Testing $cipher... result=$(echo -n | openssl s_client -cipher "$cipher" -connect $SERVER 2>&1) if [[ "$result" =~ ":error:" ]] ; then true else if [[ "$result" =~ "Cipher is ${cipher}" || "$result" =~ "Cipher :" ]] ; then echo ${cipher} else true fi fi sleep $DELAY done #################################################### Above script works, and I am able to get the supported-ciphers-listing. But all those ciphers are in stringified-form. Is there a way, so that I can get the supported-ciphers in their corrsponding numeric-values form? I ask this, because a particular device supports only a restricted set of ciphers, and I am not able to properly match the cipher-suites using their stringified-forms. Looking forward to some help from the experts :) Thanks and Regards, Ajay -------------- next part -------------- An HTML attachment was scrubbed... URL: From yangjun9772 at gmail.com Wed Dec 14 08:42:45 2016 From: yangjun9772 at gmail.com (=?UTF-8?B?5p2o5L+K?=) Date: Wed, 14 Dec 2016 16:42:45 +0800 Subject: [openssl-users] It reported verify error:num=20:unable to get local issuer certificate in my embedded linux device, when I used the openssl command In-Reply-To: References: Message-ID: Hi openssl-er, > Does cacert.pem contain the CA certificate that issued the certificate for > https://curl.haxx.se ? I think the cacert.pem is right. Because, I can get the ok result in my PC by this command: ? > If your embedded file system does not support symlinks, you can instead > rename the PEM files to the names of the symlinks that c_rehash generates > on a more full-blown development computer. I don't know if my way is right. I do it like this: 1. In my device, I can't use the c_rehash. It said no perl. I input the command like this: /tmp # ./openssl x509 -hash -fingerprint -noout -in /home/georgeyang/workspace/s peech_code/openssl/openssl/final/certs/cacert-2016-11-02.pem 5ad8a5d6 SHA1 Fingerprint=B1:BC:96:8B:D4:F4:9D:62:2A:A8:9A:81:F2:15:01:52:A4:1D:82:9C 2. input command: /etc/ssl/certs # ln -s /home/georgeyang/workspace/speech_code/openssl/openssl/final/certs/cacert-2016-11-02.pem 5ad8a5d6.0 /etc/ssl/certs # ls -l total 511 lrwxrwxrwx 1 root root 88 Jan 1 06:53 5ad8a5d6.0 -> /home/georgeyang/workspace/speech_code/openssl/openssl/final/certs/cacert-2016-11-02.pem Is this right? 3. the result is still NG /tmp # ./openssl s_client -connect curl.haxx.se:443 -CApath /etc/ssl/certs/ CONNECTED(00000003) depth=0 CN = anja.haxx.se verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = anja.haxx.se verify error:num=21:unable to verify the first certificate verify return:1 --- 4. NG again CONNECTED(00000003) depth=0 CN = anja.haxx.se verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = anja.haxx.se verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/CN=anja.haxx.se i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3 --- Server certificate -----BEGIN CERTIFICATE----- --- -----END CERTIFICATE----- subject=/CN=anja.haxx.se issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 --- No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 3143 bytes and written 302 bytes Verification error: unable to verify the first certificate --- New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 Session-ID: 3EA8329E6101B72FDA48B82E57049D637925CBC73064598B5B418270FFA5907C Session-ID-ctx: Master-Key: 61172C067AE0758A1BE71C7577B6A6E8EFD896516F602BCA30E4E369B61A4093702406403CF41FF3B9CFC2E9E76BE611 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: --- Start Time: 24915 Timeout : 7200 (sec) Verify return code: 21 (unable to verify the first certificate) Extended master secret: no --- closed Thank you :-( -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1481704581(1).png Type: image/png Size: 29730 bytes Desc: not available URL: From matt at openssl.org Wed Dec 14 09:26:38 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 14 Dec 2016 09:26:38 +0000 Subject: [openssl-users] Is there a way to get the numeric-value for a openssl-cipher-suite In-Reply-To: References: Message-ID: <5f8170a8-a12e-0d4c-5142-f5c9c0889a9b@openssl.org> On 14/12/16 08:09, Ajay Garg wrote: > Hi All. > > I am using the following script at myu laptop, to test for the available > cipher-suites : > > #################################################### > #!/usr/bin/env bash > > # OpenSSL requires the port number. > SERVER=server.ip.com:12345 > DELAY=1 > ciphers=$(openssl ciphers 'ALL:eNULL' | sed -e 's/:/ /g') > > echo Obtaining cipher list from $(openssl version). > > for cipher in ${ciphers[@]} > do > # echo -n Testing $cipher... > result=$(echo -n | openssl s_client -cipher "$cipher" -connect $SERVER 2>&1) > if [[ "$result" =~ ":error:" ]] ; then > true > else > if [[ "$result" =~ "Cipher is ${cipher}" || "$result" =~ "Cipher :" > ]] ; then > echo ${cipher} > else > true > fi > fi > sleep $DELAY > done > #################################################### > > > Above script works, and I am able to get the supported-ciphers-listing. > But all those ciphers are in stringified-form. > > > Is there a way, so that I can get the supported-ciphers in their > corrsponding numeric-values form? Try the -V option to the ciphers command. Matt From yangjun9772 at gmail.com Wed Dec 14 10:26:08 2016 From: yangjun9772 at gmail.com (=?UTF-8?B?5p2o5L+K?=) Date: Wed, 14 Dec 2016 18:26:08 +0800 Subject: [openssl-users] It reported verify error:num=20:unable to get local issuer certificate in my embedded linux device, when I used the openssl command In-Reply-To: References: Message-ID: Hi Jakob & openssl-er, 1. My cross compile command is : ----------- #export CROSSCOMP_DIR=/home/georgeyang/workspace/hisi/hi3516a_v100/Hi3516A_SDK_V1.0.6.0/osdrv/opensource/toolchain/arm-hisiv400-linux/arm-hisiv400-linux/bin #export INSTALL_DIR=/home/georgeyang/workspace/speech_code/openssl #./Configure -DOPENSSL_NO_HEARTBEATS linux-generic32 shared --prefix=$INSTALL_DIR --openssldir=$INSTALL_DIR/openssl/final --cross-compile-prefix=$CROSSCOMP_DIR/arm-hisiv400-linux-gnueabi- Make Make install 2. This is my openssl's details. ---------------------------------- /tmp # ./openssl version -a OpenSSL 1.1.0c 10 Nov 2016 built on: reproducible build, date unspecified platform: linux-generic32 compiler: /home/georgeyang/workspace/hisi/hi3516a_v100/Hi3516A_SDK_V1.0.6.0/osdrv/opensource/toolchain/arm-hisiv400-linux/arm-hisiv400-linux/bin/arm-hisiv400-linux-gnueabi-gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_NO_HEARTBEATS -DOPENSSLDIR="\"/home/georgeyang/workspace/speech_code/openssl/openssl/final\"" -DENGINESDIR="\"/home/georgeyang/workspace/speech_code/openssl/lib/engines-1.1\"" OPENSSLDIR: "/home/georgeyang/workspace/speech_code/openssl/openssl/final" ENGINESDIR: "/home/georgeyang/workspace/speech_code/openssl/lib/engines-1.1" /tmp # Is there something wrong in my parameters? -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Wed Dec 14 10:28:14 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 14 Dec 2016 10:28:14 +0000 Subject: [openssl-users] Signing an XML file In-Reply-To: <523c0ba6452e4e46bd3ee0984189feaa@usma1ex-dag1mb1.msg.corp.akamai.com> References: <523c0ba6452e4e46bd3ee0984189feaa@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20161214102814.GA16287@openssl.org> On Wed, Dec 14, 2016, Salz, Rich wrote: > > Is there some equivalent to PHP's openssl_sign_pkcs7 function for C/C++ users? > > Look at the apps/pkcs7.c file as a starting point. Get the command line doing what you want, and then work through the code to pull out only the bits you need. > Actually smime.c is the utility you want for PKCS#7. Alternatively cms.c if you want CMS (the successor to PKCS#7). Those though are general purpose utilities which do all sorts of things which most appications don't care about. There are some demos in demos/smime and demos/cms which are much simpler. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From jb-openssl at wisemo.com Wed Dec 14 10:32:34 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 14 Dec 2016 11:32:34 +0100 Subject: [openssl-users] It reported verify error:num=20:unable to get local issuer certificate in my embedded linux device, when I used the openssl command In-Reply-To: References: Message-ID: <5c27fc82-81d4-63fc-aa17-8aa1a0adebd6@wisemo.com> On 14/12/2016 09:42, ?? wrote: > Hi openssl-er, > > > Does cacert.pem contain the CA certificate that issued the certificate for > > https://curl.haxx.se ? > > I think the cacert.pem is right. Because, I can get the ok result in > my PC by this command: > > ? > > If your embedded file system does not support symlinks, you can instead > > rename the PEM files to the names of the symlinks that c_rehash generates > > on a more full-blown development computer. > Just to be sure (sometimes OpenSSL checks its default -CApath even if you specify a -CAfile) try this command on the development machine: openssl x509 -subject -noout -in cacert.pem Compare to the deepest value from the screenshot above. > I don't know if my way is right. I do it like this: > > > 1. In my device, I can't use the c_rehash. It said no perl. I input > the command like this: > /tmp # ./openssl x509 -hash -fingerprint -noout -in > /home/georgeyang/workspace/s > peech_code/openssl/openssl/final/certs/cacert-2016-11-02.pem > 5ad8a5d6 > SHA1 > Fingerprint=B1:BC:96:8B:D4:F4:9D:62:2A:A8:9A:81:F2:15:01:52:A4:1D:82:9C > > 2. input command: > /etc/ssl/certs # ln -s > /home/georgeyang/workspace/speech_code/openssl/openssl/final/certs/cacert-2016-11-02.pem > 5ad8a5d6.0 > /etc/ssl/certs # ls -l > total 511 > lrwxrwxrwx 1 root root 88 Jan 1 06:53 5ad8a5d6.0 -> > /home/georgeyang/workspace/speech_code/openssl/openssl/final/certs/cacert-2016-11-02.pem > > Is this right? > > 3. the result is still NG > /tmp # ./openssl s_client -connect curl.haxx.se:443 > -CApath /etc/ssl/certs/ > CONNECTED(00000003) > depth=0 CN = anja.haxx.se > verify error:num=20:unable to get local issuer certificate > verify return:1 > depth=0 CN = anja.haxx.se > verify error:num=21:unable to verify the first certificate > verify return:1 > --- > > 4. NG again > CONNECTED(00000003) > depth=0 CN = anja.haxx.se > verify error:num=20:unable to get local issuer certificate > verify return:1 > depth=0 CN = anja.haxx.se > verify error:num=21:unable to verify the first certificate > verify return:1 > --- > Certificate chain > 0 s:/CN=anja.haxx.se > i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 > 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 > i:/O=Digital Signature Trust Co./CN=DST Root CA X3 > --- > Server certificate > -----BEGIN CERTIFICATE----- > --- > -----END CERTIFICATE----- > subject=/CN=anja.haxx.se > issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 > --- > No client certificate CA names sent > Peer signing digest: SHA512 > Server Temp Key: ECDH, P-256, 256 bits > --- > SSL handshake has read 3143 bytes and written 302 bytes > Verification error: unable to verify the first certificate > --- > New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256 > Server public key is 2048 bit > Secure Renegotiation IS supported > Compression: NONE > Expansion: NONE > No ALPN negotiated > SSL-Session: > Protocol : TLSv1.2 > Cipher : ECDHE-RSA-AES128-GCM-SHA256 > Session-ID: > 3EA8329E6101B72FDA48B82E57049D637925CBC73064598B5B418270FFA5907C > Session-ID-ctx: > Master-Key: > 61172C067AE0758A1BE71C7577B6A6E8EFD896516F602BCA30E4E369B61A4093702406403CF41FF3B9CFC2E9E76BE611 > PSK identity: None > PSK identity hint: None > SRP username: None > TLS session ticket lifetime hint: 300 (seconds) > TLS session ticket: > --- > > Start Time: 24915 > Timeout : 7200 (sec) > Verify return code: 21 (unable to verify the first certificate) > Extended master secret: no > --- > closed > 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 yangjun9772 at gmail.com Wed Dec 14 12:52:39 2016 From: yangjun9772 at gmail.com (=?UTF-8?B?5p2o5L+K?=) Date: Wed, 14 Dec 2016 20:52:39 +0800 Subject: [openssl-users] It reported verify error:num=20:unable to get local issuer certificate in my embedded linux device, when I used the openssl command In-Reply-To: <5c27fc82-81d4-63fc-aa17-8aa1a0adebd6@wisemo.com> References: <5c27fc82-81d4-63fc-aa17-8aa1a0adebd6@wisemo.com> Message-ID: Hi Jakob & openssl-er, > Just to be sure (sometimes OpenSSL checks its default -CApath even > if you specify a -CAfile) try this command on the development machine: > openssl x509 -subject -noout -in cacert.pem > Compare to the deepest value from the screenshot above. I get the log from the embedded linux device and my PC. Sorry, I don't get the deference in the platform, but there is some deference between the platform and PC. Is this help? ------------------------------from embedded platform NG log-------------- /tmp # ./openssl x509 -subject -noout -in cacert-2016-11-02.pem subject=C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA /tmp # ./openssl s_client -connect curl.haxx.se:443 -CAfile ./cacert-2016-11-02.pem CONNECTED(00000003) depth=0 CN = anja.haxx.se /////////////////////////////////always depth=0//////////////////////////////////////// verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = anja.haxx.se verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/CN=anja.haxx.se i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3 --- Server certificate -----BEGIN CERTIFICATE----- ---- -----END CERTIFICATE----- subject=/CN=anja.haxx.se issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 --- No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 3143 bytes and written 302 bytes Verification error: unable to verify the first certificate --- New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 Session-ID: AB3322B63747715342DB68B4D18C27F98CF84D4A0E2711719E8B96FA5DA5C1FD Session-ID-ctx: Master-Key: 240CC5C33C7185E49C74076133DF385AB0282A3C68D6D6DC3CB74D0DB845E4242F61DA09A28B544CB5B1D39FA839E6AD PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: ..... Start Time: 39804 Timeout : 7200 (sec) Verify return code: 21 (unable to verify the first certificate) Extended master secret: no --- closed /tmp # ------------------------------from PC ok log-------------------------------------- georgeyang at georgeyang-virtual-machine:/mnt/hgfs/share/task/danale_task/3516a$ openssl x509 -subject -noout -in cacert-2016-11-02.pem subject= /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA georgeyang at georgeyang-virtual-machine:/mnt/hgfs/share/task/danale_task/3516a$ openssl s_client -connect curl.haxx.se:443 -CAfile ./cacert-2016-11-02.pem CONNECTED(00000003) depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 //////////////////////////////////////depth 0,1,2///////////////////////////////// verify return:1 depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 verify return:1 depth=0 CN = anja.haxx.se verify return:1 --- Certificate chain 0 s:/CN=anja.haxx.se i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3 --- Server certificate -----BEGIN CERTIFICATE----- ---- -----END CERTIFICATE----- subject=/CN=anja.haxx.se issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 --- No client certificate CA names sent --- SSL handshake has read 3148 bytes and written 443 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 Session-ID: 5640820B2C49B9B2E68563DFDFC7303BE01DE69E7EB4C6C833B4F7872CD173E5 Session-ID-ctx: Master-Key: 48783D2D0E03CE5EACB7AF2577E0E2AFE4F056B191BFB2641D08E602C54BF651B9C195DCFBD2AECC2092B035848B005B Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: --- Start Time: 1481718602 Timeout : 300 (sec) Verify return code: 0 (ok) --- closed georgeyang at georgeyang-virtual-machine :/mnt/hgfs/share/task/danale_task/3516a$ -------------------------------------------------------------------------------------------------------- thank you for your help. Thanks a lot. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Wed Dec 14 13:31:09 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 14 Dec 2016 13:31:09 +0000 Subject: [openssl-users] It reported verify error:num=20:unable to get local issuer certificate in my embedded linux device, when I used the openssl command In-Reply-To: References: <5c27fc82-81d4-63fc-aa17-8aa1a0adebd6@wisemo.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of ?? > Sent: Wednesday, December 14, 2016 07:53 > I get the log from the embedded linux device and my PC. > Sorry, I don't get the deference in the platform, but there is some deference between the platform and PC. (You want "difference" there, not "deference". Just another of English's many homonyms and orthographic peculiarities.) I just did a quick check, and it appears curl.haxx.se sends two certificates: the server certificate (signed by Let's Encrypt) and an intermediate (signed by Digital Signature Trust). On the PC, s_client shows a chain of three certificates, ending in the DST root. That means OpenSSL found that root certificate somewhere - it didn't get it from the server, and it's not the first certificate in cacert-2016-11-02.pem. So: either there's more than one certificate in cacert-2016-11-02.pem, or OpenSSL on the PC is searching its default CA certificate directory in addition to cacert-2016-11-02.pem. Since we don't know what's actually in cacert-2016-11-02.pem, we can't provide much further help. Note that if there are multiple certificates in cacert-2016-11-02.pem, you'll have to split them up into separate files and create the correct hash link for each one, if you want to use a certificate directory. Also, there's this from your previous note: > /tmp # ./openssl x509 -subject -noout -in cacert-2016-11-02.pem > subject=C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA Did you actually capture that, or did you retype it? Because it's not valid openssl x509 output. Note that it doesn't match what you reported from the PC: > subject= /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA Michael Wojcik Distinguished Engineer, Micro Focus From rsalz at akamai.com Wed Dec 14 14:21:38 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 14 Dec 2016 14:21:38 +0000 Subject: [openssl-users] Is there a way to get the numeric-value for a openssl-cipher-suite In-Reply-To: References: Message-ID: <9a5652ff7bb944a084b74b548a3a3809@usma1ex-dag1mb1.msg.corp.akamai.com> Does the -V flag not do what you want? From shinelight at shininglightpro.com Wed Dec 14 14:17:56 2016 From: shinelight at shininglightpro.com (Thomas J. Hruska) Date: Wed, 14 Dec 2016 07:17:56 -0700 Subject: [openssl-users] Signing an XML file In-Reply-To: <20161214102814.GA16287@openssl.org> References: <523c0ba6452e4e46bd3ee0984189feaa@usma1ex-dag1mb1.msg.corp.akamai.com> <20161214102814.GA16287@openssl.org> Message-ID: <531c6b4f-1ea9-327f-2ff3-da147c1f99bb@shininglightpro.com> On 12/14/2016 3:28 AM, Dr. Stephen Henson wrote: > On Wed, Dec 14, 2016, Salz, Rich wrote: > >>> Is there some equivalent to PHP's openssl_sign_pkcs7 function for C/C++ users? >> >> Look at the apps/pkcs7.c file as a starting point. Get the command line doing what you want, and then work through the code to pull out only the bits you need. >> > > Actually smime.c is the utility you want for PKCS#7. Alternatively cms.c if > you want CMS (the successor to PKCS#7). > > Those though are general purpose utilities which do all sorts of things which > most appications don't care about. There are some demos in demos/smime and > demos/cms which are much simpler. PHP is open source software written in C. A quick lookup in PHP's git repository (it's source code) turns up: http://git.php.net/?p=php-src.git;a=blob;f=ext/openssl/openssl.c;h=a4b302bd303579d8f3eb62abdd9f312d3fba264d;hb=HEAD#l5148 Now the OP has a model to follow for writing a similar wrapper function for their project. I've found that when people mention a specific language (in this case, PHP), they are infatuated with the language but have never bothered to crack open that language's source code to dig into how the language actually works. To some extent, they view the language as magical. And to some other extent, they irrationally fear looking at the source code of the language. Now is the perfect opportunity for the OP to start learning how one of their favorite languages operates behind the scenes with the goal of porting a single function that they are interested in. This approach solves multiple core developer problems at the same time. -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ From linuxkid.zeuz at gmail.com Wed Dec 14 14:47:24 2016 From: linuxkid.zeuz at gmail.com (Anibal F. Martinez Cortina) Date: Wed, 14 Dec 2016 11:47:24 -0300 Subject: [openssl-users] Signing an XML file In-Reply-To: <531c6b4f-1ea9-327f-2ff3-da147c1f99bb@shininglightpro.com> References: <523c0ba6452e4e46bd3ee0984189feaa@usma1ex-dag1mb1.msg.corp.akamai.com> <20161214102814.GA16287@openssl.org> <531c6b4f-1ea9-327f-2ff3-da147c1f99bb@shininglightpro.com> Message-ID: 2016-12-14 11:17 GMT-03:00 Thomas J. Hruska : > On 12/14/2016 3:28 AM, Dr. Stephen Henson wrote: > >> On Wed, Dec 14, 2016, Salz, Rich wrote: >> >> Is there some equivalent to PHP's openssl_sign_pkcs7 function for C/C++ >>>> users? >>>> >>> >>> Look at the apps/pkcs7.c file as a starting point. Get the command line >>> doing what you want, and then work through the code to pull out only the >>> bits you need. >>> >>> >> Actually smime.c is the utility you want for PKCS#7. Alternatively cms.c >> if >> you want CMS (the successor to PKCS#7). >> >> Those though are general purpose utilities which do all sorts of things >> which >> most appications don't care about. There are some demos in demos/smime and >> demos/cms which are much simpler. >> > > PHP is open source software written in C. > > A quick lookup in PHP's git repository (it's source code) turns up: > > http://git.php.net/?p=php-src.git;a=blob;f=ext/openssl/opens > sl.c;h=a4b302bd303579d8f3eb62abdd9f312d3fba264d;hb=HEAD#l5148 > > Now the OP has a model to follow for writing a similar wrapper function > for their project. > > > I've found that when people mention a specific language (in this case, > PHP), they are infatuated with the language but have never bothered to > crack open that language's source code to dig into how the language > actually works. To some extent, they view the language as magical. And to > some other extent, they irrationally fear looking at the source code of the > language. Now is the perfect opportunity for the OP to start learning how > one of their favorite languages operates behind the scenes with the goal of > porting a single function that they are interested in. This approach solves > multiple core developer problems at the same time. > > -- > Thomas Hruska > Shining Light Productions > > Home of BMP2AVI and Win32 OpenSSL. > http://www.slproweb.com/ > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > As a matter of facts, you're indeed right. I was daunted by the idea of going through PHP's source myself.. Thanks for the pointers, guys. I'll report back as soon as I get some progress. Kind regards, Anibal.- -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvioprog at gmail.com Wed Dec 14 16:09:14 2016 From: silvioprog at gmail.com (silvioprog) Date: Wed, 14 Dec 2016 13:09:14 -0300 Subject: [openssl-users] Signing an XML file In-Reply-To: References: <523c0ba6452e4e46bd3ee0984189feaa@usma1ex-dag1mb1.msg.corp.akamai.com> <20161214102814.GA16287@openssl.org> <531c6b4f-1ea9-327f-2ff3-da147c1f99bb@shininglightpro.com> Message-ID: On Wed, Dec 14, 2016 at 11:47 AM, Anibal F. Martinez Cortina < linuxkid.zeuz at gmail.com> wrote: [...] > As a matter of facts, you're indeed right. I was daunted by the idea of > going through PHP's source myself.. > Thanks for the pointers, guys. > I'll report back as soon as I get some progress. > > Kind regards, > Anibal.- > Add xmlsec to your wishlist. :-) https://www.aleksey.com/xmlsec/api/xmlsec-examples.html -- Silvio Cl?cio -------------- next part -------------- An HTML attachment was scrubbed... URL: From norm.green at gemtalksystems.com Wed Dec 14 20:41:24 2016 From: norm.green at gemtalksystems.com (Norm Green) Date: Wed, 14 Dec 2016 12:41:24 -0800 Subject: [openssl-users] AECDH problem: works in 1.0.2, fails in 1.1 In-Reply-To: <37b323b4-7ecb-8e4c-3e39-0d10fbd3d6c5@openssl.org> References: <37b323b4-7ecb-8e4c-3e39-0d10fbd3d6c5@openssl.org> Message-ID: <585ee722-a0ad-1a9b-fa82-d780e5974d7c@gemtalksystems.com> That was it. Thanks Matt! On 12/13/16 15:48, Matt Caswell wrote: > > On 13/12/16 21:09, Norm Green wrote: >> I have a simple C program that works in 1.0.2 but fails with the same >> code in 1.1. >> Here's the psuedo code for the client and server: >> >> Server: >> const SSL_METHOD *meth = TLSv1_2_server_method(); >> SSL_CTX *ctx = SSL_CTX_new(meth); >> SSL_CTX_set_ecdh_auto(ctx, 1); >> SSL_CTX_set_mode(ctx, SSL_MODE_AUTO_RETRY); >> SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, NULL); >> SSL_CTX_set_cipher_list(ctx, "AECDH"); >> SSL_CTX_set_options(ctx, SSL_OP_SINGLE_DH_USE); >> SSL *ssl = SSL_new(ctx); >> SSL_accept(ssl); >> >> >> Client: >> const SSL_METHOD *meth = TLSv1_2_client_method(); >> SSL_CTX *ctx = SSL_CTX_new(meth); >> SSL_CTX_set_mode(ctx, SSL_MODE_AUTO_RETRY); >> SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, NULL); >> SSL_CTX_set_cipher_list(ctx, "AECDH"); >> SSL *ssl = SSL_new(ctx); >> SSL_connect(ssl); >> >> >> In 1.1, the client gets this error from SSL_connect() >> >> SSL_connect returned SSL_ERROR_SSL >> Details: error:141640B5:SSL routines:tls_construct_client_hello:no >> ciphers available >> ssl/statem/statem_clnt.c at 815 >> >> >> What do I need to do to make AECDH work in 1.1 ? > AECDH is in security level 0 but the default security level is 1. Read > about security levels here: > > https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_security_level.html > > You need to set the security level to 0 either through a call to > SSL_CTX_set_security_level() or similar; or via the cipherstring using > "AECDH:@SECLEVEL=0". See: > > https://www.openssl.org/docs/manmaster/man1/ciphers.html > > Matt > > > From sgraham at topnotchtech.com Wed Dec 14 21:58:21 2016 From: sgraham at topnotchtech.com (Sean Graham) Date: Wed, 14 Dec 2016 16:58:21 -0500 Subject: [openssl-users] Compiling for an old embedded device ARM7T armv4t platform? Message-ID: Hello everyone, I'm trying to do my research, and not sure if this should go into the -dev or -user mailing list... I have an embedded device which runs an ARM7T armv4t 16-bit thumb platform. I'm not finding much info other than the compile guide telling me to modify $cflags and $ldflags (which actually don't appear to be used in ./Configure?) The IDE for development is typically done in GUI mode - and I have no clue how I could compile OpenSSL in this manner. I'm hopeful that I can just link in the library, it seems to have a built in arm-elf compiler/linker and has its own internal library files as .elf I noticed that there are linux-armv4 and linux-elf compilation targets in ./Configure, so I'm hopeful that I can go in this direction, but I'm struggling to find documentation on how to approach it in this manner. Alternately is it possible to direct-compile with an IDE? I assume it's not just as simple as adding all the .c files in... I'm normally a windows guy :) Thanks in advance! ---------- Sean Graham -------------- next part -------------- An HTML attachment was scrubbed... URL: From yangjun9772 at gmail.com Thu Dec 15 08:39:50 2016 From: yangjun9772 at gmail.com (=?UTF-8?B?5p2o5L+K?=) Date: Thu, 15 Dec 2016 16:39:50 +0800 Subject: [openssl-users] It reported verify error:num=20:unable to get local issuer certificate in my embedded linux device, when I used the openssl command In-Reply-To: References: <5c27fc82-81d4-63fc-aa17-8aa1a0adebd6@wisemo.com> Message-ID: Hi Michael & opensslers, > So: either there's more than one certificate in cacert-2016-11-02.pem, or OpenSSL on the PC is searching its default CA certificate directory in addition to cacert-2016-11-02.pem. Since we don't know what's > actually in cacert-2016-11-02.pem, we can't provide much further help. It seems there are many certificates in the cacert-2016-11-02.pem. A lot. ---------------------cacert-2016-11-02.pem------------ GlobalSign Root CA ================== -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- GlobalSign Root CA - R2 ======================= -----BEGIN CERTIFICATE----- .. -----END CERTIFICATE----- Verisign Class 3 Public Primary Certification Authority - G3 ============================================================ -----BEGIN CERTIFICATE----- .... -----END CERTIFICATE----- Entrust.net Premium 2048 Secure Server CA ========================================= -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- Baltimore CyberTrust Root ========================= -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- ......so on........... -------------------------------------------------------------- > Note that if there are multiple certificates in cacert-2016-11-02.pem, you'll have to split them up into separate files and create the correct hash link for each one, if you want to use a certificate directory. Should I need to do this? >"< Because other people(in the internet) used this pem file, have no problem. They didn't separate it. And there are so many certificates. And is this step right ? 1. /tmp # ./openssl x509 -hash -fingerprint -noout -in /home/georgeyang/workspace/speech_code/openssl/openssl/final /certs/cacert-2016-11-02.pem 5ad8a5d6 SHA1 Fingerprint=B1:BC:96:8B:D4:F4:9D:62:2A:A8:9A:81:F2:15:01:52: A4:1D:82:9C 2. /etc/ssl/certs # ln -s /home/georgeyang/workspace/spe ech_code/openssl/openssl/final/certs/cacert-2016-11-02.pem 5ad8a5d6.0 I will split them like this later. > Did you actually capture that, or did you retype it? Because it's not valid openssl x509 output. Note that it doesn't match what you reported from the PC: In the paltform, the openssl version is 1.1.0c. And in my PC, the openssl version is 1.0.1f. Today, I have rebuild the openssl1.0.1f for my paltform again. Although it was still NG. And the log is the same as the PC now: /tmp # ./openssl x509 -subject -noout -in /home/georgeyang/workspace/ speech_code /openssl/final/openssl/certs/cacert-2016-11-02.pem subject= /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA /tmp # Thank you very much -------------- next part -------------- An HTML attachment was scrubbed... URL: From yangjun9772 at gmail.com Thu Dec 15 09:26:40 2016 From: yangjun9772 at gmail.com (=?UTF-8?B?5p2o5L+K?=) Date: Thu, 15 Dec 2016 17:26:40 +0800 Subject: [openssl-users] It reported verify error:num=20:unable to get local issuer certificate in my embedded linux device, when I used the openssl command In-Reply-To: References: <5c27fc82-81d4-63fc-aa17-8aa1a0adebd6@wisemo.com> Message-ID: Hi Jakob & Michael & opensslers, I'm sorry to ask a stupid question. That I found when I used the openssl1.0.1f, it said the error log: ----------------------------------log-------------- /tmp # ./openssl s_client -connect curl.haxx.se:443 -CAfile ./cacert.pem CONNECTED(00000003) depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 verify error:num=9:certificate is not yet valid ///////////////////////////new error notBefore=Sep 30 21:12:19 2000 GMT verify return:0 --- Certificate chain 0 s:/CN=anja.haxx.se i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3 --- Server certificate -----BEGIN CERTIFICATE----- .. -----END CERTIFICATE----- subject=/CN=anja.haxx.se issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 --- No client certificate CA names sent --- SSL handshake has read 3148 bytes and written 445 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 Session-ID: FD6ABFB426CC33309DBEA4078A4D24A07D5A80A5093AB771504CEBEFDE022706 Session-ID-ctx: Master-Key: 49725D111EC25DD193FB59E485CE32D5E0F3AD6E3269FF6617B2BC4E44ED7E4CCDDC6B05D799B69EA0FF6D974C54EBDE Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: Start Time: 2002 /////////////////////////////////////// time 2002 Timeout : 300 (sec) Verify return code: 9 (certificate is not yet valid) --- closed --------------------------------------------------------------------------------- Is this error occurred by the system clock of my platform? Actually, I didn't do anything to synchronize time in my platform(no NTP). Would this be a reason for my first issue and this issue? I'm trying to do NTP now. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From yangjun9772 at gmail.com Thu Dec 15 10:33:18 2016 From: yangjun9772 at gmail.com (=?UTF-8?B?5p2o5L+K?=) Date: Thu, 15 Dec 2016 18:33:18 +0800 Subject: [openssl-users] It reported verify error:num=20:unable to get local issuer certificate in my embedded linux device, when I used the openssl command In-Reply-To: References: <5c27fc82-81d4-63fc-aa17-8aa1a0adebd6@wisemo.com> Message-ID: Hi Jakob & Michael & openssler, The openssl can work well now. I just used the date command to reset my system time. And then it can return OK value now. Although I didn't try it in the latest openssl1.1.0c. In my embedded linux device, I didn't initialize the time. And there is no RTC. This issue can be closed. Thank you for all -------------- next part -------------- An HTML attachment was scrubbed... URL: From sahorwitz at gmail.com Thu Dec 15 16:53:30 2016 From: sahorwitz at gmail.com (Samuel Horwitz) Date: Thu, 15 Dec 2016 11:53:30 -0500 Subject: [openssl-users] big endian vs little endian Message-ID: When I attempt to encrypt the same text file with the command " openssl bf tfile.bin" I get different results on big endian machines vs little endian machines. Is this the expected result? If so how do you share encrypted data between big endian and little endian machines Thanks -- *Samuel A Horwitz* *sahorwitz at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Dec 15 17:08:04 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 15 Dec 2016 17:08:04 +0000 Subject: [openssl-users] big endian vs little endian In-Reply-To: References: Message-ID: <71b0754e261f4fd9a8074d487c5cfe04@usma1ex-dag1mb1.msg.corp.akamai.com> It?s not endianness, it?s random data in the encrypted stream. Try encrypting the same file (and password) twice on the same host. Try decrypting it. Everything will work right. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tdotreppe at gmail.com Sun Dec 18 01:11:56 2016 From: tdotreppe at gmail.com (Thomas d'Otreppe) Date: Sat, 17 Dec 2016 20:11:56 -0500 Subject: [openssl-users] Setting tlsext_hb_pending in OpenSSL 1.1.x Message-ID: Hi, I'm updating some code that was working just fine with OpenSSL 1.0.x but there was a recent update to 1.1.0c that broke it. I was able to fix one of the 2 compilation issue fairly easily (TLS1_RT_HEARTBEAT that got renamed to DTLS1_RT_HEARTBEAT) but I'm struggling with the other one. I looked up only and I have been asking in the IRC with no success (the OpenSSL channel is too quiet) and that's why I'm now asking your help. Basically, the SSL structure used to contain tlsext_hb_pending variable. After looking up, I found out there is now a function to get the value of 'pending'. What I need is to set the value. How can I do that now with 1.1.x? Did this change occurred for 1.1.0 only or did it occur before (in 1.0.x)? I want to use an #ifdef so that the code can compile with different versions of OpenSSL. Best regards, Thomas From linuxkid.zeuz at gmail.com Sun Dec 18 13:05:40 2016 From: linuxkid.zeuz at gmail.com (Anibal F. Martinez Cortina) Date: Sun, 18 Dec 2016 10:05:40 -0300 Subject: [openssl-users] Error code 554184855 on PKCS7_sign_add_signer? Message-ID: Hello everyone, I've been reading smime.c and trying to work my way up from a command that does work. However, I've reached this stage, and I get an error code I don-t know how to diagnose. The source is this(BEWARE: very little error handling, this is just a first informed attempt at the problem): X509 * certificado = NULL; FILE * archivoCertificado = NULL; archivoCertificado = fopen("cert.crt","rb"); if (!archivoCertificado) { qDebug() << "Fallo abrir el archivo del certificado"; return; } PEM_read_X509(archivoCertificado,&certificado,NULL,NULL); if (!certificado) { qDebug() << "Fallo al generar la estructura X509"; return; } FILE* archivoLlave = NULL; archivoLlave = fopen("key.key","rb"); EVP_PKEY * llave; PEM_read_PrivateKey(archivoLlave,&llave,NULL,NULL); if (!llave) { qDebug() << "Fallo la lectura de la llave"; return; } BIO * datos = NULL; FILE * fDatos = NULL; fDatos = fopen("Prueba.xml","rb"); if (!fDatos) { qDebug() << "Fallo la apertura del archivo de prueba."; return; } datos = BIO_new_fp(fDatos,NULL); if (!datos) { qDebug() << "Error al leer el archivo de prueba.xml"; return; } PKCS7 *estructura = NULL; if (!PKCS7_sign_add_signer(estructura,certificado,llave,NULL,0)) { qDebug() << "PKCS7_sign_add_signer fallo:" << ERR_get_error(); return; } estructura = PKCS7_sign(certificado,llave,NULL,datos,PKCS7_TEXT); if (!estructura) { qDebug() << "Fallo la creacion de la estructura."; return; } Failure comes at PKCS7_sign_add_signer.. Sorry for the main language used in the code, let me know if its of best practices to keep it to english or if it wouldn't be a real issue for the time being. Kind regards, Anibal.- -------------- next part -------------- An HTML attachment was scrubbed... URL: From sahorwitz at gmail.com Sun Dec 18 16:21:30 2016 From: sahorwitz at gmail.com (sahorwitz) Date: Sun, 18 Dec 2016 09:21:30 -0700 (MST) Subject: [openssl-users] big endian vs little endian In-Reply-To: <71b0754e261f4fd9a8074d487c5cfe04@usma1ex-dag1mb1.msg.corp.akamai.com> References: <71b0754e261f4fd9a8074d487c5cfe04@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <1482078090341-69377.post@n7.nabble.com> I am obviosly a newbie and missing something. How then do I encrypt the file on one machine (little endian), transmit it to another machine (big endian) and decrypt it there? -- View this message in context: http://openssl.6102.n7.nabble.com/big-endian-vs-little-endian-tp69372p69377.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From brice at famille-andre.be Sun Dec 18 20:05:42 2016 From: brice at famille-andre.be (=?UTF-8?B?QnJpY2UgQW5kcsOp?=) Date: Sun, 18 Dec 2016 21:05:42 +0100 Subject: [openssl-users] Problem with certificate check when it does not match CN Message-ID: Dear all, I use a gsoap application for which I write the server (php/apache) and client (gsoap and openssl). As I am pretty sure my problem comes from openssl and not gsoap, I am asking my question here. I developped the service a few years ago and got wildcard certificates from Startcom. Due to the recent probems with startcom, I migrated my certificates to COMODO. I also tried to rationalise the number of certificates, and I think several of my problems come from here. For a dedicate web service, I use a server located at https://www.online-rdv.be/v1/.... With my previous certificate, CN of certificate was a wildcard certificate : *.online-rdv.be. Everything worked fine. But now, my new certificate is common for all my web sites. So, the CN is www.ams-solutions.be and, in the list of alternate names, I have an entry *. online-rdv.be. >From this point, all gsoap connections fail from SSL checks. If checked the certificate bundle provided to my gsoap client application and it contains root certificate, as well as intermediate certificates. This same soap server is directly used by the website and all browsers I checked do not encounter the problem. So, my best guess is that the way I configure openssl with gsoap is not correct and does not allow validating a web site if it does not match the CN certificate field. I do no special configuration (nearly all default parameters). In fact, the only ssl configuration I perform is the following : soap_ssl_init(); soap_ssl_client_context(service.soap, SOAP_SSL_DEFAULT, NULL, NULL, cert_path.GetCString(), NULL, NULL); where cert_path points to a file with root and intermediate certificates. Any suggestion on how to solve my problem ? Regards, Brice -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgoldman at us.ibm.com Sun Dec 18 20:05:51 2016 From: kgoldman at us.ibm.com (Ken Goldman) Date: Sun, 18 Dec 2016 15:05:51 -0500 Subject: [openssl-users] big endian vs little endian In-Reply-To: <1482078090341-69377.post@n7.nabble.com> References: <71b0754e261f4fd9a8074d487c5cfe04@usma1ex-dag1mb1.msg.corp.akamai.com> <1482078090341-69377.post@n7.nabble.com> Message-ID: On 12/18/2016 11:21 AM, sahorwitz wrote: > I am obviously a newbie and missing something. How then do I encrypt the file > on one machine (little endian), transmit it to another machine (big endian) > and decrypt it there? Why do you think endian'ness is an issue? From Walter.H at mathemainzel.info Sun Dec 18 19:55:42 2016 From: Walter.H at mathemainzel.info (Walter H.) Date: Sun, 18 Dec 2016 20:55:42 +0100 Subject: [openssl-users] big endian vs little endian In-Reply-To: <1482078090341-69377.post@n7.nabble.com> References: <71b0754e261f4fd9a8074d487c5cfe04@usma1ex-dag1mb1.msg.corp.akamai.com> <1482078090341-69377.post@n7.nabble.com> Message-ID: <5856E9BE.1070203@mathemainzel.info> On 18.12.2016 17:21, sahorwitz wrote: > I am obviosly a newbie and missing something. How then do I encrypt the file > on one machine (little endian), transmit it to another machine (big endian) > and decrypt it there? > > > similar to this: encrypt openssl enc -e -in file -out encryptfile -aes-256-gcm decrypt openssl enc -d -in encryptfile -out file -aes-256-gcm can someone explain why I get the following output enter aes-256-gcm decryption password: bad decrypt but the file is correctly decrypted I'm using latest openssl rpm package from CentOS 6 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3827 bytes Desc: S/MIME Cryptographic Signature URL: From openssl-users at dukhovni.org Sun Dec 18 21:25:03 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 18 Dec 2016 16:25:03 -0500 Subject: [openssl-users] Problem with certificate check when it does not match CN In-Reply-To: References: Message-ID: > On Dec 18, 2016, at 3:05 PM, Brice Andr? wrote: > > I developped the service a few years ago and got wildcard certificates from Startcom. Due to the recent probems with startcom, I migrated my certificates to COMODO. I also tried to rationalise the number of certificates, and I think several of my problems come from here. Your problem is an incomplete migration. The certificate presented by www.online-rdv.be on port 443 is the StartCom certificate you intended to replace. > For a dedicate web service, I use a server located at https://www.online-rdv.be/v1/.... With my previous certificate, CN of certificate was a wildcard certificate : *.online-rdv.be. Everything worked fine. See below for the presented chain: Certificate: Data: Version: 3 (0x2) Serial Number: 2304556835693556 (0x82ffb738e63f4) Signature Algorithm: sha256WithRSAEncryption Issuer: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Class 2 Primary Intermediate Server CA Validity Not Before: Oct 14 10:40:52 2015 GMT Not After : Oct 14 15:54:25 2017 GMT Subject: C=BE, ST=Hainaut, L=Couillet, O=Brice Andr\xE9, CN=*.online-rdv.be/emailAddress=hostmaster at online-rdv.be Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:c7:15:56:aa:b7:13:50:b6:30:af:aa:53:00:d1: 34:ae:d7:c9:62:95:80:f7:70:93:d1:13:16:04:bd: 70:ac:fa:b0:74:0d:ce:c2:1c:e6:96:d0:cd:5d:4d: 59:e7:bb:1d:34:7e:05:b3:60:96:aa:fa:88:4d:75: 61:52:59:f5:ae:58:86:7d:7a:5d:93:c1:f8:dc:be: 86:25:c1:d4:63:60:eb:1d:ab:8a:da:a4:4d:4a:17: 40:ef:02:55:57:2b:53:42:0e:ac:21:7c:13:6c:c4: ed:72:ba:99:8a:63:b3:02:c9:3f:ff:36:d6:a2:81: 95:38:32:ec:ae:c7:fe:75:54:17:82:b5:16:c9:ae: c5:46:05:28:b5:c3:24:76:65:60:dd:21:15:c7:28: b8:ec:a5:d2:15:bf:5d:58:e3:cb:ef:ca:9a:09:54: 31:f1:4d:b7:ae:89:dd:60:a7:8f:1c:d7:06:8d:91: ab:9f:68:36:fa:e9:ba:9c:ff:64:c1:58:9b:d7:de: df:b9:ac:bd:e0:05:08:d1:fb:a1:02:08:01:11:bf: fc:9c:73:7b:b7:7d:ec:0f:0c:bf:73:8b:fc:6e:b1: 56:dd:ca:58:00:d8:80:53:8e:f0:ff:72:70:ae:14: ad:0c:0e:ae:23:9c:1a:a2:dd:11:41:6e:8d:87:f5: 6a:35 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: Digital Signature, Key Encipherment, Key Agreement X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication X509v3 Subject Key Identifier: E5:7E:1E:3D:4C:C1:71:36:3A:FE:F8:D3:E7:E2:5F:A1:7D:8B:42:A3 X509v3 Authority Key Identifier: keyid:11:DB:23:45:FD:54:CC:6A:71:6F:84:8A:03:D7:BE:F7:01:2F:26:86 X509v3 Subject Alternative Name: DNS:*.online-rdv.be, DNS:online-rdv.be, DNS:online-rdv.biz, DNS:*.online-rdv.biz, DNS:online-rdv.com, DNS:*.online-rdv.com, DNS:online-rdv.eu, DNS:*.online-rdv.eu, DNS:online-rdv.info, DNS:*.online-rdv.info, DNS:online-rdv.net, DNS:*.online-rdv.net, DNS:online-rdv.org, DNS:*.online-rdv.org, DNS:rdv-doc.be, DNS:*.rdv-doc.be, DNS:doc-rdv.be, DNS:*.doc-rdv.be X509v3 Certificate Policies: Policy: 2.23.140.1.2.2 Policy: 1.3.6.1.4.1.23223.1.2.3 CPS: http://www.startssl.com/policy.pdf User Notice: Organization: StartCom Certification Authority Number: 1 Explicit Text: This certificate was issued according to the Class 2 Validation requirements of the StartCom CA policy, reliance only for the intended purpose in compliance of the relying party obligations. X509v3 CRL Distribution Points: Full Name: URI:http://crl.startssl.com/crt2-crl.crl Authority Information Access: OCSP - URI:http://ocsp.startssl.com/sub/class2/server/ca CA Issuers - URI:http://aia.startssl.com/certs/sub.class2.server.ca.crt X509v3 Issuer Alternative Name: URI:http://www.startssl.com/ Signature Algorithm: sha256WithRSAEncryption a9:f2:f6:ea:a8:57:bc:1b:11:51:05:eb:b8:b5:55:0f:96:e6: 08:73:ef:67:92:bf:aa:b0:54:32:48:3e:61:91:73:dd:2d:fd: 2a:e7:2b:57:81:a5:a5:46:17:5b:2d:9a:62:f3:fa:43:11:ba: 48:0f:47:65:19:ca:2b:82:dd:0f:e7:da:2d:1c:99:55:b6:86: 93:b7:58:31:d3:a9:1a:34:ae:b8:5f:65:29:a0:0a:22:49:0f: df:a9:1b:06:b6:ba:9f:b6:4b:58:82:f6:d1:00:2f:a3:3b:4e: f8:51:3c:b9:3b:88:42:f8:9e:c8:02:41:7d:b2:41:d9:f6:d4: d9:97:a8:1c:83:e9:6a:38:05:5a:1e:28:f3:29:ee:6d:b5:50: 3e:24:a2:88:33:62:66:14:6b:1c:37:47:07:d1:79:2c:60:de: 48:49:4e:a9:48:65:05:07:8f:e2:be:0f:13:e2:99:6f:f3:14: ce:22:cb:77:09:8a:fa:c6:29:47:ba:06:58:db:6a:80:15:d2: 99:77:d1:4c:4c:21:7c:f1:d3:8d:62:74:53:d3:39:4d:11:e2: 9b:8e:f2:24:0a:ed:f0:f0:58:61:d0:14:ed:e2:4f:45:4e:9f: 75:ab:b0:4f:79:02:fd:5a:f0:cf:de:ff:b6:9b:83:62:a9:4b: 81:49:74:d9 -----BEGIN CERTIFICATE----- MIIHjzCCBnegAwIBAgIHCC/7c45j9DANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBE aWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgU2VydmVyIENBMB4XDTE1MTAxNDEw NDA1MloXDTE3MTAxNDE1NTQyNVowgYsxCzAJBgNVBAYTAkJFMRAwDgYDVQQIEwdI YWluYXV0MREwDwYDVQQHEwhDb3VpbGxldDEUMBIGA1UEChQLQnJpY2UgQW5kcukx GDAWBgNVBAMUDyoub25saW5lLXJkdi5iZTEnMCUGCSqGSIb3DQEJARYYaG9zdG1h c3RlckBvbmxpbmUtcmR2LmJlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxxVWqrcTULYwr6pTANE0rtfJYpWA93CT0RMWBL1wrPqwdA3OwhzmltDNXU1Z 57sdNH4Fs2CWqvqITXVhUln1rliGfXpdk8H43L6GJcHUY2DrHauK2qRNShdA7wJV VytTQg6sIXwTbMTtcrqZimOzAsk//zbWooGVODLsrsf+dVQXgrUWya7FRgUotcMk dmVg3SEVxyi47KXSFb9dWOPL78qaCVQx8U23rondYKePHNcGjZGrn2g2+um6nP9k wVib197fuay94AUI0fuhAggBEb/8nHN7t33sDwy/c4v8brFW3cpYANiAU47w/3Jw rhStDA6uI5waot0RQW6Nh/VqNQIDAQABo4ID8zCCA+8wCQYDVR0TBAIwADALBgNV HQ8EBAMCA6gwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMB0GA1UdDgQW BBTlfh49TMFxNjr++NPn4l+hfYtCozAfBgNVHSMEGDAWgBQR2yNF/VTManFvhIoD 1773AS8mhjCCAS0GA1UdEQSCASQwggEggg8qLm9ubGluZS1yZHYuYmWCDW9ubGlu ZS1yZHYuYmWCDm9ubGluZS1yZHYuYml6ghAqLm9ubGluZS1yZHYuYml6gg5vbmxp bmUtcmR2LmNvbYIQKi5vbmxpbmUtcmR2LmNvbYINb25saW5lLXJkdi5ldYIPKi5v bmxpbmUtcmR2LmV1gg9vbmxpbmUtcmR2LmluZm+CESoub25saW5lLXJkdi5pbmZv gg5vbmxpbmUtcmR2Lm5ldIIQKi5vbmxpbmUtcmR2Lm5ldIIOb25saW5lLXJkdi5v cmeCECoub25saW5lLXJkdi5vcmeCCnJkdi1kb2MuYmWCDCoucmR2LWRvYy5iZYIK ZG9jLXJkdi5iZYIMKi5kb2MtcmR2LmJlMIIBVgYDVR0gBIIBTTCCAUkwCAYGZ4EM AQICMIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFy dENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZp Y2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxp YW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNl IG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA1BgNVHR8ELjAsMCqg KKAmhiRodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnQyLWNybC5jcmwwgY4GCCsG AQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNv bS9zdWIvY2xhc3MyL3NlcnZlci9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5z dGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5zZXJ2ZXIuY2EuY3J0MCMGA1Ud EgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQsFAAOC AQEAqfL26qhXvBsRUQXruLVVD5bmCHPvZ5K/qrBUMkg+YZFz3S39KucrV4GlpUYX Wy2aYvP6QxG6SA9HZRnKK4LdD+faLRyZVbaGk7dYMdOpGjSuuF9lKaAKIkkP36kb Bra6n7ZLWIL20QAvoztO+FE8uTuIQvieyAJBfbJB2fbU2ZeoHIPpajgFWh4o8ynu bbVQPiSiiDNiZhRrHDdHB9F5LGDeSElOqUhlBQeP4r4PE+KZb/MUziLLdwmK+sYp R7oGWNtqgBXSmXfRTEwhfPHTjWJ0U9M5TRHim47yJArt8PBYYdAU7eJPRU6fdauw T3kC/Vrwz97/tpuDYqlLgUl02Q== -----END CERTIFICATE----- Certificate: Data: Version: 3 (0x2) Serial Number: 8069548958653521 (0x1cab36472d9c51) Signature Algorithm: sha256WithRSAEncryption Issuer: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Certification Authority Validity Not Before: Oct 14 20:57:09 2007 GMT Not After : Oct 14 20:57:09 2022 GMT Subject: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Class 2 Primary Intermediate Server CA Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:e2:4f:39:2f:a1:8c:9a:85:ad:08:0e:08:3e:57: f2:88:01:21:1b:94:a9:6c:e2:b8:db:aa:19:18:46: 3a:52:a1:f5:0f:f4:6e:8c:ea:96:8c:96:87:79:13: 40:51:2f:22:f2:0c:8b:87:0f:65:df:71:74:34:43: 55:b1:35:09:9b:d9:bc:1f:fa:eb:42:d0:97:40:72: b7:43:96:3d:ba:96:9d:5d:50:02:1c:9b:91:8d:9c: c0:ac:d7:bb:2f:17:d7:cb:3e:82:9d:73:eb:07:42: 92:b2:cd:64:b3:74:55:1b:b4:4b:86:21:2c:f7:78: 87:32:e0:16:e4:da:bd:4c:95:ea:a4:0a:7e:b6:0a: 0d:2e:8a:cf:55:ab:c3:e5:dd:41:8a:4e:e6:6f:65: 6c:b2:40:cf:17:5d:b9:c3:6a:0b:27:11:84:77:61: f6:c2:7c:ed:c0:8d:78:14:18:99:81:99:75:63:b7: e8:53:d3:ba:61:e9:0e:fa:a2:30:f3:46:a2:b9:c9: 1f:6c:80:5a:40:ac:27:ed:48:47:33:b0:54:c6:46: 1a:f3:35:61:c1:02:29:90:54:7e:64:4d:c4:30:52: 02:82:d7:df:ce:21:6e:18:91:d7:b8:ab:8c:27:17: b5:f0:a3:01:2f:8e:d2:2e:87:3a:3d:b4:29:67:8a: c4:03 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Subject Key Identifier: 11:DB:23:45:FD:54:CC:6A:71:6F:84:8A:03:D7:BE:F7:01:2F:26:86 X509v3 Authority Key Identifier: keyid:4E:0B:EF:1A:A4:40:5B:A5:17:69:87:30:CA:34:68:43:D0:41:AE:F2 Authority Information Access: OCSP - URI:http://ocsp.startssl.com/ca CA Issuers - URI:http://aia.startssl.com/certs/ca.crt X509v3 CRL Distribution Points: Full Name: URI:http://crl.startssl.com/sfsca.crl X509v3 Certificate Policies: Policy: X509v3 Any Policy CPS: http://www.startssl.com/policy.pdf Signature Algorithm: sha256WithRSAEncryption 52:c9:bd:f3:bd:cb:f9:eb:a2:c4:32:ca:86:72:fc:cf:bf:a7: 30:b5:fd:91:f7:d5:81:e1:21:04:ad:00:4c:ff:e9:8b:27:da: ff:f2:24:cd:fc:1f:0f:7f:d2:d1:e5:81:92:23:78:16:ee:6b: 03:2e:9d:00:48:4f:ae:82:65:2e:87:6f:ee:6a:07:5f:4b:56: 6e:f7:96:46:41:e6:dd:fe:45:b9:62:2a:9a:8a:76:e9:ad:bd: d6:73:b3:bc:31:2b:d0:2c:d5:6c:6b:bc:6a:3a:25:87:a9:a8: a5:0d:d7:85:f1:6c:6c:05:0e:f4:c1:68:cb:bb:2a:81:58:a5: 3e:99:c4:9f:f7:1f:84:8e:a0:7a:d1:4d:db:b8:01:9c:0d:81: 34:ca:82:fe:23:62:4d:3f:6d:a4:52:c0:4c:5e:f2:69:48:b1: f2:df:ac:44:64:69:b0:46:29:c7:ad:f0:f2:c0:9d:68:23:8a: a8:67:71:22:17:be:ce:89:7a:76:be:54:6c:93:5c:8b:f0:1a: 6e:ae:ed:8e:ae:c2:05:ae:13:57:e6:b9:e7:70:c8:33:b8:9e: fd:4a:30:e3:98:d4:13:6b:ee:4e:b9:e6:ec:df:ce:ea:a0:9e: 76:6a:97:aa:ea:df:34:45:42:f5:da:4d:d6:87:76:6d:ff:ce: 69:86:7a:81:5f:db:b2:4f:ce:b0:e0:67:60:39:44:b0:45:10: 85:65:97:12:79:df:d4:97:d8:78:21:0c:84:98:ce:bb:4f:6b: 0f:19:da:85:69:91:41:6c:17:1c:c6:b9:f6:14:ae:f2:a1:80: 7a:e2:e9:95:ef:22:8a:cc:ff:38:db:fc:21:56:ec:80:fd:6d: a2:85:91:29:03:ea:ab:03:bd:2c:60:44:82:00:35:e7:14:6c: 76:3b:40:83:55:d5:5c:df:c7:28:a3:59:d5:89:78:3e:0f:e0: 06:fd:d5:57:8a:24:1c:a7:62:38:1d:85:93:4b:f9:93:7f:f3: 44:fa:63:98:9e:ed:26:89:9d:f6:fe:f8:43:6c:25:ff:07:f9: 12:3c:9e:11:b0:d3:80:ee:ec:ab:3b:0c:a4:72:03:92:14:36: e9:be:e6:8a:3a:91:8b:ad:0c:06:a8:b3:83:82:6f:a9:f5:36: 39:82:23:0c:8e:ea:fd:5c:7e:d3:4b:5c:33:d3:67:48:cf:4e: ee:cb:63:70:61:67:55:eb:bb:dc:9c:0b:7a:43:14:48:49:aa: 79:45:b6:8f:be:2c:90:67:1c:f8:9c:56:92:95:30:30:1e:83: da:5b:5c:ae:55:2d:75:b6:6b:11:38:c9:51:44:db:db:68:0c: 48:53:85:3a:ed:86:99:4b -----BEGIN CERTIFICATE----- MIIF2TCCA8GgAwIBAgIHHKs2Ry2cUTANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQG EwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDE0MjA1NzA5WhcNMjIxMDE0MjA1 NzA5WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgU2VydmVy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4k85L6GMmoWtCA4I PlfyiAEhG5SpbOK426oZGEY6UqH1D/RujOqWjJaHeRNAUS8i8gyLhw9l33F0NENV sTUJm9m8H/rrQtCXQHK3Q5Y9upadXVACHJuRjZzArNe7LxfXyz6CnXPrB0KSss1k s3RVG7RLhiEs93iHMuAW5Nq9TJXqpAp+tgoNLorPVavD5d1Bik7mb2VsskDPF125 w2oLJxGEd2H2wnztwI14FBiZgZl1Y7foU9O6YekO+qIw80aiuckfbIBaQKwn7UhH M7BUxkYa8zVhwQIpkFR+ZE3EMFICgtffziFuGJHXuKuMJxe18KMBL47SLoc6PbQp Z4rEAwIDAQABo4IBTDCCAUgwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8E BAMCAQYwHQYDVR0OBBYEFBHbI0X9VMxqcW+EigPXvvcBLyaGMB8GA1UdIwQYMBaA FE4L7xqkQFulF2mHMMo0aEPQQa7yMGkGCCsGAQUFBwEBBF0wWzAnBggrBgEFBQcw AYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMDAGCCsGAQUFBzAChiRodHRw Oi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwMgYDVR0fBCswKTAnoCWg I4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMEMGA1UdIAQ8MDow OAYEVR0gADAwMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9w b2xpY3kucGRmMA0GCSqGSIb3DQEBCwUAA4ICAQBSyb3zvcv566LEMsqGcvzPv6cw tf2R99WB4SEErQBM/+mLJ9r/8iTN/B8Pf9LR5YGSI3gW7msDLp0ASE+ugmUuh2/u agdfS1Zu95ZGQebd/kW5Yiqainbprb3Wc7O8MSvQLNVsa7xqOiWHqailDdeF8Wxs BQ70wWjLuyqBWKU+mcSf9x+EjqB60U3buAGcDYE0yoL+I2JNP22kUsBMXvJpSLHy 36xEZGmwRinHrfDywJ1oI4qoZ3EiF77OiXp2vlRsk1yL8Bpuru2OrsIFrhNX5rnn cMgzuJ79SjDjmNQTa+5Ouebs387qoJ52apeq6t80RUL12k3Wh3Zt/85phnqBX9uy T86w4GdgOUSwRRCFZZcSed/Ul9h4IQyEmM67T2sPGdqFaZFBbBccxrn2FK7yoYB6 4umV7yKKzP842/whVuyA/W2ihZEpA+qrA70sYESCADXnFGx2O0CDVdVc38coo1nV iXg+D+AG/dVXiiQcp2I4HYWTS/mTf/NE+mOYnu0miZ32/vhDbCX/B/kSPJ4RsNOA 7uyrOwykcgOSFDbpvuaKOpGLrQwGqLODgm+p9TY5giMMjur9XH7TS1wz02dIz07u y2NwYWdV67vcnAt6QxRISap5RbaPviyQZxz4nFaSlTAwHoPaW1yuVS11tmsROMlR RNvbaAxIU4U67YaZSw== -----END CERTIFICATE----- -- Viktor. From brice at famille-andre.be Sun Dec 18 21:52:01 2016 From: brice at famille-andre.be (=?UTF-8?B?QnJpY2UgQW5kcsOp?=) Date: Sun, 18 Dec 2016 21:52:01 +0000 Subject: [openssl-users] Problem with certificate check when it does not match CN In-Reply-To: References: Message-ID: Dear Viktor, Thanks for your answer. I Know that the current certificate is the old one, but this is because my service is in production. I tested new certificate this evening to limit the number of impacted clients. And as it did not worked, i reinstalled previous certificate waiting a solution for the new one. If it may help, i can installe new cerrificate on a test site. Regards, Brice Le dim. 18 d?c. 2016 ? 22:26, Viktor Dukhovni a ?crit : > > > > On Dec 18, 2016, at 3:05 PM, Brice Andr? wrote: > > > > > > I developped the service a few years ago and got wildcard certificates > from Startcom. Due to the recent probems with startcom, I migrated my > certificates to COMODO. I also tried to rationalise the number of > certificates, and I think several of my problems come from here. > > > > Your problem is an incomplete migration. The certificate > > presented by www.online-rdv.be on port 443 is the StartCom > > certificate you intended to replace. > > > > > For a dedicate web service, I use a server located at > https://www.online-rdv.be/v1/.... With my previous certificate, CN of > certificate was a wildcard certificate : *.online-rdv.be. Everything > worked fine. > > > > See below for the presented chain: > > > > Certificate: > > Data: > > Version: 3 (0x2) > > Serial Number: 2304556835693556 (0x82ffb738e63f4) > > Signature Algorithm: sha256WithRSAEncryption > > Issuer: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate > Signing, CN=StartCom Class 2 Primary Intermediate Server CA > > Validity > > Not Before: Oct 14 10:40:52 2015 GMT > > Not After : Oct 14 15:54:25 2017 GMT > > Subject: C=BE, ST=Hainaut, L=Couillet, O=Brice Andr\xE9, CN=*. > online-rdv.be/emailAddress=hostmaster at online-rdv.be > > Subject Public Key Info: > > Public Key Algorithm: rsaEncryption > > Public-Key: (2048 bit) > > Modulus: > > 00:c7:15:56:aa:b7:13:50:b6:30:af:aa:53:00:d1: > > 34:ae:d7:c9:62:95:80:f7:70:93:d1:13:16:04:bd: > > 70:ac:fa:b0:74:0d:ce:c2:1c:e6:96:d0:cd:5d:4d: > > 59:e7:bb:1d:34:7e:05:b3:60:96:aa:fa:88:4d:75: > > 61:52:59:f5:ae:58:86:7d:7a:5d:93:c1:f8:dc:be: > > 86:25:c1:d4:63:60:eb:1d:ab:8a:da:a4:4d:4a:17: > > 40:ef:02:55:57:2b:53:42:0e:ac:21:7c:13:6c:c4: > > ed:72:ba:99:8a:63:b3:02:c9:3f:ff:36:d6:a2:81: > > 95:38:32:ec:ae:c7:fe:75:54:17:82:b5:16:c9:ae: > > c5:46:05:28:b5:c3:24:76:65:60:dd:21:15:c7:28: > > b8:ec:a5:d2:15:bf:5d:58:e3:cb:ef:ca:9a:09:54: > > 31:f1:4d:b7:ae:89:dd:60:a7:8f:1c:d7:06:8d:91: > > ab:9f:68:36:fa:e9:ba:9c:ff:64:c1:58:9b:d7:de: > > df:b9:ac:bd:e0:05:08:d1:fb:a1:02:08:01:11:bf: > > fc:9c:73:7b:b7:7d:ec:0f:0c:bf:73:8b:fc:6e:b1: > > 56:dd:ca:58:00:d8:80:53:8e:f0:ff:72:70:ae:14: > > ad:0c:0e:ae:23:9c:1a:a2:dd:11:41:6e:8d:87:f5: > > 6a:35 > > Exponent: 65537 (0x10001) > > X509v3 extensions: > > X509v3 Basic Constraints: > > CA:FALSE > > X509v3 Key Usage: > > Digital Signature, Key Encipherment, Key Agreement > > X509v3 Extended Key Usage: > > TLS Web Client Authentication, TLS Web Server > Authentication > > X509v3 Subject Key Identifier: > > E5:7E:1E:3D:4C:C1:71:36:3A:FE:F8:D3:E7:E2:5F:A1:7D:8B:42:A3 > > X509v3 Authority Key Identifier: > > > keyid:11:DB:23:45:FD:54:CC:6A:71:6F:84:8A:03:D7:BE:F7:01:2F:26:86 > > > > X509v3 Subject Alternative Name: > > DNS:*.online-rdv.be, DNS:online-rdv.be, DNS:online-rdv.biz, > DNS:*.online-rdv.biz, DNS:online-rdv.com, DNS:*.online-rdv.com, DNS: > online-rdv.eu, DNS:*.online-rdv.eu, DNS:online-rdv.info, DNS:*. > online-rdv.info, DNS:online-rdv.net, DNS:*.online-rdv.net, DNS: > online-rdv.org, DNS:*.online-rdv.org, DNS:rdv-doc.be, DNS:*.rdv-doc.be, > DNS:doc-rdv.be, DNS:*.doc-rdv.be > > X509v3 Certificate Policies: > > Policy: 2.23.140.1.2.2 > > Policy: 1.3.6.1.4.1.23223.1.2.3 > > CPS: http://www.startssl.com/policy.pdf > > User Notice: > > Organization: StartCom Certification Authority > > Number: 1 > > Explicit Text: This certificate was issued according > to the Class 2 Validation requirements of the StartCom CA policy, reliance > only for the intended purpose in compliance of the relying party > obligations. > > > > X509v3 CRL Distribution Points: > > > > Full Name: > > URI:http://crl.startssl.com/crt2-crl.crl > > > > Authority Information Access: > > OCSP - URI:http://ocsp.startssl.com/sub/class2/server/ca > > CA Issuers - URI: > http://aia.startssl.com/certs/sub.class2.server.ca.crt > > > > X509v3 Issuer Alternative Name: > > URI:http://www.startssl.com/ > > Signature Algorithm: sha256WithRSAEncryption > > a9:f2:f6:ea:a8:57:bc:1b:11:51:05:eb:b8:b5:55:0f:96:e6: > > 08:73:ef:67:92:bf:aa:b0:54:32:48:3e:61:91:73:dd:2d:fd: > > 2a:e7:2b:57:81:a5:a5:46:17:5b:2d:9a:62:f3:fa:43:11:ba: > > 48:0f:47:65:19:ca:2b:82:dd:0f:e7:da:2d:1c:99:55:b6:86: > > 93:b7:58:31:d3:a9:1a:34:ae:b8:5f:65:29:a0:0a:22:49:0f: > > df:a9:1b:06:b6:ba:9f:b6:4b:58:82:f6:d1:00:2f:a3:3b:4e: > > f8:51:3c:b9:3b:88:42:f8:9e:c8:02:41:7d:b2:41:d9:f6:d4: > > d9:97:a8:1c:83:e9:6a:38:05:5a:1e:28:f3:29:ee:6d:b5:50: > > 3e:24:a2:88:33:62:66:14:6b:1c:37:47:07:d1:79:2c:60:de: > > 48:49:4e:a9:48:65:05:07:8f:e2:be:0f:13:e2:99:6f:f3:14: > > ce:22:cb:77:09:8a:fa:c6:29:47:ba:06:58:db:6a:80:15:d2: > > 99:77:d1:4c:4c:21:7c:f1:d3:8d:62:74:53:d3:39:4d:11:e2: > > 9b:8e:f2:24:0a:ed:f0:f0:58:61:d0:14:ed:e2:4f:45:4e:9f: > > 75:ab:b0:4f:79:02:fd:5a:f0:cf:de:ff:b6:9b:83:62:a9:4b: > > 81:49:74:d9 > > -----BEGIN CERTIFICATE----- > > MIIHjzCCBnegAwIBAgIHCC/7c45j9DANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UE > > BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBE > > aWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs > > YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgU2VydmVyIENBMB4XDTE1MTAxNDEw > > NDA1MloXDTE3MTAxNDE1NTQyNVowgYsxCzAJBgNVBAYTAkJFMRAwDgYDVQQIEwdI > > YWluYXV0MREwDwYDVQQHEwhDb3VpbGxldDEUMBIGA1UEChQLQnJpY2UgQW5kcukx > > GDAWBgNVBAMUDyoub25saW5lLXJkdi5iZTEnMCUGCSqGSIb3DQEJARYYaG9zdG1h > > c3RlckBvbmxpbmUtcmR2LmJlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC > > AQEAxxVWqrcTULYwr6pTANE0rtfJYpWA93CT0RMWBL1wrPqwdA3OwhzmltDNXU1Z > > 57sdNH4Fs2CWqvqITXVhUln1rliGfXpdk8H43L6GJcHUY2DrHauK2qRNShdA7wJV > > VytTQg6sIXwTbMTtcrqZimOzAsk//zbWooGVODLsrsf+dVQXgrUWya7FRgUotcMk > > dmVg3SEVxyi47KXSFb9dWOPL78qaCVQx8U23rondYKePHNcGjZGrn2g2+um6nP9k > > wVib197fuay94AUI0fuhAggBEb/8nHN7t33sDwy/c4v8brFW3cpYANiAU47w/3Jw > > rhStDA6uI5waot0RQW6Nh/VqNQIDAQABo4ID8zCCA+8wCQYDVR0TBAIwADALBgNV > > HQ8EBAMCA6gwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMB0GA1UdDgQW > > BBTlfh49TMFxNjr++NPn4l+hfYtCozAfBgNVHSMEGDAWgBQR2yNF/VTManFvhIoD > > 1773AS8mhjCCAS0GA1UdEQSCASQwggEggg8qLm9ubGluZS1yZHYuYmWCDW9ubGlu > > ZS1yZHYuYmWCDm9ubGluZS1yZHYuYml6ghAqLm9ubGluZS1yZHYuYml6gg5vbmxp > > bmUtcmR2LmNvbYIQKi5vbmxpbmUtcmR2LmNvbYINb25saW5lLXJkdi5ldYIPKi5v > > bmxpbmUtcmR2LmV1gg9vbmxpbmUtcmR2LmluZm+CESoub25saW5lLXJkdi5pbmZv > > gg5vbmxpbmUtcmR2Lm5ldIIQKi5vbmxpbmUtcmR2Lm5ldIIOb25saW5lLXJkdi5v > > cmeCECoub25saW5lLXJkdi5vcmeCCnJkdi1kb2MuYmWCDCoucmR2LWRvYy5iZYIK > > ZG9jLXJkdi5iZYIMKi5kb2MtcmR2LmJlMIIBVgYDVR0gBIIBTTCCAUkwCAYGZ4EM > > AQICMIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 > > LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFy > > dENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZp > > Y2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxpZGF0 > > aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxp > > YW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNl > > IG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA1BgNVHR8ELjAsMCqg > > KKAmhiRodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnQyLWNybC5jcmwwgY4GCCsG > > AQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNv > > bS9zdWIvY2xhc3MyL3NlcnZlci9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5z > > dGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5zZXJ2ZXIuY2EuY3J0MCMGA1Ud > > EgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQsFAAOC > > AQEAqfL26qhXvBsRUQXruLVVD5bmCHPvZ5K/qrBUMkg+YZFz3S39KucrV4GlpUYX > > Wy2aYvP6QxG6SA9HZRnKK4LdD+faLRyZVbaGk7dYMdOpGjSuuF9lKaAKIkkP36kb > > Bra6n7ZLWIL20QAvoztO+FE8uTuIQvieyAJBfbJB2fbU2ZeoHIPpajgFWh4o8ynu > > bbVQPiSiiDNiZhRrHDdHB9F5LGDeSElOqUhlBQeP4r4PE+KZb/MUziLLdwmK+sYp > > R7oGWNtqgBXSmXfRTEwhfPHTjWJ0U9M5TRHim47yJArt8PBYYdAU7eJPRU6fdauw > > T3kC/Vrwz97/tpuDYqlLgUl02Q== > > -----END CERTIFICATE----- > > > > Certificate: > > Data: > > Version: 3 (0x2) > > Serial Number: 8069548958653521 (0x1cab36472d9c51) > > Signature Algorithm: sha256WithRSAEncryption > > Issuer: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate > Signing, CN=StartCom Certification Authority > > Validity > > Not Before: Oct 14 20:57:09 2007 GMT > > Not After : Oct 14 20:57:09 2022 GMT > > Subject: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate > Signing, CN=StartCom Class 2 Primary Intermediate Server CA > > Subject Public Key Info: > > Public Key Algorithm: rsaEncryption > > Public-Key: (2048 bit) > > Modulus: > > 00:e2:4f:39:2f:a1:8c:9a:85:ad:08:0e:08:3e:57: > > f2:88:01:21:1b:94:a9:6c:e2:b8:db:aa:19:18:46: > > 3a:52:a1:f5:0f:f4:6e:8c:ea:96:8c:96:87:79:13: > > 40:51:2f:22:f2:0c:8b:87:0f:65:df:71:74:34:43: > > 55:b1:35:09:9b:d9:bc:1f:fa:eb:42:d0:97:40:72: > > b7:43:96:3d:ba:96:9d:5d:50:02:1c:9b:91:8d:9c: > > c0:ac:d7:bb:2f:17:d7:cb:3e:82:9d:73:eb:07:42: > > 92:b2:cd:64:b3:74:55:1b:b4:4b:86:21:2c:f7:78: > > 87:32:e0:16:e4:da:bd:4c:95:ea:a4:0a:7e:b6:0a: > > 0d:2e:8a:cf:55:ab:c3:e5:dd:41:8a:4e:e6:6f:65: > > 6c:b2:40:cf:17:5d:b9:c3:6a:0b:27:11:84:77:61: > > f6:c2:7c:ed:c0:8d:78:14:18:99:81:99:75:63:b7: > > e8:53:d3:ba:61:e9:0e:fa:a2:30:f3:46:a2:b9:c9: > > 1f:6c:80:5a:40:ac:27:ed:48:47:33:b0:54:c6:46: > > 1a:f3:35:61:c1:02:29:90:54:7e:64:4d:c4:30:52: > > 02:82:d7:df:ce:21:6e:18:91:d7:b8:ab:8c:27:17: > > b5:f0:a3:01:2f:8e:d2:2e:87:3a:3d:b4:29:67:8a: > > c4:03 > > Exponent: 65537 (0x10001) > > X509v3 extensions: > > X509v3 Basic Constraints: critical > > CA:TRUE, pathlen:0 > > X509v3 Key Usage: critical > > Certificate Sign, CRL Sign > > X509v3 Subject Key Identifier: > > 11:DB:23:45:FD:54:CC:6A:71:6F:84:8A:03:D7:BE:F7:01:2F:26:86 > > X509v3 Authority Key Identifier: > > > keyid:4E:0B:EF:1A:A4:40:5B:A5:17:69:87:30:CA:34:68:43:D0:41:AE:F2 > > > > Authority Information Access: > > OCSP - URI:http://ocsp.startssl.com/ca > > CA Issuers - URI:http://aia.startssl.com/certs/ca.crt > > > > X509v3 CRL Distribution Points: > > > > Full Name: > > URI:http://crl.startssl.com/sfsca.crl > > > > X509v3 Certificate Policies: > > Policy: X509v3 Any Policy > > CPS: http://www.startssl.com/policy.pdf > > > > Signature Algorithm: sha256WithRSAEncryption > > 52:c9:bd:f3:bd:cb:f9:eb:a2:c4:32:ca:86:72:fc:cf:bf:a7: > > 30:b5:fd:91:f7:d5:81:e1:21:04:ad:00:4c:ff:e9:8b:27:da: > > ff:f2:24:cd:fc:1f:0f:7f:d2:d1:e5:81:92:23:78:16:ee:6b: > > 03:2e:9d:00:48:4f:ae:82:65:2e:87:6f:ee:6a:07:5f:4b:56: > > 6e:f7:96:46:41:e6:dd:fe:45:b9:62:2a:9a:8a:76:e9:ad:bd: > > d6:73:b3:bc:31:2b:d0:2c:d5:6c:6b:bc:6a:3a:25:87:a9:a8: > > a5:0d:d7:85:f1:6c:6c:05:0e:f4:c1:68:cb:bb:2a:81:58:a5: > > 3e:99:c4:9f:f7:1f:84:8e:a0:7a:d1:4d:db:b8:01:9c:0d:81: > > 34:ca:82:fe:23:62:4d:3f:6d:a4:52:c0:4c:5e:f2:69:48:b1: > > f2:df:ac:44:64:69:b0:46:29:c7:ad:f0:f2:c0:9d:68:23:8a: > > a8:67:71:22:17:be:ce:89:7a:76:be:54:6c:93:5c:8b:f0:1a: > > 6e:ae:ed:8e:ae:c2:05:ae:13:57:e6:b9:e7:70:c8:33:b8:9e: > > fd:4a:30:e3:98:d4:13:6b:ee:4e:b9:e6:ec:df:ce:ea:a0:9e: > > 76:6a:97:aa:ea:df:34:45:42:f5:da:4d:d6:87:76:6d:ff:ce: > > 69:86:7a:81:5f:db:b2:4f:ce:b0:e0:67:60:39:44:b0:45:10: > > 85:65:97:12:79:df:d4:97:d8:78:21:0c:84:98:ce:bb:4f:6b: > > 0f:19:da:85:69:91:41:6c:17:1c:c6:b9:f6:14:ae:f2:a1:80: > > 7a:e2:e9:95:ef:22:8a:cc:ff:38:db:fc:21:56:ec:80:fd:6d: > > a2:85:91:29:03:ea:ab:03:bd:2c:60:44:82:00:35:e7:14:6c: > > 76:3b:40:83:55:d5:5c:df:c7:28:a3:59:d5:89:78:3e:0f:e0: > > 06:fd:d5:57:8a:24:1c:a7:62:38:1d:85:93:4b:f9:93:7f:f3: > > 44:fa:63:98:9e:ed:26:89:9d:f6:fe:f8:43:6c:25:ff:07:f9: > > 12:3c:9e:11:b0:d3:80:ee:ec:ab:3b:0c:a4:72:03:92:14:36: > > e9:be:e6:8a:3a:91:8b:ad:0c:06:a8:b3:83:82:6f:a9:f5:36: > > 39:82:23:0c:8e:ea:fd:5c:7e:d3:4b:5c:33:d3:67:48:cf:4e: > > ee:cb:63:70:61:67:55:eb:bb:dc:9c:0b:7a:43:14:48:49:aa: > > 79:45:b6:8f:be:2c:90:67:1c:f8:9c:56:92:95:30:30:1e:83: > > da:5b:5c:ae:55:2d:75:b6:6b:11:38:c9:51:44:db:db:68:0c: > > 48:53:85:3a:ed:86:99:4b > > -----BEGIN CERTIFICATE----- > > MIIF2TCCA8GgAwIBAgIHHKs2Ry2cUTANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQG > > EwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp > > Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2Vy > > dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDE0MjA1NzA5WhcNMjIxMDE0MjA1 > > NzA5WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp > > BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV > > BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgU2VydmVy > > IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4k85L6GMmoWtCA4I > > PlfyiAEhG5SpbOK426oZGEY6UqH1D/RujOqWjJaHeRNAUS8i8gyLhw9l33F0NENV > > sTUJm9m8H/rrQtCXQHK3Q5Y9upadXVACHJuRjZzArNe7LxfXyz6CnXPrB0KSss1k > > s3RVG7RLhiEs93iHMuAW5Nq9TJXqpAp+tgoNLorPVavD5d1Bik7mb2VsskDPF125 > > w2oLJxGEd2H2wnztwI14FBiZgZl1Y7foU9O6YekO+qIw80aiuckfbIBaQKwn7UhH > > M7BUxkYa8zVhwQIpkFR+ZE3EMFICgtffziFuGJHXuKuMJxe18KMBL47SLoc6PbQp > > Z4rEAwIDAQABo4IBTDCCAUgwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8E > > BAMCAQYwHQYDVR0OBBYEFBHbI0X9VMxqcW+EigPXvvcBLyaGMB8GA1UdIwQYMBaA > > FE4L7xqkQFulF2mHMMo0aEPQQa7yMGkGCCsGAQUFBwEBBF0wWzAnBggrBgEFBQcw > > AYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMDAGCCsGAQUFBzAChiRodHRw > > Oi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwMgYDVR0fBCswKTAnoCWg > > I4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMEMGA1UdIAQ8MDow > > OAYEVR0gADAwMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9w > > b2xpY3kucGRmMA0GCSqGSIb3DQEBCwUAA4ICAQBSyb3zvcv566LEMsqGcvzPv6cw > > tf2R99WB4SEErQBM/+mLJ9r/8iTN/B8Pf9LR5YGSI3gW7msDLp0ASE+ugmUuh2/u > > agdfS1Zu95ZGQebd/kW5Yiqainbprb3Wc7O8MSvQLNVsa7xqOiWHqailDdeF8Wxs > > BQ70wWjLuyqBWKU+mcSf9x+EjqB60U3buAGcDYE0yoL+I2JNP22kUsBMXvJpSLHy > > 36xEZGmwRinHrfDywJ1oI4qoZ3EiF77OiXp2vlRsk1yL8Bpuru2OrsIFrhNX5rnn > > cMgzuJ79SjDjmNQTa+5Ouebs387qoJ52apeq6t80RUL12k3Wh3Zt/85phnqBX9uy > > T86w4GdgOUSwRRCFZZcSed/Ul9h4IQyEmM67T2sPGdqFaZFBbBccxrn2FK7yoYB6 > > 4umV7yKKzP842/whVuyA/W2ihZEpA+qrA70sYESCADXnFGx2O0CDVdVc38coo1nV > > iXg+D+AG/dVXiiQcp2I4HYWTS/mTf/NE+mOYnu0miZ32/vhDbCX/B/kSPJ4RsNOA > > 7uyrOwykcgOSFDbpvuaKOpGLrQwGqLODgm+p9TY5giMMjur9XH7TS1wz02dIz07u > > y2NwYWdV67vcnAt6QxRISap5RbaPviyQZxz4nFaSlTAwHoPaW1yuVS11tmsROMlR > > RNvbaAxIU4U67YaZSw== > > -----END CERTIFICATE----- > > > > -- > > Viktor. > > > > -- > > 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 Dec 18 22:08:00 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 18 Dec 2016 17:08:00 -0500 Subject: [openssl-users] Problem with certificate check when it does not match CN In-Reply-To: References: Message-ID: <0EFEA7FA-4B7E-44F8-B52C-248D1F13A13F@dukhovni.org> > On Dec 18, 2016, at 4:52 PM, Brice Andr? wrote: > > I know that the current certificate is the old one, but this > is because my service is in production. > > I tested new certificate this evening to limit the number of > impacted clients. And as it did not worked, i reinstalled > previous certificate waiting a solution for the new one. > > If it may help, i can install the new cerrificate on a > test site. Either that, or post a problem report that contains detailed technical information, rather than a hand-waving story. What version of OpenSSL are you using? What O/S platform? What certificate stores did you configure in your OpenSSL client. Which pertinent certificates (post these) did you ensure are contained in that store. What certificate chain is returned by the server? Post the output of: $ (sleep 2; exit) | openssl s_client -showcerts -connect : 2>&1 | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -print_certs | tee chain.pem Copy the trusted roots into a file named trusted.pem, then make sure the server's chain validates: $ openssl verify -trusted trusted.pem -untrusted chain.pem chain.pem (post the output...). [ By the way, your problem is not a bug in DNS subjectAltName processing in OpenSSL. Either your server configuration or client code is in error, if you present sufficient detail, it will be possible to help you determine which. ] -- Viktor. From openssl-users at dukhovni.org Sun Dec 18 22:09:58 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 18 Dec 2016 17:09:58 -0500 Subject: [openssl-users] big endian vs little endian In-Reply-To: <5856E9BE.1070203@mathemainzel.info> References: <71b0754e261f4fd9a8074d487c5cfe04@usma1ex-dag1mb1.msg.corp.akamai.com> <1482078090341-69377.post@n7.nabble.com> <5856E9BE.1070203@mathemainzel.info> Message-ID: <01609A5D-F917-41B7-9DC2-4C5F72F51BCC@dukhovni.org> > On Dec 18, 2016, at 2:55 PM, Walter H. via openssl-users wrote: > > encrypt > openssl enc -e -in file -out encryptfile -aes-256-gcm GCM is not supported with "openssl enc(1)". Use a CBC cipher instead. -- Viktor. From jeremy.farrell at oracle.com Mon Dec 19 01:57:56 2016 From: jeremy.farrell at oracle.com (Jeremy Farrell) Date: Mon, 19 Dec 2016 01:57:56 +0000 Subject: [openssl-users] big endian vs little endian In-Reply-To: <1482078090341-69377.post@n7.nabble.com> References: <71b0754e261f4fd9a8074d487c5cfe04@usma1ex-dag1mb1.msg.corp.akamai.com> <1482078090341-69377.post@n7.nabble.com> Message-ID: On 18/12/2016 16:21, sahorwitz wrote: > I am obviosly a newbie and missing something. How then do I encrypt the file > on one machine (little endian), transmit it to another machine (big endian) > and decrypt it there? What problem are you actually seeing? In what way does the decryption fail on the destination machine? Please include the commands you are using in the problem scenario, and any messages put out by the commands. The endianness of the machines isn't relevant. -- J. J. Farrell Not speaking for Oracle -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Mon Dec 19 02:09:52 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 18 Dec 2016 21:09:52 -0500 Subject: [openssl-users] big endian vs little endian In-Reply-To: <01609A5D-F917-41B7-9DC2-4C5F72F51BCC@dukhovni.org> References: <71b0754e261f4fd9a8074d487c5cfe04@usma1ex-dag1mb1.msg.corp.akamai.com> <1482078090341-69377.post@n7.nabble.com> <5856E9BE.1070203@mathemainzel.info> <01609A5D-F917-41B7-9DC2-4C5F72F51BCC@dukhovni.org> Message-ID: On Sun, Dec 18, 2016 at 5:09 PM, Viktor Dukhovni wrote: > >> On Dec 18, 2016, at 2:55 PM, Walter H. via openssl-users wrote: >> >> encrypt >> openssl enc -e -in file -out encryptfile -aes-256-gcm > > GCM is not supported with "openssl enc(1)". Use a CBC cipher > instead. +1. This was late to be documented, but its available at (https://www.openssl.org/docs/man1.0.2/apps/enc.html): "The enc program does not support authenticated encryption modes like CCM and GCM. The utility does not store or retrieve the authentication tag." Maybe the encrypt program should throw an error rather than producing incorrect results without a warning. From brice at famille-andre.be Mon Dec 19 07:12:04 2016 From: brice at famille-andre.be (=?UTF-8?B?QnJpY2UgQW5kcsOp?=) Date: Mon, 19 Dec 2016 08:12:04 +0100 Subject: [openssl-users] Problem with certificate check when it does not match CN In-Reply-To: <0EFEA7FA-4B7E-44F8-B52C-248D1F13A13F@dukhovni.org> References: <0EFEA7FA-4B7E-44F8-B52C-248D1F13A13F@dukhovni.org> Message-ID: Dear Viktor, Once again, thanks for your help. I quickly setup a test server with new certificate. URL is the following : https://test.online-rdv.be/demo Soap is used for both website and self-written C++ application. You can test soap directly with the provided link : enter a username and password (whatever it is) and you will see a soap request to urls https://test.online-rdv.be/v1/soap/public/ and another one to https://test.online-rdv.be/v1/soap/user/ Both are accepted by web browsers. So, my best guess is that my server is properly configured. On self-written client side, I use C++ code whose soap part is generated by gsoap. You will find attached the generated code, as well as the wrapper that I wrote and that uses the generated code). I also use openssl (1.0.1j 15 Oct 2014). The bundle containing the root certificates is quite large because my application performs several SSL access, but I added the certificates that I copy-pasted here below, which, at my best knowledge,should be enough for my certificate: If it may be useful, I can write a small test program that performs only the soap request instead of providing parts of code. Many thanks for your help, Brice Comodo certification chain ========================== -----BEGIN CERTIFICATE----- MIIGCDCCA/CgAwIBAgIQKy5u6tl1NmwUim7bo3yMBzANBgkqhkiG9w0BAQwFADCB hTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNV BAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTQwMjEy MDAwMDAwWhcNMjkwMjExMjM1OTU5WjCBkDELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxNjA0BgNVBAMTLUNPTU9ETyBSU0EgRG9tYWluIFZh bGlkYXRpb24gU2VjdXJlIFNlcnZlciBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAI7CAhnhoFmk6zg1jSz9AdDTScBkxwtiBUUWOqigwAwCfx3M28Sh bXcDow+G+eMGnD4LgYqbSRutA776S9uMIO3Vzl5ljj4Nr0zCsLdFXlIvNN5IJGS0 Qa4Al/e+Z96e0HqnU4A7fK31llVvl0cKfIWLIpeNs4TgllfQcBhglo/uLQeTnaG6 ytHNe+nEKpooIZFNb5JPJaXyejXdJtxGpdCsWTWM/06RQ1A/WZMebFEh7lgUq/51 UHg+TLAchhP6a5i84DuUHoVS3AOTJBhuyydRReZw3iVDpA3hSqXttn7IzW3uLh0n c13cRTCAquOyQQuvvUSH2rnlG51/ruWFgqUCAwEAAaOCAWUwggFhMB8GA1UdIwQY MBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSQr2o6lFoL2JDqElZz 30O0Oija5zAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNV HSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwGwYDVR0gBBQwEjAGBgRVHSAAMAgG BmeBDAECATBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNv bS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcB AQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9E T1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21v ZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAE4rdk+SHGI2ibp3wScF9BzWRJ2p mj6q1WZmAT7qSeaiNbz69t2Vjpk1mA42GHWx3d1Qcnyu3HeIzg/3kCDKo2cuH1Z/ e+FE6kKVxF0NAVBGFfKBiVlsit2M8RKhjTpCipj4SzR7JzsItG8kO3KdY3RYPBps P0/HEZrIqPW1N+8QRcZs2eBelSaz662jue5/DJpmNXMyYE7l3YphLG5SEXdoltMY dVEVABt0iN3hxzgEQyjpFv3ZBdRdRydg1vs4O2xyopT4Qhrf7W8GjEXCBgCq5Ojc 2bXhc3js9iPc0d1sjhqPpepUfJa3w/5Vjo1JXvxku88+vZbrac2/4EjxYoIQ5QxG V/Iz2tDIY+3GH5QFlkoakdH368+PUq4NCNk+qKBR6cGHdNXJ93SrLlP7u3r7l+L4 HyaPs9Kg4DdbKDsx5Q5XLVq4rXmsXiBmGqW5prU5wfWYQ//u+aen/e7KJD2AFsQX j4rBYKEMrltDR5FL1ZoXX/nUh8HCjLfn4g8wGTeGrODcQgPmlKidrv0PJFGUzpII 0fxQ8ANAe4hZ7Q7drNJ3gjTcBpUC2JD5Leo31Rpg0Gcg19hCC0Wvgmje3WYkN5Ap lBlGGSW4gNfL1IYoakRwJiNiqZ+Gb7+6kHDSVneFeO/qJakXzlByjAA6quPbYzSf +AZxAeKCINT+b72x -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIFdDCCBFygAwIBAgIQJ2buVutJ846r13Ci/ITeIjANBgkqhkiG9w0BAQwFADBv MQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFk ZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBF eHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFow gYUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYD VQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIICIjANBgkq hkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAkehUktIKVrGsDSTdxc9EZ3SZKzejfSNw AHG8U9/E+ioSj0t/EFa9n3Byt2F/yUsPF6c947AEYe7/EZfH9IY+Cvo+XPmT5jR6 2RRr55yzhaCCenavcZDX7P0N+pxs+t+wgvQUfvm+xKYvT3+Zf7X8Z0NyvQwA1onr ayzT7Y+YHBSrfuXjbvzYqOSSJNpDa2K4Vf3qwbxstovzDo2a5JtsaZn4eEgwRdWt 4Q08RWD8MpZRJ7xnw8outmvqRsfHIKCxH2XeSAi6pE6p8oNGN4Tr6MyBSENnTnIq m1y9TBsoilwie7SrmNnu4FGDwwlGTm0+mfqVF9p8M1dBPI1R7Qu2XK8sYxrfV8g/ vOldxJuvRZnio1oktLqpVj3Pb6r/SVi+8Kj/9Lit6Tf7urj0Czr56ENCHonYhMsT 8dm74YlguIwoVqwUHZwK53Hrzw7dPamWoUi9PPevtQ0iTMARgexWO/bTouJbt7IE IlKVgJNp6I5MZfGRAy1wdALqi2cVKWlSArvX31BqVUa/oKMoYX9w0MOiqiwhqkfO KJwGRXa/ghgntNWutMtQ5mv0TIZxMOmm3xaG4Nj/QN370EKIf6MzOi5cHkERgWPO GHFrK+ymircxXDpqR+DDeVnWIBqv8mqYqnK8V0rSS527EPywTEHl7R09XiidnMy/ s1Hap0flhFMCAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUu69+Aj36pvE8hI6t7jiY7NkyMtQwDgYDVR0PAQH/BAQD AgGGMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEQGA1UdHwQ9 MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVy bmFsQ0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6 Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggEBAGS/g/FfmoXQ zbihKVcN6Fr30ek+8nYEbvFScLsePP9NDXRqzIGCJdPDoCpdTPW6i6FtxFQJdcfj Jw5dhHk3QBN39bSsHNA7qxcS1u80GH4r6XnTq1dFDK8o+tDb5VCViLvfhVdpfZLY Uspzgb8c8+a4bmYRBbMelC1/kZWSWfFMzqORcUx8Rww7Cxn2obFshj5cqsQugsv5 B5a6SE2Q8pTIqXOi6wZ7I53eovNNVZ96YUWYGGjHXkBrI/V5eu+MtWuLt29G9Hvx PUsE2JOAWVrgQSQdso8VYFhH2+9uRv0V9dlfmrPb2LjkQLPNlzmuhbsdjrzch5vR pu/xO28QOG8= -----END CERTIFICATE----- 2016-12-18 23:08 GMT+01:00 Viktor Dukhovni : > > > On Dec 18, 2016, at 4:52 PM, Brice Andr? wrote: > > > > I know that the current certificate is the old one, but this > > is because my service is in production. > > > > I tested new certificate this evening to limit the number of > > impacted clients. And as it did not worked, i reinstalled > > previous certificate waiting a solution for the new one. > > > > If it may help, i can install the new cerrificate on a > > test site. > > Either that, or post a problem report that contains detailed > technical information, rather than a hand-waving story. > > What version of OpenSSL are you using? What O/S platform? > What certificate stores did you configure in your OpenSSL > client. Which pertinent certificates (post these) did you > ensure are contained in that store. > > What certificate chain is returned by the server? > Post the output of: > > $ (sleep 2; exit) | > openssl s_client -showcerts -connect : 2>&1 | > openssl crl2pkcs7 -nocrl -certfile /dev/stdin | > openssl pkcs7 -print_certs | tee chain.pem > > Copy the trusted roots into a file named trusted.pem, then > make sure the server's chain validates: > > $ openssl verify -trusted trusted.pem -untrusted chain.pem chain.pem > > (post the output...). [ By the way, your problem is not a bug in DNS > subjectAltName processing in OpenSSL. Either your server configuration > or client code is in error, if you present sufficient detail, it will > be possible to help you determine which. ] > > -- > Viktor. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: soap.zip Type: application/zip Size: 48318 bytes Desc: not available URL: From andy at warmcat.com Mon Dec 19 11:22:15 2016 From: andy at warmcat.com (Andy Green) Date: Mon, 19 Dec 2016 19:22:15 +0800 Subject: [openssl-users] General approach for keeping a client cert from openssl Message-ID: <1482146535.10687.23.camel@warmcat.com> Hi - I have a situation coming up that is similar to a client cert being held on a secure key store, like a key vault. We need to be able to perform TLS communication with a remote server using the key, but without giving the key to OpenSSL. The "other side" of the "key vault" is smart, and we can run code there, and communicate with it. So we need to basically proxy OpenSSL operations on the "other side". I guess this is nothing new under the sun... what's the general approach to integrating this to OpenSSL? Thanks for any advice. -Andy From openssl-users at dukhovni.org Mon Dec 19 16:51:35 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 19 Dec 2016 11:51:35 -0500 Subject: [openssl-users] Problem with certificate check when it does not match CN In-Reply-To: References: <0EFEA7FA-4B7E-44F8-B52C-248D1F13A13F@dukhovni.org> Message-ID: <5E7DD7BF-7A19-4F34-BC69-051DA4E6F166@dukhovni.org> > On Dec 19, 2016, at 2:12 AM, Brice Andr? wrote: > > On self-written client side, I use C++ code whose soap part is generated by gsoap. You will find attached the generated code, as well as the wrapper that I wrote and that uses the generated code). I also use openssl (1.0.1j 15 Oct 2014). OpenSSL 1.0.1j has no built-in name checks. It only verifies the validity of the trust chain, and leaves matching of the server name to the names in the certificate up to the application. (OpenSSL 1.0.2 added support for built-in name checks, but these still have to be enabled by the application). Therefore, your guesses about the CN vs. subjectAltName wildcards are not pertinent. The presented certificate chain is fine, and validates with OpenSSL 1.0.1 (which is End-Of-Life in a few days, you really should be using 1.0.2) against the below root CA: -----BEGIN CERTIFICATE----- MIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFs IFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9v dDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTngTlvt H7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9 uMq/NzgtHj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzX mk6vBbOmcZSccbNQYArHE504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LX a0Tkx63ubUFfclpxCDezeWWkWaCUN/cALw3CknLa0Dhy2xSoRcRdKn23tNbE7qzN E0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3CitlttNCbxWyuHv77+ldU9U0 WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTLVBowCwYD VR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0 Jvf6xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRU cnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcN AQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5gdkeWxQHIzZlj7DYd7usQWxH YINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKWt9x+Tu5w/Rw5 6wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEX c4g/VhsxOBi0cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5a mnkPIAou1Z5jJh5VkpTYghdae9C8x49OhgQ= -----END CERTIFICATE----- Your Zip file contains no calls to the OpenSSL library, if your SOAP toolkit is failing to connect to your server, you'll have to pursue that with whoever supports that toolkit. -- Viktor. From aerowolf at gmail.com Mon Dec 19 18:21:08 2016 From: aerowolf at gmail.com (Kyle Hamilton) Date: Mon, 19 Dec 2016 10:21:08 -0800 Subject: [openssl-users] General approach for keeping a client cert from openssl In-Reply-To: <1482146535.10687.23.camel@warmcat.com> References: <1482146535.10687.23.camel@warmcat.com> Message-ID: You cannot keep the certificate from OpenSSL, as that's the piece that you share with the remote side. This contains the public key, and the information bound to that public key by the CA. However, you can keep the private key from being seen by OpenSSL. There exists what is called an ENGINE interface to offload cryptographic operations to a container. Right now, https://wiki.openssl.org/index.php/Creating_an_OpenSSL_Engine_to_use_indigenous_ECDH_ECDSA_and_HASH_Algorithms seems to be the best documentation available to explain the process of creating it. Obviously, depending on the type of key you're using, you will probably need to figure out the differences. -Kyle H On Mon, Dec 19, 2016 at 3:22 AM, Andy Green wrote: > Hi - > > I have a situation coming up that is similar to a client cert being > held on a secure key store, like a key vault. > > We need to be able to perform TLS communication with a remote server > using the key, but without giving the key to OpenSSL. > > The "other side" of the "key vault" is smart, and we can run code > there, and communicate with it. So we need to basically proxy OpenSSL > operations on the "other side". > > I guess this is nothing new under the sun... what's the general > approach to integrating this to OpenSSL? > > Thanks for any advice. > > -Andy > -- > 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 Mon Dec 19 19:10:31 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 19 Dec 2016 19:10:31 +0000 Subject: [openssl-users] Setting tlsext_hb_pending in OpenSSL 1.1.x In-Reply-To: References: Message-ID: <923de9890901486d96530ae2bb8dc3d8@usma1ex-dag1mb1.msg.corp.akamai.com> > Basically, the SSL structure used to contain tlsext_hb_pending variable. After > looking up, I found out there is now a function to get the value of 'pending'. > What I need is to set the value. How can I do that now with 1.1.x? It seems that when the structures were made opaque, we didn't realize that a settor was needed. Please open an issue for this. Or better, a pull request that also includes the doc update :) We can then much more easily put it in 1.1.0 and master. Missing acessors/settors are bugfixes. As for checking which version of openssl, see OPENSSL_VERSION #define. From andy at warmcat.com Tue Dec 20 00:03:14 2016 From: andy at warmcat.com (Andy Green) Date: Tue, 20 Dec 2016 08:03:14 +0800 Subject: [openssl-users] General approach for keeping a client cert from openssl In-Reply-To: References: <1482146535.10687.23.camel@warmcat.com> Message-ID: <1482192194.10687.29.camel@warmcat.com> On Mon, 2016-12-19 at 10:21 -0800, Kyle Hamilton wrote: > You cannot keep the certificate from OpenSSL, as that's the piece > that you share with the remote side.? This contains the public key, > and the information bound to that public key by the CA. Right. > However, you can keep the private key from being seen by OpenSSL. Yes, this is the game. > ? There exists what is called an ENGINE interface to offload > cryptographic operations to a container.? Right now, > https://wiki.openssl.org/index.php/Creating_an_OpenSSL_Engine_to_use_ > indigenous_ECDH_ECDSA_and_HASH_Algorithms seems to be the best > documentation available to explain the process of creating it.? Thanks, I will start with that and try to understand it better. > Obviously, depending on the type of key you're using, you will > probably need to figure out the differences. Yes, it seems it's basically overloading one or more crypto action, so we need to match the action to what it wants to do with the cert key. But I guess to get started, we can do what we have code for. Thanks again I will study it. -Andy > -Kyle H > > On Mon, Dec 19, 2016 at 3:22 AM, Andy Green wrote: > > Hi - > > > > I have a situation coming up that is similar to a client cert being > > held on a secure key store, like a key vault. > > > > We need to be able to perform TLS communication with a remote > > server > > using the key, but without giving the key to OpenSSL. > > > > The "other side" of the "key vault" is smart, and we can run code > > there, and communicate with it.? So we need to basically proxy > > OpenSSL > > operations on the "other side". > > > > I guess this is nothing new under the sun... what's the general > > approach to integrating this to OpenSSL? > > > > Thanks for any advice. > > > > -Andy > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-us > > ers > > > > From Michael.Wojcik at microfocus.com Tue Dec 20 12:29:00 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 20 Dec 2016 12:29:00 +0000 Subject: [openssl-users] General approach for keeping a client cert from openssl In-Reply-To: <1482192194.10687.29.camel@warmcat.com> References: <1482146535.10687.23.camel@warmcat.com> <1482192194.10687.29.camel@warmcat.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Andy Green > Sent: Monday, December 19, 2016 19:03 > > On Mon, 2016-12-19 at 10:21 -0800, Kyle Hamilton wrote: > > > ? There exists what is called an ENGINE interface to offload > > cryptographic operations to a container.? Right now, >> https://wiki.openssl.org/index.php/Creating_an_OpenSSL_Engine_to_use_ > > indigenous_ECDH_ECDSA_and_HASH_Algorithms seems to be the best > > documentation available to explain the process of creating it. > > Thanks, I will start with that and try to understand it better. Note that there's already an ENGINE implementation for PKCS#11, so if your hardware supports that you may be able to simply use that code. If not, then 1) why doesn't it (providing the standard API is generally a good idea), but 2) it may be a useful model. Michael Wojcik Distinguished Engineer, Micro Focus From rsalz at akamai.com Tue Dec 20 17:16:06 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 20 Dec 2016 17:16:06 +0000 Subject: [openssl-users] big endian vs little endian In-Reply-To: <1482078090341-69377.post@n7.nabble.com> References: <71b0754e261f4fd9a8074d487c5cfe04@usma1ex-dag1mb1.msg.corp.akamai.com> <1482078090341-69377.post@n7.nabble.com> Message-ID: > I am obviosly a newbie and missing something. How then do I encrypt the file > on one machine (little endian), transmit it to another machine (big endian) > and decrypt it there? Did you try it? From goldim at gmail.com Tue Dec 20 18:09:54 2016 From: goldim at gmail.com (Leo Goldim) Date: Tue, 20 Dec 2016 16:09:54 -0200 Subject: [openssl-users] Compile OpenSSL for Android Message-ID: Hi all, I'm trying to compile OpenSSL for Android, after looking at Google I found this page: https://wiki.openssl.org/index.php/Android I followed step by step but when I verified my lib (readelf -h ./libcrypto.a | grep -i 'class\|machine' | head -2) I realized that the lib was created for my machine (x86_64) not Android (arm). So, I changed the configure command to: ./Configure android --openssldir=/home/ec2-user/android-openssl/android-12 And I got the following error: make[2]: Entering directory `/home/ec2-user/android-openssl/openssl-1.1.0c' LD_LIBRARY_PATH=: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSLDIR="/home/ec2-user/android-openssl/android-12" -DENGINESDIR="/usr/local/lib/engines-1.1" -Wall -O3 -pthread -mandroid -fPIC --sysroot= -Wa,--noexecstack -fPIC -DOPENSSL_USE_NODELETE -Wl,-znodelete -shared -Wl,-Bsymbolic -Wl,-soname=libcrypto.so.1.1 -o ./libcrypto.so.1.1 -Wl,--whole-archive,--version-script=crypto.map ./libcrypto.a -Wl,--no-whole-archive -ldl /usr/bin/ld: cannot find crtbegin_so.o: No such file or directory collect2: error: ld returned 1 exit status make[2]: *** [link_shlib.linux-shared] Error 1 make[2]: Leaving directory `/home/ec2-user/android-openssl/openssl-1.1.0c' make[1]: *** [libcrypto.so] Error 2 make[1]: Leaving directory `/home/ec2-user/android-openssl/openssl-1.1.0c' make: *** [all] Error 2 Someone already compiled the OpenSSL version 1.1.0c for Android and can help me? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl.org at 18informatique.com Wed Dec 21 15:07:06 2016 From: openssl.org at 18informatique.com (mlrx) Date: Wed, 21 Dec 2016 16:07:06 +0100 Subject: [openssl-users] stronger Kex Message-ID: <7b0a0592-9820-f334-01c6-8109469f0fd6@18informatique.com> Hello, I have two servers for testing purpose : - debian 6, apache 2.2, openssl 1.0.1t (mutu) - centos 7, apache 2.4.6, openssl 1.0.1e-fips (dedicated) Now, these 2 serveurs offers only those ciphers : TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) I have two goals. First, I would like to use at least secp384r1 and second (no problem), use an ECC certificate. Is it possible to do it with CHACHA20-POLY1305 ? Is it possible to use this cipher on those servers ? openssl ciphers -V CHACHA20 return an error on each server. I understand it's because there is no chacha20 cipher (?). Why can I connect a server by SSH with chacha20-poly1305 at openssh.com and not using it with Apache ? All advices are welcome :-). Best regards, -- benoist From horwitz at argoscomp.com Wed Dec 21 17:23:47 2016 From: horwitz at argoscomp.com (Sam Horwitz) Date: Wed, 21 Dec 2016 17:23:47 +0000 Subject: [openssl-users] big endian vs little endian In-Reply-To: References: <71b0754e261f4fd9a8074d487c5cfe04@usma1ex-dag1mb1.msg.corp.akamai.com> <1482078090341-69377.post@n7.nabble.com> Message-ID: Yes. Thanks you it works. My stupid. -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich Sent: Tuesday, December 20, 2016 12:16 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] big endian vs little endian > I am obviosly a newbie and missing something. How then do I encrypt > the file on one machine (little endian), transmit it to another > machine (big endian) and decrypt it there? Did you try it? -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From goldim at gmail.com Wed Dec 21 23:06:08 2016 From: goldim at gmail.com (Leo Goldim) Date: Wed, 21 Dec 2016 21:06:08 -0200 Subject: [openssl-users] Compile OpenSSL for Android In-Reply-To: References: Message-ID: Hey all, I finally compiled the OpenSSL for Android, the problem was with the Setenv-android.sh scritp. After fixed it I can compile using the following command line: ./config shared no-ssl2 no-ssl3 no-comp no-hw no-engine --openssldir=/home/ec2-user/android-openssl/android-12 --prefix=/home/ec2-user/android-openssl/android-12 With OpenSSL 1.1.0c, if I use only --openssldir the make install mess with my system libs. I have to use --prefix together to install in a different path. But, now I'm trying to compile another program, using the OpenSSL compiled lib, and I'm getting the following message: checking openssl/ssl.h usability... yes checking openssl/ssl.h presence... yes checking for openssl/ssl.h... yes checking for library containing SSL_library_init... no configure: error: libfko needs ssl Is it a problem with the compiled OpenSSL lib? Thanks On Tue, Dec 20, 2016 at 4:09 PM, Leo Goldim wrote: > Hi all, > > I'm trying to compile OpenSSL for Android, after looking at Google I found > this page: > > https://wiki.openssl.org/index.php/Android > > I followed step by step but when I verified my lib (readelf -h > ./libcrypto.a | grep -i 'class\|machine' | head -2) I realized that the lib > was created for my machine (x86_64) not Android (arm). > > So, I changed the configure command to: > > ./Configure android --openssldir=/home/ec2-user/android-openssl/android-12 > > And I got the following error: > > make[2]: Entering directory `/home/ec2-user/android- > openssl/openssl-1.1.0c' > LD_LIBRARY_PATH=: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG > -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC > -DOPENSSLDIR="/home/ec2-user/android-openssl/android-12" > -DENGINESDIR="/usr/local/lib/engines-1.1" -Wall -O3 -pthread -mandroid > -fPIC --sysroot= -Wa,--noexecstack -fPIC -DOPENSSL_USE_NODELETE > -Wl,-znodelete -shared -Wl,-Bsymbolic -Wl,-soname=libcrypto.so.1.1 -o > ./libcrypto.so.1.1 -Wl,--whole-archive,--version-script=crypto.map > ./libcrypto.a -Wl,--no-whole-archive -ldl > /usr/bin/ld: cannot find crtbegin_so.o: No such file or directory > collect2: error: ld returned 1 exit status > make[2]: *** [link_shlib.linux-shared] Error 1 > make[2]: Leaving directory `/home/ec2-user/android-openssl/openssl-1.1.0c' > make[1]: *** [libcrypto.so] Error 2 > make[1]: Leaving directory `/home/ec2-user/android-openssl/openssl-1.1.0c' > make: *** [all] Error 2 > > Someone already compiled the OpenSSL version 1.1.0c for Android and can > help me? > > Thanks > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Dec 21 23:16:58 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 21 Dec 2016 23:16:58 +0000 Subject: [openssl-users] Compile OpenSSL for Android In-Reply-To: References: Message-ID: > checking for library containing SSL_library_init... no > configure: error: libfko needs ssl The application is not prepared to build against 1.1.0 That function was removed, and a #define for backward compatibility is used instead. From noloader at gmail.com Wed Dec 21 23:54:43 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 21 Dec 2016 18:54:43 -0500 Subject: [openssl-users] Compile OpenSSL for Android In-Reply-To: References: Message-ID: On Wed, Dec 21, 2016 at 6:16 PM, Salz, Rich wrote: >> checking for library containing SSL_library_init... no >> configure: error: libfko needs ssl > > The application is not prepared to build against 1.1.0 That function was removed, and a #define for backward compatibility is used instead. > Also see https://wiki.openssl.org/index.php/Compilation_and_Installation#Autoconf . Its another way to address the "SSL_library_init symbol or OPENSSL_init_ssl symbol" issue. The missing 1.1.0 code paths will need to be added. The compiler will tell you where most of the problems are. Jeff From fuckspam at wheres5.com Thu Dec 22 10:30:12 2016 From: fuckspam at wheres5.com (Hoggins!) Date: Thu, 22 Dec 2016 11:30:12 +0100 Subject: [openssl-users] Unable to STARTTLS behind a specific network Message-ID: Hello there, First post here, I would like to know how it's possible to debug a certain problem I have. Behind a specific network, I'm unable to bootstrap a STARTTLS session on an SMTP server. Usually, it works flawlessly. So my request for help is not to try to change anything to the configuration (I'm not in charge of this network) but to confirm that there is a "problem" in between on that network that prevents the transaction from being conducted. So what I do is : $ openssl s_client -starttls smtp -crlf -connect newdude.radiom.fr:5000 No problem, I can communicate with the SMTP server after the STARTTLS occurred. But behind that specific network, if I run the same command, all I get is : CONNECTED(00000003) write:errno=104 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 351 bytes and written 147 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- When I compare two tcpdumps, I can clearly see that a lot of data is missing, the transaction is not complete. Before being paranoid, I simply suspect a MTU problem, but I'm not sure how this would only apply to SSL transactions. Should I provide tcpdumps or anything else ? Thank you ! Hoggins! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From rsalz at akamai.com Thu Dec 22 14:22:29 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 22 Dec 2016 14:22:29 +0000 Subject: [openssl-users] Unable to STARTTLS behind a specific network In-Reply-To: References: Message-ID: Well, the fact that it fails is confirmation :) > But behind that specific network, if I run the same command, all I get is : > > CONNECTED(00000003) > write:errno=104 Most likely there is a middlebox filtering traffic and closing the connection. Try an older protocol version, like -ssl3 or something. From rsalz at akamai.com Thu Dec 22 14:24:07 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 22 Dec 2016 14:24:07 +0000 Subject: [openssl-users] Unable to STARTTLS behind a specific network In-Reply-To: References: Message-ID: <7b1bd2f3d8bc43a98197547d0efa54de@usma1ex-dag1mb1.msg.corp.akamai.com> > Well, the fact that it fails is confirmation :) > > > But behind that specific network, if I run the same command, all I get is : > > > > CONNECTED(00000003) > > write:errno=104 > > Most likely there is a middlebox filtering traffic and closing the connection. > Try an older protocol version, like -ssl3 or something. Errno104 is usually "connection reset by peer" which means that the other side said "go away" From openssl-users at dukhovni.org Thu Dec 22 16:58:34 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 22 Dec 2016 11:58:34 -0500 Subject: [openssl-users] Unable to STARTTLS behind a specific network In-Reply-To: References: Message-ID: <79CF82E2-EB40-454A-8032-E4B1B2BC2271@dukhovni.org> > On Dec 22, 2016, at 5:30 AM, Hoggins! wrote: > > So what I do is : > > $ openssl s_client -starttls smtp -crlf -connect newdude.radiom.fr:5000 This (well essentially this, but with the Postfix "posttls-finger" utility) works for me from my MTA host: $ posttls-finger -d sha512 "[newdude.radiom.fr]:5000" posttls-finger: using DANE RR: _5000._tcp.newdude.radiom.fr IN TLSA 3 0 2 95:6D:5F:68:4A:65:07:55:53:7D:14:02:2C:23:F4:A2:CD:5B:93:AC:86:94:E2:D5:16:26:21:24:B7:A9:06:E3:E1:E6:61:77:DF:60:6E:98:9E:36:9F:BA:23:11:CA:F9:53:99:79:73:0C:D9:D5:10:DF:73:92:52:60:B5:EA:12 posttls-finger: Connected to newdude.radiom.fr[188.165.117.231]:5000 posttls-finger: < 220 newdude.radiom.fr ESMTP Sendmail 8.15.2/8.15.2; Thu, 22 Dec 2016 17:54:11 +0100 posttls-finger: > EHLO mournblade.imrryr.org posttls-finger: < 250-newdude.radiom.fr Hello mournblade.imrryr.org [38.117.134.19], pleased to meet you posttls-finger: < 250-ENHANCEDSTATUSCODES posttls-finger: < 250-PIPELINING posttls-finger: < 250-8BITMIME posttls-finger: < 250-SIZE posttls-finger: < 250-DSN posttls-finger: < 250-ETRN posttls-finger: < 250-AUTH GSSAPI LOGIN PLAIN posttls-finger: < 250-STARTTLS posttls-finger: < 250-DELIVERBY posttls-finger: < 250 HELP posttls-finger: > STARTTLS posttls-finger: < 220 2.0.0 Ready to start TLS posttls-finger: newdude.radiom.fr[188.165.117.231]:5000: depth=0 matched end entity certificate sha512 digest 95:6D:5F:68:4A:65:07:55:53:7D:14:02:2C:23:F4:A2:CD:5B:93:AC:86:94:E2:D5:16:26:21:24:B7:A9:06:E3:E1:E6:61:77:DF:60:6E:98:9E:36:9F:BA:23:11:CA:F9:53:99:79:73:0C:D9:D5:10:DF:73:92:52:60:B5:EA:12 posttls-finger: newdude.radiom.fr[188.165.117.231]:5000: Matched subjectAltName: *.radiom.fr posttls-finger: newdude.radiom.fr[188.165.117.231]:5000: subjectAltName: radiom.fr posttls-finger: newdude.radiom.fr[188.165.117.231]:5000 CommonName *.radiom.fr posttls-finger: newdude.radiom.fr[188.165.117.231]:5000: subject_CN=*.radiom.fr, issuer_CN=StartCom Class 2 Primary Intermediate Server CA, fingerprint=95:6D:5F:68:4A:65:07:55:53:7D:14:02:2C:23:F4:A2:CD:5B:93:AC:86:94:E2:D5:16:26:21:24:B7:A9:06:E3:E1:E6:61:77:DF:60:6E:98:9E:36:9F:BA:23:11:CA:F9:53:99:79:73:0C:D9:D5:10:DF:73:92:52:60:B5:EA:12, pkey_fingerprint=C2:86:49:CF:64:12:52:13:CE:55:AD:84:D5:50:DF:88:42:0D:58:6D:78:B0:67:F6:F3:EE:D7:48:99:F6:28:A4:59:E4:97:08:EA:E6:DA:D8:92:92:28:C9:B8:4E:83:25:3E:1A:F6:CA:C9:94:5A:83:A7:3D:0C:9B:DA:F5:F0:37 posttls-finger: Verified TLS connection established to newdude.radiom.fr[188.165.117.231]:5000: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) posttls-finger: > EHLO mournblade.imrryr.org posttls-finger: < 250-newdude.radiom.fr Hello mournblade.imrryr.org [38.117.134.19], pleased to meet you posttls-finger: < 250-ENHANCEDSTATUSCODES posttls-finger: < 250-PIPELINING posttls-finger: < 250-8BITMIME posttls-finger: < 250-SIZE posttls-finger: < 250-DSN posttls-finger: < 250-ETRN posttls-finger: < 250-AUTH GSSAPI LOGIN PLAIN posttls-finger: < 250-DELIVERBY posttls-finger: < 250 HELP posttls-finger: > QUIT posttls-finger: < 221 2.0.0 newdude.radiom.fr closing connection > No problem, I can communicate with the SMTP server after the STARTTLS > occurred. > > But behind that specific network, if I run the same command, all I get is : > > CONNECTED(00000003) > write:errno=104 > --- > no peer certificate available > --- > No client certificate CA names sent > --- > SSL handshake has read 351 bytes and written 147 bytes > --- > New, (NONE), Cipher is (NONE) > Secure Renegotiation IS NOT supported > Compression: NONE > Expansion: NONE > --- > > When I compare two tcpdumps, I can clearly see that a lot of data is > missing, the transaction is not complete. > > Before being paranoid, I simply suspect a MTU problem, but I'm not sure > how this would only apply to SSL transactions. > > Should I provide tcpdumps or anything else? Just the PCAP file for the broken session is enough. However, since the destination looks perfectly fine, the problem is surely some firewall at the source network that exhibits the problem, and figuring out exactly what's wrong with that firewall is not an OpenSSL issue. Send the PCAP file to the network administrator and ask for help there. -- Viktor. From fuckspam at wheres5.com Fri Dec 23 14:13:14 2016 From: fuckspam at wheres5.com (Hoggins!) Date: Fri, 23 Dec 2016 15:13:14 +0100 Subject: [openssl-users] Unable to STARTTLS behind a specific network In-Reply-To: <79CF82E2-EB40-454A-8032-E4B1B2BC2271@dukhovni.org> References: <79CF82E2-EB40-454A-8032-E4B1B2BC2271@dukhovni.org> Message-ID: <98ac869b-a1cc-3d8e-fa4e-8cc6c94db170@wheres5.com> Hello all, Thank you for your help ! Le 22/12/2016 ? 17:58, Viktor Dukhovni a ?crit : >> On Dec 22, 2016, at 5:30 AM, Hoggins! wrote: >> >> So what I do is : >> >> $ openssl s_client -starttls smtp -crlf -connect newdude.radiom.fr:5000 > This (well essentially this, but with the Postfix "posttls-finger" utility) > works for me from my MTA host: > > $ posttls-finger -d sha512 "[newdude.radiom.fr]:5000" > posttls-finger: using DANE RR: _5000._tcp.newdude.radiom.fr IN TLSA 3 0 2 95:6D:5F:68:4A:65:07:55:53:7D:14:02:2C:23:F4:A2:CD:5B:93:AC:86:94:E2:D5:16:26:21:24:B7:A9:06:E3:E1:E6:61:77:DF:60:6E:98:9E:36:9F:BA:23:11:CA:F9:53:99:79:73:0C:D9:D5:10:DF:73:92:52:60:B5:EA:12 > posttls-finger: Connected to newdude.radiom.fr[188.165.117.231]:5000 > posttls-finger: < 220 newdude.radiom.fr ESMTP Sendmail 8.15.2/8.15.2; Thu, 22 Dec 2016 17:54:11 +0100 > posttls-finger: > EHLO mournblade.imrryr.org > posttls-finger: < 250-newdude.radiom.fr Hello mournblade.imrryr.org [38.117.134.19], pleased to meet you > posttls-finger: < 250-ENHANCEDSTATUSCODES > posttls-finger: < 250-PIPELINING > posttls-finger: < 250-8BITMIME > posttls-finger: < 250-SIZE > posttls-finger: < 250-DSN > posttls-finger: < 250-ETRN > posttls-finger: < 250-AUTH GSSAPI LOGIN PLAIN > posttls-finger: < 250-STARTTLS > posttls-finger: < 250-DELIVERBY > posttls-finger: < 250 HELP > posttls-finger: > STARTTLS > posttls-finger: < 220 2.0.0 Ready to start TLS > posttls-finger: newdude.radiom.fr[188.165.117.231]:5000: depth=0 matched end entity certificate sha512 digest 95:6D:5F:68:4A:65:07:55:53:7D:14:02:2C:23:F4:A2:CD:5B:93:AC:86:94:E2:D5:16:26:21:24:B7:A9:06:E3:E1:E6:61:77:DF:60:6E:98:9E:36:9F:BA:23:11:CA:F9:53:99:79:73:0C:D9:D5:10:DF:73:92:52:60:B5:EA:12 > posttls-finger: newdude.radiom.fr[188.165.117.231]:5000: Matched subjectAltName: *.radiom.fr > posttls-finger: newdude.radiom.fr[188.165.117.231]:5000: subjectAltName: radiom.fr > posttls-finger: newdude.radiom.fr[188.165.117.231]:5000 CommonName *.radiom.fr > posttls-finger: newdude.radiom.fr[188.165.117.231]:5000: subject_CN=*.radiom.fr, issuer_CN=StartCom Class 2 Primary Intermediate Server CA, fingerprint=95:6D:5F:68:4A:65:07:55:53:7D:14:02:2C:23:F4:A2:CD:5B:93:AC:86:94:E2:D5:16:26:21:24:B7:A9:06:E3:E1:E6:61:77:DF:60:6E:98:9E:36:9F:BA:23:11:CA:F9:53:99:79:73:0C:D9:D5:10:DF:73:92:52:60:B5:EA:12, pkey_fingerprint=C2:86:49:CF:64:12:52:13:CE:55:AD:84:D5:50:DF:88:42:0D:58:6D:78:B0:67:F6:F3:EE:D7:48:99:F6:28:A4:59:E4:97:08:EA:E6:DA:D8:92:92:28:C9:B8:4E:83:25:3E:1A:F6:CA:C9:94:5A:83:A7:3D:0C:9B:DA:F5:F0:37 > posttls-finger: Verified TLS connection established to newdude.radiom.fr[188.165.117.231]:5000: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) > posttls-finger: > EHLO mournblade.imrryr.org > posttls-finger: < 250-newdude.radiom.fr Hello mournblade.imrryr.org [38.117.134.19], pleased to meet you > posttls-finger: < 250-ENHANCEDSTATUSCODES > posttls-finger: < 250-PIPELINING > posttls-finger: < 250-8BITMIME > posttls-finger: < 250-SIZE > posttls-finger: < 250-DSN > posttls-finger: < 250-ETRN > posttls-finger: < 250-AUTH GSSAPI LOGIN PLAIN > posttls-finger: < 250-DELIVERBY > posttls-finger: < 250 HELP > posttls-finger: > QUIT > posttls-finger: < 221 2.0.0 newdude.radiom.fr closing connection > >> No problem, I can communicate with the SMTP server after the STARTTLS >> occurred. >> >> But behind that specific network, if I run the same command, all I get is : >> >> CONNECTED(00000003) >> write:errno=104 >> --- >> no peer certificate available >> --- >> No client certificate CA names sent >> --- >> SSL handshake has read 351 bytes and written 147 bytes >> --- >> New, (NONE), Cipher is (NONE) >> Secure Renegotiation IS NOT supported >> Compression: NONE >> Expansion: NONE >> --- >> >> When I compare two tcpdumps, I can clearly see that a lot of data is >> missing, the transaction is not complete. >> >> Before being paranoid, I simply suspect a MTU problem, but I'm not sure >> how this would only apply to SSL transactions. >> >> Should I provide tcpdumps or anything else? > Just the PCAP file for the broken session is enough. However, since the > destination looks perfectly fine, the problem is surely some firewall at > the source network that exhibits the problem, and figuring out exactly > what's wrong with that firewall is not an OpenSSL issue. Send the PCAP > file to the network administrator and ask for help there. > Routing my traffic through an IPSec VPN directly to the host solves the issue, so we can definitely bet on a problem on the local network. I'm afraid the administrators are not too much into Net neutrality ;) Cheers ! Hoggins! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From fuckspam at wheres5.com Fri Dec 23 16:28:12 2016 From: fuckspam at wheres5.com (Hoggins!) Date: Fri, 23 Dec 2016 17:28:12 +0100 Subject: [openssl-users] Unable to STARTTLS behind a specific network In-Reply-To: <7b1bd2f3d8bc43a98197547d0efa54de@usma1ex-dag1mb1.msg.corp.akamai.com> References: <7b1bd2f3d8bc43a98197547d0efa54de@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <56c5a8f9-568a-b148-7d1c-a3a87f23ffd4@wheres5.com> Yes, confirmed here ! Le 22/12/2016 ? 15:24, Salz, Rich a ?crit : > Errno104 is usually "connection reset by peer" which means that the other side said "go away" Both parties receive an RST from "the middle" as shown in the tcpdump captures (output1 from client, output0 from server). Now I have to try to deal with the network administrator to understand why this happens, and what they're trying to do. Hoggins! -------------- next part -------------- A non-text attachment was scrubbed... Name: output0 Type: application/octet-stream Size: 16256 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: output1 Type: application/octet-stream Size: 3608 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From ronmlgaw at yahoo.com Tue Dec 27 05:24:04 2016 From: ronmlgaw at yahoo.com (Ron Gaw ) Date: Tue, 27 Dec 2016 05:24:04 +0000 (UTC) Subject: [openssl-users] MinGW64 / MSYS2 and ./Configure : use of Windows style path causing failures to 'make' References: <1733025605.2034908.1482816244923.ref@mail.yahoo.com> Message-ID: <1733025605.2034908.1482816244923@mail.yahoo.com> I am using a MinGW64 / MSYS2 environment to compile OpenSSL1.1.0c, but failing consistently after multiple attempts with a few variations each attempt (including deleting entire source directory and re-untar/ungzipping). ? I believe there's something wrong either with my environment settings or ./Configure options.? This is the output of ./Configure after setting only the CFLAGS env var: $ export "CFLAGS=-03"$ ./Configure mingw64 --prefix=/usr/local zlib shared Configuring OpenSSL version 1.1.0c (0x1010003fL) ??? no-asan???????? [default]? OPENSSL_NO_ASAN ??? no-crypto-mdebug [default]? OPENSSL_NO_CRYPTO_MDEBUG ??? no-crypto-mdebug-backtrace [default]? OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE ??? no-ec_nistp_64_gcc_128 [default]? OPENSSL_NO_EC_NISTP_64_GCC_128 ??? no-egd????????? [default]? OPENSSL_NO_EGD ??? no-fuzz-afl???? [default]? OPENSSL_NO_FUZZ_AFL ??? no-fuzz-libfuzzer [default]? OPENSSL_NO_FUZZ_LIBFUZZER ??? no-heartbeats?? [default]? OPENSSL_NO_HEARTBEATS ??? no-md2????????? [default]? OPENSSL_NO_MD2 (skip dir) ??? no-msan???????? [default]? OPENSSL_NO_MSAN ??? no-rc5????????? [default]? OPENSSL_NO_RC5 (skip dir) ??? no-sctp???????? [default]? OPENSSL_NO_SCTP ??? no-ssl-trace??? [default]? OPENSSL_NO_SSL_TRACE ??? no-ssl3???????? [default]? OPENSSL_NO_SSL3 ??? no-ssl3-method? [default]? OPENSSL_NO_SSL3_METHOD ??? no-ubsan??????? [default]? OPENSSL_NO_UBSAN ??? no-unit-test??? [default]? OPENSSL_NO_UNIT_TEST ??? no-weak-ssl-ciphers [default]? OPENSSL_NO_WEAK_SSL_CIPHERS ??? no-zlib-dynamic [default] Configuring for mingw64 CC??????????? =gcc CFLAG???????? =-DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall -O3 -D_MT SHARED_CFLAG? =-D_WINDLL DEFINES?????? =ZLIB DSO_WIN32 NDEBUG OPENSSL_THREADS OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM RC4_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM POLY1305_ASM LFLAG???????? = PLIB_LFLAG??? = EX_LIBS?????? =-lz -lws2_32 -lgdi32 -lcrypt32 APPS_OBJ????? =win32_init.o CPUID_OBJ???? =x86_64cpuid.o UPLINK_OBJ??? = BN_ASM??????? =asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o EC_ASM??????? =ecp_nistz256.o ecp_nistz256-x86_64.o DES_ENC?????? =des_enc.o fcrypt_b.o AES_ENC?????? =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o BF_ENC??????? =bf_enc.o CAST_ENC????? =c_enc.o RC4_ENC?????? =rc4-x86_64.o rc4-md5-x86_64.o RC5_ENC?????? =rc5_enc.o MD5_OBJ_ASM?? =md5-x86_64.o SHA1_OBJ_ASM? =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o sha256-mb-x86_64.o RMD160_OBJ_ASM= CMLL_ENC????? =cmll-x86_64.o cmll_misc.o MODES_OBJ???? =ghash-x86_64.o aesni-gcm-x86_64.o PADLOCK_OBJ?? =e_padlock-x86_64.o CHACHA_ENC??? =chacha-x86_64.o POLY1305_OBJ? =poly1305-x86_64.o BLAKE2_OBJ??? = PROCESSOR???? = RANLIB??????? =ranlib ARFLAGS?????? = PERL????????? =C:\msys64\mingw64\bin\perl.exe SIXTY_FOUR_BIT mode Configured for mingw64. $ make C:\msys64\mingw64\bin\perl.exe "-I." -Mconfigdata "util\dofile.pl" \ ??? "-oMakefile" crypto\include\internal\bn_conf.h.in > crypto\include\internal\bn_conf.h /bin/sh: C:msys64mingw64binperl.exe: command not found make: *** [Makefile:701: crypto\include\internal\bn_conf.h] Error 127 It seems the "\" is the culprit here, since the execution of the make command appears to strip those out and then (as expected) the /bin/sh cannot recognize that large hash of what should have been the path to Perl.? I did edit the first Makefile above to :??? Change the base PERL to "C:/msys64/mingw64/bin/perl.exe", *and* ??? crypto/include/internal/bin_conf.h.in > crypto/include/internal/bin_conf.h The above worked, but *only* for that line of the make file (as I expected).? It then fails at the very next line because I didn't edit every "\" to become "/" instead.? I'm not sure I'm willing to do that much editing... seems there's got to be a better way to make this work. I realize this has something to do with specifying ./Configure mingw64 .... and how it's populating the Makefiles using Windows-style paths, but I'm not sure it's safe / okay to fake having a Unix build target instead, since this will likely create new / other problems with libraries, etc. Am I missing a ./Configure option, an environment variable I should preset, or something else altogether? -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Tue Dec 27 05:40:15 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 27 Dec 2016 00:40:15 -0500 Subject: [openssl-users] MinGW64 / MSYS2 and ./Configure : use of Windows style path causing failures to 'make' In-Reply-To: <1733025605.2034908.1482816244923@mail.yahoo.com> References: <1733025605.2034908.1482816244923.ref@mail.yahoo.com> <1733025605.2034908.1482816244923@mail.yahoo.com> Message-ID: On Tue, Dec 27, 2016 at 12:24 AM, Ron Gaw via openssl-users wrote: > I am using a MinGW64 / MSYS2 environment to compile OpenSSL1.1.0c, but > failing consistently after multiple attempts with a few variations each > attempt (including deleting entire source directory and > re-untar/ungzipping). I believe there's something wrong either with my > environment settings or ./Configure options. This is the output of > ./Configure after setting only the CFLAGS env var: > > $ export "CFLAGS=-03" > $ ./Configure mingw64 --prefix=/usr/local zlib shared > Configuring OpenSSL version 1.1.0c (0x1010003fL) > ... > PERL =C:\msys64\mingw64\bin\perl.exe > > SIXTY_FOUR_BIT mode > > Configured for mingw64. > > $ make > C:\msys64\mingw64\bin\perl.exe "-I." -Mconfigdata "util\dofile.pl" \ > "-oMakefile" crypto\include\internal\bn_conf.h.in > > crypto\include\internal\bn_conf.h > /bin/sh: C:msys64mingw64binperl.exe: command not found > make: *** [Makefile:701: crypto\include\internal\bn_conf.h] Error 127 > > > It seems the "\" is the culprit here, since the execution of the make > command appears to strip those out and then (as expected) the /bin/sh cannot > recognize that large hash of what should have been the path to Perl. I did > edit the first Makefile above to : > Change the base PERL to "C:/msys64/mingw64/bin/perl.exe", *and* > crypto/include/internal/bin_conf.h.in > > crypto/include/internal/bin_conf.h > > The above worked, but *only* for that line of the make file (as I expected). > It then fails at the very next line because I didn't edit every "\" to > become "/" instead. I'm not sure I'm willing to do that much editing... > seems there's got to be a better way to make this work. > > I realize this has something to do with specifying ./Configure mingw64 .... > and how it's populating the Makefiles using Windows-style paths, but I'm not > sure it's safe / okay to fake having a Unix build target instead, since this > will likely create new / other problems with libraries, etc. > > Am I missing a ./Configure option, an environment variable I should preset, > or something else altogether? http://stackoverflow.com/q/40948353/608639 From openssl.org at 18informatique.com Tue Dec 27 08:15:21 2016 From: openssl.org at 18informatique.com (mlrx) Date: Tue, 27 Dec 2016 09:15:21 +0100 Subject: [openssl-users] stronger Kex In-Reply-To: <7b0a0592-9820-f334-01c6-8109469f0fd6@18informatique.com> References: <7b0a0592-9820-f334-01c6-8109469f0fd6@18informatique.com> Message-ID: <7c90e857-4960-2aab-eab4-42579eb88224@18informatique.com> Le 21/12/2016 ? 16:07, mlrx a ?crit : > Hello, > > I have two servers for testing purpose : > - debian 6, apache 2.2, openssl 1.0.1t (mutu) > - centos 7, apache 2.4.6, openssl 1.0.1e-fips (dedicated) > > Now, these 2 serveurs offers only those ciphers : > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) > > I have two goals. First, I would like to use at least secp384r1 > and second (no problem), use an ECC certificate. > > Is it possible to do it with CHACHA20-POLY1305 ? > Is it possible to use this cipher on those servers ? > > openssl ciphers -V CHACHA20 return an error on each server. > I understand it's because there is no chacha20 cipher (?). > > Why can I connect a server by SSH with chacha20-poly1305 at openssh.com > and not using it with Apache ? > > All advices are welcome :-). > > Best regards, Hello, Is somebody could explain me the difference between a message who received an answer and this one ? What's wrong ? RTFM ? Best regards, -- benoist From jb-openssl at wisemo.com Tue Dec 27 09:16:50 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 27 Dec 2016 10:16:50 +0100 Subject: [openssl-users] stronger Kex In-Reply-To: <7c90e857-4960-2aab-eab4-42579eb88224@18informatique.com> References: <7b0a0592-9820-f334-01c6-8109469f0fd6@18informatique.com> <7c90e857-4960-2aab-eab4-42579eb88224@18informatique.com> Message-ID: <47c51e6f-e0c7-a51b-14c6-b1c4c2d3a8f3@wisemo.com> On 27/12/2016 09:15, mlrx wrote: > Le 21/12/2016 ? 16:07, mlrx a ?crit : >> Hello, >> >> I have two servers for testing purpose : >> - debian 6, apache 2.2, openssl 1.0.1t (mutu) >> - centos 7, apache 2.4.6, openssl 1.0.1e-fips (dedicated) >> >> Now, these 2 serveurs offers only those ciphers : >> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) >> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) >> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) >> >> I have two goals. First, I would like to use at least secp384r1 >> and second (no problem), use an ECC certificate. >> >> Is it possible to do it with CHACHA20-POLY1305 ? >> Is it possible to use this cipher on those servers ? >> >> openssl ciphers -V CHACHA20 return an error on each server. >> I understand it's because there is no chacha20 cipher (?). >> >> Why can I connect a server by SSH with chacha20-poly1305 at openssh.com >> and not using it with Apache ? >> >> All advices are welcome :-). >> >> Best regards, > Hello, > Is somebody could explain me the difference between a message who > received an answer and this one ? > What's wrong ? RTFM ? Even though at least one SSH program (OpenSSH) uses the crypto functions from the OpenSSL libcrypto, the SSH protocol is completely unrealted to the SSL/TLS security protocol. So the ability to use specific settings with SSH is almost completely unrelated to the ability to use similarly named settings for SSL. One major difference is that SSH identifies cryptographic suites by strings that can easily be extended by organizations such as openssh.com. In contrast, SSL/TLS identifies cryptographic suites by 16 bit numbers specified in RFCs and listed in a table published by IANA/ICANN. Thus for SSL/TLS libraries such as OpenSSL can really only provide choices that were given an official number in an RFC and added to that table as part of the RFC publishing process. On top of that, the OpenSSL team has a policy of only implementing new SSL/TLS cryptographic suites when the number part of the OpenSSL version number changes. Thus anything not included in the original OpenSSL 1.0.2 release will only be available in 1.1.0 or an even later release (because they will not be making a 1.0.3 release). Similarly anything not in the original 1.1.0 release will only be in 1.2.0 or later (assuming there is no 1.1.1 release). 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 ronmlgaw at yahoo.com Tue Dec 27 15:19:53 2016 From: ronmlgaw at yahoo.com (Ron Gaw ) Date: Tue, 27 Dec 2016 15:19:53 +0000 (UTC) Subject: [openssl-users] MinGW64 / MSYS2 and ./Configure : use of Windows style path causing failures to 'make' In-Reply-To: References: <1733025605.2034908.1482816244923.ref@mail.yahoo.com> <1733025605.2034908.1482816244923@mail.yahoo.com> Message-ID: <1226932444.2226642.1482851993181@mail.yahoo.com> From: Jeffrey Walton via openssl-users wrote: > http://stackoverflow.com/q/40948353/608639 In my original note, I explained that I'd done something similar to what the above stackoverflow.com entry suggested: ....>> I did edit the first Makefile above to : >>? ? 1. Change the base PERL to "C:/msys64/mingw64/bin/perl.exe", *and* >>? ? 2. crypto/include/internal/bin_conf.h.in > crypto/include/internal/bin_conf.h >> >> The above worked, but *only* for that line of the make file (as I expected). >>ADDENDUM<< Changing PERL to "C:/mysys64/mingw64/bin/perl.exe" in the top level Makefile was sufficient, even the second action correctly called perl.exe. The real issue is with the "\" in the paths for all the *.h files (there are many of these in each Makefile, too numerous to hand edit).? I can't just find / replace all "\", this will create new issues where the Makefile needs the "\" as it is. I can't imagine the Makefiles use the "\" in the paths when Configure'd for a Unix (Linux) system, there should be a way to modify the Configure Perl script to use Unix paths when compiling for "mingw64" systems, but I've yet to find it in the Configure code.... -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Tue Dec 27 16:38:57 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 27 Dec 2016 11:38:57 -0500 Subject: [openssl-users] stronger Kex In-Reply-To: <7b0a0592-9820-f334-01c6-8109469f0fd6@18informatique.com> References: <7b0a0592-9820-f334-01c6-8109469f0fd6@18informatique.com> Message-ID: > I have two servers for testing purpose : > - debian 6, apache 2.2, openssl 1.0.1t (mutu) > - centos 7, apache 2.4.6, openssl 1.0.1e-fips (dedicated) > > Now, these 2 serveurs offers only those ciphers : > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) > > I have two goals. First, I would like to use at least secp384r1 > and second (no problem), use an ECC certificate. > > Is it possible to do it with CHACHA20-POLY1305 ? > Is it possible to use this cipher on those servers ? You need OpenSSL 1.1.0 or above for ChaCha20/Poly1305: $ openssl version OpenSSL 1.1.0b 26 Sep 2016 $ openssl ciphers | tr ':' '\n' | grep -i chacha ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-CHACHA20-POLY1305 DHE-RSA-CHACHA20-POLY1305 RSA-PSK-CHACHA20-POLY1305 DHE-PSK-CHACHA20-POLY1305 ECDHE-PSK-CHACHA20-POLY1305 PSK-CHACHA20-POLY1305 Jeff From levitte at openssl.org Tue Dec 27 19:25:33 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 27 Dec 2016 20:25:33 +0100 (CET) Subject: [openssl-users] MinGW64 / MSYS2 and ./Configure : use of Windows style path causing failures to 'make' In-Reply-To: <1733025605.2034908.1482816244923@mail.yahoo.com> References: <1733025605.2034908.1482816244923.ref@mail.yahoo.com> <1733025605.2034908.1482816244923@mail.yahoo.com> Message-ID: <20161227.202533.1340608693718566398.levitte@openssl.org> In message <1733025605.2034908.1482816244923 at mail.yahoo.com> on Tue, 27 Dec 2016 05:24:04 +0000 (UTC), "Ron Gaw " said: ronmlgaw> I am using a MinGW64 / MSYS2 environment to compile OpenSSL1.1.0c, but ronmlgaw> failing consistently after multiple attempts with a few variations ronmlgaw> each attempt (including deleting entire source directory and ronmlgaw> re-untar/ungzipping). I believe there's something wrong either with my ronmlgaw> environment settings or ./Configure options. This is the output of . ronmlgaw> /Configure after setting only the CFLAGS env var: ronmlgaw> ronmlgaw> $ export "CFLAGS=-03" ronmlgaw> $ ./Configure mingw64 --prefix=/usr/local zlib shared ronmlgaw> Configuring OpenSSL version 1.1.0c (0x1010003fL) ronmlgaw> no-asan [default] OPENSSL_NO_ASAN ronmlgaw> no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG ronmlgaw> no-crypto-mdebug-backtrace [default] ronmlgaw> OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE ronmlgaw> no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 ronmlgaw> no-egd [default] OPENSSL_NO_EGD ronmlgaw> no-fuzz-afl [default] OPENSSL_NO_FUZZ_AFL ronmlgaw> no-fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER ronmlgaw> no-heartbeats [default] OPENSSL_NO_HEARTBEATS ronmlgaw> no-md2 [default] OPENSSL_NO_MD2 (skip dir) ronmlgaw> no-msan [default] OPENSSL_NO_MSAN ronmlgaw> no-rc5 [default] OPENSSL_NO_RC5 (skip dir) ronmlgaw> no-sctp [default] OPENSSL_NO_SCTP ronmlgaw> no-ssl-trace [default] OPENSSL_NO_SSL_TRACE ronmlgaw> no-ssl3 [default] OPENSSL_NO_SSL3 ronmlgaw> no-ssl3-method [default] OPENSSL_NO_SSL3_METHOD ronmlgaw> no-ubsan [default] OPENSSL_NO_UBSAN ronmlgaw> no-unit-test [default] OPENSSL_NO_UNIT_TEST ronmlgaw> no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS ronmlgaw> no-zlib-dynamic [default] ronmlgaw> Configuring for mingw64 ronmlgaw> CC =gcc ronmlgaw> CFLAG =-DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 - ronmlgaw> Wall -O3 -D_MT ronmlgaw> SHARED_CFLAG =-D_WINDLL ronmlgaw> DEFINES =ZLIB DSO_WIN32 NDEBUG OPENSSL_THREADS ronmlgaw> OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2 ronmlgaw> OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM ronmlgaw> SHA256_ASM SHA512_ASM RC4_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM ronmlgaw> GHASH_ASM ECP_NISTZ256_ASM POLY1305_ASM ronmlgaw> LFLAG = ronmlgaw> PLIB_LFLAG = ronmlgaw> EX_LIBS =-lz -lws2_32 -lgdi32 -lcrypt32 ronmlgaw> APPS_OBJ =win32_init.o ronmlgaw> CPUID_OBJ =x86_64cpuid.o ronmlgaw> UPLINK_OBJ = ronmlgaw> BN_ASM =asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o ronmlgaw> rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o ronmlgaw> EC_ASM =ecp_nistz256.o ecp_nistz256-x86_64.o ronmlgaw> DES_ENC =des_enc.o fcrypt_b.o ronmlgaw> AES_ENC =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o ronmlgaw> aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o ronmlgaw> BF_ENC =bf_enc.o ronmlgaw> CAST_ENC =c_enc.o ronmlgaw> RC4_ENC =rc4-x86_64.o rc4-md5-x86_64.o ronmlgaw> RC5_ENC =rc5_enc.o ronmlgaw> MD5_OBJ_ASM =md5-x86_64.o ronmlgaw> SHA1_OBJ_ASM =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o ronmlgaw> sha1-mb-x86_64.o sha256-mb-x86_64.o ronmlgaw> RMD160_OBJ_ASM= ronmlgaw> CMLL_ENC =cmll-x86_64.o cmll_misc.o ronmlgaw> MODES_OBJ =ghash-x86_64.o aesni-gcm-x86_64.o ronmlgaw> PADLOCK_OBJ =e_padlock-x86_64.o ronmlgaw> CHACHA_ENC =chacha-x86_64.o ronmlgaw> POLY1305_OBJ =poly1305-x86_64.o ronmlgaw> BLAKE2_OBJ = ronmlgaw> PROCESSOR = ronmlgaw> RANLIB =ranlib ronmlgaw> ARFLAGS = ronmlgaw> PERL =C:\msys64\mingw64\bin\perl.exe The PERL definition is a bit odd for a mingw perl. That path comes from the perl variable $^X. In my MSYS2/Mingw64 shell, I get this: Richard at OSFWin7 MINGW64 ~ $ type perl perl is hashed (/usr/bin/perl) Richard at OSFWin7 MINGW64 ~ $ perl -v This is perl 5, version 22, subversion 1 (v5.22.1) built for i686-msys-thread-multi-64int Copyright 1987-2015, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. Richard at OSFWin7 MINGW64 ~ $ perl -e 'print $^X,"\n";' perl So the question is, what perl do you use? From your output, I'd say it isn't the mingw64 one... ronmlgaw> SIXTY_FOUR_BIT mode ronmlgaw> ronmlgaw> Configured for mingw64. Richard at OSFWin7 MINGW64 ~/gitwrk/openssl.org/official/_build $ ../master/Configure mingw64 --prefix=/usr/local zlib shared Configuring OpenSSL version 1.1.0c (0x1010003fL) no-asan [default] OPENSSL_NO_ASAN no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG no-crypto-mdebug-backtrace [default] OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 no-egd [default] OPENSSL_NO_EGD no-fuzz-afl [default] OPENSSL_NO_FUZZ_AFL no-fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER no-heartbeats [default] OPENSSL_NO_HEARTBEATS no-md2 [default] OPENSSL_NO_MD2 (skip dir) no-msan [default] OPENSSL_NO_MSAN no-rc5 [default] OPENSSL_NO_RC5 (skip dir) no-sctp [default] OPENSSL_NO_SCTP no-ssl-trace [default] OPENSSL_NO_SSL_TRACE no-ssl3 [default] OPENSSL_NO_SSL3 no-ssl3-method [default] OPENSSL_NO_SSL3_METHOD no-ubsan [default] OPENSSL_NO_UBSAN no-unit-test [default] OPENSSL_NO_UNIT_TEST no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS no-zlib-dynamic [default] Configuring for mingw64 CC =gcc CFLAG =-DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall -O3 -D_MT SHARED_CFLAG =-D_WINDLL DEFINES =ZLIB DSO_WIN32 NDEBUG OPENSSL_THREADS OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM RC4_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM POLY1305_ASM LFLAG = PLIB_LFLAG = EX_LIBS =-lz -lws2_32 -lgdi32 -lcrypt32 APPS_OBJ =win32_init.o CPUID_OBJ =x86_64cpuid.o UPLINK_OBJ = BN_ASM =asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o EC_ASM =ecp_nistz256.o ecp_nistz256-x86_64.o DES_ENC =des_enc.o fcrypt_b.o AES_ENC =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o BF_ENC =bf_enc.o CAST_ENC =c_enc.o RC4_ENC =rc4-x86_64.o rc4-md5-x86_64.o RC5_ENC =rc5_enc.o MD5_OBJ_ASM =md5-x86_64.o SHA1_OBJ_ASM =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o sha256-mb-x86_64.o RMD160_OBJ_ASM= CMLL_ENC =cmll-x86_64.o cmll_misc.o MODES_OBJ =ghash-x86_64.o aesni-gcm-x86_64.o PADLOCK_OBJ =e_padlock-x86_64.o CHACHA_ENC =chacha-x86_64.o POLY1305_OBJ =poly1305-x86_64.o BLAKE2_OBJ = PROCESSOR = RANLIB =ranlib ARFLAGS = PERL =perl SIXTY_FOUR_BIT mode Configured for mingw64. Cheers, Richard From ronmlgaw at yahoo.com Tue Dec 27 20:05:25 2016 From: ronmlgaw at yahoo.com (Ron Gaw ) Date: Tue, 27 Dec 2016 20:05:25 +0000 (UTC) Subject: [openssl-users] MinGW64 / MSYS2 and ./Configure : use of Windows style path causing failures to 'make' In-Reply-To: <20161227.202533.1340608693718566398.levitte@openssl.org> References: <1733025605.2034908.1482816244923.ref@mail.yahoo.com> <1733025605.2034908.1482816244923@mail.yahoo.com> <20161227.202533.1340608693718566398.levitte@openssl.org> Message-ID: <1767402444.2364257.1482869125627@mail.yahoo.com> I wondered about that as well.? First, regarding my msys64: The root '/' is mapped to "C:\msys64", and "/mingw64" is the directory where I keep all things MinGW64 w64. Second: I do have multiple Perl's installed, though only one in the /mingw64 tree.? In essence, I *think* all the non-mingw64 per stuff I list below is irrelevant, but I'm not ruling those out as possible culprits in this issue... So here's what I see (spoiler alert : nothing is jumping out at me as the culprit): $ type /mingw64/bin/perl /mingw64/bin/perl is /mingw64/bin/perl $ /mingw64/bin/perl -v This is perl 5, version 22, subversion 0 (v5.22.0) built for MSWin32-x64-multi-thread Copyright 1987-2015, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl".? If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. $ pacman -Ss perl? /*--- NOTE: I cut out all the extraneous stuff and narrowed it to only what's [installed] mingw64/mingw-w64-x86_64-perl 5.22.0-1 [installed] ??? A highly capable, feature-rich programming language (mingw-w64) msys/libpcre 8.38-1 (libraries) [installed] ??? A library that implements Perl 5-style regular expressions msys/libpcre16 8.38-1 (libraries) [installed] ??? A library that implements Perl 5-style regular expressions msys/libpcre32 8.38-1 (libraries) [installed] ??? A library that implements Perl 5-style regular expressions msys/libpcrecpp 8.38-1 (libraries) [installed] ??? A library that implements Perl 5-style regular expressions msys/libpcreposix 8.38-1 (libraries) [installed] ??? A library that implements Perl 5-style regular expressions msys/pcre 8.38-1 [installed] ??? A library that implements Perl 5-style regular expressions msys/perl 5.22.1-1 (base-devel) [installed] ??? A highly capable, feature-rich programming language msys/perl-Authen-SASL 2.16-2 (perl-modules) [installed] ??? Perl/CPAN Module Authen::SASL : SASL authentication framework msys/perl-Convert-BinHex 1.123-2 [installed] ??? Perl module to extract data from Macintosh BinHex files msys/perl-Encode-Locale 1.04-1 (perl-modules) [installed] ??? Determine the locale encoding msys/perl-File-Listing 6.04-2 (perl-modules) [installed] ??? parse directory listing msys/perl-HTML-Parser 3.71-3 (perl-modules) [installed] ??? Perl HTML parser class msys/perl-HTML-Tagset 3.20-2 (perl-modules) [installed] ??? Data tables useful in parsing HTML msys/perl-HTTP-Cookies 6.01-2 (perl-modules) [installed] ??? HTTP cookie jars msys/perl-HTTP-Daemon 6.01-2 (perl-modules) [installed] ??? A simple http server class msys/perl-HTTP-Date 6.02-2 (perl-modules) [installed] ??? Date conversion routines msys/perl-HTTP-Message 6.06-2 (perl-modules) [installed] ??? HTTP style messages msys/perl-HTTP-Negotiate 6.01-2 (perl-modules) [installed] ??? choose a variant to serve msys/perl-IO-Socket-SSL 2.016-1 (perl-modules) [installed] ??? Nearly transparent SSL encapsulation for IO::Socket::INET msys/perl-IO-stringy 2.111-1 (perl-modules) [installed] ??? I/O on in-core objects like strings/arrays msys/perl-LWP-MediaTypes 6.02-2 (perl-modules) [installed] ??? Guess the media type of a file or a URL msys/perl-MIME-tools 5.506-1 [installed] ??? Parses streams to create MIME entities msys/perl-MailTools 2.14-1 [installed] ??? Various e-mail related modules msys/perl-Module-Build 0.4212-1 [installed] ??? Build, test, and install Perl modules msys/perl-Net-HTTP 6.09-1 (perl-modules) [installed] ??? Low-level HTTP connection (client) msys/perl-Net-SMTP-SSL 1.02-1 (perl-modules) [installed] ??? SSL support for Net::SMTP msys/perl-Net-SSLeay 1.72-1 (perl-modules) [installed] ??? Perl extension for using OpenSSL msys/perl-TermReadKey 2.33-1 (perl-modules) [installed] ??? Provides simple control over terminal driver modes msys/perl-Test-Pod 1.50-1 (perl-modules) [installed] ??? Check for POD errors in files msys/perl-TimeDate 2.30-2 [installed] ??? Date formating subroutines msys/perl-URI 1.68-1 (perl-modules) [installed] ??? Uniform Resource Identifiers (absolute and relative) msys/perl-WWW-RobotRules 6.02-2 (perl-modules) [installed] ??? Database of robots.txt-derived permissions msys/perl-YAML-Syck 1.29-1 (perl-modules) [installed] ??? Fast, lightweight YAML loader and dumper msys/perl-libwww 6.13-1 (perl-modules) [installed] ??? The World-Wide Web library for Perl From: Richard Levitte levitte>> The PERL definition is a bit odd for a mingw perl.? That path comes levitte>> mingw64/mingw-w64-x86_64-perl 5.22.0-1 [installed]levitte>> ??? A highly capable, feature-rich programming language (mingw-w64)levitte>> from the perl variable $^X.levitte>> levitte>> In my MSYS2/Mingw64 shell, I get this:levitte>> levitte>> ? ? Richard at OSFWin7 MINGW64 ~levitte>> ? ? $ type perllevitte>> ? ? perl is hashed (/usr/bin/perl)levitte>> ? ? levitte>> ? ? Richard at OSFWin7 MINGW64 ~levitte>> ? ? $ perl -vlevitte>> ? ? levitte>> ? ? This is perl 5, version 22, subversion 1 (v5.22.1) built for i686-msys-thread-levitte>> multi-64intlevitte>> ? ? levitte>> ? ? Copyright 1987-2015, Larry Walllevitte>> ? ? levitte>> ? ? Perl may be copied only under the terms of either the Artistic License or thelevitte>> ? ? GNU General Public License, which may be found in the Perl 5 source kit.levitte>> ? ? levitte>> ? ? Complete documentation for Perl, including FAQ lists, should be found onlevitte>> ? ? this system using "man perl" or "perldoc perl".? If you have access to thelevitte>> ? ? Internet, point your browser at http://www.perl.org/, the Perl Home Page.levitte>> ? ? levitte>> ? ? levitte>> ? ? Richard at OSFWin7 MINGW64 ~levitte>> ? ? $ perl -e 'print $^X,"\n";'levitte>> ? ? perllevitte>> levitte>> So the question is, what perl do you use?? From your output, I'd saylevitte>> it isn't the mingw64 one...levitte>> levitte>>?? levitte>> ? ? SIXTY_FOUR_BIT modelevitte>> ? ? levitte>> ? ? Configured for mingw64.levitte>> ? ? levitte>> Cheers,levitte>> Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy.farrell at oracle.com Tue Dec 27 21:48:41 2016 From: jeremy.farrell at oracle.com (Jeremy Farrell) Date: Tue, 27 Dec 2016 21:48:41 +0000 Subject: [openssl-users] MinGW64 / MSYS2 and ./Configure : use of Windows style path causing failures to 'make' In-Reply-To: <1767402444.2364257.1482869125627@mail.yahoo.com> References: <1733025605.2034908.1482816244923.ref@mail.yahoo.com> <1733025605.2034908.1482816244923@mail.yahoo.com> <20161227.202533.1340608693718566398.levitte@openssl.org> <1767402444.2364257.1482869125627@mail.yahoo.com> Message-ID: <2475a60d-3ebd-5a60-3730-f1765e5b16ff@oracle.com> What output do you get when you run the same commands as Richard? That is: type perl perl -v perl -e 'print $^X,"\n";' On 27/12/2016 20:05, Ron Gaw via openssl-users wrote: > I wondered about that as well. > > First, regarding my msys64: The root '/' is mapped to "C:\msys64", and > "/mingw64" is the directory where I keep all things MinGW64 w64. > > Second: I do have multiple Perl's installed, though only one in the > /mingw64 tree. In essence, I *think* all the non-mingw64 per stuff I > list below is irrelevant, but I'm not ruling those out as possible > culprits in this issue... > > > So here's what I see (spoiler alert : nothing is jumping out at me as > the culprit): > > $ type /mingw64/bin/perl > /mingw64/bin/perl is /mingw64/bin/perl > > $ /mingw64/bin/perl -v > > This is perl 5, version 22, subversion 0 (v5.22.0) built for > MSWin32-x64-multi-thread > > Copyright 1987-2015, Larry Wall > > Perl may be copied only under the terms of either the Artistic License > or the > GNU General Public License, which may be found in the Perl 5 source kit. > > Complete documentation for Perl, including FAQ lists, should be found on > this system using "man perl" or "perldoc perl". If you have access to the > Internet, point your browser at http://www.perl.org/, the Perl Home Page. > > $ pacman -Ss perl /*--- NOTE: I cut out all the extraneous stuff and > narrowed it to only what's [installed] > > mingw64/mingw-w64-x86_64-perl 5.22.0-1 [installed] > A highly capable, feature-rich programming language (mingw-w64) > msys/libpcre 8.38-1 (libraries) [installed] > A library that implements Perl 5-style regular expressions > msys/libpcre16 8.38-1 (libraries) [installed] > A library that implements Perl 5-style regular expressions > msys/libpcre32 8.38-1 (libraries) [installed] > A library that implements Perl 5-style regular expressions > msys/libpcrecpp 8.38-1 (libraries) [installed] > A library that implements Perl 5-style regular expressions > msys/libpcreposix 8.38-1 (libraries) [installed] > A library that implements Perl 5-style regular expressions > msys/pcre 8.38-1 [installed] > A library that implements Perl 5-style regular expressions > msys/perl 5.22.1-1 (base-devel) [installed] > A highly capable, feature-rich programming language > msys/perl-Authen-SASL 2.16-2 (perl-modules) [installed] > Perl/CPAN Module Authen::SASL : SASL authentication framework > msys/perl-Convert-BinHex 1.123-2 [installed] > Perl module to extract data from Macintosh BinHex files > msys/perl-Encode-Locale 1.04-1 (perl-modules) [installed] > Determine the locale encoding > msys/perl-File-Listing 6.04-2 (perl-modules) [installed] > parse directory listing > msys/perl-HTML-Parser 3.71-3 (perl-modules) [installed] > Perl HTML parser class > msys/perl-HTML-Tagset 3.20-2 (perl-modules) [installed] > Data tables useful in parsing HTML > msys/perl-HTTP-Cookies 6.01-2 (perl-modules) [installed] > HTTP cookie jars > msys/perl-HTTP-Daemon 6.01-2 (perl-modules) [installed] > A simple http server class > msys/perl-HTTP-Date 6.02-2 (perl-modules) [installed] > Date conversion routines > msys/perl-HTTP-Message 6.06-2 (perl-modules) [installed] > HTTP style messages > msys/perl-HTTP-Negotiate 6.01-2 (perl-modules) [installed] > choose a variant to serve > msys/perl-IO-Socket-SSL 2.016-1 (perl-modules) [installed] > Nearly transparent SSL encapsulation for IO::Socket::INET > msys/perl-IO-stringy 2.111-1 (perl-modules) [installed] > I/O on in-core objects like strings/arrays > msys/perl-LWP-MediaTypes 6.02-2 (perl-modules) [installed] > Guess the media type of a file or a URL > msys/perl-MIME-tools 5.506-1 [installed] > Parses streams to create MIME entities > msys/perl-MailTools 2.14-1 [installed] > Various e-mail related modules > msys/perl-Module-Build 0.4212-1 [installed] > Build, test, and install Perl modules > msys/perl-Net-HTTP 6.09-1 (perl-modules) [installed] > Low-level HTTP connection (client) > msys/perl-Net-SMTP-SSL 1.02-1 (perl-modules) [installed] > SSL support for Net::SMTP > msys/perl-Net-SSLeay 1.72-1 (perl-modules) [installed] > Perl extension for using OpenSSL > msys/perl-TermReadKey 2.33-1 (perl-modules) [installed] > Provides simple control over terminal driver modes > msys/perl-Test-Pod 1.50-1 (perl-modules) [installed] > Check for POD errors in files > msys/perl-TimeDate 2.30-2 [installed] > Date formating subroutines > msys/perl-URI 1.68-1 (perl-modules) [installed] > Uniform Resource Identifiers (absolute and relative) > msys/perl-WWW-RobotRules 6.02-2 (perl-modules) [installed] > Database of robots.txt-derived permissions > msys/perl-YAML-Syck 1.29-1 (perl-modules) [installed] > Fast, lightweight YAML loader and dumper > msys/perl-libwww 6.13-1 (perl-modules) [installed] > The World-Wide Web library for Perl > > > * > * > *From:* Richard Levitte > ** > > > levitte>> The PERL definition is a bit odd for a mingw perl. That > path comes > levitte>> mingw64/mingw-w64-x86_64-perl 5.22.0-1 [installed] > levitte>> A highly capable, feature-rich programming language > (mingw-w64) > levitte>> from the perl variable $^X. > levitte>> > levitte>> In my MSYS2/Mingw64 shell, I get this: > levitte>> > levitte>> Richard at OSFWin7 MINGW64 ~ > levitte>> $ type perl > levitte>> perl is hashed (/usr/bin/perl) > levitte>> > levitte>> Richard at OSFWin7 MINGW64 ~ > levitte>> $ perl -v > levitte>> > levitte>> This is perl 5, version 22, subversion 1 (v5.22.1) built > for i686-msys-thread-levitte>> multi-64int > levitte>> > levitte>> Copyright 1987-2015, Larry Wall > levitte>> > levitte>> Perl may be copied only under the terms of either the > Artistic License or the > levitte>> GNU General Public License, which may be found in the > Perl 5 source kit. > levitte>> > levitte>> Complete documentation for Perl, including FAQ lists, > should be found on > levitte>> this system using "man perl" or "perldoc perl". If you > have access to the > levitte>> Internet, point your browser at http://www.perl.org/, > the Perl Home Page. > levitte>> > levitte>> > levitte>> Richard at OSFWin7 MINGW64 ~ > levitte>> $ perl -e 'print $^X,"\n";' > levitte>> perl > levitte>> > levitte>> So the question is, what perl do you use? From your output, > I'd say > levitte>> it isn't the mingw64 one... > levitte>> > levitte>> > levitte>> SIXTY_FOUR_BIT mode > levitte>> > levitte>> Configured for mingw64. > levitte>> > levitte>> Cheers, > levitte>> Richard > > > > > -- J. J. Farrell Not speaking for Oracle -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronmlgaw at yahoo.com Wed Dec 28 00:52:40 2016 From: ronmlgaw at yahoo.com (Ron Gaw ) Date: Wed, 28 Dec 2016 00:52:40 +0000 (UTC) Subject: [openssl-users] MinGW64 / MSYS2 and ./Configure : use of Windows style path causing failures to 'make' In-Reply-To: <2475a60d-3ebd-5a60-3730-f1765e5b16ff@oracle.com> References: <1733025605.2034908.1482816244923.ref@mail.yahoo.com> <1733025605.2034908.1482816244923@mail.yahoo.com> <20161227.202533.1340608693718566398.levitte@openssl.org> <1767402444.2364257.1482869125627@mail.yahoo.com> <2475a60d-3ebd-5a60-3730-f1765e5b16ff@oracle.com> Message-ID: <1559827769.2481614.1482886360588@mail.yahoo.com> See below. Jeremy Farrell>> What output do you get when you run the same commands as Richard? That is:Jeremy Farrell>> Jeremy Farrell>> type perl $ type perl perl is hashed (/mingw64/bin/perl) Jeremy Farrell>> Jeremy Farrell>> perl -v $ perl -v This is perl 5, version 22, subversion 0 (v5.22.0) built for MSWin32-x64-multi-thread Copyright 1987-2015, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl".? If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. Jeremy Farrell>> Jeremy Farrell>> perl -e 'print $^X,"\n";' C:\msys64\mingw64\bin\perl.exe -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy.farrell at oracle.com Wed Dec 28 02:40:02 2016 From: jeremy.farrell at oracle.com (Jeremy Farrell) Date: Wed, 28 Dec 2016 02:40:02 +0000 Subject: [openssl-users] MinGW64 / MSYS2 and ./Configure : use of Windows style path causing failures to 'make' In-Reply-To: <1559827769.2481614.1482886360588@mail.yahoo.com> References: <1733025605.2034908.1482816244923.ref@mail.yahoo.com> <1733025605.2034908.1482816244923@mail.yahoo.com> <20161227.202533.1340608693718566398.levitte@openssl.org> <1767402444.2364257.1482869125627@mail.yahoo.com> <2475a60d-3ebd-5a60-3730-f1765e5b16ff@oracle.com> <1559827769.2481614.1482886360588@mail.yahoo.com> Message-ID: <80f63719-7436-c237-7184-1ef1a27eccd0@oracle.com> So you're not using the MSYS version of Perl - compare your output of 'perl -v' with that given by Richard. That's very likely your problem, as Matt Caswell pointed out in the stackoverflow thread referred to earlier. On 28/12/2016 00:52, Ron Gaw via openssl-users wrote: > See below. > > Jeremy Farrell>> What output do you get when you run the same commands > as Richard? That is: > Jeremy Farrell>> > Jeremy Farrell>> type perl > > $ type perl > perl is hashed (/mingw64/bin/perl) > > Jeremy Farrell>> > Jeremy Farrell>> perl -v > > $ perl -v > > This is perl 5, version 22, subversion 0 (v5.22.0) built for > MSWin32-x64-multi-thread > > Copyright 1987-2015, Larry Wall > > Perl may be copied only under the terms of either the Artistic License > or the > GNU General Public License, which may be found in the Perl 5 source kit. > > Complete documentation for Perl, including FAQ lists, should be found on > this system using "man perl" or "perldoc perl". If you have access to the > Internet, point your browser at http://www.perl.org/, the Perl Home Page. > > Jeremy Farrell>> > Jeremy Farrell>> perl -e 'print $^X,"\n";' > > C:\msys64\mingw64\bin\perl.exe -- J. J. Farrell Not speaking for Oracle -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Wed Dec 28 04:39:13 2016 From: levitte at openssl.org (Richard Levitte) Date: Wed, 28 Dec 2016 05:39:13 +0100 (CET) Subject: [openssl-users] MinGW64 / MSYS2 and ./Configure : use of Windows style path causing failures to 'make' In-Reply-To: <1767402444.2364257.1482869125627@mail.yahoo.com> References: <1733025605.2034908.1482816244923@mail.yahoo.com> <20161227.202533.1340608693718566398.levitte@openssl.org> <1767402444.2364257.1482869125627@mail.yahoo.com> Message-ID: <20161228.053913.1285676592689685362.levitte@openssl.org> In message <1767402444.2364257.1482869125627 at mail.yahoo.com> on Tue, 27 Dec 2016 20:05:25 +0000 (UTC), "Ron Gaw " said: ronmlgaw> I wondered about that as well. ronmlgaw> ronmlgaw> First, regarding my msys64: The root '/' is mapped to "C:\msys64", and ronmlgaw> "/mingw64" is the directory where I keep all things MinGW64 w64. ronmlgaw> ronmlgaw> Second: I do have multiple Perl's installed, though only one in the ronmlgaw> /mingw64 tree. In essence, I *think* all the non-mingw64 per stuff I ronmlgaw> list below is irrelevant, but I'm not ruling those out as possible ronmlgaw> culprits in this issue... ronmlgaw> ronmlgaw> So here's what I see (spoiler alert : nothing is jumping out at me as ronmlgaw> the culprit): ronmlgaw> ronmlgaw> $ type /mingw64/bin/perl ronmlgaw> /mingw64/bin/perl is /mingw64/bin/perl So here's one thing already that jumps out to me. On mingw, perl is usually installed in /usr/bin, not in /mingw64/bin (which is empty on my installation). Do you have /usr/bin/perl.exe on your installation (you whould, considering pacman reports mingw64 perl to be installed)? ronmlgaw> $ /mingw64/bin/perl -v ronmlgaw> ronmlgaw> This is perl 5, version 22, subversion 0 (v5.22.0) built for ronmlgaw> MSWin32-x64-multi-thread Here's the next thing that jumps at me. 'MSWin32' indicates to me that it was built for use directly in MS cmd.exe or the like (where backslashes make sense) rather than a Unix like shell such as bash (where backslashes don't make sense). So this all tells to me that your /mingw64/bin/perl.exe comes from somewhere else, that you will probably find /usr/bin/perl.exe, and that's the perl you should use. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From openssl-users at dukhovni.org Wed Dec 28 06:58:59 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 28 Dec 2016 01:58:59 -0500 Subject: [openssl-users] downgrade openssl In-Reply-To: References: Message-ID: <7661490D-2136-4968-8CCD-22ACE3B30FC2@dukhovni.org> > On Dec 28, 2016, at 1:27 AM, Fateme Hajikarami wrote: > > I need some help about downgrading my openssl, I know it is not usual to use old version, but I want to use SCAPI library (a cryptographic library) and they use 1.0 version. > I have openssl v1.1.1 on my ubuntu. There is no OpenSSL v1.1.1, the latest version is 1.1.0 and even that is not yet the default version of OpenSSL on most O/S distributions. You probably have 1.0.1, which is which is a 1.0 version and is binary-compatible with 1.0.0. Please DO NOT write to the OpenSSL team members directly, instead post questions on the openssl-users list. -- Viktor. From fateme.hajikarami at gmail.com Wed Dec 28 07:26:33 2016 From: fateme.hajikarami at gmail.com (Fateme Hajikarami) Date: Wed, 28 Dec 2016 10:56:33 +0330 Subject: [openssl-users] downgrading openssl Message-ID: Hi I need some help about downgrading my openssl, I know it is not usual to use old version, but I want to use SCAPI library (a cryptographic library) and they use 1.0 version. I have openssl v1.1.1 on my ubuntu. when I tryied to install it by apt-get (telling the specific version), there were some errors because version 1.0 is not in repositories now, when I tried to install it from source, everything seems well, but when i check the version of my openssl, it's still 1.1.1 ! Would you please give me some help with this? -- Fateme Hajikarami, M.Sc. Department of Electrical & Computer Engineering Isfahan University of Technology -------------- next part -------------- An HTML attachment was scrubbed... URL: From fateme.hajikarami at gmail.com Wed Dec 28 08:53:59 2016 From: fateme.hajikarami at gmail.com (Fateme Hajikarami) Date: Wed, 28 Dec 2016 12:23:59 +0330 Subject: [openssl-users] downgrade openssl In-Reply-To: <7661490D-2136-4968-8CCD-22ACE3B30FC2@dukhovni.org> References: <7661490D-2136-4968-8CCD-22ACE3B30FC2@dukhovni.org> Message-ID: I have another question, as you told the last version is 1.1.0, so what is this: https://github.com/openssl/openssl/readme? it tells: OpenSSL 1.1.1-dev I am really confused. -------------- next part -------------- An HTML attachment was scrubbed... URL: From krrishh7 at gmail.com Wed Dec 28 08:28:03 2016 From: krrishh7 at gmail.com (krish) Date: Wed, 28 Dec 2016 01:28:03 -0700 (MST) Subject: [openssl-users] Can SSL_CTX_set_tmp_ecdh_callback be used to set ECDHstatic ciphers ? Message-ID: <1482913683808-69455.post@n7.nabble.com> I am a beginer to the openssl world :) I was coding a simple TLS client/server C code for simulating a ECDH* key exchange scenario. In the server code, after creating the SSL context, i have the *SSL_CTX_set_tmp_ecdh_callback*() procedure in place to set the EC_KEY from a named curve. I was able to make the server choose TLS_ECDHE_* ciphers for RSA and ECDSA algorithms. However my doubt is whether *SSL_CTX_set_tmp_ecdh_callback*() api lets the server choose TLS_ECDH_* ciphers as well ? If i make the client send only TLS_ECDH_* cipher suites in the clientHello, the server breaks the connection stating "no shared cipher". With my repeated tries i was not able to simulate the scenario. Please give me some insight for the same. Regards, krish -- View this message in context: http://openssl.6102.n7.nabble.com/Can-SSL-CTX-set-tmp-ecdh-callback-be-used-to-set-ECDHstatic-ciphers-tp69455.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From fateme.hajikarami at gmail.com Wed Dec 28 14:37:08 2016 From: fateme.hajikarami at gmail.com (Fateme Hajikarami) Date: Wed, 28 Dec 2016 18:07:08 +0330 Subject: [openssl-users] downgrading openssl In-Reply-To: References: Message-ID: I tried to remove openssl by this command: apt-get install remove openssl and it's done successfully! now if I run this command again I get this message: Reading package lists... Done Building dependency tree Reading state information... Done Package 'openssl' is not installed, so not removed 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. but if I type "openssl version", it tells me again that : OpenSSL 1.1.1-dev xx XXX xxxx How can I remove this?? I dont wanna have this version of ssl on my ubuntu, how can I remove it? On Wed, Dec 28, 2016 at 10:56 AM, Fateme Hajikarami < fateme.hajikarami at gmail.com> wrote: > Hi > I need some help about downgrading my openssl, I know it is not usual to > use old version, but I want to use SCAPI library (a cryptographic library) > and they use 1.0 version. > I have openssl v1.1.1 on my ubuntu. > when I tryied to install it by apt-get (telling the specific version), > there were some errors because version 1.0 is not in repositories now, when > I tried to install it from source, everything seems well, but when i check > the version of my openssl, it's still 1.1.1 ! > Would you please give me some help with this? > > -- > Fateme Hajikarami, M.Sc. > Department of Electrical & Computer Engineering > Isfahan University of Technology > -- Fateme Hajikarami, M.Sc. Department of Electrical & Computer Engineering Isfahan University of Technology -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Dec 28 15:13:55 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 28 Dec 2016 15:13:55 +0000 Subject: [openssl-users] downgrading openssl In-Reply-To: References: Message-ID: <20161228151355.GT13486@mournblade.imrryr.org> On Wed, Dec 28, 2016 at 06:07:08PM +0330, Fateme Hajikarami wrote: > but if I type "openssl version", it tells me again that : > OpenSSL 1.1.1-dev xx XXX xxxx That's the unstable development version of OpenSSL and should only be used for integration testing by O/S distribution and dependent package maintainers. It seems you have an "out of tree" version of OpenSSL installed somewhere on your PATH. Report the verbatim output of the commands below (executed in the same shell in the below order): echo $PATH openssl version -a path=$(type -p openssl); echo $path pkg=$(dpkg -S $path | egrep ": $path" | sed 's/:.*//'); echo $pkg dpkg -l "$pkg" | grep '^i' > How can I remove this?? > I dont wanna have this version of ssl on my ubuntu, how can I remove it? Use an LTS version of Ubuntu, and don't install "out of tree" versions of OpenSSL on your PATH. -- Viktor. From jb-openssl at wisemo.com Thu Dec 29 15:40:46 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 29 Dec 2016 16:40:46 +0100 Subject: [openssl-users] downgrade openssl In-Reply-To: References: <7661490D-2136-4968-8CCD-22ACE3B30FC2@dukhovni.org> Message-ID: On 28/12/2016 09:53, Fateme Hajikarami wrote: > I have another question, as you told the last version is 1.1.0, so > what is this: https://github.com/openssl/openssl/readme > ? > it tells: > OpenSSL 1.1.1-dev Unreleased, still in development, may or may not get a different version number once released. 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 rschm2 at unh.newhaven.edu Fri Dec 30 02:38:07 2016 From: rschm2 at unh.newhaven.edu (Schmicker, Robert) Date: Fri, 30 Dec 2016 02:38:07 +0000 Subject: [openssl-users] Linker error when adding new cipher to crypto folder Message-ID: <88322398-32FF-41C1-BD9B-A9C08746DEAA@unh.newhaven.edu> Hello, I am attempting to add a new cipher into the crypto library. I have done the following so far? 1. Added my code to the openssl/crypto folder 2. Created a build.info for make to compile my code (created this based off of openssl/crypto/dh?s build.info) 3. Added my cipher name to the list of ciphers to compile in Configure 4. Compiled and installed all code without errors and object files for my new cipher are created in openssl/crypto/mycipher/ 5. Created a test.c file that verifies that the library is installed and working properly by generating a MD5 hash of a string Compiled as: gcc test.c -I/usr/local/openssl/include/openssl/ -o test -lcrypto -lssl -Wall 6. I am able to properly include in my test.c file However, as soon as I make a call to my cipher in test.c I get a linker error and gcc is unable to find any of my functions. It seems that the header file I have in the openssl/include folder isn?t being linked somehow to my code in the openssl/cypto folder. I feel like I?m missing a step here? Any help is much appreciated! Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Fri Dec 30 19:43:12 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 30 Dec 2016 19:43:12 +0000 Subject: [openssl-users] Linker error when adding new cipher to crypto folder In-Reply-To: <88322398-32FF-41C1-BD9B-A9C08746DEAA@unh.newhaven.edu> References: <88322398-32FF-41C1-BD9B-A9C08746DEAA@unh.newhaven.edu> Message-ID: The header is irrelevant to linking, unless it contains macros that change the names of external symbols. My guess is that you need -L/usr/local/openssl/lib, or something along those lines, on your gcc command line. I suspect you're linking against normal OpenSSL libraries installed elsewhere on your system, and not against the ones you built. This is not specific to OpenSSL, by the way; it's all standard UNIX / Linux library use. Michael Wojcik Distinguished Engineer, Micro Focus From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Schmicker, Robert Sent: Thursday, December 29, 2016 21:38 To: openssl-users at openssl.org Subject: [openssl-users] Linker error when adding new cipher to crypto folder Hello, I am attempting to add a new cipher into the crypto library. I have done the following so far? 1. Added my code to the openssl/crypto folder 2. Created a build.info for make to compile my code (created this based off of openssl/crypto/dh?s build.info) 3. Added my cipher name to the list of ciphers to compile in Configure 4. Compiled and installed all code without errors and object files for my new cipher are created in openssl/crypto/mycipher/ 5. Created a test.c file that verifies that the library is installed and working properly by generating a MD5 hash of a string Compiled as: gcc test.c -I/usr/local/openssl/include/openssl/ -o test -lcrypto -lssl -Wall 6. I am able to properly include in my test.c file However, as soon as I make a call to my cipher in test.c I get a linker error and gcc is unable to find any of my functions. It seems that the header file I have in the openssl/include folder isn?t being linked somehow to my code in the openssl/cypto folder. I feel like I?m missing a step here? Any help is much appreciated! Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsmith at progress.com Fri Dec 30 20:09:44 2016 From: bsmith at progress.com (Bill Smith) Date: Fri, 30 Dec 2016 20:09:44 +0000 Subject: [openssl-users] openssl version -a bug in 1.1.0c ? Message-ID: Hi, I'm in the process of building 1.1.0c and noticed a behavior difference with "openssl version -a". The bug is that we're not seeing all of the compiler flags on the "compiler: " line. In the following example, we're not seeing: -q64 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst in the line compiler: ... With 1.1.0c, I see this: aix64:117$ /vobs_prgs/tools/aix64/openssl/bin/openssl version -a OpenSSL 1.1.0c 10 Nov 2016 built on: reproducible build, date unspecified platform: aix64-cc compiler: /usr/vac11/usr/vac/bin/xlc_r -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSL_PIC -DOPENSSLDIR="\"/vobs_prgs/tools/aix64/openssl/ssl\"" -DENGINESDIR="\"/vobs_prgs/tools/aix64/openssl/lib/engines-1.1\"" OPENSSLDIR: "/vobs_prgs/tools/aix64/openssl/ssl" ENGINESDIR: "/vobs_prgs/tools/aix64/openssl/lib/engines-1.1" aix64:117$ With 1.0.1m, I see this: aix64:117$ /vobs_prgs/src/openssl/aix64/bin/openssl version -a OpenSSL 1.0.1m 19 Mar 2015 built on: Tue Aug 30 09:59:40 2016 platform: aix64-cc options: bn(64,64) rc4(ptr,char) des(idx,cisc,2,long) idea(int) blowfish(idx) compiler: /usr/vac11/usr/vac/bin/xlc_r -I. -I.. -I../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q64 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst OPENSSLDIR: "/vobs_prgs/tools/aix64/openssl/ssl" aix64:117$ The 1.1.0c compile line: /usr/vac11/usr/vac/bin/xlc_r -I. -Icrypto/include -Iinclude -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSL_PIC -DOPENSSLDIR="\"/vobs_prgs/tools/aix64/openssl/ssl\"" -DENGINESDIR="\"/vobs_prgs/tools/aix64/openssl/lib/engines-1.1\"" -q64 -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -O -qthreaded -D_THREAD_SAFE -c -o crypto/aes/aes_cbc.o crypto/aes/aes_cbc.c The 1.0.1m compile line: /usr/vac11/usr/vac/bin/xlc_r -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q64 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -q64 -c -o aes_cbc.o aes_cbc.c The configure command line is: /scratch/bsmith/perl/install/aix64/bin/perl /vobs_prgs/tools/aix64/openssl/build/Configure --prefix=/vobs_prgs/tools/aix64/openssl enable-weak-ssl-ciphers enable-rc4 enable-deprecated no-shared no-asm aix64-cc; \ Configuring for aix64-cc CC =/usr/vac11/usr/vac/bin/xlc_r CFLAG =-q64 -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -O -qthreaded -D_THREAD_SAFE I didn't see any bug reports for this in Github. I'm seeing this behavior for HPUX and AIX. I didn't check Linux, Solaris, or Windows. From bsmith at progress.com Fri Dec 30 22:42:13 2016 From: bsmith at progress.com (Bill Smith) Date: Fri, 30 Dec 2016 22:42:13 +0000 Subject: [openssl-users] openssl 1.1.0c - cannot run Configure on Windows with a UNC pathname for perl Message-ID: <0bdb43464f224da68d0626d705546234@ntmaexbe04.bedford.progress.com> Hi, While trying to build openssl 1.1.0c on Windows, the configure step failed for me if I used a perl that is on a network share. Example: \\rdlserv\tools\nt\asperl-5.24.0\bin\perl ./Configure VC-WIN64A enable-weak-ssl-ciphers enable-rc4 enable-deprecated no-shared --prefix=z:\openssl\work\nt64\install -openssldir=z:\openssl\work\nt64\install It fails at the system call: my $cmd = "$perlcmd \"-I.\" \"-Mconfigdata\" \"$dofile\" -o\"Configure\" \"".join("\" \"", at templates)."\" > \"$out.new\""; #print STDERR "DEBUG[run_dofile]: \$cmd = $cmd\n"; system($cmd); inside the function "run_dofile" I looked at the $cmd string and it looks fine to me. It fails with an error "The specified path is invalid." The only way I could get a UNC pathname to work was to map the share to a drive letter. Example: net use p: \\rdlserv\tools\nt p:\asperl-5.24.0\bin\perl ./Configure VC-WIN64A enable-weak-ssl-ciphers enable-rc4 enable-deprecated no-shared --prefix=z:\openssl\work\nt64\install -openssldir=z:\openssl\work\nt64\install From kgoldman at us.ibm.com Sat Dec 31 01:20:38 2016 From: kgoldman at us.ibm.com (Ken Goldman) Date: Fri, 30 Dec 2016 20:20:38 -0500 Subject: [openssl-users] Raw EC key to EVP_PKEY to certificate Message-ID: My overall goal is to create an X509 certificate for an ECC public key. I am starting with the X and Y points. The curve is NIST_P256. Here's the basic code. Am I close? - EC_KEY ecKey = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1) - convert x and y from bin to bignum - EC_KEY_set_public_key_affine_coordinates(ecKey, x, y) - EVP_PUBKEY evpPubkey = EVP_PKEY_new() - EVP_PKEY_set1_EC_KEY(evpPubkey, ecKey); - X509_set_pubkey(x509Certificate, evpPubkey); I'm getting far more information that I suspect I need. See the two dumps below. My result looks like this: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:e7:de:55:b0:09:2f:0a:83:0a:c9:fc:f0:82:d7: 97:e0:4e:02:7d:75:08:44:74:3e:5f:b6:b3:29:3d: ad:69:b3:f4:c5:3d:65:ed:94:23:89:37:5c:d5:e5: 4c:0b:77:d4:55:f6:3c:83:24:27:fb:cb:21:dc:66: df:11:5d:ac:65 Field Type: prime-field Prime: 00:ff:ff:ff:ff:00:00:00:01:00:00:00:00:00:00: 00:00:00:00:00:00:ff:ff:ff:ff:ff:ff:ff:ff:ff: ff:ff:ff A: 00:ff:ff:ff:ff:00:00:00:01:00:00:00:00:00:00: 00:00:00:00:00:00:ff:ff:ff:ff:ff:ff:ff:ff:ff: ff:ff:fc B: 5a:c6:35:d8:aa:3a:93:e7:b3:eb:bd:55:76:98:86: bc:65:1d:06:b0:cc:53:b0:f6:3b:ce:3c:3e:27:d2: 60:4b Generator (uncompressed): 04:6b:17:d1:f2:e1:2c:42:47:f8:bc:e6:e5:63:a4: 40:f2:77:03:7d:81:2d:eb:33:a0:f4:a1:39:45:d8: 98:c2:96:4f:e3:42:e2:fe:1a:7f:9b:8e:e7:eb:4a: 7c:0f:9e:16:2b:ce:33:57:6b:31:5e:ce:cb:b6:40: 68:37:bf:51:f5 Order: 00:ff:ff:ff:ff:00:00:00:00:ff:ff:ff:ff:ff:ff: ff:ff:bc:e6:fa:ad:a7:17:9e:84:f3:b9:ca:c2:fc: 63:25:51 Cofactor: 1 (0x1) Seed: c4:9d:36:08:86:e7:04:93:6a:66:78:e1:13:9d:26: b7:81:9f:7e:90 while other certificates I see look like this: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:b2:72:2e:90:17:f8:19:2e:20:bb:cd:ee:fd:0a: c5:f8:79:9f:33:e2:e3:04:f5:54:2c:39:7d:bb:b7: 7d:d5:b4:51:38:02:df:f1:14:44:81:9f:1e:1d:e1: df:0e:4d:94:c8:15:26:5d:2a:96:9f:c2:dc:f0:c1: 3c:78:c1:1d:eb ASN1 OID: prime256v1 NIST CURVE: P-256 From openssl-users at dukhovni.org Sat Dec 31 01:27:38 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 30 Dec 2016 20:27:38 -0500 Subject: [openssl-users] Raw EC key to EVP_PKEY to certificate In-Reply-To: References: Message-ID: <719641EC-99FC-46D8-B84C-927EF0F0D880@dukhovni.org> > On Dec 30, 2016, at 8:20 PM, Ken Goldman wrote: > > - EC_KEY ecKey = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1) > - convert x and y from bin to bignum > - EC_KEY_set_public_key_affine_coordinates(ecKey, x, y) > - EVP_PUBKEY evpPubkey = EVP_PKEY_new() > - EVP_PKEY_set1_EC_KEY(evpPubkey, ecKey); > - X509_set_pubkey(x509Certificate, evpPubkey); Start with: EC_KEY *eckey = EC_KEY_new(); EC_GROUP *group = EC_GROUP_new_by_curve_name(NID_X9_62_prime256v1); EC_GROUP_set_asn1_flag(group, OPENSSL_EC_NAMED_CURVE); EC_KEY_set_group(eckey, group); ... -- Viktor. From fateme.hajikarami at gmail.com Sat Dec 31 06:04:54 2016 From: fateme.hajikarami at gmail.com (Fateme Hajikarami) Date: Sat, 31 Dec 2016 09:34:54 +0330 Subject: [openssl-users] Fwd: downgrade openssl In-Reply-To: References: <7661490D-2136-4968-8CCD-22ACE3B30FC2@dukhovni.org> Message-ID: Yes you are right, it is under develop version. thanks :) -------------- next part -------------- An HTML attachment was scrubbed... URL: