From Michael.Wojcik at microfocus.com Fri Sep 1 20:02:47 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 1 Sep 2017 20:02:47 +0000 Subject: [openssl-users] Internet Draft Guide to creating an EDSA PKI In-Reply-To: <151765c0-abea-814d-4565-7e3aaf099b8d@htt-consult.com> References: <151765c0-abea-814d-4565-7e3aaf099b8d@htt-consult.com> Message-ID: Bob, I just want to say thanks for producing this. Even if it never makes it out of I-D stage, there's a lot of useful information here. It would probably make a good addition to the OpenSSL wiki, too. -- Michael Wojcik Distinguished Engineer, Micro Focus From uri at ll.mit.edu Fri Sep 1 20:30:30 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 1 Sep 2017 20:30:30 +0000 Subject: [openssl-users] Internet Draft Guide to creating an EDSA PKI In-Reply-To: References: <151765c0-abea-814d-4565-7e3aaf099b8d@htt-consult.com> Message-ID: On 9/1/17, 16:26, "openssl-users on behalf of Michael Wojcik" wrote: > Bob, I just want to say thanks for producing this. Even if it never makes it out of I-D stage, there's a lot of useful information here. > > It would probably make a good addition to the OpenSSL wiki, too. +1 on both. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5211 bytes Desc: not available URL: From rgm at htt-consult.com Fri Sep 1 21:55:20 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Fri, 1 Sep 2017 17:55:20 -0400 Subject: [openssl-users] Internet Draft Guide to creating an EDSA PKI In-Reply-To: References: <151765c0-abea-814d-4565-7e3aaf099b8d@htt-consult.com> Message-ID: <277f49fe-9e42-2886-7359-79fbb422cc40@htt-consult.com> On 09/01/2017 04:30 PM, Blumenthal, Uri - 0553 - MITLL wrote: > On 9/1/17, 16:26, "openssl-users on behalf of Michael Wojcik" wrote: > >> Bob, I just want to say thanks for producing this. Even if it never makes it out of I-D stage, there's a lot of useful information here. >> >> It would probably make a good addition to the OpenSSL wiki, too. > > +1 on both. Rich indicated that he would link this I-D on the wiki. And I-Ds are 'forever'. So far there are a couple nits on the draft. Nothing on the body. One item that perhaps others might know of and can help... In the Security section I reference papers on problems with lack of randomness. I found the one paper that I really remember: https://factorable.net/weakkeys12.extended.pdf But perhaps there is a better site for this paper and perhaps people here know of more papers like this to put in the reference section.. Thanks Bob From rsalz at akamai.com Fri Sep 1 22:32:01 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 1 Sep 2017 22:32:01 +0000 Subject: [openssl-users] [openssl-dev] How to use BIO_do_connect(), blocking and non-blocking with timeout, coping with errors In-Reply-To: References: <69d6c8c3-c3ba-44f5-fad0-4b2294e210d3@siemens.com> Message-ID: FWIW, there?s a ?libtls? library from the libre folks that might be worth looking at. If you come up with useful snippets we can start by posting them to the wiki, for example -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgm at htt-consult.com Mon Sep 4 21:08:04 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Mon, 4 Sep 2017 17:08:04 -0400 Subject: [openssl-users] [openssl-dev] How to use BIO_do_connect(), blocking and non-blocking with timeout, coping with errors In-Reply-To: References: <69d6c8c3-c3ba-44f5-fad0-4b2294e210d3@siemens.com> Message-ID: Here is the URL for the paper fromusenix: https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final228.pdf I would like to find a more recent work as well. On 09/01/2017 06:32 PM, Salz, Rich via openssl-users wrote: > > FWIW, there?s a ?libtls? library from the libre folks that might be > worth looking at. > > If you come up with useful snippets we can start by posting them to > the wiki, for example > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.von.Oheimb at siemens.com Tue Sep 5 12:12:23 2017 From: David.von.Oheimb at siemens.com (David von Oheimb) Date: Tue, 5 Sep 2017 14:12:23 +0200 Subject: [openssl-users] [openssl-dev] How to use BIO_do_connect(), blocking and non-blocking with timeout, coping with errors In-Reply-To: References: <69d6c8c3-c3ba-44f5-fad0-4b2294e210d3@siemens.com> Message-ID: <687c5c90-0a7c-ab0a-3197-472975acc9af@siemens.com> /[ Further below I quote my first two messages including my original questions and tentative code,// //?since Cc'ing to openssl-users did not work when I tried first. In this way I hope to get further, // //?more detailed responses by people with specific experience on the issues I mentioned,// //?possibly even concrete feedback how to enhance my code or where to find a better solution. ]/ On 09/01/2017 06:32 PM, Salz, Rich via openssl-users wrote: > > FWIW, there?s a ?libtls? library from the libre folks that might be > worth looking at. > This looks very nice. Yet is this of any practical benefit when using OpenSSL? > If you come up with useful snippets we can start by posting them to > the wiki, for example > Which wiki do you mean? I could not find anything related on https://wiki.openssl.org/ Anyway, most people (including me) would not search through wikis for finding useful code, and it would be much more useful if code like the bio_connect() function I mentioned below was readily available within the OpenSSL libraries, in an official high-level API. /[ Since this is worth a topic of its own, I'll write more on this in my next email. ]/ More low-level code that is already used by the crypto lib itself (e.g., using select() in rand_unix.c) would be better packaged into abstractions within that library, for instance the socket_wait() function for waiting on a socket with a timeout that I proposed below. I'd contribute pull requests for those I'm aware of. On 29.08.2017 16:15, Salz, Rich via openssl-dev wrote: >> Getting the client connect right appears surprisingly messy when one >> needs to cope with all kinds of network error situations including >> domain name resolution issues and temporarily unreachable servers. >> Both indefinitely blocking and non-blocking behavior (i.e., connection >> attempts with and without a timeout) should be supported. > It is a complicated issue and hard to get right for all definitions of right for all applications ? Hmm - on the one hand, good to get confirmation that I did not just miss a simple way of out the maze, ... > A set of API?s that set up all the TLS ?metadata?, and took a connected socket might be a way through the maze. For example: > SSL *SSL_connection(int socket, const char *servername, ?whatever?) ... on the other hand, it's a pity that such a high-level API does not (yet) exist, at least not in OpenSSL. How about adding at least some clearly useful abstractions like the below socket_wait() function, which would reduce code duplication in the OpenSSL crypto lib and apps and help application developers? Maybe other OpenSSL users have specific experience on error and timeout handling for BIO_do_connect() etc. and can comment in more detail on the (approximate) solution, bio_connect(), that I gave below? On 28.08.2017 13:46, David von Oheimb wrote: > Hi all, > > I'm currently enhancing HTTP(S) clients based on OpenSSL in several > flavors, in particular a CMP client, which in turn uses simple HTTP > clients for contacting CRL distribution points or OCSP responders. > > Getting the client connect right appears surprisingly messy when one > needs to cope with all kinds of network error situations including > domain name resolution issues and temporarily unreachable servers. > Both indefinitely blocking and non-blocking behavior (i.e., connection > attempts with and without a timeout) should be supported. > > Since these are pretty general problems I wonder why there there is > rather limited support via generic higher-level OpenSSL or C library > functions, or at least I was unable to find it. Instead, the OpenSSL > apps contain code that calls BIO_do_connect directly (or the equivalent > BIO_do_handshake), in particular query_responder() in apps/ocsp.c. > (The situation is similar for the subsequent exchange of data via the > BIO, optionally with a timeout). > > So I constructed my own abstraction, called bio_connect, which took > quite some effort testing network error situations. Please see below its > code including comments on some strange behavior I experienced and my > workarounds for that. Does this code make sense, or do I miss anything? > > How about adding such a function for instance to crypto/bio/bio_lib.c? > > BTW, my code uses a handy generic helper function, socket_wait, for > waiting for read/write form/to a socket, with a given timeout. Since > several instances of that pretty common code pattern using select() are > spread over the OpenSSL apps (and crypto lib), I suggest adding this > function to the library. Where would be a good place to put it? > > Thanks, > David >> /* returns -1 on error, 0 on timeout, 1 on success */ >> int bio_connect(BIO *bio, int timeout) { >> int blocking; >> time_t max_time; >> int rv; >> >> blocking = timeout == 0; >> max_time = timeout != 0 ? time(NULL) + timeout : 0; >> >> if (!blocking) >> BIO_set_nbio(bio, 1); >> retry: >> rv = BIO_do_connect(bio); >> if (rv <= 0 && (errno == ETIMEDOUT /* in blocking case, >> despite blocking BIO, BIO_do_connect() timed out */ || >> ERR_GET_REASON(ERR_peek_error()) == ETIMEDOUT/* when non-blocking, >> BIO_do_connect() timed out early with rv == -1 and errno == 0 */)) { >> ERR_clear_error(); >> (void)BIO_reset(bio); /* otherwise, blocking next connect() may crash >> and non-blocking next BIO_do_connect() will fail */ >> goto retry; >> } >> if (!blocking && rv <= 0 && BIO_should_retry(bio)) { >> int fd; >> if (BIO_get_fd(bio, &fd) <= 0) >> return -1; >> rv = socket_wait(fd, 1, max_time - time(NULL)); >> if (rv > 0) >> /* for some reason, select() may wrongly have returned success */ >> goto retry; >> } >> return rv; >> } >> /* returns < 0 on error, 0 on timeout, >0 on success */ >> int socket_wait(int fd, int for_read, int timeout) >> { >> fd_set confds; >> struct timeval tv; >> >> if (timeout <= 0) >> return 0; >> >> FD_ZERO(&confds); >> openssl_fdset(fd, &confds); >> tv.tv_usec = 0; >> tv.tv_sec = timeout; >> return select(fd + 1, for_read ? &confds : NULL, >> for_read ? NULL : &confds, NULL, &tv); >> } -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.von.Oheimb at siemens.com Tue Sep 5 12:12:37 2017 From: David.von.Oheimb at siemens.com (David von Oheimb) Date: Tue, 5 Sep 2017 14:12:37 +0200 Subject: [openssl-users] Introduce a TLS application library - a proposal on the overall OpenSSL code structure In-Reply-To: References: Message-ID: Back on 13 May 2016 I had proposed by email to a couple of people including Rich Salz a third library level (on top of crypto and ssl) with more high-level, application-oriented code. His response was: > That is a really interesting idea. Please bring this up on openssl-dev mailing list. Then I posted that by mistake unfortunately not in the right forum but at: https://groups.google.com/forum/#!topic/mailing.openssl.dev/FOL2afc3cb8 I quote my post here for convenience: > So far, the OpenSSL code has essentially a three-level structure with > a hierarchy of two libraries and a command-line application at the top: > > apps/openssl > libssl > libcrypto > > In the apps/ directory there is various generally useful code like > handling crypto-related files and messages, general TLS client/server > and CA functionality, implementing parts of protocols like S/MIME, > CRL, and OCSP, and certainly more to come. > > While this code serves as a model for using the libraries and it can > be used in a limited way by invoking the openssl application binary, > it cannot be re-used directly. Other applications that need similar > functionality need to copy/re-implement and then maintain portions of > that code. > > On the other hand, the libraries contain some code that is actually > too high-level for them, for instance the minimal HTTP client as part > of the crypto library (crypto/ocsp/ocsp_ht.c). > > It would be very helpful to introduce a further level in the hierarchy > consisting of a more application-oriented library: > > apps/openssl > libtlsapps <-- new (with tentative name here) > libssl > libcrypto > > Then all more high-level and application support functionality will go > there. This would make much of the generally useful code that so far > resides in the apps/ folder directly accessible to other > ?applications at the programming level, i.e., in the form of a > library/API, with all the re-usability advantages that this brings. It > would also relieve libcrypto from more application-/high-level topics > like HTTP. > > This library would also form an ideal condensation point for further > high-level uses of TLS that may in the future get integrated with > OpenSSL, like CMP and EST implementations. I recently learned that LibreSSL already/meanwhile has something in this direction: * libtls : a new TLS library, designed to make it easier to write foolproof applications I believe this would be of great benefit also for OpenSSL itself. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgm at htt-consult.com Tue Sep 5 12:43:15 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Tue, 5 Sep 2017 08:43:15 -0400 Subject: [openssl-users] Testing OCSP with openssl Message-ID: <63a48d96-7c72-a9d5-e613-19125cb942c1@htt-consult.com> Jamie Nugyen's guide uses openssl to test OCSP with 'openssl ocsp': https://jamielinux.com/docs/openssl-certificate-authority/online-certificate-status-protocol.html What is unclear here is: Does openssl read the index.txt file once at startup, or does it read it with each query. From the way I read his guide it reads like index.txt is only read at startup. Also he recommends password protecting the keypair. That results in needing to provide the password at responder startup. Is this the 'normal' approach? Is the password provided in some other file (like a responder config file)? I am use to putting SQL passwords into php config files, not that I like that... thanks Bob From Michael.Wojcik at microfocus.com Tue Sep 5 13:10:49 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 5 Sep 2017 13:10:49 +0000 Subject: [openssl-users] Testing OCSP with openssl In-Reply-To: <63a48d96-7c72-a9d5-e613-19125cb942c1@htt-consult.com> References: <63a48d96-7c72-a9d5-e613-19125cb942c1@htt-consult.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Robert Moskowitz > Sent: Tuesday, September 05, 2017 08:43 > > Also he recommends password protecting the keypair. That results in > needing to provide the password at responder startup. Is this the > 'normal' approach? Is the password provided in some other file (like a > responder config file)? I am use to putting SQL passwords into php > config files, not that I like that... That's one of the oldest problems in IT security. Most approaches fall into one of three categories: - Specialized hardware. This was one of the original intended uses for Sun's JavaButton hardware token, back in the '90s, but the JavaButton never really took off. These days we have various flavors of HSMs which act as key vaults and signing servers - though then you have the problem of authenticating to the signing server, or if you offload all crypto operations, authenticating to the crypto server. TPMs (which are essentially integrated HSMs), smartcard readers, etc can also hold keys, but typically require some authentication by a human at system startup. - Attended startup with manual passphrase entry. The server can't start until someone enters the passphrase at the keyboard. - Passphrase or private key in a file for unattended startup, hopefully protected as well as possible by filesystem permissions, filesystem encryption, etc. This is obviously the weakest choice for key protection, since it has a wider threat tree (more paths for an attacker to make use of the private key) than the other two options. For general-purpose applications where you don't need particularly good performance, such as a moderate-volume web server, there are some very inexpensive hardware options. OpenSSL works well with the NitroKey HSM (via the PKCS#11 engine), for example. Things get tougher as you add requirements. -- Michael Wojcik Distinguished Engineer, Micro Focus From rgm at htt-consult.com Tue Sep 5 13:24:04 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Tue, 5 Sep 2017 09:24:04 -0400 Subject: [openssl-users] Testing OCSP with openssl In-Reply-To: References: <63a48d96-7c72-a9d5-e613-19125cb942c1@htt-consult.com> Message-ID: Michael, Thanks for this concise review. I look at it as the "Big Bang theory of Security". i.e. what comes first. And HOW DID we get those heavy metals beyond Iron? :) Bob On 09/05/2017 09:10 AM, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Robert Moskowitz >> Sent: Tuesday, September 05, 2017 08:43 >> >> Also he recommends password protecting the keypair. That results in >> needing to provide the password at responder startup. Is this the >> 'normal' approach? Is the password provided in some other file (like a >> responder config file)? I am use to putting SQL passwords into php >> config files, not that I like that... > That's one of the oldest problems in IT security. Most approaches fall into one of three categories: > > - Specialized hardware. This was one of the original intended uses for Sun's JavaButton hardware token, back in the '90s, but the JavaButton never really took off. These days we have various flavors of HSMs which act as key vaults and signing servers - though then you have the problem of authenticating to the signing server, or if you offload all crypto operations, authenticating to the crypto server. TPMs (which are essentially integrated HSMs), smartcard readers, etc can also hold keys, but typically require some authentication by a human at system startup. > > - Attended startup with manual passphrase entry. The server can't start until someone enters the passphrase at the keyboard. > > - Passphrase or private key in a file for unattended startup, hopefully protected as well as possible by filesystem permissions, filesystem encryption, etc. This is obviously the weakest choice for key protection, since it has a wider threat tree (more paths for an attacker to make use of the private key) than the other two options. > > For general-purpose applications where you don't need particularly good performance, such as a moderate-volume web server, there are some very inexpensive hardware options. OpenSSL works well with the NitroKey HSM (via the PKCS#11 engine), for example. Things get tougher as you add requirements. > From Elio.Gerardi at netapp.com Tue Sep 5 15:37:59 2017 From: Elio.Gerardi at netapp.com (Gerardi, Elio) Date: Tue, 5 Sep 2017 15:37:59 +0000 Subject: [openssl-users] Problem with Last step in setup Message-ID: I am getting the following error when I run the ?make install? command on OPenSSL make install /Library/Developer/CommandLineTools/usr/bin/make depend && /Library/Developer/CommandLineTools/usr/bin/make _all *** Installing development files Cannot create directory /usr/local/include: No such file or directory make: *** [install_dev] Error 2 Elio Gerardi ? Cloud Architect Hyperscaler GTM team Cloud Business Unit cloud.netapp.com NetApp 646.313.3079 Direct Phone 914.419.0396 Mobile Phone elio at netapp.com [cid:image001.jpg at 01D3263B.6C8D1E70] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 32060 bytes Desc: image001.jpg URL: From steve at openssl.org Tue Sep 5 15:59:29 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 5 Sep 2017 15:59:29 +0000 Subject: [openssl-users] Testing OCSP with openssl In-Reply-To: <63a48d96-7c72-a9d5-e613-19125cb942c1@htt-consult.com> References: <63a48d96-7c72-a9d5-e613-19125cb942c1@htt-consult.com> Message-ID: <20170905155929.GA2042@openssl.org> On Tue, Sep 05, 2017, Robert Moskowitz wrote: > Jamie Nugyen's guide uses openssl to test OCSP with 'openssl ocsp': > > https://jamielinux.com/docs/openssl-certificate-authority/online-certificate-status-protocol.html > > What is unclear here is: > > Does openssl read the index.txt file once at startup, or does it > read it with each query. From the way I read his guide it reads > like index.txt is only read at startup. > Once on startup. The mini-responder is only a test utility. It is not usable as a full blown responder. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rgm at htt-consult.com Tue Sep 5 16:06:03 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Tue, 5 Sep 2017 12:06:03 -0400 Subject: [openssl-users] Testing OCSP with openssl In-Reply-To: <20170905155929.GA2042@openssl.org> References: <63a48d96-7c72-a9d5-e613-19125cb942c1@htt-consult.com> <20170905155929.GA2042@openssl.org> Message-ID: <47d330cb-5130-40f0-3768-60f4dcb80284@htt-consult.com> On 09/05/2017 11:59 AM, Dr. Stephen Henson wrote: > On Tue, Sep 05, 2017, Robert Moskowitz wrote: > >> Jamie Nugyen's guide uses openssl to test OCSP with 'openssl ocsp': >> >> https://jamielinux.com/docs/openssl-certificate-authority/online-certificate-status-protocol.html >> >> What is unclear here is: >> >> Does openssl read the index.txt file once at startup, or does it >> read it with each query. From the way I read his guide it reads >> like index.txt is only read at startup. >> > Once on startup. The mini-responder is only a test utility. > It is not usable as a full blown responder. Oh, I got the test utility limitation. Just for my guide, after revoking the certificate which results in index.txt being updated, does the test 'openssl ocsp' service need to be restarted to reread the index.txt file? So from your response, just the once at startup, and I will have to specify (as Jamie does in his guide) to restart the test responder. I am searching for a 'simple' OCSP responder for myself... Thanks Bob From levitte at openssl.org Tue Sep 5 16:16:35 2017 From: levitte at openssl.org (Richard Levitte) Date: Tue, 05 Sep 2017 18:16:35 +0200 (CEST) Subject: [openssl-users] Problem with Last step in setup In-Reply-To: References: Message-ID: <20170905.181635.1745982711495035349.levitte@openssl.org> In message on Tue, 5 Sep 2017 15:37:59 +0000, "Gerardi, Elio" said: Elio.Gerardi> I am getting the following error when I run the ?make install? command on OPenSSL Elio.Gerardi> Elio.Gerardi> make install Elio.Gerardi> Elio.Gerardi> /Library/Developer/CommandLineTools/usr/bin/make depend && Elio.Gerardi> /Library/Developer/CommandLineTools/usr/bin/make _all Elio.Gerardi> Elio.Gerardi> *** Installing development files Elio.Gerardi> Elio.Gerardi> Cannot create directory /usr/local/include: No such file or directory Elio.Gerardi> Elio.Gerardi> make: *** [install_dev] Error 2 Is there a directory /usr/local on your system? Does the user your running 'make install' with have permission to write to the /usr/local directory? An alternative, if you have sudo privileges, is this: sudo make install Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From jb-openssl at wisemo.com Tue Sep 5 16:17:32 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 5 Sep 2017 18:17:32 +0200 Subject: [openssl-users] Problem with Last step in setup In-Reply-To: References: Message-ID: <4055a2c4-906a-bd1b-ba93-78e6f54ece07@wisemo.com> On 05/09/2017 17:37, Gerardi, Elio wrote: > > I am getting the following error when I run the ?make install? command > on OPenSSL > > make install > > /Library/Developer/CommandLineTools/usr/bin/make depend && > /Library/Developer/CommandLineTools/usr/bin/make _all > > *** Installing development files > > Cannot create directory /usr/local/include: No such file or directory > > make: *** [install_dev] Error 2 > Simple. The default "make install" location for most UNIX-style software is in the? /usr/local/ subtree.? The Linux community even created a standard explaining the typical layout of Linux, which is based on decades of UNIX tradition, with some choices made where traditions varied. The intended typical use is to run the other make steps as a build user, then running make install as someone with the (delegated) authority to write to /usr/local (e.g. membership of a 'staff' group). In the case of OpenSSL 0.9.x and 1.0.x, this value can be changed by passing --openssldir=/some/dir/of/your/choice to Configure, but unfortunately, this also causes the compiled code to expect things like openssl.cnf to be located beneath that directory on all machines where the binary code are run. 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 mcr at sandelman.ca Tue Sep 5 17:16:33 2017 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 05 Sep 2017 13:16:33 -0400 Subject: [openssl-users] Problem with Last step in setup In-Reply-To: References: Message-ID: <6796.1504631793@obiwan.sandelman.ca> Gerardi, Elio wrote: > I am getting the following error when I run the ?make install? command on > OPenSSL > make install > /Library/Developer/CommandLineTools/usr/bin/make depend && > /Library/Developer/CommandLineTools/usr/bin/make _all > *** Installing development files > Cannot create directory /usr/local/include: No such file or directory Probably because you don't have a /usr/local/include, and it isn't autocreated ("mkdir -p"), and you aren't running this as root. (maybe you want to install it some place other than /usr/local?) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From mahesh116 at gmail.com Wed Sep 6 05:02:28 2017 From: mahesh116 at gmail.com (mahesh gs) Date: Wed, 6 Sep 2017 10:32:28 +0530 Subject: [openssl-users] SSL_CTX_set_cipher_list returns failure for DHE-DSS-AES256-GCM-SHA384 Message-ID: Hi All, I am using openssl version 01.01.00f for providing TLS and DTLS security for TCP and SCTP connection for our application. I have query regarding the "Ciphers" that are accepted by the SSL_CTX_set_cpiher_list API. The list of ciphers that are supported by openssl version 01.01.00f that is output of command "openssl ciphers -v" is as listed down below. When i try to set these ciphers through API "SSL_CTX_set_cipher_list" returns success for some and failure for some other ciphers. For example if i set "ECDHE-RSA-AES256-GCM-SHA384" API returns success but if i set "DHE-DSS-AES256-GCM-SHA384" or "RC4-MD5" API returns failure. My query is what are the accepted ciphers ? and what is the reason behind not accepting some of them? *openssl ciphers -v* ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256 DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1 ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA384 ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA384 ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1 ECDH-ECDSA-AES256-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1 AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1 PSK-AES256-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA1 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128) Mac=SHA256 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1 ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1 DHE-RSA-SEED-SHA SSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1 DHE-DSS-SEED-SHA SSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1 DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1 DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1 EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD ECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA256 ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA256 ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA1 ECDH-ECDSA-AES128-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA1 ECDH-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1 ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1 AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 SEED-SHA SSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1 CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1 DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 IDEA-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1 PSK-AES128-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA1 PSK-3DES-EDE-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=3DES(168) Mac=SHA1 KRB5-IDEA-CBC-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=IDEA(128) Mac=SHA1 KRB5-DES-CBC3-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=3DES(168) Mac=SHA1 KRB5-IDEA-CBC-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=IDEA(128) Mac=MD5 KRB5-DES-CBC3-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=3DES(168) Mac=MD5 ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1 ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1 ECDH-RSA-RC4-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128) Mac=SHA1 ECDH-ECDSA-RC4-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128) Mac=SHA1 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 PSK-RC4-SHA SSLv3 Kx=PSK Au=PSK Enc=RC4(128) Mac=SHA1 KRB5-RC4-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=SHA1 KRB5-RC4-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=MD5 Thanks & Regards, Mahesh G S -------------- next part -------------- An HTML attachment was scrubbed... URL: From grace.priscilla at gmail.com Wed Sep 6 05:10:00 2017 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Wed, 6 Sep 2017 10:40:00 +0530 Subject: [openssl-users] Query on usage of openssl 1.1.0f with openssl-FIPS Message-ID: Hi All, We would want to build our openssl 1.1.0f with FIPS but we noticed it is mentioned as ?The 2.0 FIPS module is compatible with OpenSSL releases 1.0.1 and 1.0.2, and no others?. I am unable to find the openssl-fips module for 1.1.0f. Do you know when it will be available? Could you please let us know the latest openssl 1.0 version that can be compiled with ?openssl-fips-2.0.16?? Also, please let know if that version supports DTLS. Thanks, Grace -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Wed Sep 6 08:12:02 2017 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 6 Sep 2017 11:12:02 +0300 Subject: [openssl-users] ASN1_TIME to time_t Message-ID: Hello, Is there a way to convert ASN1_TIME to time_t or smth compatible? Quick googling does not show good results. Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Sep 6 08:16:24 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 6 Sep 2017 09:16:24 +0100 Subject: [openssl-users] ASN1_TIME to time_t In-Reply-To: References: Message-ID: <0a8048bf-4e0a-9cd6-7777-476ffb58c76f@openssl.org> On 06/09/17 09:12, Dmitry Belyavsky wrote: > Hello, > > Is there a way to convert ASN1_TIME to time_t or smth compatible? Quick > googling does not show good results. In master you can use ASN1_TIME_to_tm() which will give you a struct tm. Not available in released versions yet though. Matt From beldmit at gmail.com Wed Sep 6 08:20:37 2017 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 6 Sep 2017 11:20:37 +0300 Subject: [openssl-users] ASN1_TIME to time_t In-Reply-To: <0a8048bf-4e0a-9cd6-7777-476ffb58c76f@openssl.org> References: <0a8048bf-4e0a-9cd6-7777-476ffb58c76f@openssl.org> Message-ID: Dear Matt, On Wed, Sep 6, 2017 at 11:16 AM, Matt Caswell wrote: > > > On 06/09/17 09:12, Dmitry Belyavsky wrote: > > Hello, > > > > Is there a way to convert ASN1_TIME to time_t or smth compatible? Quick > > googling does not show good results. > > In master you can use ASN1_TIME_to_tm() which will give you a struct tm. > Not available in released versions yet though. > Is it implementable via API in 1.0.2? -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Sep 6 08:23:26 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 6 Sep 2017 09:23:26 +0100 Subject: [openssl-users] ASN1_TIME to time_t In-Reply-To: References: <0a8048bf-4e0a-9cd6-7777-476ffb58c76f@openssl.org> Message-ID: <80071aad-ef69-1428-bff4-918fb30f37cb@openssl.org> On 06/09/17 09:20, Dmitry Belyavsky wrote: > Dear Matt, > > On Wed, Sep 6, 2017 at 11:16 AM, Matt Caswell > wrote: > > > > On 06/09/17 09:12, Dmitry Belyavsky wrote: > > Hello, > > > > Is there a way to convert ASN1_TIME to time_t or smth compatible? Quick > > googling does not show good results. > > In master you can use ASN1_TIME_to_tm() which will give you a struct tm. > Not available in released versions yet though. > > > Is it implementable via API in 1.0.2? Probably (not checked in detail), but you'd have to copy the implementation into your code. See asn1_time_to_tm() in crypto/asn1/a_time.c in master. Matt From Michael.Wojcik at microfocus.com Wed Sep 6 12:17:32 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 6 Sep 2017 12:17:32 +0000 Subject: [openssl-users] ASN1_TIME to time_t In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Dmitry Belyavsky > Sent: Wednesday, September 06, 2017 04:12 > Is there a way to convert ASN1_TIME to time_t or smth compatible? Quick googling does not show good results. We just implemented it ourselves, by parsing the data field of the (1.0.2) OpenSSL ASN1_TIME structure into a struct tm and using mktime. That's not ideal, since it's looking at an internal representation. Also, for some reason, 1.0.2 seems to keep the year as a two-digit value for ASN.1 UTC Time, with a window centered on 1970, while it uses a 4-digit year for ASN.1 Generalized Time. The code handles that but it makes me nervous - it's the sort of internal detail that seems likely to change. struct tm is local time, so you need to adjust for timezone. With Generalized Time you need to parse the offset from UTC; then you adjust your struct tm based on the difference between the ASN.1 time's offset and your local offset. I should really review that code at some point. But for now it appears to work. Michael Wojcik Distinguished Engineer, Micro Focus From bkaduk at akamai.com Wed Sep 6 12:47:22 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Wed, 6 Sep 2017 07:47:22 -0500 Subject: [openssl-users] SSL_CTX_set_cipher_list returns failure for DHE-DSS-AES256-GCM-SHA384 In-Reply-To: References: Message-ID: <2b57d0c8-0aeb-1852-8e6b-2900cabb2b3d@akamai.com> On 09/06/2017 12:02 AM, mahesh gs wrote: > Hi All, > > I am using openssl version 01.01.00f for providing TLS and DTLS > security for TCP and SCTP connection for our application. I have query > regarding the "Ciphers" that are accepted by the > SSL_CTX_set_cpiher_list API. The list of ciphers that are supported by > openssl version 01.01.00f that is output of command "openssl ciphers > -v" is as listed down below. When i try to set these ciphers through > API "SSL_CTX_set_cipher_list" returns success for some and failure for > some other ciphers. > > For example if i set "ECDHE-RSA-AES256-GCM-SHA384" API returns success > but if i set "DHE-DSS-AES256-GCM-SHA384" or "RC4-MD5" API returns > failure. My query is what are the accepted ciphers ? and what is the > reason behind not accepting some of them? > OpenSSL 1.1.0 added a concept of "security level" for ciphers; see https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_security_level for which levels correspond to bits of security, prohibited message digests, etc. -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Sep 6 13:27:22 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 6 Sep 2017 15:27:22 +0200 Subject: [openssl-users] ASN1_TIME to time_t In-Reply-To: References: Message-ID: <78b4a107-4493-599c-0b8a-6801ed5c98d2@wisemo.com> On 06/09/2017 14:17, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Dmitry Belyavsky >> Sent: Wednesday, September 06, 2017 04:12 >> Is there a way to convert ASN1_TIME to time_t or smth compatible? Quick googling does not show good results. > We just implemented it ourselves, by parsing the data field of the (1.0.2) OpenSSL ASN1_TIME structure into a struct tm and using mktime. > > That's not ideal, since it's looking at an internal representation. Also, for some reason, 1.0.2 seems to keep the year as a two-digit value for ASN.1 UTC Time, with a window centered on 1970, while it uses a 4-digit year for ASN.1 Generalized Time. The code handles that but it makes me nervous - it's the sort of internal detail that seems likely to change. Really?? I thought the standard window for the two-digit representation in the DER/BER encoding was centered on 2000, at least in certificates. But I may be mistaken. > struct tm is local time, so you need to adjust for timezone. With Generalized Time you need to parse the offset from UTC; then you adjust your struct tm based on the difference between the ASN.1 time's offset and your local offset. It's not as much struct tm, as it is the mktime() API.? If available, try the BSD/GNU API timegm(), although that is officially "obsolete". Or you could go pure C and use the integer arithmetic that converts broken-down Gregorian dates to a day count since an arbitrary base, either the Gauss formula, or something based on: ?((month < 3u ? month - 3u : month + 9u) * 367u + Yu) / 12u + mday (Y is a single digit constant, forgot which). (That particular formula is my reconstruction of how the calendar was probably designed by the advisor to Julius Caesar: Worst case year is 367 days, divide equally among 12 months, restart about 20 days before spring equinox, use a historic rounding rule represented by Y. Of cause with Roman numerals, they would have used (month - 2)). 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 rsalz at akamai.com Wed Sep 6 13:48:34 2017 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 6 Sep 2017 13:48:34 +0000 Subject: [openssl-users] Query on usage of openssl 1.1.0f with openssl-FIPS In-Reply-To: References: Message-ID: ? I am unable to find the openssl-fips module for 1.1.0f. Do you know when it will be available? We have no date. Work hasn?t fully started, and isn?t fully funded. Perhaps your company would like to help? :) See our blog for updates (look in the archive for postings with FIPS in the title; https://www.openssl.org/blog ) ? Could you please let us know the latest openssl 1.0 version that can be compiled with ?openssl-fips-2.0.16?? 1.0.2, latest release. > Also, please let know if that version supports DTLS. I think no, but am not positive. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andrew_Porter at bmc.com Wed Sep 6 13:55:47 2017 From: Andrew_Porter at bmc.com (Porter, Andrew) Date: Wed, 6 Sep 2017 13:55:47 +0000 Subject: [openssl-users] Query on usage of openssl 1.1.0f with openssl-FIPS In-Reply-To: References: Message-ID: <4897d355c8214c5e97ee2bbc221d340b@phx-exmbprd-02.adprod.bmc.com> Support for DTLS 1.2 was one of the major changes from 1.0.1 to 1.0.2, see https://www.openssl.org/news/openssl-1.0.2-notes.html From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich via openssl-users Sent: Wednesday, September 06, 2017 06:49 To: openssl-users at openssl.org Subject: Re: [openssl-users] Query on usage of openssl 1.1.0f with openssl-FIPS ? I am unable to find the openssl-fips module for 1.1.0f. Do you know when it will be available? We have no date. Work hasn?t fully started, and isn?t fully funded. Perhaps your company would like to help? :) See our blog for updates (look in the archive for postings with FIPS in the title; https://www.openssl.org/blog ) ? Could you please let us know the latest openssl 1.0 version that can be compiled with ?openssl-fips-2.0.16?? 1.0.2, latest release. > Also, please let know if that version supports DTLS. I think no, but am not positive. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Elio.Gerardi at netapp.com Wed Sep 6 14:20:34 2017 From: Elio.Gerardi at netapp.com (Gerardi, Elio) Date: Wed, 6 Sep 2017 14:20:34 +0000 Subject: [openssl-users] Problem with Last step in setup In-Reply-To: <6796.1504631793@obiwan.sandelman.ca> References: <6796.1504631793@obiwan.sandelman.ca> Message-ID: <9F87F389-8E17-47C2-88E2-E103749C164C@netapp.com> Looks like changing to root did it?.Sometimes when your string at the screen for hours doing other things, the answer passes you by?.Thanks for the support Elio Gerardi ? Cloud Architect Hyperscaler GTM team Cloud Business Unit cloud.netapp.com NetApp 646.313.3079 Direct Phone 914.419.0396 Mobile Phone elio at netapp.com On 9/5/17, 1:16 PM, "openssl-users on behalf of Michael Richardson" wrote: Gerardi, Elio wrote: > I am getting the following error when I run the ?make install? command on > OPenSSL > make install > /Library/Developer/CommandLineTools/usr/bin/make depend && > /Library/Developer/CommandLineTools/usr/bin/make _all > *** Installing development files > Cannot create directory /usr/local/include: No such file or directory Probably because you don't have a /usr/local/include, and it isn't autocreated ("mkdir -p"), and you aren't running this as root. (maybe you want to install it some place other than /usr/local?) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From georg.hoellrigl at gmx.at Wed Sep 6 14:18:21 2017 From: georg.hoellrigl at gmx.at (=?UTF-8?Q?=22Georg_H=C3=B6llrigl=22?=) Date: Wed, 6 Sep 2017 16:18:21 +0200 Subject: [openssl-users] openssl -check Message-ID: An HTML attachment was scrubbed... URL: From steve at openssl.org Wed Sep 6 14:26:19 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 6 Sep 2017 14:26:19 +0000 Subject: [openssl-users] ASN1_TIME to time_t In-Reply-To: References: <0a8048bf-4e0a-9cd6-7777-476ffb58c76f@openssl.org> Message-ID: <20170906142619.GA21327@openssl.org> On Wed, Sep 06, 2017, Dmitry Belyavsky wrote: > Dear Matt, > > On Wed, Sep 6, 2017 at 11:16 AM, Matt Caswell wrote: > > > > > > > On 06/09/17 09:12, Dmitry Belyavsky wrote: > > > Hello, > > > > > > Is there a way to convert ASN1_TIME to time_t or smth compatible? Quick > > > googling does not show good results. > > > > In master you can use ASN1_TIME_to_tm() which will give you a struct tm. > > Not available in released versions yet though. > > > > Is it implementable via API in 1.0.2? > No but there is a a round about way of achieving the same result. The ASN1_TIME_diff() function will determine the difference between two ASN1_TIME structures and return the result as a number of days and seconds. So if you set one to the epoch time you can then calculate the time_t from the difference. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From Michael.Wojcik at microfocus.com Wed Sep 6 15:00:26 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 6 Sep 2017 15:00:26 +0000 Subject: [openssl-users] ASN1_TIME to time_t In-Reply-To: <20170906142619.GA21327@openssl.org> References: <0a8048bf-4e0a-9cd6-7777-476ffb58c76f@openssl.org> <20170906142619.GA21327@openssl.org> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Dr. Stephen Henson > Sent: Wednesday, September 06, 2017 10:26 > > No but there is a a round about way of achieving the same result. The > ASN1_TIME_diff() function will determine the difference between two > ASN1_TIME structures and return the result as a number of days and seconds. > > So if you set one to the epoch time you can then calculate the time_t from > the difference. That's almost certainly a much better approach than the one I described in my previous email. I assume ASN1_TIME_diff takes into account ASN.1 UTC Time versus Generalized Time, and timezone information. Though it wouldn't be hard to have a few different ASN1_TIME structures for the various permutations. -- Michael Wojcik Distinguished Engineer, Micro Focus From Michael.Wojcik at microfocus.com Wed Sep 6 15:00:24 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 6 Sep 2017 15:00:24 +0000 Subject: [openssl-users] ASN1_TIME to time_t In-Reply-To: <78b4a107-4493-599c-0b8a-6801ed5c98d2@wisemo.com> References: <78b4a107-4493-599c-0b8a-6801ed5c98d2@wisemo.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Jakob Bohm > Sent: Wednesday, September 06, 2017 09:27 > > On 06/09/2017 14:17, Michael Wojcik wrote: > > > struct tm is local time, so you need to adjust for timezone. > > It's not as much struct tm, as it is the mktime() API. Of course you're right. >? If available, try the BSD/GNU API timegm(), although that is > officially "obsolete". We need much wider platform compatibility. It's not a big deal, though. -- Michael Wojcik Distinguished Engineer, Micro Focus From jb-openssl at wisemo.com Wed Sep 6 16:06:51 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 6 Sep 2017 18:06:51 +0200 Subject: [openssl-users] openssl -check In-Reply-To: References: Message-ID: On 06/09/2017 16:18, "Georg H?llrigl" wrote: > Hello, > Is there a way to verifiy a cert? > I'm thinking about some equivalent to > openssl rsa -noout -in example.key -check > but for the public part. > I found some broken certifiate (lines in the PEM encoding got swapped) > openssl x509 -in broken.cer but see no way to verify... > compareing with the original cert shows different thumbprint... but > shouldn't there be some kind of checksum to verify? The signature on a certificate is a very strong checksum. For certificates that are not self-signed, openssl x509 -verify should do it. 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 steve at openssl.org Wed Sep 6 16:23:26 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 6 Sep 2017 16:23:26 +0000 Subject: [openssl-users] ASN1_TIME to time_t In-Reply-To: References: <0a8048bf-4e0a-9cd6-7777-476ffb58c76f@openssl.org> <20170906142619.GA21327@openssl.org> Message-ID: <20170906162326.GA23432@openssl.org> On Wed, Sep 06, 2017, Michael Wojcik wrote: > > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > > Of Dr. Stephen Henson > > Sent: Wednesday, September 06, 2017 10:26 > > > > No but there is a a round about way of achieving the same result. The > > ASN1_TIME_diff() function will determine the difference between two > > ASN1_TIME structures and return the result as a number of days and seconds. > > > > So if you set one to the epoch time you can then calculate the time_t from > > the difference. > > That's almost certainly a much better approach than the one I described in my previous email. > > I assume ASN1_TIME_diff takes into account ASN.1 UTC Time versus Generalized Time, and timezone information. Though it wouldn't be hard to have a few different ASN1_TIME structures for the various permutations. > Yes ASN1_TIME corresponds to the ASN.1 Time structure which ia a choice of UTCTime and GeneralizedTime it acts in an appropriate way depending on the type that has been passed in. Timezones should be handled properly though there was a recent bug fixed: timezones are only rarely encountered in practice and not legal in many standards (e.g. RFC5280). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rgm at htt-consult.com Wed Sep 6 16:23:11 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Wed, 6 Sep 2017 12:23:11 -0400 Subject: [openssl-users] Env variables in config file to add a whole line Message-ID: I am trying to use an environment variable to add a whole line to the config file. This is to control adding (or not providing) CRL and/or OCSP support. export shows: declare -x crlDP="crlDistributionPoints = URI:http://www.htt-consult.com/pki/intermediate.crl.pem" declare -x default_crl_days="default_crl_days = 30" declare -x ocspIAI="authorityInfoAccess = OCSP;URI:http://ocsp.htt-consult.com" The config file starts with: [ ca ] # `man ca` default_ca = CA_default [ CA_default ] # Directory and file locations. dir= $ENV::dir cadir = $ENV::cadir format= $ENV::format crlDP = $ENV::crlDP default_crl_days = $ENV::default_crl_days ocspIAI = $ENV::ocspIAI The usr_cert section has: [ usr_cert ] # Extensions for client certificates (`man x509v3_config`). basicConstraints = CA:FALSE nsCertType = client, email nsComment = "OpenSSL Generated Client Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer keyUsage = critical,nonRepudiation,digitalSignature,keyEncipherment extendedKeyUsage = clientAuth, emailProtection $crlDP $ocspIAI Note that the line with "$crlDP" is line 123 When I run the command: openssl req -config $dir/openssl-intermediate.cnf -key $dir/private/$serverfqdn.key.$format -subj "$DN" -new -sha256 -out $dir/csr/$serverfqdn.csr.$format I get the error: req: Error on line 123 of config file "/home/rgm/ca/intermediate/openssl-intermediate.cnf" unable to find 'distinguished_name' in config problems making Certificate Request 3070145488:error:0E06D06A:configuration file routines:NCONF_get_string:no conf or environment variable:crypto/conf/conf_lib.c:272: note that if I: grep -n distinguished_name openssl-intermediate.cnf 68:distinguished_name = req_distinguished_name 78:[ req_distinguished_name ] So the warning about unable to find 'distinguished_name' in config Is misleading. The problem is more likely with line 123 which is only the env variable. I can play around with this and hopefully the variables to work as crlDistributionPoints = $crlDP And if $crlDP is empty, it will not put an empty value into the cert. But why does what I have not work? thanks Bob From rgm at htt-consult.com Wed Sep 6 16:55:27 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Wed, 6 Sep 2017 12:55:27 -0400 Subject: [openssl-users] Env variables in config file to add a whole line In-Reply-To: References: Message-ID: I got past the error to build the CSR by using: crlDistributionPoints = $ENV::crlDP authorityInfoAccess = $ENV::ocspIAI Just $crlDP failed even though I had this defined in the [ca} section. The CSR does not use the user_cert or server_cert. This was 'just' a config file syntax issue. When I try to make the cert I get the following: crlDP=URI:http://www.htt-consult.com/pki/intermediate.crl.pem default_crl_days=30 ocspIAI="OCSP;URI:http://ocsp.htt-consult.com" openssl ca -config $dir/openssl-intermediate.cnf -days 375\ -extensions server_cert -notext -md sha256 \ -in $dir/csr/$serverfqdn.csr.$format\ -out $dir/certs/$serverfqdn.cert.$format It works. But if I DON'T want a CRL or OCSP support and I use: crlDP= ocspIAI= with the same command I get: Error Loading extension section server_cert 3069510608:error:0E06D06C:configuration file routines:NCONF_get_string:no value:crypto/conf/conf_lib.c:275:group=CA_default name=email_in_dn 3069510608:error:2206D06C:X509 V3 routines:X509V3_parse_list:invalid null name:crypto/x509v3/v3_utl.c:316: 3069510608:error:22097069:X509 V3 routines:do_ext_nconf:invalid extension string:crypto/x509v3/v3_conf.c:93:name=crlDistributionPoints,section= 3069510608:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:crypto/x509v3/v3_conf.c:47:name=crlDistributionPoints, value= So I need a way to have a 'null' value for NO CRL or NO OCSP. I don't want to have to use SED to edit the config file based on what the goal is... thanks Bob On 09/06/2017 12:23 PM, Robert Moskowitz wrote: > I am trying to use an environment variable to add a whole line to the > config file. This is to control adding (or not providing) CRL and/or > OCSP support. > > export shows: > > declare -x crlDP="crlDistributionPoints = > URI:http://www.htt-consult.com/pki/intermediate.crl.pem" > declare -x default_crl_days="default_crl_days = 30" > declare -x ocspIAI="authorityInfoAccess = > OCSP;URI:http://ocsp.htt-consult.com" > > The config file starts with: > > > [ ca ] > # `man ca` > default_ca = CA_default > > [ CA_default ] > # Directory and file locations. > dir= $ENV::dir > cadir = $ENV::cadir > format= $ENV::format > crlDP = $ENV::crlDP > default_crl_days = $ENV::default_crl_days > ocspIAI = $ENV::ocspIAI > > > The usr_cert section has: > > [ usr_cert ] > # Extensions for client certificates (`man x509v3_config`). > basicConstraints = CA:FALSE > nsCertType = client, email > nsComment = "OpenSSL Generated Client Certificate" > subjectKeyIdentifier = hash > authorityKeyIdentifier = keyid,issuer > keyUsage = critical,nonRepudiation,digitalSignature,keyEncipherment > extendedKeyUsage = clientAuth, emailProtection > $crlDP > $ocspIAI > > Note that the line with "$crlDP" is line 123 > > When I run the command: > > openssl req -config $dir/openssl-intermediate.cnf -key > $dir/private/$serverfqdn.key.$format -subj "$DN" -new -sha256 > -out $dir/csr/$serverfqdn.csr.$format > > I get the error: > > req: Error on line 123 of config file > "/home/rgm/ca/intermediate/openssl-intermediate.cnf" > unable to find 'distinguished_name' in config > problems making Certificate Request > 3070145488:error:0E06D06A:configuration file > routines:NCONF_get_string:no conf or environment > variable:crypto/conf/conf_lib.c:272: > > note that if I: > > grep -n distinguished_name openssl-intermediate.cnf > > 68:distinguished_name = req_distinguished_name > 78:[ req_distinguished_name ] > > So the warning about unable to find 'distinguished_name' in config > > Is misleading. The problem is more likely with line 123 which is only > the env variable. > > I can play around with this and hopefully the variables to work as > > crlDistributionPoints = $crlDP > > And if $crlDP is empty, it will not put an empty value into the cert. > But why does what I have not work? > > thanks > > Bob > From rsalz at akamai.com Wed Sep 6 17:31:34 2017 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 6 Sep 2017 17:31:34 +0000 Subject: [openssl-users] Env variables in config file to add a whole line In-Reply-To: References: Message-ID: <6D2AFE41-03A3-456C-BA8D-8A96B1B48A76@akamai.com> ? $crlDP $ocspIAI This is not supported. You can only put variables in *values* From rgm at htt-consult.com Wed Sep 6 17:34:14 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Wed, 6 Sep 2017 13:34:14 -0400 Subject: [openssl-users] Env variables in config file to add a whole line In-Reply-To: <6D2AFE41-03A3-456C-BA8D-8A96B1B48A76@akamai.com> References: <6D2AFE41-03A3-456C-BA8D-8A96B1B48A76@akamai.com> Message-ID: On 09/06/2017 01:31 PM, Salz, Rich via openssl-users wrote: > ? > > $crlDP > $ocspIAI > > > This is not supported. You can only put variables in *values* OK. But now I have to work out values. Bob From jb-openssl at wisemo.com Wed Sep 6 18:55:12 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 6 Sep 2017 20:55:12 +0200 Subject: [openssl-users] Env variables in config file to add a whole line In-Reply-To: References: <6D2AFE41-03A3-456C-BA8D-8A96B1B48A76@akamai.com> Message-ID: <4d3f7a93-325a-34d9-600c-bf531066f74e@wisemo.com> On 06/09/2017 19:34, Robert Moskowitz wrote: > > > On 09/06/2017 01:31 PM, Salz, Rich via openssl-users wrote: >> ? >> >> ???? $crlDP >> ???? $ocspIAI >> >> This is not supported.? You can only put variables in *values* > > OK.? But now I have to work out values. > > Bob > As previously, have a set of "certificate profiles" (other CA products name), in the form of different [foo_ext] and [policy_foo] sections in the CA's openssl.cnf, then run "openssl ca -extensions foo_ext -policy policy_foo ..." Since each CA needs its own directory anyway, each CA would have its own openssl.cnf (generated by a script that sets up the CA). For example, "foo" could be "server" (has crl and ocsp, plus other relevant settings), "client" (has crl and ocsp, plus different relevant settings), "ocsp-signer" (no crl, no ocsp, short lifespan, other relevant settings), "ecu" (has crl and ocsp, plus different settings again), etc. etc. Very different certificate purposes should ideally have their own SubCA's that can be managed differently, and have the CA cert restricted. 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 georg.hoellrigl at gmx.at Thu Sep 7 05:58:08 2017 From: georg.hoellrigl at gmx.at (=?UTF-8?Q?=22Georg_H=C3=B6llrigl=22?=) Date: Thu, 7 Sep 2017 07:58:08 +0200 Subject: [openssl-users] openssl -check In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Thu Sep 7 09:45:16 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 7 Sep 2017 11:45:16 +0200 Subject: [openssl-users] openssl -check In-Reply-To: References: Message-ID: <72b0d394-92cf-62c5-2282-ad1b2d9f9ecc@wisemo.com> On 07/09/2017 07:58, "Georg H?llrigl" wrote: > *Gesendet:*?Mittwoch, 06. September 2017 um 18:06 Uhr > *Von:*?"Jakob Bohm" > *An:*?openssl-users at openssl.org > *Betreff:*?Re: [openssl-users] openssl -check > On 06/09/2017 16:18, "Georg H?llrigl" wrote: > > Hello, > > Is there a way to verifiy a cert? > > I'm thinking about some equivalent to > > openssl rsa -noout -in example.key -check > > but for the public part. > > I found some broken certifiate (lines in the PEM encoding got swapped) > > openssl x509 -in broken.cer but see no way to verify... > > compareing with the original cert shows different thumbprint... but > > shouldn't there be some kind of checksum to verify? > The signature on a certificate is a very strong checksum. > > For certificates that are not self-signed, openssl x509 -verify should > do it. > Agreed. That would be exactly what I had in mind - but it's not working. > -verify only exists for "openssl req" to check a CSR? > I've created an example broken certificate from google: > Sorry, I got the syntax wrong. It's simply openssl verify 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 carloscaraccia at gmail.com Thu Sep 7 12:02:29 2017 From: carloscaraccia at gmail.com (Carlos Caraccia) Date: Thu, 7 Sep 2017 07:02:29 -0500 Subject: [openssl-users] SMIME -sign subcommand Message-ID: <1ADCF931-EDB4-4B98-AB3F-E36A20445E4E@gmail.com> Hello, is there a way to debug or watch line by line which functions are executed when I run a this command: openssl smime -sign -signer certificadoWSASS.cer -inkey MiClave -out ticket.xml.cms -in Ticket.xml -outform PEM -nodetach I know there I can see the smile.c here /apps I want to know how to compile if it is possible to compile it and to run it in Xcode and watch step by step the functions involved. Thanks Carlos -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Thu Sep 7 12:43:29 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 7 Sep 2017 14:43:29 +0200 Subject: [openssl-users] SMIME -sign subcommand In-Reply-To: <1ADCF931-EDB4-4B98-AB3F-E36A20445E4E@gmail.com> References: <1ADCF931-EDB4-4B98-AB3F-E36A20445E4E@gmail.com> Message-ID: On 07/09/2017 14:02, Carlos Caraccia wrote: > Hello, is there a way to debug or watch line by line which functions > are executed when I run a this command: > > openssl smime -sign -signer certificadoWSASS.cer -inkey MiClave -out > ticket.xml.cms -in Ticket.xml -outform PEM -nodetach > > I know there I can see the smile.c here > > /apps > > I want to know how to compile if it is possible to compile it and to > run it in Xcode and watch step by step the functions involved. > Get the source code from https://www.openssl.org/source/ Build it for your Mac using commands such as: (Note these steps are based on a build script for OpenSSL 1.0.2k) tar xzf openssl-1.something.tar.gz cd openssl-1.something CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang export CC MACOSX_SDK=/Developer/SDKs/MacOSX10.12.sdk [ -d ${MACOSX_SDK} ] || MACOSX_SDK=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk ./Configure debug-darwin64-x86_64-cc --openssldir="$(pwd)-x86_64" perl -i -pe 's|static volatile sig_atomic_t intr_signal|static volatile int intr_signal|' crypto/ui/ui_openssl.c perl -i -pe "s|^CC= gcc|CC= ${CC} -arch x86_64 -mmacosx-version-min=10.6|g" Makefile perl -i -pe "s|^CFLAG= |CFLAG= -arch x86_64 -mmacosx-version-min=10.6 -isysroot ${MACOSX_SDK} |g" Makefile make MAKEDEPPROG=${CC} depend make make test make install Now debug the program in openssl-1.something-x86_64/bin/openssl (Sorry, I don't know how to tell XCode to debug a program already compiled with the XCode command line clang) 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 scott_n at xypro.com Thu Sep 7 15:36:49 2017 From: scott_n at xypro.com (Scott Neugroschl) Date: Thu, 7 Sep 2017 15:36:49 +0000 Subject: [openssl-users] SMIME -sign subcommand In-Reply-To: <1ADCF931-EDB4-4B98-AB3F-E36A20445E4E@gmail.com> References: <1ADCF931-EDB4-4B98-AB3F-E36A20445E4E@gmail.com> Message-ID: Run it in a debugger? From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Carlos Caraccia Sent: Thursday, September 07, 2017 5:02 AM To: openssl-users at openssl.org Subject: [openssl-users] SMIME -sign subcommand Hello, is there a way to debug or watch line by line which functions are executed when I run a this command: openssl smime -sign -signer certificadoWSASS.cer -inkey MiClave -out ticket.xml.cms -in Ticket.xml -outform PEM -nodetach I know there I can see the smile.c here /apps I want to know how to compile if it is possible to compile it and to run it in Xcode and watch step by step the functions involved. Thanks Carlos -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgm at htt-consult.com Thu Sep 7 19:20:15 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Thu, 7 Sep 2017 15:20:15 -0400 Subject: [openssl-users] Problems with server mode of openssl ocsp Message-ID: <496eb5e7-2ec3-cee3-c3fc-11ff0fbfc975@htt-consult.com> Good progress. A few questions: on https://jamielinux.com/docs/openssl-certificate-authority/online-certificate-status-protocol.html The sample server test command is: openssl ocsp -port 127.0.0.1:2560 -text -sha256 \ -index intermediate/index.txt \ -CA intermediate/certs/ca-chain.cert.pem \ -rkey intermediate/private/ocsp.example.com.key.pem \ -rsigner intermediate/certs/ocsp.example.com.cert.pem \ -nrequest 1 Turns out this is a wrong format for -port. Only the portnum is allowed, not the host. Turns out that -port 2560 works as it seems to be listening on localhost. But how DO you set up which address to listen on? -host seems to be only for client mode, and I don't see how I would use -url. The -sha256 option results in the error: ocsp: Digest must be before -cert or -serial ocsp: Use -help for summary. I don't see either -cert or -serial in that command. If I leave the hash out, it defaults to sha1. How do I specify the hash? thanks Bob From steve at openssl.org Thu Sep 7 20:13:10 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 7 Sep 2017 20:13:10 +0000 Subject: [openssl-users] Problems with server mode of openssl ocsp In-Reply-To: <496eb5e7-2ec3-cee3-c3fc-11ff0fbfc975@htt-consult.com> References: <496eb5e7-2ec3-cee3-c3fc-11ff0fbfc975@htt-consult.com> Message-ID: <20170907201310.GA16930@openssl.org> On Thu, Sep 07, 2017, Robert Moskowitz wrote: > Good progress. A few questions: > > on https://jamielinux.com/docs/openssl-certificate-authority/online-certificate-status-protocol.html > > The sample server test command is: > > openssl ocsp -port 127.0.0.1:2560 -text -sha256 \ > -index intermediate/index.txt \ > -CA intermediate/certs/ca-chain.cert.pem \ > -rkey intermediate/private/ocsp.example.com.key.pem \ > -rsigner intermediate/certs/ocsp.example.com.cert.pem \ > -nrequest 1 > > Turns out this is a wrong format for -port. Only the portnum is > allowed, not the host. Turns out that > > -port 2560 > > works as it seems to be listening on localhost. But how DO you set > up which address to listen on? -host seems to be only for client > mode, and I don't see how I would use -url. > There is currently no option to do that. > The -sha256 option results in the error: > > ocsp: Digest must be before -cert or -serial > ocsp: Use -help for summary. > > I don't see either -cert or -serial in that command. If I leave the > hash out, it defaults to sha1. How do I specify the hash? > Do you mean the digest the response is signed with? Try the -rmd option if so. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rgm at htt-consult.com Thu Sep 7 20:38:47 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Thu, 7 Sep 2017 16:38:47 -0400 Subject: [openssl-users] Problems with se...rver mode of openssl ocsp In-Reply-To: <20170907201310.GA16930@openssl.org> References: <496eb5e7-2ec3-cee3-c3fc-11ff0fbfc975@htt-consult.com> <20170907201310.GA16930@openssl.org> Message-ID: <2798220c-2e5c-1737-6f60-2835483e011b@htt-consult.com> On 09/07/2017 04:13 PM, Dr. Stephen Henson wrote: > On Thu, Sep 07, 2017, Robert Moskowitz wrote: > >> Good progress. A few questions: >> >> on https://jamielinux.com/docs/openssl-certificate-authority/online-certificate-status-protocol.html >> >> The sample server test command is: >> >> openssl ocsp -port 127.0.0.1:2560 -text -sha256 \ >> -index intermediate/index.txt \ >> -CA intermediate/certs/ca-chain.cert.pem \ >> -rkey intermediate/private/ocsp.example.com.key.pem \ >> -rsigner intermediate/certs/ocsp.example.com.cert.pem \ >> -nrequest 1 >> >> Turns out this is a wrong format for -port. Only the portnum is >> allowed, not the host. Turns out that >> >> -port 2560 >> >> works as it seems to be listening on localhost. But how DO you set >> up which address to listen on? -host seems to be only for client >> mode, and I don't see how I would use -url. >> > There is currently no option to do that. OK. It does listen on localhost, so I'm OK with just -port 2560. I will have to send Jamie a note... >> The -sha256 option results in the error: >> >> ocsp: Digest must be before -cert or -serial >> ocsp: Use -help for summary. >> >> I don't see either -cert or -serial in that command. If I leave the >> hash out, it defaults to sha1. How do I specify the hash? >> > Do you mean the digest the response is signed with? Try the -rmd option if so. No such option documented at: https://www.openssl.org/docs/man1.1.0/apps/ocsp.html but 'openssl ocsp -help' does list it. I am assuming that I would use: -rmd sha256 Be a bit to I get back to that part of the test thanks Bob From rgm at htt-consult.com Fri Sep 8 16:20:59 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Fri, 8 Sep 2017 12:20:59 -0400 Subject: [openssl-users] Why is this OCSP response reporting a hash using SHA1? Message-ID: I am using the test responder: openssl ocsp -port 2560 -text -rmd sha256\ -index index.txt \ -CA certs/ca-chain.cert.pem \ -rkey private/$ocspurl.key.pem \ -rsigner certs/$ocspurl.cert.pem \ -nrequest 1 What is the SHA1 hash report about? It comes right after the line: Certificate ID: openssl ocsp -CAfile certs/ca-chain.cert.pem \ -url http://127.0.0.1:2560 -resp_text \ -issuer certs/8021ARintermediate.cert.pem \ -cert certs/$targetcert.cert.pem OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: O = HTT Consulting, OU = Devices Produced At: Sep 8 16:11:38 2017 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: CA1F5832FA387F0127D8E0583F7331D1B903DBF0 Issuer Key Hash: A3278D00B053BF259193A4833E669C451DAD36E0 Serial Number: 762900CAB55A4762 Cert Status: revoked Revocation Time: Sep 7 06:48:28 2017 GMT This Update: Sep 8 16:11:38 2017 GMT Response Extensions: OCSP Nonce: 0410DBAEC40AE0C9696C715A8F476383D112 Signature Algorithm: ecdsa-with-SHA256 30:46:02:21:00:a7:3e:9f:40:29:21:bc:1b:af:22:41:f7:5d: 70:d8:3f:db:98:16:7c:62:b4:e9:cf:4c:1e:43:db:fa:07:42: f7:02:21:00:f6:05:82:c8:85:ef:dc:17:ec:0f:59:ce:5e:fd: 36:8f:ac:5a:29:32:17:9d:22:c1:c2:77:e8:f7:7a:0c:ff:af Certificate: Data: Version: 3 (0x2) Serial Number: aa:56:78:7a:d5:f7:de:4f Signature Algorithm: ecdsa-with-SHA256 Issuer: C=US, ST=MI, O=HTT Consulting, OU=Devices, CN=802.1AR CA Validity Not Before: Sep 7 06:40:11 2017 GMT Not After : Dec 31 23:59:59 9999 GMT Subject: O=HTT Consulting, OU=Devices Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:d8:a1:6c:09:c0:13:fc:30:6f:02:1e:a0:d3:cc: 02:8c:b0:e1:2a:84:1d:94:ed:2e:92:b8:25:d0:00: 3d:a0:1a:43:dc:83:12:13:e0:74:a4:97:b7:4e:ed: 26:18:c0:36:38:a1:f8:c0:bb:d8:5c:14:cd:a7:23: f5:71:51:bc:6c ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Subject Key Identifier: 57:34:03:80:50:53:9B:EA:2A:06:37:FF:8A:1E:32:72:70:DD:41:9F X509v3 Authority Key Identifier: keyid:A3:27:8D:00:B0:53:BF:25:91:93:A4:83:3E:66:9C:45:1D:AD:36:E0 X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: critical OCSP Signing X509v3 Subject Alternative Name: DNS:ocsp.htt-consult.com, email:postmaster at htt-consult.com Signature Algorithm: ecdsa-with-SHA256 30:44:02:20:2b:99:ba:72:2a:e5:4c:1b:c1:9c:6a:72:f9:8e: 8f:5f:97:ec:35:e0:19:f3:7f:58:c4:4b:67:fe:dc:47:68:45: 02:20:37:07:0a:be:09:bd:20:b5:21:c5:23:80:4a:4d:57:47: 56:4a:79:cc:6d:e0:57:5e:ef:bc:9b:eb:6d:3a:db:73 -----BEGIN CERTIFICATE----- MIICMTCCAdigAwIBAgIJAKpWeHrV995PMAoGCCqGSM49BAMCMFoxCzAJBgNVBAYT AlVTMQswCQYDVQQIDAJNSTEXMBUGA1UECgwOSFRUIENvbnN1bHRpbmcxEDAOBgNV BAsMB0RldmljZXMxEzARBgNVBAMMCjgwMi4xQVIgQ0EwIBcNMTcwOTA3MDY0MDEx WhgPOTk5OTEyMzEyMzU5NTlaMCsxFzAVBgNVBAoMDkhUVCBDb25zdWx0aW5nMRAw DgYDVQQLDAdEZXZpY2VzMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE2KFsCcAT /DBvAh6g08wCjLDhKoQdlO0ukrgl0AA9oBpD3IMSE+B0pJe3Tu0mGMA2OKH4wLvY XBTNpyP1cVG8bKOBszCBsDAJBgNVHRMEAjAAMB0GA1UdDgQWBBRXNAOAUFOb6ioG N/+KHjJycN1BnzAfBgNVHSMEGDAWgBSjJ40AsFO/JZGTpIM+ZpxFHa024DAOBgNV HQ8BAf8EBAMCB4AwFgYDVR0lAQH/BAwwCgYIKwYBBQUHAwkwOwYDVR0RBDQwMoIU b2NzcC5odHQtY29uc3VsdC5jb22BGnBvc3RtYXN0ZXJAaHR0LWNvbnN1bHQuY29t MAoGCCqGSM49BAMCA0cAMEQCICuZunIq5UwbwZxqcvmOj1+X7DXgGfN/WMRLZ/7c R2hFAiA3Bwq+Cb0gtSHFI4BKTVdHVkp5zG3gV17vvJvrbTrbcw== -----END CERTIFICATE----- Response verify OK certs/Wt1234.cert.pem: revoked This Update: Sep 8 16:11:38 2017 GMT Revocation Time: Sep 7 06:48:28 2017 GMT Thank you Bob From rgm at htt-consult.com Fri Sep 8 19:38:47 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Fri, 8 Sep 2017 15:38:47 -0400 Subject: [openssl-users] New version of draft-moskowitz-ecdsa-pki Message-ID: <5cf0d18f-2f22-1fd7-c1be-5b094569ba3d@htt-consult.com> I want to thank all for the help over the past few weeks. Here is the latest version. I know I have a few things to tune up. Like why the SHA1 in the OCSP response. I also want to put more justification in the beginning for people to use this (Standards writers, developers, testers,,,,). But as often said, Internet Draft revision numbers are free and it is better to get things out stepwise then wait until everything is done. Next big addition is IEEE 1609.2 cert support. Bob -------- Forwarded Message -------- Subject: New Version Notification for draft-moskowitz-ecdsa-pki-01.txt Date: Fri, 08 Sep 2017 12:26:36 -0700 From: internet-drafts at ietf.org To: Robert Moskowitz , Liang Xia , Henk Birkholz , Liang Xia A new version of I-D, draft-moskowitz-ecdsa-pki-01.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-ecdsa-pki Revision: 01 Title: Guide for building an ECC pki Document date: 2017-09-07 Group: Individual Submission Pages: 31 URL: https://www.ietf.org/internet-drafts/draft-moskowitz-ecdsa-pki-01.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-ecdsa-pki/ Htmlized: https://tools.ietf.org/html/draft-moskowitz-ecdsa-pki-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-ecdsa-pki-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-ecdsa-pki-01 Abstract: This memo provides a guide for building a PKI (Public Key Infrastructure) using openSSL. All certificates in this guide are ECDSA, P-256, with SHA256 certificates. Along with common End Entity certificates, this guide provides instructions for creating IEEE 802.1AR iDevID Secure Device certificates. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Sat Sep 9 02:08:00 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Sat, 9 Sep 2017 02:08:00 +0000 Subject: [openssl-users] Why is this OCSP response reporting a hash using SHA1? In-Reply-To: References: Message-ID: <20170909020800.GA8109@openssl.org> On Fri, Sep 08, 2017, Robert Moskowitz wrote: > I am using the test responder: > > openssl ocsp -port 2560 -text -rmd sha256\ > -index index.txt \ > -CA certs/ca-chain.cert.pem \ > -rkey private/$ocspurl.key.pem \ > -rsigner certs/$ocspurl.cert.pem \ > -nrequest 1 > > > What is the SHA1 hash report about? It comes right after the line: > Certificate ID: > > Certificate ID: > Hash Algorithm: sha1 > Issuer Name Hash: CA1F5832FA387F0127D8E0583F7331D1B903DBF0 > Issuer Key Hash: A3278D00B053BF259193A4833E669C451DAD36E0 > Serial Number: 762900CAB55A4762 It's the hash algorithm used to hash the issuer name and key to identify them. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From tshort at akamai.com Mon Sep 11 14:13:04 2017 From: tshort at akamai.com (Short, Todd) Date: Mon, 11 Sep 2017 14:13:04 +0000 Subject: [openssl-users] Fwd: [openssl-dev] QUIC References: Message-ID: FYI: Matt Caswell realized how critical TLSv1.3 (and subsequently OpenSSL) is to QUIC. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." Begin forwarded message: From: Benjamin Kaduk via openssl-dev > Subject: Re: [openssl-dev] QUIC Date: September 7, 2017 at 12:45:11 PM EDT To: openssl-dev at openssl.org, Matt Caswell > Reply-To: Benjamin Kaduk >, > On 09/06/2017 05:24 PM, Matt Caswell wrote: Issue 4283 (https://github.com/openssl/openssl/issues/4283) has caused me to take a close look at QUIC. This seems to have been getting a *lot* of attention just recently. See the IDs below for details: Yes, it's generated a lot of excitement and interest at the IETF. https://tools.ietf.org/html/draft-ietf-quic-transport-05 https://tools.ietf.org/html/draft-ietf-quic-tls-05 https://tools.ietf.org/html/draft-ietf-quic-recovery-05 For the uninitiated QUIC is a new general-purpose transport protocol built on top of UDP. It provides applications with a secure stream abstraction (like TLS over TCP) with reliable, in-order delivery, as well as the ability to multiplex many streams over a single connection (without head-of-line blocking). It is *very* closely integrated with TLSv1.3. It uses the TLSv1.3 handshake for agreeing various QUIC parameters (via extensions) as well as for agreeing keying material and providing an "early data" capability. The actual packet protection is done by QUIC itself (so it doesn't use TLS application data) using a QUIC ciphersuite that matches the negotiated TLS ciphersuite. Effectively you can think of QUIC as a modernised rival to TLS over TCP. The nature of the QUIC/TLSv1.3 integration is somewhat interesting. QUIC has its origins at Google, and the "Google QUIC" or gQUIC variant is deployed on the public internet even now; since TLS 1.3 was not available then, it uses a separate "quic-crypto" scheme for these purposes. quic-crypto, in turn, helped shape the evolution of TLS 1.3, including the strong desire for 0-RTT functionality. But, as I understand it, the intent is to leave enough hooks that a different crypto layer could be used, including (but not limited to) a subsequent version of TLS. I've spent some time today reading through the IDs. It has become clear to me that in order for OpenSSL to be used to implement QUIC there are a number of new requirements/issues we would need to address: - We need to provide the server half of the TLSv1.3 cookie mechanism. At the moment an OpenSSL client will echo a TLSv1.3 cookie it receives back to the server, but you cannot generate a cookie on the server side. Yeah, the cookie is pretty clear to the UDP/"stateless" operation. - We need to be able to support *stateless* operation for the ClientHello->HelloRetryRequest exchange. This is very much in the same vein as the stateless way that DTLSv1_listen() works now for DTLS in the ClientHello->HelloVerifyRequest exchange. This is quite a significant requirement. The expectation is that the state gets bundled into the cookie, yes. - A QUIC server needs to be able to issue a NewSessionTicket on demand - Ticket PSKs need to be able to have an embedded QUIC layer token (the equivalent of the cookie - but embedded inside the PSK). I think https://github.com/openssl/openssl/pull/3802 is pretty close, in this space. - We need to extend the "exporter" API to allow early_secret based exports. At the moment you can only export based on the final 1-RTT key. It seems in keeping with our existing handling of early data, to at least consider providing a separate API for these early exporter values. - TLS PSKs are transferable between TLS-TCP and QUIC/TLS-UDP. There are some special rules around ALPN for this that may impact our current logic in this area. - Possibly a QUIC implementation will need to have knowledge of the TLSv1.3 state machine because different TLSv1.3 handshake records need to go into different types of QUIC packets (ClientHello needs to go into "Client Initial" packet, HelloRetryRequest needs to go into a "Server Stateless Retry" packet and everything else goes into "Client Cleartext" or "Server Cleartext" packets). It may be possible for a QUIC implementation to infer the required information without additional APIs, but I'm not sure. We do have existing things like the message callback, but I won't try to argue that that's an ideal situation for a QUIC implementor. And the QUIC layer could even parse out the unencrypted records for itself from the output BIO, as silly as that would be. - QUIC places size limits on the allowed size of a ClientHello. Possibly we may want some way of failing gracefully if we attempt to exceed that (or maybe we just leave that to the QUIC implementation to detect). (This is to limit the potential for a DoS amplification attack via spoofed client address, since UDP does not provide the reachability confirmation that TCP's handshake does, for the spectators.) I'm going to start working through this list of requirements, but if anyone fancies picking some of it up then let me know. Also, did I miss anything from the above list? Nothing sticks out as missing to me, but I've not been following QUIC development as closely as I'd like. -Ben -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgm at htt-consult.com Mon Sep 11 16:16:27 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Mon, 11 Sep 2017 12:16:27 -0400 Subject: [openssl-users] Why is this OCSP response reporting a hash using SHA1? In-Reply-To: <20170909020800.GA8109@openssl.org> References: <20170909020800.GA8109@openssl.org> Message-ID: <323138cf-827b-2c13-30c8-792b33642e5e@htt-consult.com> On 09/08/2017 10:08 PM, Dr. Stephen Henson wrote: > On Fri, Sep 08, 2017, Robert Moskowitz wrote: > >> I am using the test responder: >> >> openssl ocsp -port 2560 -text -rmd sha256\ >> -index index.txt \ >> -CA certs/ca-chain.cert.pem \ >> -rkey private/$ocspurl.key.pem \ >> -rsigner certs/$ocspurl.cert.pem \ >> -nrequest 1 >> >> >> What is the SHA1 hash report about? It comes right after the line: >> Certificate ID: >> >> Certificate ID: >> Hash Algorithm: sha1 >> Issuer Name Hash: CA1F5832FA387F0127D8E0583F7331D1B903DBF0 >> Issuer Key Hash: A3278D00B053BF259193A4833E669C451DAD36E0 >> Serial Number: 762900CAB55A4762 > It's the hash algorithm used to hash the issuer name and key to identify them. And how do you get it to use sha256? I would think that the -rmd sha256 in the responder command would that? What does it do anyway? It is listed in the -help: -rmd val Digest Algorithm to use in signature of OCSP response but not in the man page. Ah, put -sha256 in the CLIENT request. Seems kind of backward. Or at least the server should have some control over the hash used? thanks Bob From rsalz at akamai.com Mon Sep 11 16:23:06 2017 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 11 Sep 2017 16:23:06 +0000 Subject: [openssl-users] Why is this OCSP response reporting a hash using SHA1? In-Reply-To: <323138cf-827b-2c13-30c8-792b33642e5e@htt-consult.com> References: <20170909020800.GA8109@openssl.org> <323138cf-827b-2c13-30c8-792b33642e5e@htt-consult.com> Message-ID: Ah, put -sha256 in the CLIENT request. Seems kind of backward. Or at least the server should have some control over the hash used? Well, it is the client that is making the request, so therefore the client needs to hash the cert information. A production-quality OCSP responder might have configuration controls to specify which type of digests it wants to see in the request. As with most of the OpenSSL command-line interface, it?s not a product. From rgm at htt-consult.com Mon Sep 11 16:33:30 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Mon, 11 Sep 2017 12:33:30 -0400 Subject: [openssl-users] Why is this OCSP response reporting a hash using SHA1? In-Reply-To: References: <20170909020800.GA8109@openssl.org> <323138cf-827b-2c13-30c8-792b33642e5e@htt-consult.com> Message-ID: <845ac763-902b-e8fd-3864-787d1f97cff5@htt-consult.com> On 09/11/2017 12:23 PM, Salz, Rich via openssl-users wrote: > > Ah, put -sha256 in the CLIENT request. Seems kind of backward. Or at > least the server should have some control over the hash used? > > > Well, it is the client that is making the request, so therefore the client needs to hash the cert information. Ah, I see. I was looking at this from the wrong side. > A production-quality OCSP responder might have configuration controls to specify which type of digests it wants to see in the request. As with most of the OpenSSL command-line interface, it?s not a product. Understood. This is mostly about providing a development/testing environment. And if your standard calls out use of OCSP, then you really should include that in testing. I am getting ready to focus on the IETF SIngapore hackathon... I would actually really like to have a SIMPLE OCSP responder. But so far have not found one. freeIPA has one buried within it, but that is too disruptive to install unless you buy into freeIPA. thanks Bob From steve at openssl.org Tue Sep 12 13:09:18 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 12 Sep 2017 13:09:18 +0000 Subject: [openssl-users] Why is this OCSP response reporting a hash using SHA1? In-Reply-To: <845ac763-902b-e8fd-3864-787d1f97cff5@htt-consult.com> References: <20170909020800.GA8109@openssl.org> <323138cf-827b-2c13-30c8-792b33642e5e@htt-consult.com> <845ac763-902b-e8fd-3864-787d1f97cff5@htt-consult.com> Message-ID: <20170912130918.GA13663@openssl.org> On Mon, Sep 11, 2017, Robert Moskowitz wrote: > > I would actually really like to have a SIMPLE OCSP responder. But > so far have not found one. freeIPA has one buried within it, but > that is too disruptive to install unless you buy into freeIPA. > Well the OpenSSL ocsp respoder isn't much use for that, it only handles one request at a time, can't handle dynamic updates in the status information (needs to be restarted), has pretty awful performance (reads status from a text file which resides in memory) and you can't tell it which interface to bind to either. There is a way to deal with some of those issues by running the ocsp utility from a CGI script in a web server. The script decodes the OCSP request, hands it to the ocsp utility and sends back the response. The down side is the performance is worse: the OCSP utility has to parse the text file and read it into memory on every incoming request. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rgm at htt-consult.com Tue Sep 12 13:38:32 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Tue, 12 Sep 2017 09:38:32 -0400 Subject: [openssl-users] Why is this OCSP response reporting a hash using SHA1? In-Reply-To: <20170912130918.GA13663@openssl.org> References: <20170909020800.GA8109@openssl.org> <323138cf-827b-2c13-30c8-792b33642e5e@htt-consult.com> <845ac763-902b-e8fd-3864-787d1f97cff5@htt-consult.com> <20170912130918.GA13663@openssl.org> Message-ID: <3b1fc059-cd21-099a-728f-a73a90180ac7@htt-consult.com> On 09/12/2017 09:09 AM, Dr. Stephen Henson wrote: > On Mon, Sep 11, 2017, Robert Moskowitz wrote: > >> I would actually really like to have a SIMPLE OCSP responder. But >> so far have not found one. freeIPA has one buried within it, but >> that is too disruptive to install unless you buy into freeIPA. >> > Well the OpenSSL ocsp respoder isn't much use for that, it only handles one > request at a time, can't handle dynamic updates in the status information > (needs to be restarted), has pretty awful performance (reads status from a > text file which resides in memory) and you can't tell it which interface to > bind to either. > > There is a way to deal with some of those issues by running the ocsp utility > from a CGI script in a web server. The script decodes the OCSP request, hands > it to the ocsp utility and sends back the response. The down side is the > performance is worse: the OCSP utility has to parse the text file and read it > into memory on every incoming request. Yeah, I thought of the cgi (or php) approach and kind of cringed. That is why I am still googling for OCSP responders. Rather depressing how little is out there. Also nice would be index.txt in SQL. Bob From rgm at htt-consult.com Tue Sep 12 13:56:15 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Tue, 12 Sep 2017 09:56:15 -0400 Subject: [openssl-users] Why is this OCSP response reporting a hash using SHA1? In-Reply-To: <3b1fc059-cd21-099a-728f-a73a90180ac7@htt-consult.com> References: <20170909020800.GA8109@openssl.org> <323138cf-827b-2c13-30c8-792b33642e5e@htt-consult.com> <845ac763-902b-e8fd-3864-787d1f97cff5@htt-consult.com> <20170912130918.GA13663@openssl.org> <3b1fc059-cd21-099a-728f-a73a90180ac7@htt-consult.com> Message-ID: <0dabef9e-a2e9-d022-9624-35c4e4bd2d9a@htt-consult.com> On 09/12/2017 09:38 AM, Robert Moskowitz wrote: > > > On 09/12/2017 09:09 AM, Dr. Stephen Henson wrote: >> On Mon, Sep 11, 2017, Robert Moskowitz wrote: >> >>> I would actually really like to have a SIMPLE OCSP responder. But >>> so far have not found one. freeIPA has one buried within it, but >>> that is too disruptive to install unless you buy into freeIPA. >>> >> Well the OpenSSL ocsp respoder isn't much use for that, it only >> handles one >> request at a time, can't handle dynamic updates in the status >> information >> (needs to be restarted), has pretty awful performance (reads status >> from a >> text file which resides in memory) and you can't tell it which >> interface to >> bind to either. >> >> There is a way to deal with some of those issues by running the ocsp >> utility >> from a CGI script in a web server. The script decodes the OCSP >> request, hands >> it to the ocsp utility and sends back the response. The down side is the >> performance is worse: the OCSP utility has to parse the text file and >> read it >> into memory on every incoming request. > > Yeah, I thought of the cgi (or php) approach and kind of cringed. That > is why I am still googling for OCSP responders. Rather depressing how > little is out there. I see ocspd available in Fedora. I will have to do a bit of reading.... Perhaps part of OpenCA,,, Sometimes start in the 'obvious' starting point. Like your own OS repo... > > Also nice would be index.txt in SQL. > > Bob > From jb-openssl at wisemo.com Tue Sep 12 14:08:04 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 12 Sep 2017 16:08:04 +0200 Subject: [openssl-users] Why is this OCSP response reporting a hash using SHA1? In-Reply-To: <0dabef9e-a2e9-d022-9624-35c4e4bd2d9a@htt-consult.com> References: <20170909020800.GA8109@openssl.org> <323138cf-827b-2c13-30c8-792b33642e5e@htt-consult.com> <845ac763-902b-e8fd-3864-787d1f97cff5@htt-consult.com> <20170912130918.GA13663@openssl.org> <3b1fc059-cd21-099a-728f-a73a90180ac7@htt-consult.com> <0dabef9e-a2e9-d022-9624-35c4e4bd2d9a@htt-consult.com> Message-ID: <6aeecb7c-f3de-b0df-25e4-cfe3c0066ea4@wisemo.com> On 12/09/2017 15:56, Robert Moskowitz wrote: > > > On 09/12/2017 09:38 AM, Robert Moskowitz wrote: >> >> >> On 09/12/2017 09:09 AM, Dr. Stephen Henson wrote: >>> On Mon, Sep 11, 2017, Robert Moskowitz wrote: >>> >>>> I would actually really like to have a SIMPLE OCSP responder.? But >>>> so far have not found one.? freeIPA has one buried within it, but >>>> that is too disruptive to install unless you buy into freeIPA. >>>> >>> Well the OpenSSL ocsp respoder isn't much use for that, it only >>> handles one >>> request at a time, can't handle dynamic updates in the status >>> information >>> (needs to be restarted), has pretty awful performance (reads status >>> from a >>> text file which resides in memory) and you can't tell it which >>> interface to >>> bind to either. >>> >>> There is a way to deal with some of those issues by running the ocsp >>> utility >>> from a CGI script in a web server. The script decodes the OCSP >>> request, hands >>> it to the ocsp utility and sends back the response. The down side is >>> the >>> performance is worse: the OCSP utility has to parse the text file >>> and read it >>> into memory on every incoming request. >> >> Yeah, I thought of the cgi (or php) approach and kind of cringed. >> That is why I am still googling for OCSP responders. Rather >> depressing how little is out there. > I see ocspd available in Fedora.? I will have to do a bit of > reading....? Perhaps part of OpenCA,,, > Yes it's part of OpenCA, not sure of the OpenCA project status though. Another standalone ocsp responder, which unfortunately seems to require a complete Java environment and a Java driver to treat the cert list as a "database" is the one from EJBCA. EJBCA seems to be very actively maintained and some professionals consider it the best CA implementation suite. > Sometimes start in the 'obvious' starting point.? Like your own OS > repo... > > >> >> Also nice would be index.txt in SQL. >> >> Bob >> > 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 alexxplus at hotmail.com Mon Sep 11 09:32:02 2017 From: alexxplus at hotmail.com (Alejandro Pulido) Date: Mon, 11 Sep 2017 09:32:02 +0000 Subject: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates Message-ID: Dear team of OpenSSL, First of all, congratulations for your invaluable work! I have a question regarding the issue of certificates X.509 with infinite duration and I don't know where to submit it. Please, could you help me? Thank you very much and kind regards Alejandro J Pulido Duque -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgm at htt-consult.com Tue Sep 12 14:30:20 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Tue, 12 Sep 2017 10:30:20 -0400 Subject: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates In-Reply-To: References: Message-ID: Depends on the question.... 'Infinite' duration is used in IEEE 802.1AR Device Identities. The concept is the vendor installs the certificate in read-only memory. It is expected to be good for the life of the device. On 09/11/2017 05:32 AM, Alejandro Pulido wrote: > Dear team of OpenSSL, > First of all, congratulations for your invaluable work! > I have a question regarding the issue of certificates X.509 with > infinite duration and I don't know where to submit it. > Please, could you help me? > Thank you very much and kind regards > > > > */Alejandro J Pulido Duque/* > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgm at htt-consult.com Tue Sep 12 15:57:41 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Tue, 12 Sep 2017 11:57:41 -0400 Subject: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates In-Reply-To: References: Message-ID: <86389fab-e4e6-5fde-5e71-723717647295@htt-consult.com> IEEE 802.1ARce (latest draft addendum) specifies: 8.7 validity The time period over which the DevID issuer expects the device to be used. All times are stated in the Universal Coordinated Time (UTC) time zone. Times up to and including 23:59:59 December 31, 2049 UTC are encoded as UTCTime as YYMMDDHHmmssZ. Times later than 23:59:59 December 31, 2049 UTC are encoded as GeneralizedTime as YYYYMMDDHHmmssZ. The time the DevID is created is encoded in the notBefore field of DevID certificates. Each DevID chain certificate has a notBefore value that encodes a time that is the same as or prior to that of any DevID certificate that relies on the chain for certificate validation. The latest time a DevID is expected to be used is encoded in the notAfter field of the DevID certificate. Each DevID chain certificate has a notBefore value that encodes a time that is the same as or later than that of any DevID certificate that relies on the chain for certificate validation. Devices possessing an IDevID are expected to operate indefinitely into the future and should use the GeneralizedTime value 99991231235959Z (10) in the notAfter field of IDevID certificates. Solutions verifying a DevID are expected to accept this value indefinitely. Values in notAfter fields are treated as specified in RFC 5280. Footnote: (10) This value corresponds to one second before the year 10 000; note the creation of an opportunity for the Y10K bug fix industry. ===================== It is really rare to find humor in IEEE specifications! Bob On 09/12/2017 11:39 AM, Alejandro Pulido wrote: > > Hello! > > > Thanks for the response. > > I was thinking of setting the duration fo the certificate to infinite, > > i.e. the Validity period set to infinite. > > Because in the information I have, the only possibility is to set the > duration (in days) with the command, but the command doesn't allow to > put other value rather an integer. > > > Thanks again > > > > */Alejandro J Pulido Duque/* > ------------------------------------------------------------------------ > *De:* Robert Moskowitz > *Enviado:* martes, 12 de septiembre de 2017 14:30:20 > *Para:* openssl-users at openssl.org; Alejandro Pulido > *Asunto:* Re: [openssl-users] Doubt regarding O-SSL and setting the > duration of certificates > Depends on the question.... > > 'Infinite' duration is used in IEEE 802.1AR Device Identities. The > concept is the vendor installs the certificate in read-only memory. > It is expected to be good for the life of the device. > > On 09/11/2017 05:32 AM, Alejandro Pulido wrote: >> Dear team of OpenSSL, >> First of all, congratulations for your invaluable work! >> I have a question regarding the issue of certificates X.509 with >> infinite duration and I don't know where to submit it. >> Please, could you help me? >> Thank you very much and kind regards >> >> >> >> */Alejandro J Pulido Duque/* >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcepl at cepl.eu Tue Sep 12 17:58:16 2017 From: mcepl at cepl.eu (=?UTF-8?Q?Mat=c4=9bj_Cepl?=) Date: Tue, 12 Sep 2017 19:58:16 +0200 Subject: [openssl-users] Lost in STACK_OF again (porting M2Crypto to OpenSSL 1.1.* API) Message-ID: <46e1df56-a7a6-90ff-80ad-3bf842369afb@cepl.eu> Hi, I am working on porting M2Crypto to OpenSSL 1.1.* API (in branch https://gitlab.com/mcepl/m2crypto/commits/openssl-1.1.0 ) and I got lost in STACK_OF structures. Simplified function I have troubles with is (the real stuff with all Python2/Python3 shims is https://is.gd/Nbq3Qp ; the similar problem is couple of lines below in the function get_der_encoding_stack). ????#include ????#include ????#include ????#include ????typedef STACK_OF(X509) SEQ_CERT; ????ASN1_ITEM_TEMPLATE(SEQ_CERT) = ????????ASN1_EX_TEMPLATE_TYPE(ASN1_TFLG_SEQUENCE_OF, 0, SeqCert, X509) ????ASN1_ITEM_TEMPLATE_END(SEQ_CERT) ????IMPLEMENT_ASN1_FUNCTIONS(SEQ_CERT) ????... ????STACK_OF(X509) * ????? make_stack_from_der_sequence(PyObject * pyEncodedString){ ??????????STACK_OF(X509) *certs; ??????????Py_ssize_t encoded_string_len; ??????????char *encoded_string; ??????????encoded_string_len = PyString_Size(pyEncodedString); ??????????if (encoded_string_len > INT_MAX) { ??????????????PyErr_SetString(PyExc_ValueError, "object too large"); ??????????????return NULL; ??????????} ??????????encoded_string = PyString_AsString(pyEncodedString); ??????????if (!encoded_string) { ??????????????return NULL; ??????????} ??????????certs = ASN1_seq_unpack( (unsigned char *)encoded_string, ???? encoded_string_len, ??????????????????d2i_X509, X509_free ); ??????????if (!certs) { ??????????????PyErr_SetString(_x509_err, ??????????????????????????????ERR_reason_error_string( ERR_get_error())); ??????????????return NULL; ??????????} ??????????return certs; ????? } Obviously this fails to compile with these errors: SWIG/_m2crypto_wrap.c: In function ?make_stack_from_der_sequence?: SWIG/_m2crypto_wrap.c:8718:13: warning: implicit declaration of function ?ASN1_seq_unpack?; did you mean ?ASN1_item_unpack?? [- Wimplicit-function-declaration] ?????certs = ASN1_seq_unpack((unsigned char *)encoded_string, encoded_string_len, d2i_X509, X509_free ); ?????????????^~~~~~~~~~~~~~~ ?????????????ASN1_item_unpack SWIG/_m2crypto_wrap.c:8718:11: warning: assignment makes pointer from integer without a cast [-Wint-conversion] ?????certs = ASN1_seq_unpack((unsigned char *)encoded_string, encoded_string_len, d2i_X509, X509_free ); ???????????^ Obviously I have missed something from STACK_OF API, but I cannot for the love of the world find what. Did truly *_seq_unpack functions got lost on the way to 1.1 API? If I have to do the unpacking "manually", how to do it? How can I get STACK_OF(X509) from the string with DER certificate? I was looking also to the discussion by Jim Carroll on https://goo.gl/ZUxQH8 but I have probably misunderstood something.?I believe I do everything I am supposed to, but still there is something apparently missing. Thank you for any help, Mat?j -- http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 A philosopher like Plato, according to Luther's colorful imagery, remains like a cow who looks at a new door, refusing to enter? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From steve at openssl.org Tue Sep 12 19:33:26 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 12 Sep 2017 19:33:26 +0000 Subject: [openssl-users] Lost in STACK_OF again (porting M2Crypto to OpenSSL 1.1.* API) In-Reply-To: <46e1df56-a7a6-90ff-80ad-3bf842369afb@cepl.eu> References: <46e1df56-a7a6-90ff-80ad-3bf842369afb@cepl.eu> Message-ID: <20170912193326.GB20554@openssl.org> On Tue, Sep 12, 2017, Mat??j Cepl wrote: > Hi, > > I am working on porting M2Crypto to OpenSSL 1.1.* API (in branch > https://gitlab.com/mcepl/m2crypto/commits/openssl-1.1.0 ) and I > got lost in STACK_OF structures. > > Simplified function I have troubles with is (the real stuff with > all Python2/Python3 shims is https://is.gd/Nbq3Qp ; the similar problem > is couple of lines below in the function get_der_encoding_stack). > > ????#include > ????#include > ????#include > > ????#include > > ????typedef STACK_OF(X509) SEQ_CERT; > > ????ASN1_ITEM_TEMPLATE(SEQ_CERT) = > ????????ASN1_EX_TEMPLATE_TYPE(ASN1_TFLG_SEQUENCE_OF, 0, > SeqCert, X509) > ????ASN1_ITEM_TEMPLATE_END(SEQ_CERT) > > ????IMPLEMENT_ASN1_FUNCTIONS(SEQ_CERT) > > ????... > > ????STACK_OF(X509) * > ????? make_stack_from_der_sequence(PyObject * pyEncodedString){ > ??????????STACK_OF(X509) *certs; > ??????????Py_ssize_t encoded_string_len; > ??????????char *encoded_string; > > ??????????encoded_string_len = PyString_Size(pyEncodedString); > > ??????????if (encoded_string_len > INT_MAX) { > ??????????????PyErr_SetString(PyExc_ValueError, > "object too large"); > ??????????????return NULL; > ??????????} > > ??????????encoded_string = PyString_AsString(pyEncodedString); > > ??????????if (!encoded_string) { > ??????????????return NULL; > ??????????} > > ??????????certs = ASN1_seq_unpack( > (unsigned char *)encoded_string, > ???? encoded_string_len, > ??????????????????d2i_X509, X509_free ); > ??????????if (!certs) { > ??????????????PyErr_SetString(_x509_err, > ??????????????????????????????ERR_reason_error_string( > ERR_get_error())); > ??????????????return NULL; > ??????????} > > ??????????return certs; > ????? } > > Obviously this fails to compile with these errors: > > SWIG/_m2crypto_wrap.c: In function > ???make_stack_from_der_sequence???: > SWIG/_m2crypto_wrap.c:8718:13: warning: implicit declaration of > function ???ASN1_seq_unpack???; did you mean ???ASN1_item_unpack???? [- > Wimplicit-function-declaration] > ?????certs = ASN1_seq_unpack((unsigned char *)encoded_string, > encoded_string_len, d2i_X509, X509_free ); > ?????????????^~~~~~~~~~~~~~~ > ?????????????ASN1_item_unpack > SWIG/_m2crypto_wrap.c:8718:11: warning: assignment makes pointer > from integer without a cast [-Wint-conversion] > ?????certs = ASN1_seq_unpack((unsigned char *)encoded_string, > encoded_string_len, d2i_X509, X509_free ); > ???????????^ > Obviously I have missed something from STACK_OF API, but I cannot > for the love of the world find what. Did truly *_seq_unpack > functions got lost on the way to 1.1 API? If I have to do the > unpacking "manually", how to do it? > > How can I get STACK_OF(X509) from the string with DER > certificate? > > I was looking also to the discussion by Jim Carroll on > https://goo.gl/ZUxQH8 but I have probably misunderstood > something.?I believe I do everything I am supposed to, but still > there is something apparently missing. > Yes *_seq_unpack() is no longer in 1.1. What happens is that code above it generates a function d2i_SEQ_CERT() which does the same as ASN1_seq_unpack() for a certificate. So something like this should work: const unsigned char *tmp = (unsigned char *)encoded_string; ... certs = d21_SEQ_CERT(NULL, &tmp, encoded_string_len); Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From fm at frank4dd.com Tue Sep 12 22:51:37 2017 From: fm at frank4dd.com (Frank Migge) Date: Wed, 13 Sep 2017 07:51:37 +0900 Subject: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates In-Reply-To: <86389fab-e4e6-5fde-5e71-723717647295@htt-consult.com> References: <86389fab-e4e6-5fde-5e71-723717647295@htt-consult.com> Message-ID: <59B864F9.3050807@frank4dd.com> This is an interesting statement. >> should use the GeneralizedTime value 99991231235959Z (10) in the notAfter field ... >> Solutions verifying a DevID are expected to accept this value indefinitely Isn't using that large a time value in certificates problematic? Not all systems can handle it today. At best, they may gracefully decline it as invalid. Windows up to version 10 is unable to display it, and fails to work with such a cert. Even closer into the future, 20 years from now, I am not sure how far the industry came in dealing with the upcoming year 2038 problem on 32bit systems. It is indirectly related to OpenSSL when system time is used, converted to or from. Particularly in IOT/ICS industry situations with scaled down CPUs, long device lifespans and support requirements, functional validation with future time settings would definitely be a good idea on the test plan. Frank > Robert Moskowitz > Wednesday, September 13, 2017 12:57 AM > IEEE 802.1ARce (latest draft addendum) specifies: > > 8.7 validity > > The time period over which the DevID issuer expects the device to be used. > > All times are stated in the Universal Coordinated Time (UTC) time > zone. Times up to and including > 23:59:59 December 31, 2049 UTC are encoded as UTCTime as > YYMMDDHHmmssZ. Times later than > 23:59:59 December 31, 2049 UTC are encoded as GeneralizedTime as > YYYYMMDDHHmmssZ. > > The time the DevID is created is encoded in the notBefore field of > DevID certificates. Each DevID chain > certificate has a notBefore value that encodes a time that is the same > as or prior to that of any DevID > certificate that relies on the chain for certificate validation. > > The latest time a DevID is expected to be used is encoded in the > notAfter field of the DevID certificate. > Each DevID chain certificate has a notBefore value that encodes a time > that is the same as or later than that of any DevID certificate that > relies on the chain for certificate validation. > > Devices possessing an IDevID are expected to operate indefinitely into > the future and should use the > GeneralizedTime value 99991231235959Z (10) in the notAfter field of > IDevID certificates. Solutions > verifying a DevID are expected to accept this value indefinitely. > Values in notAfter fields are treated as > specified in RFC 5280. > > Footnote: (10) > This value corresponds to one second before the year 10 000; note the > creation of an opportunity for the Y10K bug fix industry. > > ===================== > > It is really rare to find humor in IEEE specifications! > > Bob > > On 09/12/2017 11:39 AM, Alejandro Pulido wrote: > > Robert Moskowitz > Tuesday, September 12, 2017 11:30 PM > Depends on the question.... > > 'Infinite' duration is used in IEEE 802.1AR Device Identities. The > concept is the vendor installs the certificate in read-only memory. > It is expected to be good for the life of the device. > > On 09/11/2017 05:32 AM, Alejandro Pulido wrote: > > Alejandro Pulido > Monday, September 11, 2017 6:32 PM > Dear team of OpenSSL, > > First of all, congratulations for your invaluable work! > > I have a question regarding the issue of certificates X.509 with > infinite duration and I don't know where to submit it. > > Please, could you help me? > > Thank you very much and kind regards > > > > */Alejandro J Pulido Duque/* -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgm at htt-consult.com Wed Sep 13 00:14:59 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Tue, 12 Sep 2017 20:14:59 -0400 Subject: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates In-Reply-To: <59B864F9.3050807@frank4dd.com> References: <86389fab-e4e6-5fde-5e71-723717647295@htt-consult.com> <59B864F9.3050807@frank4dd.com> Message-ID: <4495a70d-3eff-95a9-a1d5-4b2da3532f7c@htt-consult.com> The devices never test out the lifetime of their certs. That is up to the validating servers. And the iDevID is not really intended for operational use. Rather it is the security bootstrap for the lDevID. See the work being done in the ANIMA workgroup as an example of what to do with this. Michael Richardson, who recently joined this list is working on the related Internet Draft(s). I should test out a cert beyond 2038 on my armv7 32 bit Cubieboard. Will try that tomorrow.... I HAVE made certs with this value and I am displaying their content. But that system is off right now. I will get one of the samples also tomorrow. And yes, the industry does need to think some about this... On 09/12/2017 06:51 PM, Frank Migge wrote: > This is an interesting statement. > > >> should use the GeneralizedTime value 99991231235959Z (10) in the > notAfter field ... > >> Solutions verifying a DevID are expected to accept this value > indefinitely > > Isn't using that large a time value in certificates problematic? Not > all systems can handle it today. At best, they may gracefully decline > it as invalid. Windows up to version 10 is unable to display it, and > fails to work with such a cert. > > Even closer into the future, 20 years from now, I am not sure how far > the industry came in dealing with the upcoming year 2038 problem on > 32bit systems. It is indirectly related to OpenSSL when system time is > used, converted to or from. Particularly in IOT/ICS industry > situations with scaled down CPUs, long device lifespans and support > requirements, functional validation with future time settings would > definitely be a good idea on the test plan. > > Frank >> Robert Moskowitz >> Wednesday, September 13, 2017 12:57 AM >> IEEE 802.1ARce (latest draft addendum) specifies: >> >> 8.7 validity >> >> The time period over which the DevID issuer expects the device to be >> used. >> >> All times are stated in the Universal Coordinated Time (UTC) time >> zone. Times up to and including >> 23:59:59 December 31, 2049 UTC are encoded as UTCTime as >> YYMMDDHHmmssZ. Times later than >> 23:59:59 December 31, 2049 UTC are encoded as GeneralizedTime as >> YYYYMMDDHHmmssZ. >> >> The time the DevID is created is encoded in the notBefore field of >> DevID certificates. Each DevID chain >> certificate has a notBefore value that encodes a time that is the >> same as or prior to that of any DevID >> certificate that relies on the chain for certificate validation. >> >> The latest time a DevID is expected to be used is encoded in the >> notAfter field of the DevID certificate. >> Each DevID chain certificate has a notBefore value that encodes a >> time that is the same as or later than that of any DevID certificate >> that relies on the chain for certificate validation. >> >> Devices possessing an IDevID are expected to operate indefinitely >> into the future and should use the >> GeneralizedTime value 99991231235959Z (10) in the notAfter field of >> IDevID certificates. Solutions >> verifying a DevID are expected to accept this value indefinitely. >> Values in notAfter fields are treated as >> specified in RFC 5280. >> >> Footnote: (10) >> This value corresponds to one second before the year 10 000; note the >> creation of an opportunity for the Y10K bug fix industry. >> >> ===================== >> >> It is really rare to find humor in IEEE specifications! >> >> Bob >> >> On 09/12/2017 11:39 AM, Alejandro Pulido wrote: >> >> Robert Moskowitz >> Tuesday, September 12, 2017 11:30 PM >> Depends on the question.... >> >> 'Infinite' duration is used in IEEE 802.1AR Device Identities. The >> concept is the vendor installs the certificate in read-only memory. >> It is expected to be good for the life of the device. >> >> On 09/11/2017 05:32 AM, Alejandro Pulido wrote: >> >> Alejandro Pulido >> Monday, September 11, 2017 6:32 PM >> Dear team of OpenSSL, >> First of all, congratulations for your invaluable work! >> I have a question regarding the issue of certificates X.509 with >> infinite duration and I don't know where to submit it. >> Please, could you help me? >> Thank you very much and kind regards >> >> >> >> */Alejandro J Pulido Duque/* > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexxplus at hotmail.com Tue Sep 12 15:39:49 2017 From: alexxplus at hotmail.com (Alejandro Pulido) Date: Tue, 12 Sep 2017 15:39:49 +0000 Subject: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates In-Reply-To: References: , Message-ID: Hello! Thanks for the response. I was thinking of setting the duration fo the certificate to infinite, i.e. the Validity period set to infinite. Because in the information I have, the only possibility is to set the duration (in days) with the command, but the command doesn't allow to put other value rather an integer. Thanks again Alejandro J Pulido Duque ________________________________ De: Robert Moskowitz Enviado: martes, 12 de septiembre de 2017 14:30:20 Para: openssl-users at openssl.org; Alejandro Pulido Asunto: Re: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates Depends on the question.... 'Infinite' duration is used in IEEE 802.1AR Device Identities. The concept is the vendor installs the certificate in read-only memory. It is expected to be good for the life of the device. On 09/11/2017 05:32 AM, Alejandro Pulido wrote: Dear team of OpenSSL, First of all, congratulations for your invaluable work! I have a question regarding the issue of certificates X.509 with infinite duration and I don't know where to submit it. Please, could you help me? Thank you very much and kind regards Alejandro J Pulido Duque -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcr at sandelman.ca Wed Sep 13 13:31:51 2017 From: mcr at sandelman.ca (Michael Richardson) Date: Wed, 13 Sep 2017 09:31:51 -0400 Subject: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates In-Reply-To: <4495a70d-3eff-95a9-a1d5-4b2da3532f7c@htt-consult.com> References: <86389fab-e4e6-5fde-5e71-723717647295@htt-consult.com> <59B864F9.3050807@frank4dd.com> <4495a70d-3eff-95a9-a1d5-4b2da3532f7c@htt-consult.com> Message-ID: <29081.1505309511@obiwan.sandelman.ca> Robert Moskowitz wrote: > The devices never test out the lifetime of their certs. That is up to Exactly... (Do you think about the MacGyver/StarTrek/A-Team/Leverage/MissionImpossible plot line that goes along with each engineering decision?...) > validating servers. And the iDevID is not really intended for operational > use. Rather it is the security bootstrap for the lDevID. See the work being > done in the ANIMA workgroup as an example of what to do with this. Michael > Richardson, who recently joined this list is working on the related Internet > Draft(s). > I should test out a cert beyond 2038 on my armv7 32 bit Cubieboard. Will try > that tomorrow.... > I HAVE made certs with this value and I am displaying their content. But that > system is off right now. I will get one of the samples also tomorrow. > And yes, the industry does need to think some about this... I suspect that the value: literal value 99991231235959Z will simply come to mean "the end of time", even after the year 10,000. It has a well known DER encoding, and one can memcmp() it. Perhaps we will define an OID which means "no expiry", and start including that. I don't think the expiry date is an optional part. I will also have example vouchers, voucher requests and ECDSA ("prime256v1") certs with known private keys (so you can replicate my work) for the ANIMA BRSKI document, perhaps next week. I'd rather publish Curve25519/EdDSA examples, but it's too bleeding edge for the moment. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From rsalz at akamai.com Wed Sep 13 13:39:56 2017 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 13 Sep 2017 13:39:56 +0000 Subject: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates In-Reply-To: <29081.1505309511@obiwan.sandelman.ca> References: <86389fab-e4e6-5fde-5e71-723717647295@htt-consult.com> <59B864F9.3050807@frank4dd.com> <4495a70d-3eff-95a9-a1d5-4b2da3532f7c@htt-consult.com> <29081.1505309511@obiwan.sandelman.ca> Message-ID: An X509v3 certificate has ?notBefore? and ?notAfter? fields. If either of those is not present, then it is not an X509v3 certificate. The time marked by those fields is the validity period. If you want ?never expires? X509v3 certificates, the best you can do it put a very large value in the notAfter field. Some software may have issues around 32bit representation of classic Unix time_t and therefore have problems with times greater than 2038; OpenSSL does not have those problems. The OpenSSL command-line tools do not handle every possible corner case, including the ability to reasonably set dates that more than 7,500 years in the future. You will have to modify the source. From Michael.Wojcik at microfocus.com Wed Sep 13 15:08:51 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 13 Sep 2017 15:08:51 +0000 Subject: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates In-Reply-To: <29081.1505309511@obiwan.sandelman.ca> References: <86389fab-e4e6-5fde-5e71-723717647295@htt-consult.com> <59B864F9.3050807@frank4dd.com> <4495a70d-3eff-95a9-a1d5-4b2da3532f7c@htt-consult.com> <29081.1505309511@obiwan.sandelman.ca> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Michael Richardson > Sent: Wednesday, September 13, 2017 09:32 > > I suspect that the value: literal value 99991231235959Z will simply come to > mean "the end of time", even after the year 10,000.? It has a well known > DER encoding, and one can memcmp() it. Personally, I'm really hoping we're not still using ASN.1 in the year 10000. But I'll put something on my calendar for the year 9999 to remediate any possible issues in my software around this issue. -- Michael Wojcik Distinguished Engineer, Micro Focus From rgm at htt-consult.com Wed Sep 13 17:20:38 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Wed, 13 Sep 2017 13:20:38 -0400 Subject: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates In-Reply-To: References: <86389fab-e4e6-5fde-5e71-723717647295@htt-consult.com> <59B864F9.3050807@frank4dd.com> <4495a70d-3eff-95a9-a1d5-4b2da3532f7c@htt-consult.com> <29081.1505309511@obiwan.sandelman.ca> Message-ID: On 09/13/2017 09:39 AM, Salz, Rich via openssl-users wrote: > An X509v3 certificate has ?notBefore? and ?notAfter? fields. If either of those is not present, then it is not an X509v3 certificate. The time marked by those fields is the validity period. > > If you want ?never expires? X509v3 certificates, the best you can do it put a very large value in the notAfter field. Some software may have issues around 32bit representation of classic Unix time_t and therefore have problems with times greater than 2038; OpenSSL does not have those problems. > > The OpenSSL command-line tools do not handle every possible corner case, including the ability to reasonably set dates that more than 7,500 years in the future. You will have to modify the source. It handles notAfter past 2038 (25*365 days from today): openssl req -config $dir/openssl-root.cnf\ -set_serial 0x$(openssl rand -hex $sn)\ -keyform $format -outform $format\ -key $dir/private/ca.key.$format -subj "$DN"\ -new -x509 -days 9125 -sha256 -extensions v3_ca\ -out $dir/certs/ca.cert.$format openssl x509 -inform $format -in $dir/certs/ca.cert.$format\ -text -noout ... Validity Not Before: Sep 13 17:09:50 2017 GMT Not After : Sep 7 17:09:50 2042 GMT ... I create 802.1AR cert with: default_enddate = 99991231235959Z # per IEEE 802.1AR in the config: ... Validity Not Before: Sep 7 04:43:27 2017 GMT Not After : Dec 31 23:59:59 9999 GMT ... So it seems you can create things like signing certs with enddates out beyond 2038 and you can create EE certs with 'end of time' enddates. The rest is up to the software that uses these certs... Bob From Erwann.Abalea at docusign.com Wed Sep 13 17:17:21 2017 From: Erwann.Abalea at docusign.com (Erwann Abalea) Date: Wed, 13 Sep 2017 17:17:21 +0000 Subject: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates In-Reply-To: References: <86389fab-e4e6-5fde-5e71-723717647295@htt-consult.com> <59B864F9.3050807@frank4dd.com> <4495a70d-3eff-95a9-a1d5-4b2da3532f7c@htt-consult.com> <29081.1505309511@obiwan.sandelman.ca> Message-ID: <5D24CEA5-8F53-4AB0-8ED0-AEEF5E80BBBB@docusign.com> > Le 13 sept. 2017 ? 17:08, Michael Wojcik a ?crit : > >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Michael Richardson >> Sent: Wednesday, September 13, 2017 09:32 >> >> I suspect that the value: literal value 99991231235959Z will simply come to >> mean "the end of time", even after the year 10,000. It has a well known >> DER encoding, and one can memcmp() it. > > Personally, I'm really hoping we're not still using ASN.1 in the year 10000. Why not? ;) X.680 relies in ISO8601 for the date/time definitions. GeneralizedTime uses the Basic format from ISO8601 for the date (year on 4 digits, month on 2 starting with 01, day on 2 starting with 01), liberal time of day (minutes and/or seconds can be omitted, optional fraction of second/minute/hour depending on what is included), and a timezone from -15h to +15h with a one hour or one minute accuracy, or Z for UTC. BER accepts pretty much everything from this definition, DER has a few restrictions: - in ISO8601, there are 2 different midnights (00:00:00 and 24:00:00), the DER encoding requires such date/time to be transformed into 00:00:00 the day after - DER only accepts the ? Z ? timezone and not the +/-HH(MM) variant - DER requires the minutes and seconds to be present in the time of day, and no fraction of a second In theory, the very last date/time expressed in ASN.1 is 99991231240000+1500, and it would be valid if expressed in BER. In DER, the very last date/time would have been 99991231235960Z (in case a positive leap second gets inserted that day), but something else was preferred. It?s still possible that there?s a negative leap second happening at that exact day, removing second 59 completely. Just think of this as a magical value. Cordialement, Erwann Abalea From rgm at htt-consult.com Wed Sep 13 20:36:50 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Wed, 13 Sep 2017 16:36:50 -0400 Subject: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates In-Reply-To: <29081.1505309511@obiwan.sandelman.ca> References: <86389fab-e4e6-5fde-5e71-723717647295@htt-consult.com> <59B864F9.3050807@frank4dd.com> <4495a70d-3eff-95a9-a1d5-4b2da3532f7c@htt-consult.com> <29081.1505309511@obiwan.sandelman.ca> Message-ID: On 09/13/2017 09:31 AM, Michael Richardson wrote: > Robert Moskowitz wrote: > > The devices never test out the lifetime of their certs. That is up to > > Exactly... > (Do you think about the MacGyver/StarTrek/A-Team/Leverage/MissionImpossible > plot line that goes along with each engineering decision?...) Never was into watching TV. Maybe saw half a dozen MI and maybe 4 - 5 StarTrek, so I really can't answer this... :) > > validating servers. And the iDevID is not really intended for operational > > use. Rather it is the security bootstrap for the lDevID. See the work being > > done in the ANIMA workgroup as an example of what to do with this. Michael > > Richardson, who recently joined this list is working on the related Internet > > Draft(s). > > > I should test out a cert beyond 2038 on my armv7 32 bit Cubieboard. Will try > > that tomorrow.... > > > I HAVE made certs with this value and I am displaying their content. But that > > system is off right now. I will get one of the samples also tomorrow. > > > And yes, the industry does need to think some about this... > > I suspect that the value: literal value 99991231235959Z will simply come to > mean "the end of time", even after the year 10,000. It has a well known > DER encoding, and one can memcmp() it. > Perhaps we will define an OID which means "no expiry", and start including > that. I don't think the expiry date is an optional part. Nice thought. Not really an option. > I will also have example vouchers, voucher requests and ECDSA ("prime256v1") > certs with known private keys (so you can replicate my work) for the ANIMA > BRSKI document, perhaps next week. Do we agree on the DN and SAN content per 802.1AR? I am not entirely confident with my reading of what I contributed to! Well at that time I left the cert profile to others. I can send you a whole pki tree zipped up. Do you have any 'live' specimens? > I'd rather publish Curve25519/EdDSA examples, but it's too bleeding edge for the moment. We wait until 1.1.1 ships. But MAYBE we should be doing builds and testing now instead of after it ships... > -- > ] Never tell me the odds! | ipv6 mesh networks [ Odds are it won't make a difference. Bob From doctor at doctor.nl2k.ab.ca Thu Sep 14 12:09:11 2017 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Thu, 14 Sep 2017 06:09:11 -0600 Subject: [openssl-users] 20170914 snapshots Message-ID: <20170914120911.GA24772@doctor.nl2k.ab.ca> They are missing in action! -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism Talk Sense to a fool and he calls you foolish - Euripides From rsalz at akamai.com Thu Sep 14 12:29:38 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 14 Sep 2017 12:29:38 +0000 Subject: [openssl-users] [openssl-dev] 20170914 snapshots In-Reply-To: <20170914120911.GA24772@doctor.nl2k.ab.ca> References: <20170914120911.GA24772@doctor.nl2k.ab.ca> Message-ID: <53047E00-A952-4AAD-9F37-5976A0FFF870@akamai.com> We did some system upgrades and they were down during the update time. As I?ve said before, please wait for at least a second day before writing about the snapshots. On 9/14/17, 8:09 AM, "The Doctor" wrote: They are missing in action! From mcepl at cepl.eu Thu Sep 14 12:16:29 2017 From: mcepl at cepl.eu (=?UTF-8?Q?Mat=C4=9Bj?= Cepl) Date: Thu, 14 Sep 2017 14:16:29 +0200 Subject: [openssl-users] Lost in STACK_OF again (porting M2Crypto to OpenSSL 1.1.* API) References: <46e1df56-a7a6-90ff-80ad-3bf842369afb@cepl.eu> <20170912193326.GB20554@openssl.org> Message-ID: On 2017-09-12, 19:33 GMT, Dr. Stephen Henson wrote: > Yes *_seq_unpack() is no longer in 1.1. What happens is that > code above it generates a function d2i_SEQ_CERT() which does > the same as ASN1_seq_unpack() for a certificate. > > So something like this should work: > > const unsigned char *tmp = (unsigned char *)encoded_string; > > ... > > certs = d2i_SEQ_CERT(NULL, &tmp, encoded_string_len); Thank you very much for the help. It really helped! Also, for those who will get to this later, the documentation can be found in d2i_x509(3) and i2d_x509(3) (both are quite different in 1.1.0). Best, Mat?j -- http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 The law, in its majestic equality, forbids the rich as well as the poor to sleep under bridges, to beg in the streets, and to steal bread. -- Anatole France From npathak2 at ncsu.edu Thu Sep 14 20:20:02 2017 From: npathak2 at ncsu.edu (Neetish Pathak) Date: Thu, 14 Sep 2017 16:20:02 -0400 Subject: [openssl-users] TLS 1.3 performance Message-ID: Hi, I worked on TLS 1.3 performance bench-marking. After my tests, I found that TLS 1.3 based resumption is not giving us the connection latency benefits when tested in a LAN environment. It is slower than TLS 1.2. When tested on WAN, definitely, TLS 1.3 fares better than TLS 1.2. I want your suggestion on whether can I work on the following problem for my research project: *"Investigating why TLS 1.3 resumption/0-RTT/full-handshake doesn't provide the desired connection latency benefits in LAN and the ways to make it faster?"* I want suggestions/references on the right research problem. Any ideas will be appreciated. Thanks in advance Thanks Best Regards, Neetish -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roelof_Dutoit at symantec.com Thu Sep 14 20:45:31 2017 From: Roelof_Dutoit at symantec.com (Roelof Du Toit) Date: Thu, 14 Sep 2017 20:45:31 +0000 Subject: [openssl-users] [EXT] TLS 1.3 performance In-Reply-To: References: Message-ID: Hi Neetish, I would recommend considering the following in your research: - The impact of Nagle. See https://github.com/openssl/openssl/issues/4237 - The impact of the KeyShare calculation on TLS 1.3 session resumption (assuming most deployments will use psk_dhe_ke) - The impact of post-handshake handshake messages. Regards Roelof From: openssl-users on behalf of Neetish Pathak Reply-To: "openssl-users at openssl.org" Date: Thursday, September 14, 2017 at 4:20 PM To: "openssl-users at openssl.org" Subject: [EXT] [openssl-users] TLS 1.3 performance Hi, I worked on TLS 1.3 performance bench-marking. After my tests, I found that TLS 1.3 based resumption is not giving us the connection latency benefits when tested in a LAN environment. It is slower than TLS 1.2. When tested on WAN, definitely, TLS 1.3 fares better than TLS 1.2. I want your suggestion on whether can I work on the following problem for my research project: "Investigating why TLS 1.3 resumption/0-RTT/full-handshake doesn't provide the desired connection latency benefits in LAN and the ways to make it faster?" I want suggestions/references on the right research problem. Any ideas will be appreciated. Thanks in advance Thanks Best Regards, Neetish -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Thu Sep 14 21:03:39 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 14 Sep 2017 23:03:39 +0200 Subject: [openssl-users] Why wasn't the fix for IP name restrictions included in 1.0.2 ? Message-ID: <07e0f196-bbe2-e138-ca89-6f13f7bede49@wisemo.com> Way back in May 2014, there was a patch by Matt Casswell to not incorrectly reject all certificate chains with IP address name constraints and actual IP address names (dd36fce023a64d90058b8fefbd95dadaca98f9ca). However for some unknown reason, this was not included in 1.0.2 which thus still rejects all such certificate chains. Why? 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 rsalz at akamai.com Thu Sep 14 21:06:12 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 14 Sep 2017 21:06:12 +0000 Subject: [openssl-users] Why wasn't the fix for IP name restrictions included in 1.0.2 ? In-Reply-To: <07e0f196-bbe2-e138-ca89-6f13f7bede49@wisemo.com> References: <07e0f196-bbe2-e138-ca89-6f13f7bede49@wisemo.com> Message-ID: <2AD83111-7486-422A-9B04-F33DB3BC2E8F@akamai.com> ? However for some unknown reason, this was not included in 1.0.2 which thus still rejects all such certificate chains. Because it was seen to be a feature, not a bug-fix? From jb-openssl at wisemo.com Thu Sep 14 21:08:30 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 14 Sep 2017 23:08:30 +0200 Subject: [openssl-users] Why wasn't the fix for IP name restrictions included in 1.0.2 ? In-Reply-To: <2AD83111-7486-422A-9B04-F33DB3BC2E8F@akamai.com> References: <07e0f196-bbe2-e138-ca89-6f13f7bede49@wisemo.com> <2AD83111-7486-422A-9B04-F33DB3BC2E8F@akamai.com> Message-ID: <967c4454-5712-c7f7-366f-77ce087c9a39@wisemo.com> On 14/09/2017 23:06, Salz, Rich via openssl-users wrote: > ? However for some unknown reason, this was not included in 1.0.2 > which thus still rejects all such certificate chains. > > Because it was seen to be a feature, not a bug-fix? > But the patch was put in git almost 10 months before 1.0.2 initial 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 rsalz at akamai.com Thu Sep 14 23:05:22 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 14 Sep 2017 23:05:22 +0000 Subject: [openssl-users] Why wasn't the fix for IP name restrictions included in 1.0.2 ? In-Reply-To: <967c4454-5712-c7f7-366f-77ce087c9a39@wisemo.com> References: <07e0f196-bbe2-e138-ca89-6f13f7bede49@wisemo.com> <2AD83111-7486-422A-9B04-F33DB3BC2E8F@akamai.com> <967c4454-5712-c7f7-366f-77ce087c9a39@wisemo.com> Message-ID: <031AFDA8-884D-436B-9907-DDCC06C5E87A@akamai.com> ? But the patch was put in git almost 10 months before 1.0.2 initial release. We weren?t using git back then. So maybe it?s a bad/confusing import. Maybe matt can explain. From uri at ll.mit.edu Fri Sep 15 02:32:04 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 15 Sep 2017 02:32:04 +0000 Subject: [openssl-users] -pkeyopt parameters? Message-ID: I seem unable to figure how to configure RSA-OAEP parameters (hash and MGF functions) for ?opensl pkeyutl? command. The man page seems to say that only thing I can do is tell openssl CLI that I want OAEP padding, and nothing more. File ?apps/pkeyutl.c? was of no help. Where can I find all the pkeyopt parameters? Thanks! -- Regards, Uri -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5211 bytes Desc: not available URL: From matt at openssl.org Fri Sep 15 11:15:18 2017 From: matt at openssl.org (Matt Caswell) Date: Fri, 15 Sep 2017 12:15:18 +0100 Subject: [openssl-users] Why wasn't the fix for IP name restrictions included in 1.0.2 ? In-Reply-To: <031AFDA8-884D-436B-9907-DDCC06C5E87A@akamai.com> References: <07e0f196-bbe2-e138-ca89-6f13f7bede49@wisemo.com> <2AD83111-7486-422A-9B04-F33DB3BC2E8F@akamai.com> <967c4454-5712-c7f7-366f-77ce087c9a39@wisemo.com> <031AFDA8-884D-436B-9907-DDCC06C5E87A@akamai.com> Message-ID: On 15/09/17 00:05, Salz, Rich via openssl-users wrote: > > ? But the patch was put in git almost 10 months before 1.0.2 initial release. > > We weren?t using git back then. So maybe it?s a bad/confusing import. Maybe matt can explain. > Actually I think we were using git at that point. I calculate it at about 8 months at the point of that commit before the 1.0.2 release. IIRC 1.0.2 had a very long and protracted release period. It actually went into beta at the end of February 2014. Shortly afterwards heartbleed hit and we had our minds on other things for a bit, so it didn't get released until January 2015. The 1.0.2 branch was in "feature freeze" during that whole period - so that is almost certainly the reason why this wasn't backported. Perhaps if we had realised in May 2014 that we weren't going to release 1.0.2 for another 8 months then we might have made different decisions. Matt From rolsen at quotient-inc.com Fri Sep 15 13:24:57 2017 From: rolsen at quotient-inc.com (Richard Olsen) Date: Fri, 15 Sep 2017 09:24:57 -0400 Subject: [openssl-users] Self signed cert issue Message-ID: I've run out of ideas on this and hope someone here can help me. I'm trying to set up SSL with self signed certificates. I'm on RHEL6 with httpd 2.2.15-60.el6.9_5 using firefox browser. I've created the certs with the following code: [CODE] ### Options fed into certs ## Country Name (2 letter code) [XX]:US ## State or Province Name (full name) []:STATE ## Locality Name (eg, city) [Default City]:City ## Organization Name (eg, company) [Default Company Ltd]:Company ## Organizational Unit Name (eg, section) []:Section ## Common Name (eg, your name or your server's hostname) []:host.local.com ## Email Address []: # Create private key for CA openssl genrsa -out HOME_Root_CA.key 2048 # Create CA certificate openssl req -x509 -new -nodes -key HOME_Root_CA.key -sha256 -days 3650 -out HOME_Root_CA.pem # Review ticket just created openssl x509 -in HOME_Root_CA.pem -noout -text # Create private key for Server openssl genrsa -out HOME_Server.key 2048 # Create CA certificate openssl req -x509 -new -nodes -key HOME_Server.key -sha256 -days 3650 -out HOME_Server.pem # Review ticket just created openssl x509 -in HOME_Server.pem -noout -text # Create private key for Client openssl genrsa -out HOME_Client.key 2048 # Create Certificate Signing Request (.csr) openssl req -new -key HOME_Client.key -out HOME_Client.csr # Generate client certficate based on CA openssl x509 -req -in HOME_Client.csr -CA HOME_Root_CA.pem -CAkey HOME_Root_CA.key -CAcreateserial -out HOME_Client.pem -days 3650 -sha256 [/CODE] Then I tried to create a client cert i can import in the browser and be authenticated. [CODE] # Create Personal Information Exchange (pfx) cert openssl pkcs12 -export -in HOME_Client.pem -inkey HOME_Client.key -out HOME-client-cert.pfx [/CODE] My ssl config file in /etc/httpd/conf.d/home-test.conf [CODE] Listen 443 LoadModule ssl_module modules/mod_ssl.so DocumentRoot "/var/www/html" ErrorLog logs/ssl_error_log TransferLog logs/ssl_access_log #LogLevel warn LogLevel debug SSLEngine on SSLCertificateFile /var/tmp/HOME-test/HOME_Server.pem SSLCertificateKeyFile /var/tmp/HOME-test/HOME_Server.key SSLCACertificateFile /var/tmp/HOME-test/COMBO-test.pem #SSLCACertificateFile /var/tmp/HOME-test/HOME_Root_CA.pem #SSLVerifyClient require SSLVerifyClient optional #DocumentRoot "/var/www/html" [/CODE] So when i try to browse to [url]https://host.local.com[/url] i get the error "The owner of host.local.com has configured their website improperly. To protect your information from being stolen, Firefox has not connected to this website" When i click on advanced i see "host.local.com uses and invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. The server might not be sending the appropriate intermediate certficates. An addistional root certificate may need to be imported. Error code"SEC_ERROR_UNKNOWN_ISSUER" I created a Combo.pem file with the CA pem, Server pem, and client pem and put it as the SSLCACertificateFile but that didn't work either. What am i missing, I've been through so many web pages and still can't see the problem. Also trying to set up a client/user pkcs12 cert/file to authenticate to the above listed webserver. I have access to a set of certs for a different system and in the client.pfx file there are 2 certificates, but mine only has one -------------- next part -------------- An HTML attachment was scrubbed... URL: From wouter.verhelst at fedict.be Fri Sep 15 13:32:17 2017 From: wouter.verhelst at fedict.be (Wouter Verhelst) Date: Fri, 15 Sep 2017 15:32:17 +0200 Subject: [openssl-users] Self signed cert issue In-Reply-To: References: Message-ID: On 15-09-17 15:24, Richard Olsen wrote: > "host.local.com uses and invalid security > certificate. The certificate is not trusted because the issuer > certificate is unknown. The server might not be sending the appropriate > intermediate certficates. An addistional root certificate may need to be > imported> > Error code"SEC_ERROR_UNKNOWN_ISSUER" This is the normal message you get from firefox when your certificate is self-signed. It appears because firefox doesn't know the certificate issuer (obviously), and is important so as to avoid an MITM attack. You have three options: - (preferred) use something like letsencrypt to get a public-trusted certificate (although obviously that won't work if your site is not on the public Internet) - Create your own private CA that you then import as trusted into the browsers on your network (rather a lot of work, but probably the better option if this isn't just a home experiment) - Tell Firefox to ignore the fact that it's a self-signed certificate by clicking on the "Add exception..." button. In the dialog that appears, make sure that the "Permanently store this exception" option is checked, and hit "Confirm security exception". You will need to do this on every machine that wants to connect to your server, for every certificate that you create in this way, which may be a lot of work; if you don't want that, see above. -- Wouter Verhelst From dhm at mersenne.com Fri Sep 15 13:31:39 2017 From: dhm at mersenne.com (David H. Madden) Date: Fri, 15 Sep 2017 06:31:39 -0700 Subject: [openssl-users] Self signed cert issue In-Reply-To: References: Message-ID: <85615bfd-3d03-da4b-5f0a-18df3d497771@mersenne.com> On 15-Sep-2017 06:24, Richard Olsen wrote: > When i click on advanced i see > > "host.local.com uses and invalid security certificate. The certificate is > not trusted because the issuer certificate is unknown. The server might not > be sending the appropriate intermediate certficates. An addistional root > certificate may need to be imported. This is what you should expect to see. Your browser is telling you that your self-signed server certificate isn't part of a chain, where the top of the chain is some CA that the browser trusts (because the top-level CA is in a configuration file somewhere). You may be able to import the self-signed server certificate into the browser as a trusted root, but the slightly-better option is to set up your own top-level CA (whose certificate you import into the browser), and then use that CA to create your server and client certificates. It's a bit more work, but also more useful if you ever want to issue certificates for a different server, different client, or issue a new certificate after one expires (and not have to update all the self-signed stuff.) Regards, -- Mersenne Law ? www.mersenne.com ? +1-503-679-1671 Small Business, Startup & Intellectual Property Law 9600 S.W. Oak Street Suite 500 Tigard, Oregon 97223 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3937 bytes Desc: S/MIME Cryptographic Signature URL: From rolsen at quotient-inc.com Fri Sep 15 13:55:15 2017 From: rolsen at quotient-inc.com (Richard Olsen) Date: Fri, 15 Sep 2017 09:55:15 -0400 Subject: [openssl-users] Self signed cert issue In-Reply-To: References: Message-ID: Sorry I left out half of my message. I created from CA down. As listed below. ### Options fed into certs ## Country Name (2 letter code) [XX]:US ## State or Province Name (full name) []:STATE ## Locality Name (eg, city) [Default City]:City ## Organization Name (eg, company) [Default Company Ltd]:Company ## Organizational Unit Name (eg, section) []:Section ## Common Name (eg, your name or your server's hostname) []:host.local.com ## Email Address []: # Create private key for CA openssl genrsa -out HOME_Root_CA.key 2048 # Create CA certificate openssl req -x509 -new -nodes -key HOME_Root_CA.key -sha256 -days 3650 -out HOME_Root_CA.pem # Review ticket just created openssl x509 -in HOME_Root_CA.pem -noout -text # Create private key for Client openssl genrsa -out HOME_Client.key 2048 # Create Certificate Signing Request (.csr) openssl req -new -key HOME_Client.key -out HOME_Client.csr # Generate client certficate based on CA openssl x509 -req -in HOME_Client.csr -CA HOME_Root_CA.pem -CAkey HOME_Root_CA.key -CAcreateserial -out HOME_Client.pem -days 3650 -sha256 # Create Personal Information Exchange (pfx) cert openssl pkcs12 -export -in HOME_Client.pem -inkey HOME_Client.key -out HOME-client-cert.pfx On Fri, Sep 15, 2017 at 9:24 AM, Richard Olsen wrote: > I've run out of ideas on this and hope someone here can help me. I'm > trying to set up SSL with self signed certificates. I'm on RHEL6 with httpd > 2.2.15-60.el6.9_5 using firefox browser. I've created the certs with the > following code: > > [CODE] > > ### Options fed into certs > > ## Country Name (2 letter code) [XX]:US > > ## State or Province Name (full name) []:STATE > > ## Locality Name (eg, city) [Default City]:City > > ## Organization Name (eg, company) [Default Company Ltd]:Company > > ## Organizational Unit Name (eg, section) []:Section > > ## Common Name (eg, your name or your server's hostname) []:host.local.com > > ## Email Address []: > > # Create private key for CA > > openssl genrsa -out HOME_Root_CA.key 2048 > > # Create CA certificate > > openssl req -x509 -new -nodes -key HOME_Root_CA.key -sha256 -days 3650 > -out HOME_Root_CA.pem > > # Review ticket just created > > openssl x509 -in HOME_Root_CA.pem -noout -text > > # Create private key for Server > > openssl genrsa -out HOME_Server.key 2048 > > # Create CA certificate > > openssl req -x509 -new -nodes -key HOME_Server.key -sha256 -days 3650 -out > HOME_Server.pem > > # Review ticket just created > > openssl x509 -in HOME_Server.pem -noout -text > > # Create private key for Client > > openssl genrsa -out HOME_Client.key 2048 > > # Create Certificate Signing Request (.csr) > > openssl req -new -key HOME_Client.key -out HOME_Client.csr > > # Generate client certficate based on CA > > openssl x509 -req -in HOME_Client.csr -CA HOME_Root_CA.pem -CAkey > HOME_Root_CA.key -CAcreateserial -out HOME_Client.pem -days 3650 -sha256 > > [/CODE] > > Then I tried to create a client cert i can import in the browser and be > authenticated. > > [CODE] > > # Create Personal Information Exchange (pfx) cert > > openssl pkcs12 -export -in HOME_Client.pem -inkey HOME_Client.key -out > HOME-client-cert.pfx > > [/CODE] > > My ssl config file in /etc/httpd/conf.d/home-test.conf > > [CODE] > > Listen 443 > > LoadModule ssl_module modules/mod_ssl.so > > DocumentRoot "/var/www/html" > > > > > > > > ErrorLog logs/ssl_error_log > > TransferLog logs/ssl_access_log > > #LogLevel warn > > LogLevel debug > > SSLEngine on > > SSLCertificateFile /var/tmp/HOME-test/HOME_Server.pem > > SSLCertificateKeyFile /var/tmp/HOME-test/HOME_Server.key > > SSLCACertificateFile /var/tmp/HOME-test/COMBO-test.pem > > #SSLCACertificateFile /var/tmp/HOME-test/HOME_Root_CA.pem > > #SSLVerifyClient require > > SSLVerifyClient optional > > #DocumentRoot "/var/www/html" > > > > [/CODE] > > So when i try to browse to [url]https://host.local.com[/url] i get the > error > > "The owner of host.local.com has configured their website improperly. To > protect your information from being stolen, Firefox has not connected to > this website" > > When i click on advanced i see > > "host.local.com uses and invalid security certificate. The certificate is > not trusted because the issuer certificate is unknown. The server might not > be sending the appropriate intermediate certficates. An addistional root > certificate may need to be imported. > > Error code"SEC_ERROR_UNKNOWN_ISSUER" > > I created a Combo.pem file with the CA pem, Server pem, and client pem and > put it as the SSLCACertificateFile but that didn't work either. > > What am i missing, I've been through so many web pages and still can't see > the problem. > > > Also trying to set up a client/user pkcs12 cert/file to authenticate to > the above listed webserver. I have access to a set of certs for a > different system and in the client.pfx file there are 2 certificates, but > mine only has one > -- Richard W. Olsen Sr Security Engineer 6310 Hillside Court, Suite 101 Columbia, MD 21046 USA Phone: 301-225-9699 <301.225.9699> Email: rolsen at Quotient-Inc.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rolsen at quotient-inc.com Fri Sep 15 13:58:39 2017 From: rolsen at quotient-inc.com (Richard Olsen) Date: Fri, 15 Sep 2017 09:58:39 -0400 Subject: [openssl-users] Self signed cert issue In-Reply-To: <85615bfd-3d03-da4b-5f0a-18df3d497771@mersenne.com> References: <85615bfd-3d03-da4b-5f0a-18df3d497771@mersenne.com> Message-ID: I missed putting in the email that i created all the certs as listed below. SO i have the CA, Server and Client certs created. And tried to do the pfx file for authentication with a "Soft cert" where i'll have to configure later for a "hard cert" smartcard. ### Options fed into certs ## Country Name (2 letter code) [XX]:US ## State or Province Name (full name) []:STATE ## Locality Name (eg, city) [Default City]:City ## Organization Name (eg, company) [Default Company Ltd]:Company ## Organizational Unit Name (eg, section) []:Section ## Common Name (eg, your name or your server's hostname) []:host.local.com ## Email Address []: # Create private key for CA openssl genrsa -out HOME_Root_CA.key 2048 # Create CA certificate openssl req -x509 -new -nodes -key HOME_Root_CA.key -sha256 -days 3650 -out HOME_Root_CA.pem # Review ticket just created openssl x509 -in HOME_Root_CA.pem -noout -text # Create private key for Client openssl genrsa -out HOME_Client.key 2048 # Create Certificate Signing Request (.csr) openssl req -new -key HOME_Client.key -out HOME_Client.csr # Generate client certficate based on CA openssl x509 -req -in HOME_Client.csr -CA HOME_Root_CA.pem -CAkey HOME_Root_CA.key -CAcreateserial -out HOME_Client.pem -days 3650 -sha256 # Create Personal Information Exchange (pfx) cert openssl pkcs12 -export -in HOME_Client.pem -inkey HOME_Client.key -out HOME-client-cert.pfx On Fri, Sep 15, 2017 at 9:31 AM, David H. Madden wrote: > On 15-Sep-2017 06:24, Richard Olsen wrote: > > When i click on advanced i see > > > > "host.local.com uses and invalid security certificate. The certificate > is > > not trusted because the issuer certificate is unknown. The server might > not > > be sending the appropriate intermediate certficates. An addistional root > > certificate may need to be imported. > > This is what you should expect to see. Your browser is telling you that > your self-signed server certificate isn't part of a chain, where the top > of the chain is some CA that the browser trusts (because the top-level > CA is in a configuration file somewhere). > > You may be able to import the self-signed server certificate into the > browser as a trusted root, but the slightly-better option is to set up > your own top-level CA (whose certificate you import into the browser), > and then use that CA to create your server and client certificates. > > It's a bit more work, but also more useful if you ever want to issue > certificates for a different server, different client, or issue a new > certificate after one expires (and not have to update all the > self-signed stuff.) > > Regards, > -- > Mersenne Law ? www.mersenne.com ? +1-503-679-1671 > Small Business, Startup & Intellectual Property Law > 9600 S.W. Oak Street Suite 500 Tigard, Oregon 97223 > > -- Richard W. Olsen Sr Security Engineer 6310 Hillside Court, Suite 101 Columbia, MD 21046 USA Phone: 301-225-9699 <301.225.9699> Email: rolsen at Quotient-Inc.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From wouter.verhelst at fedict.be Fri Sep 15 14:06:12 2017 From: wouter.verhelst at fedict.be (Wouter Verhelst) Date: Fri, 15 Sep 2017 16:06:12 +0200 Subject: [openssl-users] Self signed cert issue In-Reply-To: References: <85615bfd-3d03-da4b-5f0a-18df3d497771@mersenne.com> Message-ID: <9baadc05-c95d-0f30-ec4e-6f5b85c7c72e@fedict.be> On 15-09-17 15:58, Richard Olsen wrote: > I missed putting in the email? that i created all the certs as listed > below. SO i have the CA, Server and Client certs created. And tried to > do the pfx file for authentication with a "Soft cert" where i'll have to > configure later for a "hard cert" smartcard. Okay, so what are you trying to do, then? - If you're trying to do client-side authentication, then you need to place your CA certificate in a file that you point to with SSLCACertificateFile (see http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslcacertificatefile for the apache 2.2 version of that configuration item). The Server certificate can be any (and should probably be a public-trust one). - If you're trying to authenticate your server against a private CA, then you should import the private CA certificate into your browser trust store. For firefox, you do that by going to Preferences -> Advanced -> View Certificates -> Authorities -> Import..., and then pointing to the .crt file. Note that while it is allowed, it is absolutely not necessary that your server certificate and client certificate are from the same CA. -- Wouter Verhelst From anton at advancedtelematic.com Fri Sep 15 14:12:37 2017 From: anton at advancedtelematic.com (Anton Gerasimov) Date: Fri, 15 Sep 2017 16:12:37 +0200 Subject: [openssl-users] Error in X509_check_private_key when using pkcs11 engine (OpenSSL 1.0.2j) Message-ID: Greetings, I'm trying to make OpenSSL (v. 1.0.2j) get client certificate/private key from a virtual PKCS#11 device, namely SoftHSM. I've imported a certificate and private key into SoftHSM, configured openssl as following and run ??? openssl s_client -engine pkcs11 -connect mydomain.com:443 -cert '/path/to/client.pem' -certform PEM -key 'pkcs11:serial=41e0a668eb25afbc;id=%02' -keyform engine (I've made it take the certificate from a file just to narrow down field of possible error causes, it gives similar results reading certifivate from the device as well). openssl then asks for a PIN and after receiving it returns "error setting private key" and the following error: 139798174321496:error:0B080075:x509 certificate routines:X509_check_private_key:unknown key type:x509_cmp.c:368: After some more debugging I've learned that X509_check_private_key() fails because EVP_PKEY_cmp() fails which in turn fails because eckey_pub_cmp() fails (yes, I use an EC key) which fails because "pb", return value of EC_KEY_get0_public_key() on the second parameter is NULL. It also looks like both compared keys have 'engine' set to NULL. I don't quite confident with what's going on here, so I would be grateful for any help from someone who is closer familiar with OpenSSL codebase. Thanks, Anton Gerasimov From rolsen at quotient-inc.com Fri Sep 15 14:29:47 2017 From: rolsen at quotient-inc.com (Richard Olsen) Date: Fri, 15 Sep 2017 10:29:47 -0400 Subject: [openssl-users] Self signed cert issue In-Reply-To: <9baadc05-c95d-0f30-ec4e-6f5b85c7c72e@fedict.be> References: <85615bfd-3d03-da4b-5f0a-18df3d497771@mersenne.com> <9baadc05-c95d-0f30-ec4e-6f5b85c7c72e@fedict.be> Message-ID: I created the CA, then created the key for a Server then created a server.csr and generated the cert. openssl genrsa -out HOME_Root_CA.key 2048openssl req -x509 -new -nodes -key HOME_Root_CA.key -sha256 -days 3650 -out HOME_Root_CA.pemopenssl x509 -in HOME_Root_CA.pem -noout -text # Create private key for Server openssl genrsa -out HOME_Server.key 2048 openssl req -new -key HOME_Server.key -out HOME_Server.csr openssl x509 -req -in HOME_Server.csr -CA HOME_Root_CA.pem -CAkey HOME_Root_CA.key -CAcreateserial -out HOME_Server.pem -days 3650 -sha256 The httpd/conf.d/home.conf file has SSLEngine on SSLCertificateFile /var/tmp/HOME-test/HOME_Server.pem SSLCertificateKeyFile /var/tmp/HOME-test/HOME_Server.key SSLCACertificateFile /var/tmp/HOME-test/COMBO-test.pem #SSLCACertificateFile /var/tmp/HOME-test/HOME_Root_CA.pem What i need is for the browser to aknowledge the CA i created. Since seeing responses to this saying i needed to import the CA into the browser i have done that and I get an "SCC_ERROR_Untrusted_ISSUER with that in place. On Fri, Sep 15, 2017 at 10:06 AM, Wouter Verhelst wrote: > > > On 15-09-17 15:58, Richard Olsen wrote: >> I missed putting in the email that i created all the certs as listed >> below. SO i have the CA, Server and Client certs created. And tried to >> do the pfx file for authentication with a "Soft cert" where i'll have to >> configure later for a "hard cert" smartcard. > > Okay, so what are you trying to do, then? > > - If you're trying to do client-side authentication, then you need to > place your CA certificate in a file that you point to with > SSLCACertificateFile (see > http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslcacertificatefile > for the apache 2.2 version of that configuration item). The Server > certificate can be any (and should probably be a public-trust one). > - If you're trying to authenticate your server against a private CA, > then you should import the private CA certificate into your browser > trust store. For firefox, you do that by going to Preferences -> > Advanced -> View Certificates -> Authorities -> Import..., and then > pointing to the .crt file. > > Note that while it is allowed, it is absolutely not necessary that your > server certificate and client certificate are from the same CA. > > -- > Wouter Verhelst > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Richard W. Olsen Sr Security Engineer 6310 Hillside Court, Suite 101 Columbia, MD 21046 USA Phone: 301-225-9699 Email: rolsen at Quotient-Inc.com From mcr at sandelman.ca Fri Sep 15 15:44:43 2017 From: mcr at sandelman.ca (Michael Richardson) Date: Fri, 15 Sep 2017 11:44:43 -0400 Subject: [openssl-users] documentation for 1.1.0 Message-ID: <6834.1505490283@obiwan.sandelman.ca> Many pages like: https://www.openssl.org/docs/man1.0.2/crypto/PEM_read_bio_PUBKEY.html will have a link on the right that says: "1.1.0" version, which I'd rather read because I'm using 1.1.0+, but it links to: https://www.openssl.org/docs/man1.1.0/crypto/pem.html which does not exist. Nor does the "master' page at: https://www.openssl.org/docs/manmaster/crypto/pem.html perhaps they are auto-generated, and the auto-generation is failing? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From rsalz at akamai.com Fri Sep 15 15:54:16 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 15 Sep 2017 15:54:16 +0000 Subject: [openssl-users] documentation for 1.1.0 In-Reply-To: <6834.1505490283@obiwan.sandelman.ca> References: <6834.1505490283@obiwan.sandelman.ca> Message-ID: <5864F7A5-0565-4274-BD83-CCA8D1903286@akamai.com> Links across versions don?t really work since we moved from ?crypto? ?ssl? to man3, etc. Perhaps we should just take them down. From mcr at sandelman.ca Fri Sep 15 15:57:17 2017 From: mcr at sandelman.ca (Michael Richardson) Date: Fri, 15 Sep 2017 11:57:17 -0400 Subject: [openssl-users] reading DER format public keys Message-ID: <9664.1505491037@obiwan.sandelman.ca> The PEM_* routines, as documented at: https://www.openssl.org/docs/man1.0.2/crypto/PEM_read_bio_PUBKEY.html do not claim to read DER format input. (Actually they don't say anything about DER). Ruby's library uses: pkey = PEM_read_bio_PUBKEY(bio, NULL, ossl_pem_passwd_cb, (void *)pass); It's documentation claims it read DER, which either it's wrong, or the underlying ruby extension or SSL code has changed. There must be a way to read DER format public keys. I'm suspecting that maybe the magic is in the way the BIO is created? (FAQ question PROG03, hints this for PKCS7 processing). Going to read the source code. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From rsalz at akamai.com Fri Sep 15 16:01:14 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 15 Sep 2017 16:01:14 +0000 Subject: [openssl-users] reading DER format public keys In-Reply-To: <9664.1505491037@obiwan.sandelman.ca> References: <9664.1505491037@obiwan.sandelman.ca> Message-ID: ? pkey = PEM_read_bio_PUBKEY(bio, NULL, ossl_pem_passwd_cb, (void *)pass); That only reads PEM files. If docs say otherwise, they are wrong. ? There must be a way to read DER format public keys. A raw public key? Or a cert? Or a pkcs object? Anyhow, doc/man3/d2i_X509.pod in master. From dave at dashs.denver.co.us Fri Sep 15 15:52:24 2017 From: dave at dashs.denver.co.us (Dave Serls) Date: Fri, 15 Sep 2017 09:52:24 -0600 Subject: [openssl-users] Compatibility of OpenSSL (Debian) Message-ID: <20170915095224.7422f793@groucho.dashs.denver.co.us> A file DES3 encrypted here by OpenSSL 1.0.1t 3 May 2016 (Debian 7 or earlier version) is not accessible by OpenSSL 1.1.0f 25 May 2017 (Debian 9). Is this expected behavior? -- ************************************************************************ * Dave Serls Littleton, CO, USA * * dashs.denver.co.us http://www.dashs.com * ************************************************************************ From dave at dashs.denver.co.us Fri Sep 15 16:07:50 2017 From: dave at dashs.denver.co.us (Dave Serls) Date: Fri, 15 Sep 2017 10:07:50 -0600 Subject: [openssl-users] documentation for 1.1.0 In-Reply-To: <5864F7A5-0565-4274-BD83-CCA8D1903286@akamai.com> References: <6834.1505490283@obiwan.sandelman.ca> <5864F7A5-0565-4274-BD83-CCA8D1903286@akamai.com> Message-ID: <20170915100750.38b602d3@groucho.dashs.denver.co.us> On Fri, 15 Sep 2017 15:54:16 +0000 "Salz, Rich via openssl-users" wrote: > Links across versions don?t really work since we moved from ?crypto? ?ssl? to man3, etc. > Perhaps we should just take them down. One might suppose that it "failed" to a secure mode. Older files will remain secure for eternity. The user, of course, must be alert to decrypting data prior to upgrade, or retaining a down-level openssl environment somewhere close by. For me, it is only a home-brew keyring that quickly got my attention. > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- ************************************************************************ * Dave Serls Littleton, CO, USA * * dashs.denver.co.us http://www.dashs.com * ************************************************************************ From rgm at htt-consult.com Fri Sep 15 16:12:14 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Fri, 15 Sep 2017 12:12:14 -0400 Subject: [openssl-users] reading DER format public keys In-Reply-To: <9664.1505491037@obiwan.sandelman.ca> References: <9664.1505491037@obiwan.sandelman.ca> Message-ID: On 09/15/2017 11:57 AM, Michael Richardson wrote: > The PEM_* routines, as documented at: > https://www.openssl.org/docs/man1.0.2/crypto/PEM_read_bio_PUBKEY.html > do not claim to read DER format input. (Actually they don't say anything about DER). > Ruby's library uses: > pkey = PEM_read_bio_PUBKEY(bio, NULL, ossl_pem_passwd_cb, (void *)pass); > > It's documentation claims it read DER, which either it's wrong, or the > underlying ruby extension or SSL code has changed. > > There must be a way to read DER format public keys. > I'm suspecting that maybe the magic is in the way the BIO is created? > (FAQ question PROG03, hints this for PKCS7 processing). I had problems with DER using the command line options. I can create, and display a DER keypair, a CSR, a self-signed cert. I cannot use a CSR to make a cert where everything is DER. So something is missing somewhere. If you search back a bit, you will find my postings on this with the error messages I got. > Going to read the source code. You are better man than I... Bob From rsalz at akamai.com Fri Sep 15 16:17:12 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 15 Sep 2017 16:17:12 +0000 Subject: [openssl-users] Compatibility of OpenSSL (Debian) In-Reply-To: <20170915095224.7422f793@groucho.dashs.denver.co.us> References: <20170915095224.7422f793@groucho.dashs.denver.co.us> Message-ID: <5B674478-622B-47B5-AA05-53966204E662@akamai.com> A file DES3 encrypted here by OpenSSL 1.0.1t 3 May 2016 (Debian 7 or earlier version) is not accessible by OpenSSL 1.1.0f 25 May 2017 (Debian 9). Is this expected behavior? https://www.openssl.org/docs/faq.html#USER3 From jsouthwell at serengeti.com Fri Sep 15 16:13:27 2017 From: jsouthwell at serengeti.com (Joseph Southwell) Date: Fri, 15 Sep 2017 12:13:27 -0400 Subject: [openssl-users] Compatibility of OpenSSL (Debian) In-Reply-To: <20170915095224.7422f793@groucho.dashs.denver.co.us> References: <20170915095224.7422f793@groucho.dashs.denver.co.us> Message-ID: <4BB82283-06B9-487A-93BA-9C7CFFC0C45A@serengeti.com> See: https://www.openssl.org/blog/blog/2016/08/24/sweet32 > On Sep 15, 2017, at 11:52 AM, Dave Serls wrote: > > > A file DES3 encrypted here by OpenSSL 1.0.1t 3 May 2016 (Debian 7 or earlier version) is not accessible > by OpenSSL 1.1.0f 25 May 2017 (Debian 9). Is this expected behavior? > > -- > ************************************************************************ > * Dave Serls Littleton, CO, USA * > * dashs.denver.co.us http://www.dashs.com * > ************************************************************************ > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From openssl-users at dukhovni.org Fri Sep 15 16:43:32 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 15 Sep 2017 16:43:32 +0000 Subject: [openssl-users] reading DER format public keys In-Reply-To: <9664.1505491037@obiwan.sandelman.ca> References: <9664.1505491037@obiwan.sandelman.ca> Message-ID: <20170915164332.GX3322@mournblade.imrryr.org> On Fri, Sep 15, 2017 at 11:57:17AM -0400, Michael Richardson wrote: > pkey = PEM_read_bio_PUBKEY(bio, NULL, ossl_pem_passwd_cb, (void *)pass); > There must be a way to read DER format public keys. > I'm suspecting that maybe the magic is in the way the BIO is created? > (FAQ question PROG03, hints this for PKCS7 processing). The function you're looking for is d2i_PUBKEY(3). See for example: https://github.com/openssl/openssl/blob/master/ssl/ssl_lib.c#L344 which parses public keys from "TLSA ? 1 0 " records, which have a DER encoding of the X.509 SubjectPublicKeyInfo (SPKI) in the associated-data (4th) RData field. It is the DER analogue of PEM_read_bio_PUBKEY. With few exceptions, you can s/PEM_READ_bio/d2i/ to go from reading PEM to reading DER. -- Viktor. From anton at advancedtelematic.com Fri Sep 15 16:43:58 2017 From: anton at advancedtelematic.com (Anton Gerasimov) Date: Fri, 15 Sep 2017 18:43:58 +0200 Subject: [openssl-users] Error in X509_check_private_key when using pkcs11 engine (OpenSSL 1.0.2j) In-Reply-To: References: Message-ID: <5d44b92e-e430-3b07-d367-ab3af3695e95@advancedtelematic.com> So it turns out load_privkey() function of engine_pkcs11.so sets pub_key in the returned 'struct ec_key_st' to NULL. Is it a failure inside engine_pkcs11.so? Thanks, Anton Gerasimov From security.veteran at gmail.com Fri Sep 15 21:35:25 2017 From: security.veteran at gmail.com (security veteran) Date: Fri, 15 Sep 2017 14:35:25 -0700 Subject: [openssl-users] Errors when running OpenSSL fipsalgtest.pl Message-ID: Hi All: I was using the fipsalgtest.pl utility for running tests with some input vectors. Somehow I ran into the following errors: Any suggestions will be greatly appreciated. Thanks. *Running ECDSA2 tests* DEBUG: KeyPair, Pass=240, Fail=0 ERROR: PKV mismatch: "QX = Z87BV029A938A157D32I7662BFBC5252BB1016B9347F7J93" != "QX = LKJHGB0E5B672ETD46D39D35E2797F8E25C3572D87A29653" DEBUG: SigGen, Pass=600, Fail=0 ERROR:100E5092:lib=16,func=229,reason=146:file=ec_key.c:line=522 Error setting public key Error running SigVer WARNING: error executing test SigVer for command: ../test/fips_ecdsavs SigVer "/TestVector/ECDSA/req/SigVer.req" "/TestVector/ECDSA/resp/SigVer. tst" *Running RSA tests* FATAL parse error processing line 4 FATAL RSAVTEST file processing error WARNING: error executing verify test SigGen15 ../test/fips_rsavtest "/TestVector/RSA/resp/SigGen15_186-3.tst" "/TestVector/RSA/resp/SigGen15_ 186-3.ver" -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Fri Sep 15 22:18:50 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Fri, 15 Sep 2017 22:18:50 +0000 Subject: [openssl-users] Error in X509_check_private_key when using pkcs11 engine (OpenSSL 1.0.2j) In-Reply-To: <5d44b92e-e430-3b07-d367-ab3af3695e95@advancedtelematic.com> References: <5d44b92e-e430-3b07-d367-ab3af3695e95@advancedtelematic.com> Message-ID: <20170915221850.GA1978@openssl.org> On Fri, Sep 15, 2017, Anton Gerasimov wrote: > So it turns out load_privkey() function of engine_pkcs11.so sets pub_key > in the returned 'struct ec_key_st' to NULL. Is it a failure inside > engine_pkcs11.so? > Well sort of. OpenSSL requires that public key components are set for private keys (except for a legacy RSA case). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From mcr at sandelman.ca Fri Sep 15 22:24:43 2017 From: mcr at sandelman.ca (Michael Richardson) Date: Fri, 15 Sep 2017 18:24:43 -0400 Subject: [openssl-users] reading DER format public keys In-Reply-To: <20170915164332.GX3322@mournblade.imrryr.org> References: <9664.1505491037@obiwan.sandelman.ca> <20170915164332.GX3322@mournblade.imrryr.org> Message-ID: <32739.1505514283@obiwan.sandelman.ca> Viktor Dukhovni wrote: > On Fri, Sep 15, 2017 at 11:57:17AM -0400, Michael Richardson wrote: >> pkey = PEM_read_bio_PUBKEY(bio, NULL, ossl_pem_passwd_cb, (void *)pass); >> There must be a way to read DER format public keys. >> I'm suspecting that maybe the magic is in the way the BIO is created? >> (FAQ question PROG03, hints this for PKCS7 processing). > The function you're looking for is d2i_PUBKEY(3). See for example: > https://github.com/openssl/openssl/blob/master/ssl/ssl_lib.c#L344 Once I realized what this does, I then realized that it wasn't about just about doing something to setup the bio.... then I realized that the ruby interface was in fact calling that. *THEN* I realized I was feeding a certificate blob into a PK routine, and that was really the problem. > It is the DER analogue of PEM_read_bio_PUBKEY. With few exceptions, > you can s/PEM_READ_bio/d2i/ to go from reading PEM to reading DER. It would be great if there were cross-references... -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From openssl-users at dukhovni.org Sat Sep 16 01:29:33 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 15 Sep 2017 21:29:33 -0400 Subject: [openssl-users] reading DER format public keys In-Reply-To: <32739.1505514283@obiwan.sandelman.ca> References: <9664.1505491037@obiwan.sandelman.ca> <20170915164332.GX3322@mournblade.imrryr.org> <32739.1505514283@obiwan.sandelman.ca> Message-ID: <0C5F9314-9D4E-476B-8887-224C7FB662BE@dukhovni.org> > On Sep 15, 2017, at 6:24 PM, Michael Richardson wrote: > >> It is the DER analogue of PEM_read_bio_PUBKEY. With few exceptions, >> you can s/PEM_READ_bio/d2i/ to go from reading PEM to reading DER. > > It would be great if there were cross-references... I should note that the PEM_read_bio routines read data from a file, while the d2i_PUBKEY() routine decodse data from memory. The corresponding "read a file" routines are: d2i_PUBKEY_bio() and d2i_PUBKEY_fp() -- Viktor. From npathak2 at ncsu.edu Sun Sep 17 02:22:43 2017 From: npathak2 at ncsu.edu (Neetish Pathak) Date: Sat, 16 Sep 2017 22:22:43 -0400 Subject: [openssl-users] [EXT] TLS 1.3 performance In-Reply-To: References: Message-ID: Thanks Roelof, This is really helpful. BR, Neetish On Thu, Sep 14, 2017 at 4:45 PM, Roelof Du Toit wrote: > Hi Neetish, > > > > I would recommend considering the following in your research: > > - The impact of Nagle. See https://github.com/openssl/openssl/issues/4237 > > - The impact of the KeyShare calculation on TLS 1.3 session resumption > (assuming most deployments will use psk_dhe_ke) > > - The impact of post-handshake handshake messages. > > > > Regards > > Roelof > > > > *From: *openssl-users on behalf of > Neetish Pathak > *Reply-To: *"openssl-users at openssl.org" > *Date: *Thursday, September 14, 2017 at 4:20 PM > *To: *"openssl-users at openssl.org" > *Subject: *[EXT] [openssl-users] TLS 1.3 performance > > > > Hi, > > > > I worked on TLS 1.3 performance bench-marking. After my tests, I found > that TLS 1.3 based resumption is not giving us the connection latency > benefits when tested in a LAN environment. It is slower than TLS 1.2. When > tested on WAN, definitely, TLS 1.3 fares better than TLS 1.2. > > I want your suggestion on whether can I work on the following problem for > my research project: *"Investigating why TLS 1.3 > resumption/0-RTT/full-handshake doesn't provide the desired connection > latency benefits in LAN and the ways to make it faster?"* > > I want suggestions/references on the right research problem. Any ideas > will be appreciated. > > > > Thanks in advance > > > > Thanks > > Best Regards, > > Neetish > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Sun Sep 17 22:26:32 2017 From: marquess at openssl.com (stevem) Date: Sun, 17 Sep 2017 18:26:32 -0400 Subject: [openssl-users] Errors when running OpenSSL fipsalgtest.pl In-Reply-To: References: Message-ID: <79652de3-0482-721a-39f0-55bdb2a4d2f8@openssl.com> On 09/15/2017 05:35 PM, security veteran wrote: > Hi All: > > I was using the fipsalgtest.pl utility for running tests with some input > vectors. > > Somehow I ran into the following errors: > > Any suggestions will be greatly appreciated. > > Thanks. > > > The format of the test vectors changes constantly so fipsalgtest.pl needs constant tweaking. Also it is not uncommon for any specific set of test vectors to have errors; they are manually generated from a labor intensive software tool and it's all too easy for the test lab to err even when the current version of the tool isn't buggy (also not uncommon). Each set of test vectors needs to be carefully matched to the specific module. Figuring our such discrepancies can be a lot of fun (not!). I suggest you start by comparing the test vectors you're trying to process with one of the recent sets at https://www.openssl.com/testing/validation-2.0/testvectors/. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 301 874 2571 marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From Lily.Zhang at dell.com Mon Sep 18 02:23:42 2017 From: Lily.Zhang at dell.com (Zhang, Lily (USD)) Date: Mon, 18 Sep 2017 02:23:42 +0000 Subject: [openssl-users] Openssl failed to decrypt certificate without \r\n Message-ID: Hi, Would you help me to take a look this certificate issue? In order to send out the file, I added ".txt" in the file name. Please remove it before test it. Leaf_no_rn.cer doesn't have \r\n in the BASE64 string, it can't be parsed by openssl. Leaf_with_rn.cer is the same as Leaf_no_rn.cer, but it has \r\n in BASE64 string. Both the attached two certificates can be parsed by Windows. I tried other certificates, then can be parsed by in both formats(with \r\n and no\r\n). Do you know why Leaf_no_rn.cer can't be parsed by " openssl x509 -in C:\Temp\Leaf_with_rn.cer -text"? ------------------------------------------------------------------------------------------ C:\OpenSSL\bin>openssl x509 -in C:\Temp\Leaf_with_rn.cer -text Certificate: Data: Version: 3 (0x2) Serial Number: 59:00:00:04:30:86:b8:28:2b:df:d1:0b:ae:00:00:00:00:04: Signature Algorithm: sha256WithRSAEncryption Issuer: DC=com, DC=njmgroup, CN=NJMSubEnt-CA Validity Not Before: Apr 20 08:21:19 2017 GMT Not After : Apr 20 08:21:19 2018 GMT Subject: CN=DCWT1.njmgroup.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) Modulus: 00:af:89:3b:a2:20:62:e6:9a:90:fe:2b:bb:81:8d: 78:68:0f:43:a5:98:67:29:21:1e:f2:5f:b3:15:7a: 86:9f:2c:74:40:8e:82:8c:0e:dd:b1:ea:6b:26:c1: 1d:8f:1b:8e:4c:d4:93:2a:b7:3b:1d:12:a9:2d:73: 6b:67:85:57:9c:28:5d:71:f2:f8:bd:0a:c9:58:79: d7:c1:78:99:d2:91:81:ed:a6:41:e9:b8:ac:61:d4: 78:52:79:bc:af:d4:68:b8:b3:f6:3d:1e:45:db:9b: e3:95:31:01:e2:3a:e3:76:84:ba:70:68:0b:1a:fd: 2f:1f:31:86:f3:be:1e:ff:29 Exponent: 65537 (0x10001) X509v3 extensions: 1.3.6.1.4.1.311.20.2: . .D.o.m.a.i.n.C.o.n.t.r.o.l.l.e.r X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Auth X509v3 Key Usage: Digital Signature, Key Encipherment S/MIME Capabilities: ......0...`.H.e...*0...`.H.e...-0...`.H.e....0...`.H.e....0...+... ..*.H.. X509v3 Subject Alternative Name: othername:, DNS:DCWT1.njmgroup.com X509v3 Subject Key Identifier: 8B:8B:36:E1:61:A2:85:77:28:17:97:C1:49:A0:B2:AE:9D X509v3 Authority Key Identifier: keyid:B5:B6:D4:63:FE:24:A2:45:68:93:D1:DD:D1:A2:21 E X509v3 CRL Distribution Points: Full Name: URI:ldap:///CN=NJMSubEnt-CA,CN=SCAPWT1,CN=CDP,CN 20Services,CN=Services,CN=Configuration,DC=njmgroup,DC=com?certifi List?base?objectClass=cRLDistributionPoint URI:http://pki.njmgroup.com/CertEnroll/NJMSubEnt Authority Information Access: CA Issuers - URI:ldap:///CN=NJMSubEnt-CA,CN=AIA,CN 20Services,CN=Services,CN=Configuration,DC=njmgroup,DC=com?cACerti jectClass=certificationAuthority CA Issuers - URI:http://pki.njmgroup.com/CertEnrol roup.com_NJMSubEnt-CA.crt Signature Algorithm: sha256WithRSAEncryption 31:49:55:f2:e5:29:35:c4:8f:7b:7b:22:3f:ed:2f:4a:c5:26: b0:88:47:92:39:3e:b6:0f:c7:f3:7b:c9:6d:1b:16:ac:78:9b: 62:d1:ff:dc:74:40:41:68:ac:11:65:d6:bf:fb:8f:18:66:13: 83:f6:6e:39:5a:01:2d:01:31:55:a6:1a:61:ac:02:0a:9f:ad: ac:c4:5f:b6:1e:5f:b6:18:9f:5b:77:1c:d7:f0:4a:35:bd:37: cf:23:ec:90:3d:18:a7:8f:e7:9c:73:ba:9f:1f:55:8c:c4:79: 28:23:d6:ce:31:f4:5e:c7:e4:8d:93:fb:f6:c7:c2:96:e3:bb: 0d:fd:af:cc:fb:bf:6c:f9:81:64:3c:c7:38:f7:c4:d1:7c:70: f6:e7:9a:71:e7:89:aa:82:19:cd:49:1b:81:3d:1b:37:b3:c9: c1:6c:a1:2d:76:46:fe:bd:21:65:50:58:0f:6a:68:90:0e:12: be:05:44:49:12:49:87:70:88:79:3d:84:c4:7e:8a:1b:45:cd: a4:92:fe:49:0f:84:42:e8:9f:78:97:f3:ca:24:92:03:05:aa: a7:7d:5f:99:92:cd:9f:f3:b5:27:06:24:41:81:03:86:0a:c5: 52:68:7b:67:f4:e0:b9:5c:e5:a9:36:2d:77:f2:96:d0:6f:e1: cc:f9:53:51 -----BEGIN CERTIFICATE----- MIIF6DCCBNCgAwIBAgITWQAABDCGuCgr39ELrgAAAAAEMDANBgkqhkiG9w0BAQsF ADBGMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmptZ3Jv dXAxFTATBgNVBAMTDE5KTVN1YkVudC1DQTAeFw0xNzA0MjAwODIxMTlaFw0xODA0 MjAwODIxMTlaMB0xGzAZBgNVBAMTEkRDV1QxLm5qbWdyb3VwLmNvbTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAr4k7oiBi5pqQ/iu7gY14aA9DpZhnKSEe8l+z FXqGnyx0QI6CjA7dseprJsEdjxuOTNSTKrc7HRKpLXNrZ4VXnChdcfL4vQrJWHnX wXiZ0pGB7aZB6bisYdR4Unm8r9RouLP2PR5F25vjlTEB4jrjdoS6cGgLGv0vHzGG 874e/ykCAwEAAaOCA3owggN2MC8GCSsGAQQBgjcUAgQiHiAARABvAG0AYQBpAG4A QwBvAG4AdAByAG8AbABsAGUAcjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwEwCwYDVR0PBAQDAgWgMHgGCSqGSIb3DQEJDwRrMGkwDgYIKoZIhvcNAwICAgCA MA4GCCqGSIb3DQMEAgIAgDALBglghkgBZQMEASowCwYJYIZIAWUDBAEtMAsGCWCG SAFlAwQBAjALBglghkgBZQMEAQUwBwYFKw4DAgcwCgYIKoZIhvcNAwcwPgYDVR0R BDcwNaAfBgkrBgEEAYI3GQGgEgQQQfY96mn8bUa6Xjr69o65/4ISRENXVDEubmpt Z3JvdXAuY29tMB0GA1UdDgQWBBSLizbhYaKFdygXl8FJoLKuncl7eDAfBgNVHSME GDAWgBS1ttRj/iSiRWiT0d3RoiHngvKnfjCCAQAGA1UdHwSB+DCB9TCB8qCB76CB 7IaBtGxkYXA6Ly8vQ049TkpNU3ViRW50LUNBLENOPVNDQVBXVDEsQ049Q0RQLENO PVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3Vy YXRpb24sREM9bmptZ3JvdXAsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxp c3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYzaHR0cDov L3BraS5uam1ncm91cC5jb20vQ2VydEVucm9sbC9OSk1TdWJFbnQtQ0EuY3JsMIIB FwYIKwYBBQUHAQEEggEJMIIBBTCBrAYIKwYBBQUHMAKGgZ9sZGFwOi8vL0NOPU5K TVN1YkVudC1DQSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1uam1ncm91cCxEQz1jb20/Y0FD ZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwVAYIKwYBBQUHMAKGSGh0dHA6Ly9wa2kubmptZ3JvdXAuY29tL0NlcnRFbnJv bGwvU0NBUFdUMS5uam1ncm91cC5jb21fTkpNU3ViRW50LUNBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAMUlV8uUpNcSPe3siP+0vSsUmsIhHkjk+tg/H83vJbRsWrHib YtH/3HRAQWisEWXWv/uPGGYTg/ZuOVoBLQExVaYaYawCCp+trMRfth5fthifW3cc 1/BKNb03zyPskD0Yp4/nnHO6nx9VjMR5KCPWzjH0XsfkjZP79sfCluO7Df2vzPu/ bPmBZDzHOPfE0Xxw9ueaceeJqoIZzUkbgT0bN7PJwWyhLXZG/r0hZVBYD2pokA4S vgVESRJJh3CIeT2ExH6KG0XNpJL+SQ+EQuifeJfzyiSSAwWqp31fmZLNn/O1JwYk QYEDhgrFUmh7Z/TguVzlqTYtd/KW0G/hzPlTUQ== -----END CERTIFICATE----- C:\OpenSSL\bin>openssl x509 -in C:\Temp\Leaf_no_rn.cer -text unable to load certificate -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Leaf_no_rn.cer.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Leaf_with_rn.cer.txt URL: From openssl-users at dukhovni.org Mon Sep 18 05:59:41 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 18 Sep 2017 01:59:41 -0400 Subject: [openssl-users] Openssl failed to decrypt certificate without \r\n In-Reply-To: References: Message-ID: <79924ABB-0BC7-4BAA-903D-447B148C99D9@dukhovni.org> > On Sep 17, 2017, at 10:23 PM, Zhang, Lily (USD) wrote: > > Would you help me to take a look this certificate issue? > In order to send out the file, I added ".txt" in the file name. Please remove it before test it. > > Leaf_no_rn.cer doesn't have \r\n in the BASE64 string, it can't be parsed by openssl. > Leaf_with_rn.cer is the same as Leaf_no_rn.cer, but it has \r\n in BASE64 string. > Both the attached two certificates can be parsed by Windows. This is expected, the OpenSSL PEM file reader does not support input lines with IIRC more than 64 bytes. PEM files are not supposed to have longer lines. -- Viktor. From Lily.Zhang at dell.com Mon Sep 18 07:21:15 2017 From: Lily.Zhang at dell.com (Zhang, Lily (USD)) Date: Mon, 18 Sep 2017 07:21:15 +0000 Subject: [openssl-users] Openssl failed to decrypt certificate without \r\n In-Reply-To: <79924ABB-0BC7-4BAA-903D-447B148C99D9@dukhovni.org> References: <79924ABB-0BC7-4BAA-903D-447B148C99D9@dukhovni.org> Message-ID: Hi, Viktor Thanks for your reply. Why it can decrypt attached root.cer, it also has long lines in root.cer? Thanks Lily -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Viktor Dukhovni Sent: Monday, September 18, 2017 2:00 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] Openssl failed to decrypt certificate without \r\n > On Sep 17, 2017, at 10:23 PM, Zhang, Lily (USD) wrote: > > Would you help me to take a look this certificate issue? > In order to send out the file, I added ".txt" in the file name. Please remove it before test it. > > Leaf_no_rn.cer doesn't have \r\n in the BASE64 string, it can't be parsed by openssl. > Leaf_with_rn.cer is the same as Leaf_no_rn.cer, but it has \r\n in BASE64 string. > Both the attached two certificates can be parsed by Windows. This is expected, the OpenSSL PEM file reader does not support input lines with IIRC more than 64 bytes. PEM files are not supposed to have longer lines. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: root.cer.txt URL: From openssl-users at dukhovni.org Mon Sep 18 07:47:56 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 18 Sep 2017 03:47:56 -0400 Subject: [openssl-users] Openssl failed to decrypt certificate without \r\n In-Reply-To: References: <79924ABB-0BC7-4BAA-903D-447B148C99D9@dukhovni.org> Message-ID: <30632169-4573-4D4C-86E9-F5C66843B6C1@dukhovni.org> > On Sep 18, 2017, at 3:21 AM, Zhang, Lily (USD) wrote: > > Why it can decrypt attached root.cer, it also has long lines in root.cer? > > The OpenSSL PEM code cannot decode that file. Its lines are too long: $ PS2=""; openssl x509 -subject -noout < <79924ABB-0BC7-4BAA-903D-447B148C99D9@dukhovni.org> Message-ID: I can decrypt the root.cer successfully. And my error of leaf_no_rn.cer is different from you. OpenSSL> x509 -in C:\Temp\leaf_no_rn.cer -text unable to load certificate error in x509 OpenSSL> version OpenSSL 1.0.2h 3 May 2016 OpenSSL> x509 -in C:\Temp\root.cer -text Certificate: Data: Version: 3 (0x2) Serial Number: 44:11:16:87:de:09:6e:ac:42:50:b5:d9:13:35:f9:16 Signature Algorithm: sha256WithRSAEncryption Issuer: CN=NJMRoot-CA Validity Not Before: Jun 22 14:54:53 2015 GMT Not After : Jun 22 15:04:53 2025 GMT Subject: CN=NJMRoot-CA Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:ca:38:ac:14:ba:7c:b2:1c:f2:14:70:08:10:b0: 0b:be:45:51:d9:50:6e:72:ba:10:97:7f:49:1b:b9: a9:61:ca:54:7b:55:d6:41:7d:82:20:ff:a5:02:9a: fa:61:ed:af:bb:47:d4:95:e8:d1:51:d3:05:1d:43: 4a:3a:3e:63:af:58:7f:3b:bc:3e:d3:19:9b:ba:31: d6:78:f0:09:33:97:ac:bd:27:49:15:23:f3:fa:04: 17:d4:e6:d3:fd:20:ef:87:f9:b4:38:14:2c:45:9e: ee:39:03:80:7d:e2:14:bc:2b:b3:e4:0c:f0:d5:b8: 06:66:27:71:0d:7a:42:5e:86:8f:fb:d8:73:91:52: c8:fe:ba:56:c5:07:37:18:f4:61:47:1f:1b:b0:46: 74:3d:56:96:9d:90:8d:83:0c:64:04:de:44:e8:c7: e1:c0:4c:4a:c7:76:ff:ed:08:6e:4c:10:1c:48:f5: 0f:e3:ce:10:d3:54:15:84:a1:dd:5f:da:61:88:8a: 6d:82:2e:c7:08:7a:35:62:91:92:37:49:b6:be:ac: 50:61:f5:e3:46:79:7b:ff:9b:64:ca:cb:75:ba:01: c2:de:c4:1a:80:d1:4a:bb:6f:b0:5a:a5:f3:96:a6: 17:2e:63:0a:8b:eb:1d:72:b8:84:a7:2d:08:e7:db: d3:9d Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: Digital Signature, Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE X509v3 Subject Key Identifier: B9:17:D1:69:23:34:17:B5:52:68:E9:FF:F8:57:14:5E:89:5C:34:C5 1.3.6.1.4.1.311.21.1: ... Signature Algorithm: sha256WithRSAEncryption 91:1b:79:d1:86:ab:91:a3:5e:71:30:10:26:c2:8c:13:2e:a5: c7:f2:2a:d9:00:af:01:3f:48:94:cb:f2:0c:a7:21:ea:a3:dd: aa:e5:bb:27:5f:eb:e1:76:20:f7:c3:d6:8e:ba:a2:8d:2b:67: ed:fc:1e:5b:bc:e5:ab:20:c1:24:9f:a7:ab:1b:61:35:5c:2a: 94:96:89:0d:69:77:74:94:1b:66:1e:85:39:b5:08:3f:48:4a: 98:5a:6f:fd:1b:86:42:b9:cc:4e:a7:95:56:19:a8:ad:cd:c9: 57:ba:0c:55:0c:6e:8e:87:10:3f:4c:eb:b3:e8:0e:f6:64:c4: 76:e8:dc:2d:16:aa:18:ec:c2:51:4f:df:71:3a:61:4f:b9:e8: a4:63:f8:fc:e7:5f:f1:79:fa:0e:7c:de:fe:7b:3b:62:f2:43: 2d:aa:6c:b1:72:40:37:29:c3:59:fd:6e:11:8b:82:6a:0d:6f: 46:79:51:d2:b0:41:84:68:42:c2:e1:7a:e9:db:63:c6:a7:0f: 28:92:ca:e1:9e:d9:1e:4a:08:a5:89:da:2d:0c:6e:6d:c5:a5: c6:2c:54:7e:41:1d:fa:77:2b:62:08:47:b4:15:f6:7b:67:b5: 09:fb:ce:6f:9e:07:95:f5:3a:f6:6b:a2:64:52:20:de:0a:9c: 47:29:1e:a5 -----BEGIN CERTIFICATE----- MIIDBTCCAe2gAwIBAgIQRBEWh94JbqxCULXZEzX5FjANBgkqhkiG9w0BAQsFADAV MRMwEQYDVQQDEwpOSk1Sb290LUNBMB4XDTE1MDYyMjE0NTQ1M1oXDTI1MDYyMjE1 MDQ1M1owFTETMBEGA1UEAxMKTkpNUm9vdC1DQTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMo4rBS6fLIc8hRwCBCwC75FUdlQbnK6EJd/SRu5qWHKVHtV 1kF9giD/pQKa+mHtr7tH1JXo0VHTBR1DSjo+Y69Yfzu8PtMZm7ox1njwCTOXrL0n SRUj8/oEF9Tm0/0g74f5tDgULEWe7jkDgH3iFLwrs+QM8NW4BmYncQ16Ql6Gj/vY c5FSyP66VsUHNxj0YUcfG7BGdD1Wlp2QjYMMZATeROjH4cBMSsd2/+0IbkwQHEj1 D+POENNUFYSh3V/aYYiKbYIuxwh6NWKRkjdJtr6sUGH140Z5e/+bZMrLdboBwt7E GoDRSrtvsFql85amFy5jCovrHXK4hKctCOfb050CAwEAAaNRME8wCwYDVR0PBAQD AgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFLkX0WkjNBe1Umjp//hXFF6J XDTFMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEBCwUAA4IBAQCRG3nRhquR o15xMBAmwowTLqXH8irZAK8BP0iUy/IMpyHqo92q5bsnX+vhdiD3w9aOuqKNK2ft /B5bvOWrIMEkn6erG2E1XCqUlokNaXd0lBtmHoU5tQg/SEqYWm/9G4ZCucxOp5VW GaitzclXugxVDG6OhxA/TOuz6A72ZMR26NwtFqoY7MJRT99xOmFPueikY/j851/x efoOfN7+ezti8kMtqmyxckA3KcNZ/W4Ri4JqDW9GeVHSsEGEaELC4Xrp22PGpw8o ksrhntkeSgilidotDG5txaXGLFR+QR36dytiCEe0FfZ7Z7UJ+85vngeV9Tr2a6Jk UiDeCpxHKR6l -----END CERTIFICATE----- OpenSSL> Thank Lily -----Original Message----- From: Zhang, Lily (USD) Sent: Monday, September 18, 2017 3:21 PM To: 'openssl-users at openssl.org' Subject: RE: [openssl-users] Openssl failed to decrypt certificate without \r\n Hi, Viktor Thanks for your reply. Why it can decrypt attached root.cer, it also has long lines in root.cer? Thanks Lily -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Viktor Dukhovni Sent: Monday, September 18, 2017 2:00 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] Openssl failed to decrypt certificate without \r\n > On Sep 17, 2017, at 10:23 PM, Zhang, Lily (USD) wrote: > > Would you help me to take a look this certificate issue? > In order to send out the file, I added ".txt" in the file name. Please remove it before test it. > > Leaf_no_rn.cer doesn't have \r\n in the BASE64 string, it can't be parsed by openssl. > Leaf_with_rn.cer is the same as Leaf_no_rn.cer, but it has \r\n in BASE64 string. > Both the attached two certificates can be parsed by Windows. This is expected, the OpenSSL PEM file reader does not support input lines with IIRC more than 64 bytes. PEM files are not supposed to have longer lines. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From anton at advancedtelematic.com Mon Sep 18 08:51:02 2017 From: anton at advancedtelematic.com (Anton Gerasimov) Date: Mon, 18 Sep 2017 10:51:02 +0200 Subject: [openssl-users] Error in X509_check_private_key when using pkcs11 engine (OpenSSL 1.0.2j) In-Reply-To: <20170915221850.GA1978@openssl.org> References: <5d44b92e-e430-3b07-d367-ab3af3695e95@advancedtelematic.com> <20170915221850.GA1978@openssl.org> Message-ID: <934f10d2-00db-fbf3-61bf-18fe538d4064@advancedtelematic.com> On 09/16/2017 12:18 AM, Dr. Stephen Henson wrote: > On Fri, Sep 15, 2017, Anton Gerasimov wrote: > >> So it turns out load_privkey() function of engine_pkcs11.so sets pub_key >> in the returned 'struct ec_key_st' to NULL. Is it a failure inside >> engine_pkcs11.so? >> > Well sort of. OpenSSL requires that public key components are set for private > keys (except for a legacy RSA case). OK, thank you. It turns out I've just used the wrong command to import a key into SoftHSM, namely 'pkcs11-tool -w' instead of 'softhsm2-tool --import', so libp11 could only find the private key. Thanks, Anton From bkaduk at akamai.com Mon Sep 18 12:23:43 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Mon, 18 Sep 2017 07:23:43 -0500 Subject: [openssl-users] Openssl failed to decrypt certificate without \r\n In-Reply-To: <79924ABB-0BC7-4BAA-903D-447B148C99D9@dukhovni.org> References: <79924ABB-0BC7-4BAA-903D-447B148C99D9@dukhovni.org> Message-ID: <6bb4b876-6f20-2d54-b52f-2fd3c9d02377@akamai.com> On 09/18/2017 12:59 AM, Viktor Dukhovni wrote: >> On Sep 17, 2017, at 10:23 PM, Zhang, Lily (USD) wrote: >> >> Would you help me to take a look this certificate issue? >> In order to send out the file, I added ".txt" in the file name. Please remove it before test it. >> >> Leaf_no_rn.cer doesn't have \r\n in the BASE64 string, it can't be parsed by openssl. >> Leaf_with_rn.cer is the same as Leaf_no_rn.cer, but it has \r\n in BASE64 string. >> Both the attached two certificates can be parsed by Windows. > This is expected, the OpenSSL PEM file reader does not support > input lines with IIRC more than 64 bytes. PEM files are not > supposed to have longer lines. > The current code in master should not have a particular limit on line lengths for *certificates* -- in test/recipes/04-test_pem_data we have files with 1025 characters on a line, and only use a 256-byte buffer when reading.? The PEM format does specify a 64-(base64-)characters-per-line limit when the additional PEM encryption/etc. features are used, but certificates do not use that feature and do not have a line length restriction.? Perhaps Lily should specify what version of OpenSSL is in use. -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lily.Zhang at dell.com Mon Sep 18 13:37:52 2017 From: Lily.Zhang at dell.com (Zhang, Lily (USD)) Date: Mon, 18 Sep 2017 13:37:52 +0000 Subject: [openssl-users] Openssl failed to decrypt certificate without \r\n In-Reply-To: <6bb4b876-6f20-2d54-b52f-2fd3c9d02377@akamai.com> References: <79924ABB-0BC7-4BAA-903D-447B148C99D9@dukhovni.org> <6bb4b876-6f20-2d54-b52f-2fd3c9d02377@akamai.com> Message-ID: I used OpenSSL 1.0.2h OpenSSL> version OpenSSL 1.0.2h 3 May 2016 Thanks Lily From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Benjamin Kaduk via openssl-users Sent: Monday, September 18, 2017 8:24 PM To: openssl-users at openssl.org; Viktor Dukhovni Subject: Re: [openssl-users] Openssl failed to decrypt certificate without \r\n On 09/18/2017 12:59 AM, Viktor Dukhovni wrote: On Sep 17, 2017, at 10:23 PM, Zhang, Lily (USD) wrote: Would you help me to take a look this certificate issue? In order to send out the file, I added ".txt" in the file name. Please remove it before test it. Leaf_no_rn.cer doesn't have \r\n in the BASE64 string, it can't be parsed by openssl. Leaf_with_rn.cer is the same as Leaf_no_rn.cer, but it has \r\n in BASE64 string. Both the attached two certificates can be parsed by Windows. This is expected, the OpenSSL PEM file reader does not support input lines with IIRC more than 64 bytes. PEM files are not supposed to have longer lines. The current code in master should not have a particular limit on line lengths for *certificates* -- in test/recipes/04-test_pem_data we have files with 1025 characters on a line, and only use a 256-byte buffer when reading. The PEM format does specify a 64-(base64-)characters-per-line limit when the additional PEM encryption/etc. features are used, but certificates do not use that feature and do not have a line length restriction. Perhaps Lily should specify what version of OpenSSL is in use. -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From BYan at visa.com Tue Sep 19 17:52:49 2017 From: BYan at visa.com (Yan, Bob) Date: Tue, 19 Sep 2017 17:52:49 +0000 Subject: [openssl-users] Certificate Comparison Message-ID: Hi All, I need to compare a received certificate object with a PEM-formatted certificate stored at local file system. Is there any openssl library functions or an easy way to compare these two certificates? Thank you very much! Bob From scott_n at xypro.com Tue Sep 19 18:30:10 2017 From: scott_n at xypro.com (Scott Neugroschl) Date: Tue, 19 Sep 2017 18:30:10 +0000 Subject: [openssl-users] Certificate Comparison In-Reply-To: References: Message-ID: How about saving the received cert as a PEM file and comparing the two? -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Yan, Bob via openssl-users Sent: Tuesday, September 19, 2017 10:53 AM To: openssl-users at openssl.org Subject: [openssl-users] Certificate Comparison Hi All, I need to compare a received certificate object with a PEM-formatted certificate stored at local file system. Is there any openssl library functions or an easy way to compare these two certificates? Thank you very much! Bob -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From BYan at visa.com Tue Sep 19 20:38:01 2017 From: BYan at visa.com (Yan, Bob) Date: Tue, 19 Sep 2017 20:38:01 +0000 Subject: [openssl-users] Certificate Comparison In-Reply-To: References: Message-ID: Thanks Scott, it can be done. I am also looking for some functions which can compare the fingerprint of certificates -----Original Message----- From: Scott Neugroschl [mailto:scott_n at xypro.com] Sent: Tuesday, September 19, 2017 11:30 AM To: Yan, Bob ; openssl-users at openssl.org Subject: RE: Certificate Comparison How about saving the received cert as a PEM file and comparing the two? -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Yan, Bob via openssl-users Sent: Tuesday, September 19, 2017 10:53 AM To: openssl-users at openssl.org Subject: [openssl-users] Certificate Comparison Hi All, I need to compare a received certificate object with a PEM-formatted certificate stored at local file system. Is there any openssl library functions or an easy way to compare these two certificates? Thank you very much! Bob -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From rsalz at akamai.com Tue Sep 19 22:21:54 2017 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 19 Sep 2017 22:21:54 +0000 Subject: [openssl-users] Certificate Comparison Message-ID: Convert from PEM to DER (via the X509_PEM_read_xxxx funtions) and use X509_cmp. PEM format is not guaranteed ? you could have differnet linebreaks, for example. From iikonne at us.ibm.com Wed Sep 20 02:19:40 2017 From: iikonne at us.ibm.com (Ike Ikonne) Date: Tue, 19 Sep 2017 21:19:40 -0500 Subject: [openssl-users] How can I sstart openssl ocsp in secure mode using TLS/SSL Message-ID: Hi all, I have been trying to test the embed openssl ocsp server in secure mode like: c:\openssl-0.9.8\share>c:\openssl-0.9.8\bin\openssl ocsp -url https://myhost:7575-req_text -resp_text -text -index intermediate\index.txt -CA int ermediate\certs\ca-chain-cert.pem -rkey intermediate\private\ocsp.example.com.key.pem -rsigner intermediate\certs\ocsp.example.com.cert.pem using the https protocol, but when I try to validate a certificate using the built-in ocsp client similar to: c:\openssl-0.9.8\share>c:\openssl-0.9.8\bin\openssl ocsp -CAfile intermediate\certs\ca-chain-cert.pem -url https://myhost:7575-resp_text -issuer intermediate\certs\intermediate.cert.pem -cert intermediate\certs\test.example.com.cert.pem I get the following error message Error connecting BIO Error querying OCSP responsder 12164:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:./ssl/s23_clnt.c:585: Does anyone know how I may overcome this? Thanks, Ike -------------- next part -------------- An HTML attachment was scrubbed... URL: From Raphael.Hiesgen at haw-hamburg.de Wed Sep 20 15:48:21 2017 From: Raphael.Hiesgen at haw-hamburg.de (Hiesgen, Raphael) Date: Wed, 20 Sep 2017 15:48:21 +0000 Subject: [openssl-users] Searching for a memory leak in my OpenSSL usage Message-ID: <5107E0BE-E8CF-4D03-B6E9-FBC00913BAB7@haw-hamburg.de> Hello, I got an application that establishes an TLS connection for communication. While the communication works, I run into a memory leak that originates from CRYPTO_malloc. I tried to search for proper OpenSSL shutdown and related issues, but my tries did not affect the leak. Here is the ASAN output: ``` ==2618==ERROR: LeakSanitizer: detected memory leaks Direct leak of 672 byte(s) in 12 object(s) allocated from: #0 0x7f14a2c9bec0 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc6ec0) #1 0x7f149fa4ce87 in CRYPTO_malloc (/lib/x86_64-linux-gnu/libcrypto.so.1.0.0+0x62e87) Indirect leak of 15024 byte(s) in 228 object(s) allocated from: #0 0x7f14a2c9bec0 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc6ec0) #1 0x7f149fa4ce87 in CRYPTO_malloc (/lib/x86_64-linux-gnu/libcrypto.so.1.0.0+0x62e87) SUMMARY: AddressSanitizer: 15696 byte(s) leaked in 240 allocation(s). ``` My test establishes a connection between two threads handled by the same process. Both keep their separate SSL context. Just to be sure, that this is not a multithreading problem I tried passing locking and id functions to OpenSSL but that did change anything. Here are the steps to reproduce the problem when you have OpenSSL installed via the system packet manager. If you want to use a specific SSL installation, the configure script accepts a '--with-openssl=PATH' argument. ``` git clone https://github.com/actor-framework/actor-framework.git cd actor-framework git checkout develop ./configure --build-type=debug --with-address-sanitizer make ./build/bin/caf-test -s openssl_dynamic_remote_actor ``` The SSL session is created on top of an already established TCP connection using non-blocking socket. For initialization [1], we call create_ssl_context and SSL_new. This seems to be enough (?) and using Wireshark I can observe the handshake and so on. To clean up [2], we simply call SSL_free and SSL_CTX_free. Searching online, there are really many function for cleanup of different SSL parts, but that did not seem to do anything. Here are the functions, I tired (just to be sure, I tried them all in different configurations): ``` FIPS_mode_set(0); EVP_cleanup(); SSL_COMP_free_compression_methods(); COMP_zlib_cleanup(); ERR_remove_state(0); ERR_remove_thread_state(NULL); CONF_modules_free(); CONF_modules_unload(1); ERR_free_strings(); CRYPTO_cleanup_all_ex_data(); ``` The multi threading additions are not in the branch, but I basically followed the libcurl example [3] but with a bit more C++. My host system is an Ubuntu 17.04 with the '4.10.0-35-generic' kernel, GCC ?6.3.0 (20170406)' and 'OpenSSL 1.0.2g 1 Mar 2016'. Thank you for your time! Best Regards Raphael [1] https://github.com/actor-framework/actor-framework/blob/develop/libcaf_openssl/src/session.cpp#L56 [2] https://github.com/actor-framework/actor-framework/blob/develop/libcaf_openssl/src/session.cpp#L67 [3] https://curl.haxx.se/libcurl/c/opensslthreadlock.html From openssl at jordan.maileater.net Wed Sep 20 16:33:53 2017 From: openssl at jordan.maileater.net (Jordan Brown) Date: Wed, 20 Sep 2017 09:33:53 -0700 Subject: [openssl-users] Trusting certificates with the same subject name and overlapping validity periods Message-ID: <8ee5025c-e26a-b03f-9722-4aa0bab6eda1@jordan.maileater.net> Q:? Does OpenSSL's trust-list verification support trusting multiple certificates with the same subject name and overlapping validity periods? In more detail: We have customers who issue replacement certificates with the same subject name and different validity periods.? We'd like to be able to straightforwardly add the new certificates to the trust list and have them work, but seem to find that certificate verification doesn't handle the case.? (Mozilla NSS does seem to handle it.) -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From Walter.H at mathemainzel.info Wed Sep 20 17:28:15 2017 From: Walter.H at mathemainzel.info (Walter H.) Date: Wed, 20 Sep 2017 19:28:15 +0200 Subject: [openssl-users] Trusting certificates with the same subject name and overlapping validity periods In-Reply-To: <8ee5025c-e26a-b03f-9722-4aa0bab6eda1@jordan.maileater.net> References: <8ee5025c-e26a-b03f-9722-4aa0bab6eda1@jordan.maileater.net> Message-ID: <59C2A52F.2080800@mathemainzel.info> On 20.09.2017 18:33, Jordan Brown wrote: > > Q: Does OpenSSL's trust-list verification support trusting multiple > certificates with the same subject name and overlapping validity periods? > do these replacement certificates have the same serial number and the same private key? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3491 bytes Desc: S/MIME Cryptographic Signature URL: From openssl at jordan.maileater.net Wed Sep 20 21:13:14 2017 From: openssl at jordan.maileater.net (Jordan Brown) Date: Wed, 20 Sep 2017 14:13:14 -0700 Subject: [openssl-users] Trusting certificates with the same subject name and overlapping validity periods In-Reply-To: <59C2A52F.2080800@mathemainzel.info> References: <8ee5025c-e26a-b03f-9722-4aa0bab6eda1@jordan.maileater.net> <59C2A52F.2080800@mathemainzel.info> Message-ID: On 9/20/2017 10:28 AM, Walter H. via openssl-users wrote: > On 20.09.2017 18:33, Jordan Brown wrote: >> >> Q:? Does OpenSSL's trust-list verification support trusting multiple >> certificates with the same subject name and overlapping validity periods? >> > do these replacement certificates have the same serial number and the > same private key? I'll check with my colleague who is doing the actual work, but... I assume that they do not have the same serial number, since they are new certificates. I don't know whether they have the same private key.? For discussion purposes, let's say that they might or might not have the same key. Remember that these are customer-controlled certificates; I don't get to tell them how the certificates should be structured. Note that this would be easy if each successive certificate had a different Subject, because then the trust list could contain all of them and there would be no possibility for confusion.? But they don't. -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Sep 20 21:25:18 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 20 Sep 2017 17:25:18 -0400 Subject: [openssl-users] Trusting certificates with the same subject name and overlapping validity periods In-Reply-To: <8ee5025c-e26a-b03f-9722-4aa0bab6eda1@jordan.maileater.net> References: <8ee5025c-e26a-b03f-9722-4aa0bab6eda1@jordan.maileater.net> Message-ID: <3B0606C4-DA55-431B-A74A-F35CD203B9D1@dukhovni.org> > On Sep 20, 2017, at 12:33 PM, Jordan Brown wrote: > > Q: Does OpenSSL's trust-list verification support trusting multiple certificates with the same subject name and overlapping validity periods? > > In more detail: > > We have customers who issue replacement certificates with the same subject name and different validity periods. We'd like to be able to straightforwardly add the new certificates to the trust list and have them work, but seem to find that certificate verification doesn't handle the case. (Mozilla NSS does seem to handle it.) Generally speaking, if the latest certificate has the same key, then it should cover the older ones, which can be dropped from the trust list. If, however, the newer certificates have a different key, then everything should work, provided the certificates issued under the new key carry an "authority key identifier" extension, which matches the corresponding "subject key identifier" in the issuer CA certificate. The above also works with "authorityCertSerialNumber", see https://tools.ietf.org/html/rfc5280#section-4.2.1.1 If, however, the newer certificate has a different key, and the same subject DN, but does not place matching distinct subject key identifiers in the certificates it issues, then OpenSSL will not correctly handle multiple candidate issuers that differ in the public key, but provide no hints in the issued certificates which issuer to use. -- Viktor. From openssl at jordan.maileater.net Wed Sep 20 21:48:20 2017 From: openssl at jordan.maileater.net (Jordan Brown) Date: Wed, 20 Sep 2017 14:48:20 -0700 Subject: [openssl-users] Trusting certificates with the same subject name and overlapping validity periods In-Reply-To: <3B0606C4-DA55-431B-A74A-F35CD203B9D1@dukhovni.org> References: <8ee5025c-e26a-b03f-9722-4aa0bab6eda1@jordan.maileater.net> <3B0606C4-DA55-431B-A74A-F35CD203B9D1@dukhovni.org> Message-ID: <9f779580-f7e9-ed67-56b9-2d334698f65f@jordan.maileater.net> On 9/20/2017 2:25 PM, Viktor Dukhovni wrote: >> On Sep 20, 2017, at 12:33 PM, Jordan Brown wrote: >> >> Q: Does OpenSSL's trust-list verification support trusting multiple certificates with the same subject name and overlapping validity periods? >> >> In more detail: >> >> We have customers who issue replacement certificates with the same subject name and different validity periods. We'd like to be able to straightforwardly add the new certificates to the trust list and have them work, but seem to find that certificate verification doesn't handle the case. (Mozilla NSS does seem to handle it.) > Generally speaking, if the latest certificate has the same key, then > it should cover the older ones, which can be dropped from the trust list. > > If, however, the newer certificates have a different key, then everything > should work, provided the certificates issued under the new key carry > an "authority key identifier" extension, which matches the corresponding > "subject key identifier" in the issuer CA certificate. > > The above also works with "authorityCertSerialNumber", see > > https://tools.ietf.org/html/rfc5280#section-4.2.1.1 > > If, however, the newer certificate has a different key, and the same > subject DN, but does not place matching distinct subject key identifiers > in the certificates it issues, then OpenSSL will not correctly handle > multiple candidate issuers that differ in the public key, but provide > no hints in the issued certificates which issuer to use. I'm not familiar with those extensions and will need to do more research. However, it sounds like you're assuming a CA-issued certificate where we have the CA certificate in the trust list. That's not the case.? These are (in the most relevant cases) self-signed certificates or CA-issued certificates where we have only the leaf certificate in the trust list. I suspect that they are indeed falling into that last case, where the only way to know which certificate in the trust list is "right" is to try the crypto verification on each trusted certificate until one succeeds.? (Or just compare the certificate presented with the ones in the trust list.) -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Wed Sep 20 21:58:41 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 20 Sep 2017 17:58:41 -0400 Subject: [openssl-users] Trusting certificates with the same subject name and overlapping validity periods In-Reply-To: <9f779580-f7e9-ed67-56b9-2d334698f65f@jordan.maileater.net> References: <8ee5025c-e26a-b03f-9722-4aa0bab6eda1@jordan.maileater.net> <3B0606C4-DA55-431B-A74A-F35CD203B9D1@dukhovni.org> <9f779580-f7e9-ed67-56b9-2d334698f65f@jordan.maileater.net> Message-ID: On Wed, Sep 20, 2017 at 5:48 PM, Jordan Brown wrote: > ... > The above also works with "authorityCertSerialNumber", see > > https://tools.ietf.org/html/rfc5280#section-4.2.1.1 > > If, however, the newer certificate has a different key, and the same > subject DN, but does not place matching distinct subject key identifiers > in the certificates it issues, then OpenSSL will not correctly handle > multiple candidate issuers that differ in the public key, but provide > no hints in the issued certificates which issuer to use. > > I'm not familiar with those extensions and will need to do more research. I believe the controlling IETF document is "Internet X.509 Public Key Infrastructure: Certification Path Building", https://tools.ietf.org/html/rfc4158. Jeff From mcepl at cepl.eu Wed Sep 20 22:26:22 2017 From: mcepl at cepl.eu (Matej Cepl) Date: Thu, 21 Sep 2017 00:26:22 +0200 Subject: [openssl-users] [ANN] M2Crypto 0.26.2 Message-ID: <79e8a860-a2d4-0a52-7d40-8569953b1b0c@cepl.eu> Hi, everybody, after a way too long time I have another version of M2Crypto. Despite the deceptively minor version number (0.26.2; it is mistake, it has all right to be called 0.27.0, but the release is already on PyPI, sorry) this was a lot of work. The biggest achievement here is compatibility with OpenSSL 1.1.0 (while still maintaining compatibility all the way to RHEL-6, that's Python 2.6 and OpenSSL 1.0.1e, but I think we should be compatible even with older versions of OpenSSL). A lot of work on that was done by Jim Carroll (does anybody have a better email address for him than jim at carroll.com which bounces for me?), and I wouldn't be able to do anything without help of my colleague Tom?? Mr?z from Red Hat. Thank you! I see a Debian bug https://bugs.debian.org/827061 and I hope that this release may be a way how to create a proper fix for it. This is still python 2 only release. Of course any help on python3 porting branch (https://gitlab.com/m2crypto/m2crypto/merge_requests/65) is very welcome! Happy security hacking! Mat?j -- http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 The politician attempts to remedy the evil by increasing the very thing that caused the evil in the first place: legal plunder. -- Frederick Bastiat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From hubert at levangong.org Thu Sep 21 08:30:54 2017 From: hubert at levangong.org (Le Van Gong, Hubert) Date: Thu, 21 Sep 2017 16:30:54 +0800 Subject: [openssl-users] s_server and explicit dhparam Message-ID: <1802ef53-4984-ed88-48c2-f1d20c58cf96@levangong.org> Hi there, I'm trying to run opensslin server modeand leverage non-default DH params with the following command: sudo openssl s_server -cert server_cert.pem -dhparam dhparam_2.pem -tls1_3 -accept 443 Where the dhparam_2.pem file contains the 2 DH params I want to use. However, I keep getting the following error message: Error with command: "-dhparam dhparam_2.pem" I'm using OpenSSL 1.1.1-dev and see the same behaviour on macOS or linux. Any idea as to what it is I am missing? Cheers, Hubert From bkaduk at akamai.com Thu Sep 21 12:12:53 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Thu, 21 Sep 2017 07:12:53 -0500 Subject: [openssl-users] s_server and explicit dhparam In-Reply-To: <1802ef53-4984-ed88-48c2-f1d20c58cf96@levangong.org> References: <1802ef53-4984-ed88-48c2-f1d20c58cf96@levangong.org> Message-ID: <3067f024-3b3d-27f3-317c-10f1a8f10090@akamai.com> On 09/21/2017 03:30 AM, Le Van Gong, Hubert wrote: > Hi there, > > I'm trying to run opensslin server modeand leverage non-default DH > params with the following command: > sudo openssl s_server -cert server_cert.pem -dhparam dhparam_2.pem > -tls1_3 -accept 443 > > Where the dhparam_2.pem file contains the 2 DH params I want to use. > However, I keep getting the following error message: Error with > command: "-dhparam dhparam_2.pem" > > I'm using OpenSSL 1.1.1-dev and see the same behaviour on macOS or linux. > > Any idea as to what it is I am missing? It seems that what is missing is actual support in the code, diff --git a/apps/s_server.c b/apps/s_server.c index c45256a..d54909a 100644 --- a/apps/s_server.c +++ b/apps/s_server.c @@ -795,6 +795,7 @@ const OPTIONS s_server_options[] = { ???? {"pass", OPT_PASS, 's', "Private key file pass phrase source"}, ???? {"dcert", OPT_DCERT, '<', ????? "Second certificate file to use (usually for DSA)"}, +??? {"dhparam", OPT_DHPARAM, '<', "DH parameters file to use"}, ???? {"dcertform", OPT_DCERTFORM, 'F', ????? "Second certificate format (PEM or DER) PEM default"}, ???? {"dkey", OPT_DKEY, '<', -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From elliemdaw at gmail.com Thu Sep 21 14:28:07 2017 From: elliemdaw at gmail.com (Ellie Daw) Date: Thu, 21 Sep 2017 10:28:07 -0400 Subject: [openssl-users] Un-signed CSRs Message-ID: <6FAC8ADE-F0F0-4D89-BB1E-2428AB7BB9DB@gmail.com> Has anyone had success parsing un-signed CSRs? Based on some research and the errors I?m seeing while trying to get my code working, it seems like the d2i_X509_REQ_bio (and more directly the asn1_parse) API choke on un-signed CSRs? this is the error dump: OSSL error: 140021221574400:error:0D0C40D8:asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287: 140021221574400:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=algorithm, Type=X509_ALGOR 140021221574400:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=algor, Type=X509_PUBKEY 140021221574400:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=pubkey, Type=X509_REQ_INFO 140021221574400:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=req_info, Type=X509_REQ asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287 asn1 encoding routines: ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=algorithm, Type=X509_ALGOR asn1 encoding routines: ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=algor, Type=X509_PUBKEY asn1 encoding routines: ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=pubkey, Type=X509_REQ_INFO asn1 encoding routines: ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=req_info, Type=X509_REQ When I paste the same data into a DER encoded file and use ?openssl req?? to verify the CSR, I?m getting almost the same error: asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287: 140736720540680:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:699:Field=algorithm, Type=X509_ALGOR 140736720540680:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:699:Field=algor, Type=X509_PUBKEY 140736720540680:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:699:Field=pubkey, Type=X509_REQ_INFO 140736720540680:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:699:Field=req_info, Type=X509_REQ 140736720540680:error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1 lib:pem_oth.c:83: asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287 asn1 encoding routines: ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=algorithm, Type=X509_ALGOR asn1 encoding routines: ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=algor, Type=X509_PUBKEY asn1 encoding routines: ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=pubkey, Type=X509_REQ_INFO asn1 encoding routines: ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=req_info, Type=X509_REQ PEM routines:PEM_ASN1_read_bio:ASN1 lib:pem_oth.c:83 Thanks! Ellie OSSL error: 140021221574400:error:0D0C40D8:asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287: 140021221574400:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=algorithm, Type=X509_ALGOR 140021221574400:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=algor, Type=X509_PUBKEY 140021221574400:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=pubkey, Type=X509_REQ_INFO 140021221574400:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=req_info, Type=X509_REQ OSSL error: 140021221574400:error:0D0C40D8:asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287: 140021221574400:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=algorithm, Type=X509_ALGOR 140021221574400:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=algor, Type=X509_PUBKEY 140021221574400:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=pubkey, Type=X509_REQ_INFO 140021221574400:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=req_info, Type=X509_REQ OSSL error: 140021221574400:error:0D0C40D8:asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287: 140021221574400:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=algorithm, Type=X509_ALGOR 140021221574400:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=algor, Type=X509_PUBKEY 140021221574400:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=pubkey, Type=X509_REQ_INFO 140021221574400:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=req_info, Type=X509_REQ OSSL error: 140021221574400:error:0D0C40D8:asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287: 140021221574400:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=algorithm, Type=X509_ALGOR 140021221574400:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=algor, Type=X509_PUBKEY 140021221574400:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=pubkey, Type=X509_REQ_INFO 140021221574400:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=req_info, Type=X509_REQOSSL error: 140021221574400:error:0D0C40D8:asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287:140021221574400:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=algorithm, Type=X509_ALGOR 140021221574400:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=algor, Type=X509_PUBKEY 140021221574400:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=pubkey, Type=X509_REQ_INFO 140021221574400:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=req_info, Type=X509_REQ OSSL error: 140021196396288:error:0D0C40D8:asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287: 140021196396288:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=algorithm, Type=X509_ALGOR 140021196396288:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=algor, Type=X509_PUBKEY 140021196396288:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=pubkey, Type=X509_REQ_INFO 140021196396288:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:700:Field=req_info, Type=X509_REQ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Sep 21 15:26:22 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 21 Sep 2017 15:26:22 +0000 Subject: [openssl-users] Un-signed CSRs In-Reply-To: <6FAC8ADE-F0F0-4D89-BB1E-2428AB7BB9DB@gmail.com> References: <6FAC8ADE-F0F0-4D89-BB1E-2428AB7BB9DB@gmail.com> Message-ID: <7E67B723-4606-4982-B41B-14CDE4DEF4E1@akamai.com> ? Has anyone had success parsing un-signed CSRs? By its definition a CSR is signed. So this will not work. -------------- next part -------------- An HTML attachment was scrubbed... URL: From elliemdaw at gmail.com Thu Sep 21 15:41:21 2017 From: elliemdaw at gmail.com (Ellie Daw) Date: Thu, 21 Sep 2017 11:41:21 -0400 Subject: [openssl-users] Un-signed CSRs In-Reply-To: <7E67B723-4606-4982-B41B-14CDE4DEF4E1@akamai.com> References: <6FAC8ADE-F0F0-4D89-BB1E-2428AB7BB9DB@gmail.com> <7E67B723-4606-4982-B41B-14CDE4DEF4E1@akamai.com> Message-ID: <379BB313-5A49-417B-908A-D279C77AC4B5@gmail.com> Right, I?m just trying to fill it out in steps and wanted to check to be sure I wasn?t missing a trick with the API before I implement any ?workaround?. Thanks for your response! > On Sep 21, 2017, at 11:26 AM, Salz, Rich via openssl-users wrote: > > > ? Has anyone had success parsing un-signed CSRs? > > By its definition a CSR is signed. So this will not work. > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From angus at magsys.co.uk Thu Sep 21 17:56:00 2017 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Thu, 21 Sep 2017 18:56 +0100 (BST) Subject: [openssl-users] Creating requests and certificates with Subject Alternative Names Message-ID: I'm creating X509 certificate requests and certificates in code, trying to add X509v3 Subject Alternative Name, with 1.1.0f. But if I add a list of four domains, ie: www1.mydomain www2.mydomain www3.mydomain www4.mydomain The certificate seems to ignore some and repeat others: X509v3 Subject Alternative Name: DNS:www3.mydomain, DNS:www4.mydomain, DNS:www3.mydomain, DNS:www4.mydomain Finding documentation for SANs in OpenSSL is very hard, there don't seem to be high level APIs to create extension content stacks. The best I found is set_altname in v3nametest.c which builds a stack of GENERAL_NAMES and adds it using X509_add1_ext_i2d. I must be something correct since it half works, but no idea why the data is corrupted. To complicate matters, I'm not writing in C, but using Delphi pascal, so all the OpenSSL APIs and macros have been converted to Delphi, which does potentially cause errors in translation. This is an open source Delphi interface to OpenSSL. Angus From hubert at levangong.org Fri Sep 22 03:57:20 2017 From: hubert at levangong.org (Le Van Gong, Hubert) Date: Fri, 22 Sep 2017 11:57:20 +0800 Subject: [openssl-users] s_server and explicit dhparam In-Reply-To: <3067f024-3b3d-27f3-317c-10f1a8f10090@akamai.com> References: <1802ef53-4984-ed88-48c2-f1d20c58cf96@levangong.org> <3067f024-3b3d-27f3-317c-10f1a8f10090@akamai.com> Message-ID: <900a0dd7-e7e3-16cb-8b35-681558d32136@levangong.org> Hi Ben, Ah, good catch. Maybe the doc should be updated to mention that fact. Does anyone know if this is on the roadmap? Thanks, Hubert On 9/21/17 20:12, Benjamin Kaduk wrote: > On 09/21/2017 03:30 AM, Le Van Gong, Hubert wrote: >> Hi there, >> >> I'm trying to run opensslin server modeand leverage non-default DH >> params with the following command: >> sudo openssl s_server -cert server_cert.pem -dhparam dhparam_2.pem >> -tls1_3 -accept 443 >> >> Where the dhparam_2.pem file contains the 2 DH params I want to use. >> However, I keep getting the following error message: Error with >> command: "-dhparam dhparam_2.pem" >> >> I'm using OpenSSL 1.1.1-dev and see the same behaviour on macOS or >> linux. >> >> Any idea as to what it is I am missing? > > It seems that what is missing is actual support in the code, > > diff --git a/apps/s_server.c b/apps/s_server.c > index c45256a..d54909a 100644 > --- a/apps/s_server.c > +++ b/apps/s_server.c > @@ -795,6 +795,7 @@ const OPTIONS s_server_options[] = { > ???? {"pass", OPT_PASS, 's', "Private key file pass phrase source"}, > ???? {"dcert", OPT_DCERT, '<', > ????? "Second certificate file to use (usually for DSA)"}, > +??? {"dhparam", OPT_DHPARAM, '<', "DH parameters file to use"}, > ???? {"dcertform", OPT_DCERTFORM, 'F', > ????? "Second certificate format (PEM or DER) PEM default"}, > ???? {"dkey", OPT_DKEY, '<', > > > -Ben From bkaduk at akamai.com Fri Sep 22 11:44:57 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Fri, 22 Sep 2017 06:44:57 -0500 Subject: [openssl-users] s_server and explicit dhparam In-Reply-To: <900a0dd7-e7e3-16cb-8b35-681558d32136@levangong.org> References: <1802ef53-4984-ed88-48c2-f1d20c58cf96@levangong.org> <3067f024-3b3d-27f3-317c-10f1a8f10090@akamai.com> <900a0dd7-e7e3-16cb-8b35-681558d32136@levangong.org> Message-ID: <71625280-4bc2-4626-f34c-71b86ee30b1c@akamai.com> On 09/21/2017 10:57 PM, Le Van Gong, Hubert wrote: > Hi Ben, > > Ah, good catch. Maybe the doc should be updated to mention that fact. > Does anyone know if this is on the roadmap? The documentation could not really get updated more easily than the code, and I committed the needed fix yesterday, so we're in as good a shape as we can reasonably expect to be. -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From iikonne at us.ibm.com Fri Sep 22 14:03:58 2017 From: iikonne at us.ibm.com (Ike Ikonne) Date: Fri, 22 Sep 2017 09:03:58 -0500 Subject: [openssl-users] How can I sstart openssl ocsp in secure mode using TLS/SSL Message-ID: Hi all, I have been trying to test the embed openssl ocsp server in secure mode like: c:\openssl-0.9.8\share>c:\openssl-0.9.8\bin\openssl ocsp -url https://myhost:7575-req_text -resp_text -text -index intermediate\index.txt -CA int ermediate\certs\ca-chain-cert.pem -rkey intermediate\private\ocsp.example.com.key.pem -rsigner intermediate\certs\ocsp.example.com.cert.pem using the https protocol, but when I try to validate a certificate using the built-in ocsp client similar to: c:\openssl-0.9.8\share>c:\openssl-0.9.8\bin\openssl ocsp -CAfile intermediate\certs\ca-chain-cert.pem -url https://myhost:7575-resp_text -issuer intermediate\certs\intermediate.cert.pem -cert intermediate\certs\test.example.com.cert.pem I get the following error message Error connecting BIO Error querying OCSP responsder 12164:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:./ssl/s23_clnt.c:585: Does anyone know how I may overcome this? Thanks, Ike -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Sep 22 14:08:30 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 22 Sep 2017 14:08:30 +0000 Subject: [openssl-users] How can I sstart openssl ocsp in secure mode using TLS/SSL In-Reply-To: References: Message-ID: <893816E7-B93B-4371-AAF1-EFE1333E3543@akamai.com> Openssl 0.9.8 is old and obsolete and has security issues; you should upgrade. But even if you upgrade, the ocsp command will not listen on HTTPS; that is not supported. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcepl at cepl.eu Fri Sep 22 15:07:54 2017 From: mcepl at cepl.eu (=?UTF-8?Q?Mat=c4=9bj_Cepl?=) Date: Fri, 22 Sep 2017 17:07:54 +0200 Subject: [openssl-users] [ANN] M2Crypto 0.26.3 In-Reply-To: <79e8a860-a2d4-0a52-7d40-8569953b1b0c@cepl.eu> References: <79e8a860-a2d4-0a52-7d40-8569953b1b0c@cepl.eu> Message-ID: On 21/09/17 00:26, Matej Cepl wrote: > after a way too long time I have another version of M2Crypto. Despite > the deceptively minor version number (0.26.2; it is mistake, it has all > right to be called 0.27.0, but the release is already on PyPI, sorry) > this was a lot of work. Oh well, so I have forgot one syntax error in a C file. I have no idea why it wasn't caught by CI, but there is quick 0.26.3 release available now on PyPI. Oh well, Mat?j -- https://matej.ceplovi.cz/blog/, Jabber: mcepl at ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Quod fuimus, estis; quod sumus, vos eritis. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From richmoore44 at gmail.com Fri Sep 22 16:32:16 2017 From: richmoore44 at gmail.com (Richard Moore) Date: Fri, 22 Sep 2017 17:32:16 +0100 Subject: [openssl-users] How can I sstart openssl ocsp in secure mode using TLS/SSL In-Reply-To: <893816E7-B93B-4371-AAF1-EFE1333E3543@akamai.com> References: <893816E7-B93B-4371-AAF1-EFE1333E3543@akamai.com> Message-ID: On 22 September 2017 at 15:08, Salz, Rich via openssl-users < openssl-users at openssl.org> wrote: > Openssl 0.9.8 is old and obsolete and has security issues; you should > upgrade. > > > > But even if you upgrade, the ocsp command will not listen on HTTPS; that > is not supported. > > > ?It's also worth pointing out that CAs are banned from running OCSP servers over HTTPS anyway and it isn't needed since the responses are already signed - http is fine. Cheers Rich. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From carloscaraccia at gmail.com Fri Sep 22 17:14:00 2017 From: carloscaraccia at gmail.com (Carlos Caraccia) Date: Fri, 22 Sep 2017 14:14:00 -0300 Subject: [openssl-users] SMIME -sign subcommand In-Reply-To: References: <1ADCF931-EDB4-4B98-AB3F-E36A20445E4E@gmail.com> Message-ID: <781C0A28-B1EA-49EF-810F-4A1C4CA1516E@gmail.com> Thanks a lot Jacob, I?ll try it now. I?m a hobby developer and must do this for my real work. Carlos > On Sep 7, 2017, at 09:43, Jakob Bohm wrote: > > On 07/09/2017 14:02, Carlos Caraccia wrote: >> Hello, is there a way to debug or watch line by line which functions are executed when I run a this command: >> >> openssl smime -sign -signer certificadoWSASS.cer -inkey MiClave -out ticket.xml.cms -in Ticket.xml -outform PEM -nodetach >> >> I know there I can see the smile.c here >> >> /apps >> >> I want to know how to compile if it is possible to compile it and to run it in Xcode and watch step by step the functions involved. >> > Get the source code from https://www.openssl.org/source/ > > Build it for your Mac using commands such as: > (Note these steps are based on a build script for OpenSSL 1.0.2k) > > tar xzf openssl-1.something.tar.gz > cd openssl-1.something > > CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang > export CC > MACOSX_SDK=/Developer/SDKs/MacOSX10.12.sdk > [ -d ${MACOSX_SDK} ] || MACOSX_SDK=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk > > ./Configure debug-darwin64-x86_64-cc --openssldir="$(pwd)-x86_64" > perl -i -pe 's|static volatile sig_atomic_t intr_signal|static volatile int intr_signal|' crypto/ui/ui_openssl.c > perl -i -pe "s|^CC= gcc|CC= ${CC} -arch x86_64 -mmacosx-version-min=10.6|g" Makefile > perl -i -pe "s|^CFLAG= |CFLAG= -arch x86_64 -mmacosx-version-min=10.6 -isysroot ${MACOSX_SDK} |g" Makefile > make MAKEDEPPROG=${CC} depend > make > make test > make install > > Now debug the program in openssl-1.something-x86_64/bin/openssl > > (Sorry, I don't know how to tell XCode to debug a program already > compiled with the XCode command line clang) > > 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 From dheinz at softwarekey.com Mon Sep 25 15:59:23 2017 From: dheinz at softwarekey.com (Dan Heinz) Date: Mon, 25 Sep 2017 15:59:23 +0000 Subject: [openssl-users] Manually shutdown the library Message-ID: The original issue was discussed here: https://www.mail-archive.com/openssl-users at openssl.org/msg80781.html To summarize: We have a DLL that statically links OpenSSL. Our DLL gets loaded and unloaded multiple times by a process (not our process), and we need to release OpenSSL each time. This was not possible with OpenSSL 1.1 as of October 2016 as the process's atexit is where it gets released which will not be called after a FreeLibrary() call on our DLL. Has this been revisited? If there is still not a way to manually release OpenSSL, are there any plans to add this ability? >From the previous post, something like this would address the issue: "I'm wondering whether an option to override the default behaviour might be possible, e.g. an explicit call to OPENSSL_init_crypto() with something like an OPENSSL_INIT_NO_ATEXIT_CLEANUP option. The application would then have to call OPENSSL_cleanup() explicitly." -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Sep 26 00:52:17 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 26 Sep 2017 02:52:17 +0200 Subject: [openssl-users] How can I sstart openssl ocsp in secure mode using TLS/SSL In-Reply-To: References: <893816E7-B93B-4371-AAF1-EFE1333E3543@akamai.com> Message-ID: <9808735b-8445-79e1-3db5-1433d937f8f8@wisemo.com> On 22/09/2017 18:32, Richard Moore wrote: > > > On 22 September 2017 at 15:08, Salz, Rich via openssl-users > > wrote: > > Openssl 0.9.8 is old and obsolete and has security issues; you > should upgrade. > > But even if you upgrade, the ocsp command will not listen on > HTTPS; that is not supported. > > > > ?It's also worth pointing out that CAs are banned from running OCSP > servers over HTTPS anyway and it isn't needed since the responses are > already signed - http is fine. > That particular ban has an interesting backstory of bureaucratic decisions that seem misguided in retrospect. The problem is that the information in OCSP requests is potentially very valuable to an attacker who lacks the ability to fully wiretap the connections between the OCSP client and the ultimate source of the checked certificate. 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 aerowolf at gmail.com Tue Sep 26 01:36:17 2017 From: aerowolf at gmail.com (Kyle Hamilton) Date: Mon, 25 Sep 2017 18:36:17 -0700 Subject: [openssl-users] How can I sstart openssl ocsp in secure mode using TLS/SSL In-Reply-To: References: <893816E7-B93B-4371-AAF1-EFE1333E3543@akamai.com> Message-ID: On Fri, Sep 22, 2017 at 9:32 AM, Richard Moore wrote: > > It's also worth pointing out that CAs are banned from running OCSP servers over HTTPS anyway and it isn't needed since the responses are already signed - http is fine. That argument fails when you consider that some people want the details of who they're talking to or asking about to be confidential, not merely authentic. I'm a believer in the idea that SNI and the Certificate messages should happen under an ephemeral DH or ephemeral ECDH cover. Others fear-monger to say "maybe they shouldn't". (Also, for completeness, the argument that "CAs are banned from running OCSP servers over HTTPS anyway" is a straw man at best -- not every CA is created or intends to be a member of or subject to the mandates of the CA Security Council, formerly known as the CA/Browser Forum. And every attempt to encode policy into technical standards, attempting to prohibit certain actions for whatever misguided administrative reasons, is subject to being bypassed by people who understand the various parts and how to glue them all together.) To be fair, the OCSP responder certificate may or may not be revoked... but honestly, if you're asking the OCSP responder for the status of its own certificate you're opening yourself up to a subordination/subversion attack anyway. OCSP responders should have very short-lived certificates, to minimize the temporal subordination attack surface. -Kyle H From mid_li at 163.com Tue Sep 26 07:15:10 2017 From: mid_li at 163.com (=?GBK?B?wO7D9w==?=) Date: Tue, 26 Sep 2017 15:15:10 +0800 (CST) Subject: [openssl-users] How to increase the priority of some cipher ? In-Reply-To: <708dccf5.c6c1.15b7b79df7f.Coremail.mid_li@163.com> References: <708dccf5.c6c1.15b7b79df7f.Coremail.mid_li@163.com> Message-ID: <60c65bc6.8bec.15ebd0a1d15.Coremail.mid_li@163.com> Hello, Currently, openssl prefer (EC)DHE handshakes over plain RSA, but (EC)DHE cost much more resouces than RSA. In order to get higher performance , I want to prioritize RSA related ciphers, does anyone knows how to do it. I have tried cipherlist "RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL" , it looks fine in openssl command line ./openssl ciphers -v 'RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL' AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD but, after SSL_CTX_set_cipher_list(ctx, "RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL") in my application, it didn't work, the first choice is still ECDHE-RSA-AES256-GCM-SHA384 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mid_li at 163.com Tue Sep 26 08:44:28 2017 From: mid_li at 163.com (=?GBK?B?wO7D9w==?=) Date: Tue, 26 Sep 2017 16:44:28 +0800 (CST) Subject: [openssl-users] How to increase the priority of some cipher ? In-Reply-To: <60c65bc6.8bec.15ebd0a1d15.Coremail.mid_li@163.com> References: <708dccf5.c6c1.15b7b79df7f.Coremail.mid_li@163.com> <60c65bc6.8bec.15ebd0a1d15.Coremail.mid_li@163.com> Message-ID: <17db9aa9.af84.15ebd5be18e.Coremail.mid_li@163.com> just find it, server respect client's cipher preference by default, it selects the suite preferred by client among the cipherlist that both the client and server support. so it's not enough to just increase RSA cipher priority on server side , SSL_OP_CIPHER_SERVER_PREFERENCE will make the server select the suite that itself most prefer among the cipherlist that both the client and server support. ? 2017-09-26 15:15:10?"??" ??? Hello, Currently, openssl prefer (EC)DHE handshakes over plain RSA, but (EC)DHE cost much more resouces than RSA. In order to get higher performance , I want to prioritize RSA related ciphers, does anyone knows how to do it. I have tried cipherlist "RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL" , it looks fine in openssl command line ./openssl ciphers -v 'RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL' AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD but, after SSL_CTX_set_cipher_list(ctx, "RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL") in my application, it didn't work, the first choice is still ECDHE-RSA-AES256-GCM-SHA384 ??????????????????????13?/??????75?3?>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcepl at cepl.eu Tue Sep 26 11:33:49 2017 From: mcepl at cepl.eu (=?UTF-8?Q?Mat=c4=9bj_Cepl?=) Date: Tue, 26 Sep 2017 13:33:49 +0200 Subject: [openssl-users] [ANN] M2Crypto 0.26.4 In-Reply-To: <79e8a860-a2d4-0a52-7d40-8569953b1b0c@cepl.eu> References: <79e8a860-a2d4-0a52-7d40-8569953b1b0c@cepl.eu> Message-ID: <99b3bfa1-2659-4fa7-cd10-03baf2d3025c@cepl.eu> One more bugfix release, fixing one silly FTBFS presenting itself on systems with OpenSSL 1.1.0 and LibreSSL (if anybody can provide some testing experience with LibreSSL and file bugs at https://gitlab.com/m2crypto/m2crypto/issues it would be very helpful). I am sorry, Mat?j -- https://matej.ceplovi.cz/blog/, Jabber: mcepl at ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Quod fuimus, estis; quod sumus, vos eritis. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From rsalz at akamai.com Tue Sep 26 11:57:56 2017 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 26 Sep 2017 11:57:56 +0000 Subject: [openssl-users] Manually shutdown the library Message-ID: <489F7313-A009-4611-94A2-0FC1B7A2B923@akamai.com> The original issue was discussed here: https://www.mail-archive.com/openssl-users at openssl.org/msg80781.html There are no plans to do so. You?ll have to modify the source and/or make a pull request. -------------- next part -------------- An HTML attachment was scrubbed... URL: From richmoore44 at gmail.com Tue Sep 26 12:31:16 2017 From: richmoore44 at gmail.com (Richard Moore) Date: Tue, 26 Sep 2017 13:31:16 +0100 Subject: [openssl-users] How can I sstart openssl ocsp in secure mode using TLS/SSL In-Reply-To: References: <893816E7-B93B-4371-AAF1-EFE1333E3543@akamai.com> Message-ID: On 26 September 2017 at 02:36, Kyle Hamilton wrote: > On Fri, Sep 22, 2017 at 9:32 AM, Richard Moore > wrote: > > > > It's also worth pointing out that CAs are banned from running OCSP > servers over HTTPS anyway and it isn't needed since the responses are > already signed - http is fine. > > That argument fails when you consider that some people want the > details of who they're talking to or asking about to be confidential, > not merely authentic. > > ?That doesn't change the fact it's banned.? > I'm a believer in the idea that SNI and the Certificate messages > should happen under an ephemeral DH or ephemeral ECDH cover. Others > fear-monger to say "maybe they shouldn't". > > ?There are a lot of other things that would also need addressing to make it secret /who/ you're talking to. ?It's not something https guarantees right now. If you'd like it to that would be a whole other discussion. > (Also, for completeness, the argument that "CAs are banned from > running OCSP servers over HTTPS anyway" is a straw man at best -- not > every CA is created or intends to be a member of or subject to the > mandates of the CA Security Council, formerly known as the CA/Browser > Forum. And every attempt to encode policy into technical standards, > ??The CA Security Council and CA/Browser Forum are unrelated organisations.? Regards Rich. > attempting to prohibit certain actions for whatever misguided > administrative reasons, is subject to being bypassed by people who > understand the various parts and how to glue them all together.) > To be fair, the OCSP responder certificate may or may not be > revoked... but honestly, if you're asking the OCSP responder for the > status of its own certificate you're opening yourself up to a > subordination/subversion attack anyway. OCSP responders should have > very short-lived certificates, to minimize the temporal subordination > attack surface. > ?? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Sep 26 13:22:13 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 26 Sep 2017 15:22:13 +0200 Subject: [openssl-users] How can I sstart openssl ocsp in secure mode using TLS/SSL In-Reply-To: References: <893816E7-B93B-4371-AAF1-EFE1333E3543@akamai.com> Message-ID: <5f3ae51a-ec09-6661-9746-c21df36c2b98@wisemo.com> On 26/09/2017 14:31, Richard Moore wrote: > > > On 26 September 2017 at 02:36, Kyle Hamilton > wrote: > > On Fri, Sep 22, 2017 at 9:32 AM, Richard Moore > > wrote: > > > > It's also worth pointing out that CAs are banned from running > OCSP servers over HTTPS anyway and it isn't needed since the > responses are already signed - http is fine. > > That argument fails when you consider that some people want the > details of who they're talking to or asking about to be confidential, > not merely authentic. > > > ?That doesn't change the fact it's banned.? > But ONLY for CAB/F regulated public CAs. > > I'm a believer in the idea that SNI and the Certificate messages > should happen under an ephemeral DH or ephemeral ECDH cover.? Others > fear-monger to say "maybe they shouldn't". > > > ?There are a lot of other things that would also need addressing to > make it secret /who/ you're talking to. ?It's not something https > guarantees right now. If you'd like it to that would be a whole other > discussion. > However wiretapping a few central non-https OCSP responders is one of the few attacks that will reveal this without wiretapping the actual connection. 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 Michael.Wojcik at microfocus.com Tue Sep 26 14:28:47 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 26 Sep 2017 14:28:47 +0000 Subject: [openssl-users] How can I sstart openssl ocsp in secure mode using TLS/SSL In-Reply-To: References: <893816E7-B93B-4371-AAF1-EFE1333E3543@akamai.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Richard Moore > Sent: Tuesday, September 26, 2017 06:31 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] How can I sstart openssl ocsp in secure mode using TLS/SSL ??> The CA Security Council and CA/Browser Forum are unrelated organisations.? True, but CASC endorses CA/BF, for example by requiring its members meet the CA/BF Basic Requirements. They may be "unrelated" but they're quite chummy. That said, I don't think openssl-users is an ideal, or effective, forum for organizing an escape from the CA/BF cabal. That will have to happen elsewhere, if it's to happen at all. -- Michael Wojcik Distinguished Engineer, Micro Focus From stuart at myphones.com Tue Sep 26 15:26:05 2017 From: stuart at myphones.com (Stuart Marsden) Date: Tue, 26 Sep 2017 16:26:05 +0100 Subject: [openssl-users] Hardware client certificates moving to Centos 7 Message-ID: <3D21C458-4F12-4906-866E-A76A670E95A7@myphones.com> Hi I have Centos/Apache servers for securely provisioning IP phones using hardware client certificates embedded in the phones. for this test I have allowed all protocols and ciphers on Centos 6 this works fine, the rpms are: openssl098e-0.9.8e-20.el6.centos.1.x86_64 openssl-1.0.1e-57.el6.x86_64 openssl-devel-1.0.1e-57.el6.x86_64 on centos 7 the rpms are: openssl098e-0.9.8e-29.el7.centos.3.x86_64 openssl-1.0.2k-8.el7.x86_64 openssl-libs-1.0.2k-8.el7.x86_64 xmlsec1-openssl-1.2.20-7.el7_4.x86_64 openssl-devel-1.0.2k-8.el7.x86_64 on Centos 7 the logging with "Loglevel debug" in the apache config file is a lot less than Centos 6 The SSL fails to establish with the error below: ssl_engine_kernel.c(1890): [client XX.XX.31.200:47576] AH02043: SSL virtual host for servername xxxxxxxx found ssl_engine_kernel.c(1360): [client XX.XX.31.200:47576] AH02275: Certificate Verification, depth 1, CRL checking mode: none [subject: emailAddress=support at yealink.com,CN=Yealink Equipment Issuing CA,OU=yealink.com,O=Yealink Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: emailAddress=support at yealink.com,CN=Yealink Equipment Issuing CA,OU=yealink.com,O=Yealink Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / serial: E17F3D266C47321E / notbefore: Nov 7 12:45:52 2013 GMT / notafter: Nov 7 12:45:52 2033 GMT] ssl_engine_kernel.c(1360): [client xx.xx.31.200:47576] AH02275: Certificate Verification, depth 0, CRL checking mode: none [subject: emailAddress=support at yealink.com,CN=001565c8be6f,OU=Yealink Equipment,O=Yealink Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: emailAddress=support at yealink.com,CN=Yealink Equipment Issuing CA,OU=yealink.com,O=Yealink Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / serial: 303031353635633862653666 / notbefore: Mar 1 00:00:00 2014 GMT / notafter: Feb 24 00:00:00 2034 GMT] [ssl:info] [pid 1611] [client xx.xx.31.200:47576] AH02276: Certificate Verification: Error (7): certificate signature failure [subject: emailAddress=support at yealink.com,CN=001565c8be6f,OU=Yealink Equipment,O=Yealink Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: emailAddress=support at yealink.com,CN=Yealink Equipment Issuing CA,OU=yealink.com,O=Yealink Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / serial: 303031353635633862653666 / notbefore: Mar 1 00:00:00 2014 GMT / notafter: Feb 24 00:00:00 2034 GMT] [ssl:info] [pid 1611] [client xx.xx.31.200:47576] AH02008: SSL library error 1 in handshake (server xxx.xxx.xxx.xxx:443) [ssl:info] [pid 1611] SSL Library Error: error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm [ssl:info] [pid 1611] SSL Library Error: error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed [ssl:info] [pid 1611] [client xx.xx.31.200:47576] AH01998: Connection closed to child 3 with abortive shutdown It fails across several phone vendors. Any suggestions greatly received, thanks in advance Stuart From wouter.verhelst at fedict.be Tue Sep 26 15:36:06 2017 From: wouter.verhelst at fedict.be (Wouter Verhelst) Date: Tue, 26 Sep 2017 17:36:06 +0200 Subject: [openssl-users] Hardware client certificates moving to Centos 7 In-Reply-To: <3D21C458-4F12-4906-866E-A76A670E95A7@myphones.com> References: <3D21C458-4F12-4906-866E-A76A670E95A7@myphones.com> Message-ID: On 26-09-17 17:26, Stuart Marsden wrote: > [ssl:info] [pid 1611] SSL Library Error: error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm So which message digest algorithm is the client trying to use? -- Wouter Verhelst From stuart at myphones.com Tue Sep 26 15:56:54 2017 From: stuart at myphones.com (Stuart Marsden) Date: Tue, 26 Sep 2017 16:56:54 +0100 Subject: [openssl-users] Hardware client certificates moving to Centos 7 In-Reply-To: References: <3D21C458-4F12-4906-866E-A76A670E95A7@myphones.com> Message-ID: Sorry how can I tell ? I can run a wireshark if necessary thanks > On 26 Sep 2017, at 16:36, Wouter Verhelst wrote: > > On 26-09-17 17:26, Stuart Marsden wrote: >> [ssl:info] [pid 1611] SSL Library Error: error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm > > So which message digest algorithm is the client trying to use? > > -- > Wouter Verhelst > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From bkaduk at akamai.com Tue Sep 26 16:58:43 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 26 Sep 2017 11:58:43 -0500 Subject: [openssl-users] How to increase the priority of some cipher ? In-Reply-To: <17db9aa9.af84.15ebd5be18e.Coremail.mid_li@163.com> References: <708dccf5.c6c1.15b7b79df7f.Coremail.mid_li@163.com> <60c65bc6.8bec.15ebd0a1d15.Coremail.mid_li@163.com> <17db9aa9.af84.15ebd5be18e.Coremail.mid_li@163.com> Message-ID: I am curious about this statement that "(EC)DHE cost much more resources than RSA".? In particular, ECDHE is supposed to be less computation-intensive than RSA for a given security level, so it would be interesting to hear what your setup is where the reverse is supposed to be observed. -Ben On 09/26/2017 03:44 AM, ?? wrote: > just find it,? > ?server respect client's cipher preference? by default,?? > ?it selects the suite preferred by client among the cipherlist that > both the client and server support. > ?so it's not enough to just increase RSA cipher priority on server > side ,?? > ?SSL_OP_CIPHER_SERVER_PREFERENCE will make the server select the suite > that itself most prefer among?the cipherlist that both the client and > server support. > > > ? 2017-09-26 15:15:10?"??" ??? > > Hello,? > ? ?Currently, openssl prefer?(EC)DHE handshakes over plain RSA, > but (EC)DHE cost much more resouces than RSA. > ? ?In order to get higher performance , I want to??prioritize > RSA?related?ciphers, does anyone knows how to do it. > ? ? > ? ?I have tried cipherlist "RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL" , > it looks fine in openssl command line > ? ?./openssl ciphers -v 'RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL'? > AES256-GCM-SHA384? ? ? ?TLSv1.2 Kx=RSA? ? ? Au=RSA? > Enc=AESGCM(256) Mac=AEAD > AES128-GCM-SHA256? ? ? ?TLSv1.2 Kx=RSA? ? ? Au=RSA? > Enc=AESGCM(128) Mac=AEAD > AES256-SHA256? ? ? ? ? ?TLSv1.2 Kx=RSA? ? ? Au=RSA? Enc=AES(256)? > Mac=SHA256 > AES128-SHA256? ? ? ? ? ?TLSv1.2 Kx=RSA? ? ? Au=RSA? Enc=AES(128)? > Mac=SHA256 > AES256-SHA? ? ? ? ? ? ? SSLv3 Kx=RSA? ? ? Au=RSA? Enc=AES(256)? > Mac=SHA1 > AES128-SHA? ? ? ? ? ? ? SSLv3 Kx=RSA? ? ? Au=RSA? Enc=AES(128)? > Mac=SHA1 > ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH? ? ?Au=ECDSA > Enc=AESGCM(256) Mac=AEAD > > ?but, after SSL_CTX_set_cipher_list(ctx, > "RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL")? in my application, it > didn't work, the first choice is still?ECDHE-RSA-AES256-GCM-SHA384 > > > ??????????????????????13?/??????75?3?>> > ? > > ? ? > > > > ?????|30???????????1/4?MUJI????2017??????????????34.9?>> > ? > > ? ? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Tue Sep 26 20:35:05 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Tue, 26 Sep 2017 20:35:05 +0000 Subject: [openssl-users] How to emulate EVP_PKEY_meth_get_sign() on OpenSSL-1.0.2? Message-ID: <74A8FBE7-8741-43F3-AC58-C95ADDB5F7B8@ll.mit.edu> An engine works with OpenSSL-1.1.0+. It needs to hook some methods, and it accesses them via EVP_PKEY_meth_get_sign(), EVP_PKEY_meth_get_decrypt(), and EVP_PKEY_meth_get_encrypt(). And the corresponding set() calls. I?d like to backport this engine to OpenSSL-1.0.2. But 1.0.2 does not provide these calls. Is there a way to emulate the above calls, and achieve similar result on OpenSSL-1.0.2? Thanks! -- Regards, Uri Blumenthal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5211 bytes Desc: not available URL: From rsalz at akamai.com Tue Sep 26 20:37:58 2017 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 26 Sep 2017 20:37:58 +0000 Subject: [openssl-users] How to emulate EVP_PKEY_meth_get_sign() on OpenSSL-1.0.2? In-Reply-To: <74A8FBE7-8741-43F3-AC58-C95ADDB5F7B8@ll.mit.edu> References: <74A8FBE7-8741-43F3-AC58-C95ADDB5F7B8@ll.mit.edu> Message-ID: <36F7B06B-7CDB-417F-8787-044BFA135BE3@akamai.com> ? Is there a way to emulate the above calls, and achieve similar result on OpenSSL-1.0.2? Just pull the fields out of the struct directly? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Sep 26 20:53:07 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 26 Sep 2017 22:53:07 +0200 Subject: [openssl-users] How to increase the priority of some cipher ? In-Reply-To: References: <708dccf5.c6c1.15b7b79df7f.Coremail.mid_li@163.com> <60c65bc6.8bec.15ebd0a1d15.Coremail.mid_li@163.com> <17db9aa9.af84.15ebd5be18e.Coremail.mid_li@163.com> Message-ID: Obviously, the DH Ephemeral ciphersuites consist of a (sometimes fast) DH step PLUS an RSA or ECDSA step to confirm the identity of the server, while the slightly less secure RSA suites only do the RSA step.? DH+ECDSA requires an ECDSA certificate, which won't work for clients that require RSA suites. On 26/09/2017 18:58, Benjamin Kaduk via openssl-users wrote: > I am curious about this statement that "(EC)DHE cost much more > resources than RSA".? In particular, ECDHE is supposed to be less > computation-intensive than RSA for a given security level, so it would > be interesting to hear what your setup is where the reverse is > supposed to be observed. > > -Ben > > On 09/26/2017 03:44 AM, ?? wrote: >> just find it, >> ?server respect client's cipher preference? by default, >> ?it selects the suite preferred by client among the cipherlist that >> both the client and server support. >> ?so it's not enough to just increase RSA cipher priority on server >> side , >> SSL_OP_CIPHER_SERVER_PREFERENCE will make the server select the suite >> that itself most prefer among the cipherlist that both the client and >> server support. >> >> >> ? 2017-09-26 15:15:10?"??" ??? >> >> Hello, >> ? ?Currently, openssl prefer?(EC)DHE handshakes over plain RSA, >> but (EC)DHE cost much more resouces than RSA. >> ? ?In order to get higher performance , I want to prioritize >> RSA?related?ciphers, does anyone knows how to do it. >> ? ?I have tried cipherlist "RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL" >> , it looks fine in openssl command line >> ./openssl ciphers -v 'RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL' >> AES256-GCM-SHA384 ? ? ?TLSv1.2 Kx=RSA? ? ? Au=RSA? >> Enc=AESGCM(256) Mac=AEAD >> AES128-GCM-SHA256 ? ? ?TLSv1.2 Kx=RSA? ? ? Au=RSA? >> Enc=AESGCM(128) Mac=AEAD >> AES256-SHA256 ? ? ? ? ?TLSv1.2 Kx=RSA? ? ? Au=RSA? Enc=AES(256) >> Mac=SHA256 >> AES128-SHA256 ? ? ? ? ?TLSv1.2 Kx=RSA? ? ? Au=RSA? Enc=AES(128) >> Mac=SHA256 >> AES256-SHA ? ? ? ? ? ? SSLv3 Kx=RSA? ? ? Au=RSA? Enc=AES(256) >> Mac=SHA1 >> AES128-SHA ? ? ? ? ? ? SSLv3 Kx=RSA? ? ? Au=RSA? Enc=AES(128) >> Mac=SHA1 >> ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH? ? ?Au=ECDSA >> Enc=AESGCM(256) Mac=AEAD >> >> ?but, after SSL_CTX_set_cipher_list(ctx, >> "RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL")? in my application, it >> didn't work, the first choice is still ECDHE-RSA-AES256-GCM-SHA384 >> 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 uri at ll.mit.edu Tue Sep 26 21:53:17 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Tue, 26 Sep 2017 21:53:17 +0000 Subject: [openssl-users] How to load the right engine? Message-ID: I?m debugging programmatic access to a (modified) pkcs11 engine. My system has several OpenSSL installations: Apple-provided OpenSSL-0.9.8 (kept as that came with the OS :), Macports-installed OpenSSL-1.0.2l (the main one installed to /opt/local, used by everything Macports builds, and what I use mostly for my software), and a couple of OpenSSL-1.1.x installations mostly used for debugging. Libp11 is installed in /opt/local/lib/engines, and that version is built for/compatible with OpenSSL-1.0.2. There?s an installation of OpenSSL-1.1.0-stable in ~/openssl-1.1. libp11 built for 1.1 is installed in ~/openssl-1.1/lib/engines-1.1 directory. So far so good. The problem I?m having now is ? my application appears to be getting the wrong pkcs11 engine (the one for 1.0.2), based on the error message I get on decrypting, which is indicative of the unmodified libp11 version (not the one I?m working with for 1.1). Question: how do I ensure/verify that the right pkcs11 library is loaded? Tail of openssl.cnf: [pkcs11_section] ?? engine_id = pkcs11 ?? dynamic_path = /Users/ur20980/openssl-1.1/lib/engines-1.1/pkcs11.dylib ?? MODULE_PATH = /usr/local/lib/yubihsm_pkcs11.dylib ?? init = 0 Thanks! -- Regards, Uri Blumenthal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5211 bytes Desc: not available URL: From rgm at htt-consult.com Tue Sep 26 22:39:59 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Tue, 26 Sep 2017 18:39:59 -0400 Subject: [openssl-users] Hardware client certificates moving to Centos 7 In-Reply-To: <3D21C458-4F12-4906-866E-A76A670E95A7@myphones.com> References: <3D21C458-4F12-4906-866E-A76A670E95A7@myphones.com> Message-ID: <621a5e71-4c18-72da-c4ee-0f82c599f52b@htt-consult.com> On 09/26/2017 11:26 AM, Stuart Marsden wrote: > Hi > > I have Centos/Apache servers for securely provisioning IP phones using hardware client certificates embedded in the phones. > > for this test I have allowed all protocols and ciphers > > on Centos 6 this works fine, the rpms are: > > openssl098e-0.9.8e-20.el6.centos.1.x86_64 > openssl-1.0.1e-57.el6.x86_64 > openssl-devel-1.0.1e-57.el6.x86_64 > > on centos 7 the rpms are: > > openssl098e-0.9.8e-29.el7.centos.3.x86_64 > openssl-1.0.2k-8.el7.x86_64 > openssl-libs-1.0.2k-8.el7.x86_64 > xmlsec1-openssl-1.2.20-7.el7_4.x86_64 > openssl-devel-1.0.2k-8.el7.x86_64 > > on Centos 7 the logging with "Loglevel debug" in the apache config file is a lot less than Centos 6 > > > The SSL fails to establish with the error below: > > > ssl_engine_kernel.c(1890): [client XX.XX.31.200:47576] AH02043: SSL virtual host for servername xxxxxxxx found > > ssl_engine_kernel.c(1360): [client XX.XX.31.200:47576] AH02275: Certificate Verification, depth 1, CRL checking mode: none [subject: emailAddress=support at yealink.com,CN=Yealink Equipment Issuing CA,OU=yealink.com,O=Yealink Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: emailAddress=support at yealink.com,CN=Yealink Equipment Issuing CA,OU=yealink.com,O=Yealink Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / serial: E17F3D266C47321E / notbefore: Nov 7 12:45:52 2013 GMT / notafter: Nov 7 12:45:52 2033 GMT] Please provide a complete dump of the hardware certificate. There may be a subjectAltName with fields that require an hex dump. I want to see if these are IEEE 802.1AR certificates... If they are, they are suppose to be used to provision an owner (lDevID) certificate. But they should be usable; they may be ECDSA certs. You can see some examples on how to create (and display) ECDSA 802.1AR certs in: https://datatracker.ietf.org/doc/draft-moskowitz-ecdsa-pki/ > > ssl_engine_kernel.c(1360): [client xx.xx.31.200:47576] AH02275: Certificate Verification, depth 0, CRL checking mode: none [subject: emailAddress=support at yealink.com,CN=001565c8be6f,OU=Yealink Equipment,O=Yealink Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: emailAddress=support at yealink.com,CN=Yealink Equipment Issuing CA,OU=yealink.com,O=Yealink Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / serial: 303031353635633862653666 / notbefore: Mar 1 00:00:00 2014 GMT / notafter: Feb 24 00:00:00 2034 GMT] > > [ssl:info] [pid 1611] [client xx.xx.31.200:47576] AH02276: Certificate Verification: Error (7): certificate signature failure [subject: emailAddress=support at yealink.com,CN=001565c8be6f,OU=Yealink Equipment,O=Yealink Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: emailAddress=support at yealink.com,CN=Yealink Equipment Issuing CA,OU=yealink.com,O=Yealink Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / serial: 303031353635633862653666 / notbefore: Mar 1 00:00:00 2014 GMT / notafter: Feb 24 00:00:00 2034 GMT] > > [ssl:info] [pid 1611] [client xx.xx.31.200:47576] AH02008: SSL library error 1 in handshake (server xxx.xxx.xxx.xxx:443) > [ssl:info] [pid 1611] SSL Library Error: error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm > [ssl:info] [pid 1611] SSL Library Error: error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed > [ssl:info] [pid 1611] [client xx.xx.31.200:47576] AH01998: Connection closed to child 3 with abortive shutdown > > > It fails across several phone vendors. > > Any suggestions greatly received, thanks in advance > > Stuart > > From aerowolf at gmail.com Wed Sep 27 00:04:34 2017 From: aerowolf at gmail.com (Kyle Hamilton) Date: Tue, 26 Sep 2017 17:04:34 -0700 Subject: [openssl-users] Hardware client certificates moving to Centos 7 In-Reply-To: References: <3D21C458-4F12-4906-866E-A76A670E95A7@myphones.com> Message-ID: openssl x509 -noout -text -in clientcertificate.pem You may need to extract the client certificate from wireshark, but you could also get it from openssl s_server. Specifically, that error message is suggesting that there's a message digest encoded into the certificate which is unknown to the trust path. Chances are, it's probably MD5. MD5 was broken a long time ago, and is no longer trustworthy. (SHA1 is also a possibility, but it was made unacceptable a lot more recently.) -Kyle H On Tue, Sep 26, 2017 at 8:56 AM, Stuart Marsden wrote: > Sorry how can I tell ? > > I can run a wireshark if necessary > > thanks > > >> On 26 Sep 2017, at 16:36, Wouter Verhelst wrote: >> >> On 26-09-17 17:26, Stuart Marsden wrote: >>> [ssl:info] [pid 1611] SSL Library Error: error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm >> >> So which message digest algorithm is the client trying to use? >> >> -- >> Wouter Verhelst >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From rgm at htt-consult.com Wed Sep 27 00:35:57 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Tue, 26 Sep 2017 20:35:57 -0400 Subject: [openssl-users] Hardware client certificates moving to Centos 7 In-Reply-To: References: <3D21C458-4F12-4906-866E-A76A670E95A7@myphones.com> Message-ID: <48ca85e2-af0f-b283-4262-a6cad5080eb5@htt-consult.com> On 09/26/2017 08:04 PM, Kyle Hamilton wrote: > openssl x509 -noout -text -in clientcertificate.pem > > You may need to extract the client certificate from wireshark, but you > could also get it from openssl s_server. > > Specifically, that error message is suggesting that there's a message > digest encoded into the certificate which is unknown to the trust > path. > > Chances are, it's probably MD5. MD5 was broken a long time ago, and > is no longer trustworthy. (SHA1 is also a possibility, but it was > made unacceptable a lot more recently.) If it IS a 802.1AR RSA cert (the original drivers for 802.1AR was protecting VoIP phones), 802.1AR-2009 says: 6.3.5.1 RSA Signing If the key is an RSA key, then this operation shall generate a PKCS1 signature as defined in RFC 3447 with the signature algorithm of RSASSA-PKCS1-v1_5, for maximum interoperability. The currentEncoding specifies the current encoding of the data. The dataOctets are partially encoded for RFC 3447 signing prior to calling this DevID module interface. A value of PKCS1HASH_SHA256 indicates that the dataOctets are a SHA256 hash of the original data as specified by RFC 3447 id-sha256. The DevID Module will continue encoding the data, starting at RFC 3447 Section 9.2 step 2, by building and padding the DigestInfo ASN.1 value and then building the full PKCS1 signature. A currentEncoding value of PKCS1DIGESTINFO_OPAQUE indicates that the dataOctets are already encoded into the equivalent of the RFC 3447 Section 9.2 step 2 specified DigestInfo. The DevID Module will continue encoding the data, starting at RFC 3447 Section 9.2 step 3, by padding the dataOctet as specified for the DigestInfo ASN.1 value, and then building the full PKCS1 signature. NOTE?Some uses of PKCS1 specify an alternative to the RFC 3447 DigestInfo structure. For example TLS 1.1 RFC4346 specifies ?a 36-byte structure of two hashes (one SHA and one MD5).? The use of PKCS1DIGESTINFO_OPAQUE provides support for this type of construct. It also provides a mechanism for components leveraging the DeviceID Module to obtain PCKS1 signatures using legacy hash algorithms such as SHA-1 or MD5. And: 7.3.1 RSASSA-PKCS1-v1.5 The RSASSA-PKCS1-v1.5 signature method is defined in RFC 3447. The algorithm shall be either sha1WithRSAEncryption or sha256WithRSAEncryption. The algorithm identifiers are: sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } sha256WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11 } Support for sha1WithRSAEncryption is included for maximum interoperability but is not recommended. When the sha1WithRSAEncryption or sha256WithRSAEncryption algorithm identifiers appear in the algorithm field as an AlgorithmIdentifier, the encoding must omit the parameters field. That is, the AlgorithmIdentifier shall be a SEQUENCE of one component, the object identifier sha1WithRSAEncryption or sha256WithRSAEncryption. > > -Kyle H > > > On Tue, Sep 26, 2017 at 8:56 AM, Stuart Marsden wrote: >> Sorry how can I tell ? >> >> I can run a wireshark if necessary >> >> thanks >> >> >>> On 26 Sep 2017, at 16:36, Wouter Verhelst wrote: >>> >>> On 26-09-17 17:26, Stuart Marsden wrote: >>>> [ssl:info] [pid 1611] SSL Library Error: error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm >>> So which message digest algorithm is the client trying to use? >>> >>> -- >>> Wouter Verhelst >>> -- >>> openssl-users mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>> >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From mid_li at 163.com Wed Sep 27 00:52:01 2017 From: mid_li at 163.com (=?GBK?B?wO7D9w==?=) Date: Wed, 27 Sep 2017 08:52:01 +0800 (CST) Subject: [openssl-users] How to increase the priority of some cipher ? In-Reply-To: References: <708dccf5.c6c1.15b7b79df7f.Coremail.mid_li@163.com> <60c65bc6.8bec.15ebd0a1d15.Coremail.mid_li@163.com> <17db9aa9.af84.15ebd5be18e.Coremail.mid_li@163.com> Message-ID: <53b58556.16b1.15ec0d1b085.Coremail.mid_li@163.com> The environment is quite simple?client use apachebench to test the performance of a https server the apachebench command is like this? ab -c 500 -n 1000000 https://xx.xx.xx.xx/ TLSv1.2,AES256-GCM-SHA384 ? the server can handle more than 1500 requests per second?cpu ? 99%?? TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 : the server can ONLY handle 500 requests per second?cpu ?99%?? At 2017-09-27 00:58:43, "Benjamin Kaduk" wrote: I am curious about this statement that "(EC)DHE cost much more resources than RSA". In particular, ECDHE is supposed to be less computation-intensive than RSA for a given security level, so it would be interesting to hear what your setup is where the reverse is supposed to be observed. -Ben On 09/26/2017 03:44 AM, ?? wrote: just find it, server respect client's cipher preference by default, it selects the suite preferred by client among the cipherlist that both the client and server support. so it's not enough to just increase RSA cipher priority on server side , SSL_OP_CIPHER_SERVER_PREFERENCE will make the server select the suite that itself most prefer among the cipherlist that both the client and server support. ? 2017-09-26 15:15:10?"??" ??? Hello, Currently, openssl prefer (EC)DHE handshakes over plain RSA, but (EC)DHE cost much more resouces than RSA. In order to get higher performance , I want to prioritize RSA related ciphers, does anyone knows how to do it. I have tried cipherlist "RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL" , it looks fine in openssl command line ./openssl ciphers -v 'RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL' AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD but, after SSL_CTX_set_cipher_list(ctx, "RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL") in my application, it didn't work, the first choice is still ECDHE-RSA-AES256-GCM-SHA384 ??????????????????????13?/??????75?3?>> ?????|30???????????1/4?MUJI????2017??????????????34.9?>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hongyi.zhao at gmail.com Wed Sep 27 01:08:27 2017 From: hongyi.zhao at gmail.com (Hongyi Zhao) Date: Wed, 27 Sep 2017 09:08:27 +0800 Subject: [openssl-users] How to uninstall openssl with ``sudo make uninstall''? Message-ID: Hi all, I installed the openssl-1.0.0 with the following steps: $ ./config shared $ make -j24 $ sudo make install But when I try to uninstall it, I meet the following error: $ sudo make uninstall make: *** No rule to make target 'uninstall'. Stop. ps. All of the above steps are performed under the source code root directory. Regards -- Hongsheng Zhao Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493 From mid_li at 163.com Wed Sep 27 01:23:54 2017 From: mid_li at 163.com (=?GBK?B?wO7D9w==?=) Date: Wed, 27 Sep 2017 09:23:54 +0800 (CST) Subject: [openssl-users] How to increase the priority of some cipher ? In-Reply-To: <53b58556.16b1.15ec0d1b085.Coremail.mid_li@163.com> References: <708dccf5.c6c1.15b7b79df7f.Coremail.mid_li@163.com> <60c65bc6.8bec.15ebd0a1d15.Coremail.mid_li@163.com> <17db9aa9.af84.15ebd5be18e.Coremail.mid_li@163.com> <53b58556.16b1.15ec0d1b085.Coremail.mid_li@163.com> Message-ID: <79a4a699.2130.15ec0eee0e3.Coremail.mid_li@163.com> sorry? write by mistake TLSv1.2,AES256-GCM-SHA384 ? the server can handle more than 1500 requests per second?cpu ? 99%?? TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 : the server can ONLY handle less then 1400 requests per second?cpu ?99%?? At 2017-09-27 08:52:01, "??" wrote: The environment is quite simple?client use apachebench to test the performance of a https server the apachebench command is like this? ab -c 500 -n 1000000 https://xx.xx.xx.xx/ TLSv1.2,AES256-GCM-SHA384 ? the server can handle more than 1500 requests per second?cpu ? 99%?? TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 : the server can ONLY handle 500 requests per second?cpu ?99%?? At 2017-09-27 00:58:43, "Benjamin Kaduk" wrote: I am curious about this statement that "(EC)DHE cost much more resources than RSA". In particular, ECDHE is supposed to be less computation-intensive than RSA for a given security level, so it would be interesting to hear what your setup is where the reverse is supposed to be observed. -Ben On 09/26/2017 03:44 AM, ?? wrote: just find it, server respect client's cipher preference by default, it selects the suite preferred by client among the cipherlist that both the client and server support. so it's not enough to just increase RSA cipher priority on server side , SSL_OP_CIPHER_SERVER_PREFERENCE will make the server select the suite that itself most prefer among the cipherlist that both the client and server support. ? 2017-09-26 15:15:10?"??" ??? Hello, Currently, openssl prefer (EC)DHE handshakes over plain RSA, but (EC)DHE cost much more resouces than RSA. In order to get higher performance , I want to prioritize RSA related ciphers, does anyone knows how to do it. I have tried cipherlist "RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL" , it looks fine in openssl command line ./openssl ciphers -v 'RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL' AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD but, after SSL_CTX_set_cipher_list(ctx, "RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL") in my application, it didn't work, the first choice is still ECDHE-RSA-AES256-GCM-SHA384 ??????????????????????13?/??????75?3?>> ?????|30???????????1/4?MUJI????2017??????????????34.9?>> ?????|30???????????1/4?MUJI????2017??????????????34.9?>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Wed Sep 27 07:57:03 2017 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 27 Sep 2017 10:57:03 +0300 Subject: [openssl-users] How to load the right engine? In-Reply-To: References: Message-ID: Hello, I usually use strace for this purpose. On Wed, Sep 27, 2017 at 12:53 AM, Blumenthal, Uri - 0553 - MITLL < uri at ll.mit.edu> wrote: > I?m debugging programmatic access to a (modified) pkcs11 engine. My system > has several OpenSSL installations: Apple-provided OpenSSL-0.9.8 (kept as > that came with the OS :), Macports-installed OpenSSL-1.0.2l (the main one > installed to /opt/local, used by everything Macports builds, and what I use > mostly for my software), and a couple of OpenSSL-1.1.x installations mostly > used for debugging. > > > > Libp11 is installed in /opt/local/lib/engines, and that version is built > for/compatible with OpenSSL-1.0.2. > > > > There?s an installation of OpenSSL-1.1.0-stable in ~/openssl-1.1. libp11 > built for 1.1 is installed in ~/openssl-1.1/lib/engines-1.1 directory. So > far so good. > > > > The problem I?m having now is ? my application appears to be getting the > wrong pkcs11 engine (the one for 1.0.2), based on the error message I get > on decrypting, which is indicative of the unmodified libp11 version (not > the one I?m working with for 1.1). > > > > Question: how do I ensure/verify that the right pkcs11 library is loaded? > > > > Tail of openssl.cnf: > > > > [pkcs11_section] > > engine_id = pkcs11 > > dynamic_path = /Users/ur20980/openssl-1.1/lib/engines-1.1/pkcs11.dylib > > MODULE_PATH = /usr/local/lib/yubihsm_pkcs11.dylib > > init = 0 > > > > > > Thanks! > > -- > > Regards, > > Uri Blumenthal > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart at myphones.com Wed Sep 27 12:07:46 2017 From: stuart at myphones.com (Stuart Marsden) Date: Wed, 27 Sep 2017 13:07:46 +0100 Subject: [openssl-users] Hardware client certificates moving to Centos 7 In-Reply-To: References: <3D21C458-4F12-4906-866E-A76A670E95A7@myphones.com> Message-ID: <0A422AA3-921B-442C-836D-D5FC167911AC@myphones.com> Hi I think I know what you are going to say - MD5? I ran openssl s_server -verify , then ran the x509 command as you suggested using the captured client certificate This phone model has only just gone into production, and I am using a "preview version" of the hardware Is there a way a can install a version of openssl on a dedicated standalone Centos 7 server which will support these phones? That would be preferable to me than having to leave Centos 6 servers just for this Thanks everyone for your help sofar Stuart openssl x509 -noout -text -in yealink.pem Certificate: Data: Version: 3 (0x2) Serial Number: 30:30:31:35:36:35:63:38:62:65:36:66 Signature Algorithm: md5WithRSAEncryption Issuer: C=CN, ST=Fujian, L=Xiamen, O=Yealink Network Technology Co.,Ltd., OU=yealink.com, CN=Yealink Equipment Issuing CA/emailAddress=support at yealink.com Validity Not Before: Mar 1 00:00:00 2014 GMT Not After : Feb 24 00:00:00 2034 GMT Subject: C=CN, ST=Fujian, L=Xiamen, O=Yealink Network Technology Co.,Ltd., OU=Yealink Equipment, CN=001565c8be6f/emailAddress=support at yealink.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) Modulus: 00:e9:22:52:1a:47:bf:06:4d:2e:86:4f:61:5e:f8: 70:47:7f:c7:7d:4d:1e:b7:9f:0d:38:d2:79:8e:e9: 47:88:f3:f1:dd:75:d0:b3:d7:72:da:aa:e8:72:12: 7e:67:5c:c1:63:f3:6e:54:48:f7:46:a8:1c:fe:6a: 96:13:87:31:68:bb:89:98:b5:45:8d:c2:ef:24:a0: 47:7c:bf:20:d6:88:6b:95:4b:3a:f4:90:ec:a1:b2: 8a:4e:f9:2a:01:02:ba:f9:7f:52:b7:5f:71:18:d4: 40:74:56:75:94:e1:2e:ed:87:69:5a:33:ca:51:45: 06:ce:5e:5d:f1:ff:c1:5f:2f Exponent: 65537 (0x10001) Signature Algorithm: md5WithRSAEncryption 74:a9:f7:02:52:51:86:c9:09:15:c9:2e:32:1b:29:81:b6:d0: a9:7a:88:61:5a:fe:22:3e:6d:68:e3:71:64:e2:12:1f:5a:0e: 35:54:19:b8:4a:e5:a1:70:27:0f:3b:99:ae:db:d1:bc:77:39: 22:0a:4d:71:a9:08:ca:c4:e0:28:a6:a0:e4:bc:9d:56:c1:ad: 49:4b:5c:70:b2:a7:e8:64:ef:fa:fa:c0:1c:89:92:63:c5:67: 55:ab:d9:65:57:4b:a8:6e:59:a6:d3:4b:ff:9b:27:8b:0e:ea: ac:71:de:6c:5d:97:c7:78:17:40:4b:03:79:81:1b:02:31:6c: fa:01:4a:c2:e2:c2:d6:14:4c:ff:9a:1c:41:ed:14:c2:eb:b4: f5:1b:db:06:d7:1f:e3:bc:69:d0:f7:d6:8e:13:db:7b:f1:15: 5c:11:b9:18:56:6b:d3:0f:96:20:99:a3:19:01:83:9a:f2:65: 4d:7d:6b:41:92:d2:d1:4d:40:74:b7:8b:a8:54:ba:bf:b0:04: 0e:a0:45:5b:62:c1:0e:7b:48:7d:c8:96:62:99:50:e7:44:b1: 8a:01:e0:ec:b7:42:6c:3d:52:16:70:3b:0f:e6:e3:31:8b:31: ee:62:fd:fd:3c:94:90:04:05:99:7b:b2:c0:41:8f:92:05:db: 46:a6:2d:ed:ba:e5:70:61:45:52:a4:f0:97:54:cf:75:9d:8b: f9:89:f2:01:0e:7f:f7:b6:1f:1c:03:56:a6:cc:d0:00:99:b9: f1:e3:6b:18:d5:69:46:38:a3:23:ba:f3:76:08:ff:02:bc:15: df:91:67:6e:94:62:35:34:a2:fa:d3:33:01:da:00:b6:07:4c: 89:7e:f3:98:dc:81:e5:0f:4a:19:ea:fe:91:02:3a:9d:22:25: a9:38:f8:2f:91:ca:09:e1:6c:12:b2:68:a6:a2:af:8b:41:f7: 61:e5:40:2f:98:60:18:10:90:af:55:50:8a:31:2d:17:82:d2: 13:cf:27:5b:fa:c8:ee:74:e1:98:00:26:56:24:68:38:b4:e3: 21:ee:3c:8b:16:32:72:93:fc:3b:0f:13:9a:b1:97:e8:6e:ca: 33:00:ee:7b:30:7c:e2:e7:14:99:a0:5f:f1:f9:95:1f:fc:5c: 17:79:33:2a:f1:fd:89:6e:50:d8:d7:8d:05:95:3f:11:72:c7: 69:e8:0f:4c:82:7b:9d:26:86:04:60:b2:3b:24:76:4a:34:c6: 87:ef:e6:e7:8b:53:98:de:f4:cc:d8:39:b2:2d:ea:09:a4:80: f3:c2:d7:bd:6f:7b:7d:4c:35:b2:23:ca:56:fc:5b:6d:08:05: 6b:11:bd:c6:4b:92:4f:46 > On 27 Sep 2017, at 01:04, Kyle Hamilton wrote: > > openssl x509 -noout -text -in clientcertificate.pem > > You may need to extract the client certificate from wireshark, but you > could also get it from openssl s_server. > > Specifically, that error message is suggesting that there's a message > digest encoded into the certificate which is unknown to the trust > path. > > Chances are, it's probably MD5. MD5 was broken a long time ago, and > is no longer trustworthy. (SHA1 is also a possibility, but it was > made unacceptable a lot more recently.) > > -Kyle H > > > On Tue, Sep 26, 2017 at 8:56 AM, Stuart Marsden wrote: >> Sorry how can I tell ? >> >> I can run a wireshark if necessary >> >> thanks >> >> >>> On 26 Sep 2017, at 16:36, Wouter Verhelst wrote: >>> >>> On 26-09-17 17:26, Stuart Marsden wrote: >>>> [ssl:info] [pid 1611] SSL Library Error: error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm >>> >>> So which message digest algorithm is the client trying to use? >>> >>> -- >>> Wouter Verhelst >>> -- >>> openssl-users mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>> >> >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Wed Sep 27 12:22:25 2017 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 27 Sep 2017 15:22:25 +0300 Subject: [openssl-users] Storing private key on tokens Message-ID: Hello, What is the most natural way to generate private keys using openssl but store them on a specific hardware tokens? Reading/writing is implemented via engine mechanism. I suppose that it should be added support of -outform ENGINE to the genpkey command, but do not understatnd how to deal with it after that. Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgm at htt-consult.com Wed Sep 27 12:27:47 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Wed, 27 Sep 2017 08:27:47 -0400 Subject: [openssl-users] Hardware client certificates moving to Centos 7 In-Reply-To: <0A422AA3-921B-442C-836D-D5FC167911AC@myphones.com> References: <3D21C458-4F12-4906-866E-A76A670E95A7@myphones.com> <0A422AA3-921B-442C-836D-D5FC167911AC@myphones.com> Message-ID: On 09/27/2017 08:07 AM, Stuart Marsden wrote: > Hi > > I think I know what you are going to say - MD5? Lots of problems with that cert. If you have some connection with the vendor, have them read IEEE 802.1AR-2009 standard for Device Identity credentials. You will be supporting this phone different from those that follow the standard. > > I ran openssl s_server -verify , then ran the x509 command as you > suggested using the captured client certificate > > This phone model has only just gone into production, and I am using a > "preview version" of the hardware > > Is there a way a can install a version of openssl on a dedicated > standalone Centos 7 server which will support these phones? I run Centos7 on arm platforms There are lots of ways to run dedicated C7 servers. Talk about this on the Centos-user or Centos-arm list. > > That would be preferable to me than having to leave Centos 6 servers > just for this A lot of years until EOL for Centos6. They just did it for C5... > > Thanks everyone for your help sofar > > Stuart > > > openssl x509 -noout -text -in yealink.pem > Certificate: > Data: > Version: 3 (0x2) > Serial Number: > 30:30:31:35:36:35:63:38:62:65:36:66 > Signature Algorithm: md5WithRSAEncryption > Issuer: C=CN, ST=Fujian, L=Xiamen, O=Yealink Network > Technology Co.,Ltd., OU=yealink.com , CN=Yealink > Equipment Issuing CA/emailAddress=support at yealink.com > > Validity > Not Before: Mar 1 00:00:00 2014 GMT > Not After : Feb 24 00:00:00 2034 GMT > Subject: C=CN, ST=Fujian, L=Xiamen, O=Yealink Network > Technology Co.,Ltd., OU=Yealink Equipment, > CN=001565c8be6f/emailAddress=support at yealink.com > > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: (1024 bit) > Modulus: > 00:e9:22:52:1a:47:bf:06:4d:2e:86:4f:61:5e:f8: > 70:47:7f:c7:7d:4d:1e:b7:9f:0d:38:d2:79:8e:e9: > 47:88:f3:f1:dd:75:d0:b3:d7:72:da:aa:e8:72:12: > 7e:67:5c:c1:63:f3:6e:54:48:f7:46:a8:1c:fe:6a: > 96:13:87:31:68:bb:89:98:b5:45:8d:c2:ef:24:a0: > 47:7c:bf:20:d6:88:6b:95:4b:3a:f4:90:ec:a1:b2: > 8a:4e:f9:2a:01:02:ba:f9:7f:52:b7:5f:71:18:d4: > 40:74:56:75:94:e1:2e:ed:87:69:5a:33:ca:51:45: > 06:ce:5e:5d:f1:ff:c1:5f:2f > Exponent: 65537 (0x10001) > Signature Algorithm: md5WithRSAEncryption > 74:a9:f7:02:52:51:86:c9:09:15:c9:2e:32:1b:29:81:b6:d0: > a9:7a:88:61:5a:fe:22:3e:6d:68:e3:71:64:e2:12:1f:5a:0e: > 35:54:19:b8:4a:e5:a1:70:27:0f:3b:99:ae:db:d1:bc:77:39: > 22:0a:4d:71:a9:08:ca:c4:e0:28:a6:a0:e4:bc:9d:56:c1:ad: > 49:4b:5c:70:b2:a7:e8:64:ef:fa:fa:c0:1c:89:92:63:c5:67: > 55:ab:d9:65:57:4b:a8:6e:59:a6:d3:4b:ff:9b:27:8b:0e:ea: > ac:71:de:6c:5d:97:c7:78:17:40:4b:03:79:81:1b:02:31:6c: > fa:01:4a:c2:e2:c2:d6:14:4c:ff:9a:1c:41:ed:14:c2:eb:b4: > f5:1b:db:06:d7:1f:e3:bc:69:d0:f7:d6:8e:13:db:7b:f1:15: > 5c:11:b9:18:56:6b:d3:0f:96:20:99:a3:19:01:83:9a:f2:65: > 4d:7d:6b:41:92:d2:d1:4d:40:74:b7:8b:a8:54:ba:bf:b0:04: > 0e:a0:45:5b:62:c1:0e:7b:48:7d:c8:96:62:99:50:e7:44:b1: > 8a:01:e0:ec:b7:42:6c:3d:52:16:70:3b:0f:e6:e3:31:8b:31: > ee:62:fd:fd:3c:94:90:04:05:99:7b:b2:c0:41:8f:92:05:db: > 46:a6:2d:ed:ba:e5:70:61:45:52:a4:f0:97:54:cf:75:9d:8b: > f9:89:f2:01:0e:7f:f7:b6:1f:1c:03:56:a6:cc:d0:00:99:b9: > f1:e3:6b:18:d5:69:46:38:a3:23:ba:f3:76:08:ff:02:bc:15: > df:91:67:6e:94:62:35:34:a2:fa:d3:33:01:da:00:b6:07:4c: > 89:7e:f3:98:dc:81:e5:0f:4a:19:ea:fe:91:02:3a:9d:22:25: > a9:38:f8:2f:91:ca:09:e1:6c:12:b2:68:a6:a2:af:8b:41:f7: > 61:e5:40:2f:98:60:18:10:90:af:55:50:8a:31:2d:17:82:d2: > 13:cf:27:5b:fa:c8:ee:74:e1:98:00:26:56:24:68:38:b4:e3: > 21:ee:3c:8b:16:32:72:93:fc:3b:0f:13:9a:b1:97:e8:6e:ca: > 33:00:ee:7b:30:7c:e2:e7:14:99:a0:5f:f1:f9:95:1f:fc:5c: > 17:79:33:2a:f1:fd:89:6e:50:d8:d7:8d:05:95:3f:11:72:c7: > 69:e8:0f:4c:82:7b:9d:26:86:04:60:b2:3b:24:76:4a:34:c6: > 87:ef:e6:e7:8b:53:98:de:f4:cc:d8:39:b2:2d:ea:09:a4:80: > f3:c2:d7:bd:6f:7b:7d:4c:35:b2:23:ca:56:fc:5b:6d:08:05: > 6b:11:bd:c6:4b:92:4f:46 > > >> On 27 Sep 2017, at 01:04, Kyle Hamilton > > wrote: >> >> openssl x509 -noout -text -in clientcertificate.pem >> >> You may need to extract the client certificate from wireshark, but you >> could also get it from openssl s_server. >> >> Specifically, that error message is suggesting that there's a message >> digest encoded into the certificate which is unknown to the trust >> path. >> >> Chances are, it's probably MD5. MD5 was broken a long time ago, and >> is no longer trustworthy. (SHA1 is also a possibility, but it was >> made unacceptable a lot more recently.) >> >> -Kyle H >> >> >> On Tue, Sep 26, 2017 at 8:56 AM, Stuart Marsden > > wrote: >>> Sorry how can I tell ? >>> >>> I can run a wireshark if necessary >>> >>> thanks >>> >>> >>>> On 26 Sep 2017, at 16:36, Wouter Verhelst >>>> > wrote: >>>> >>>> On 26-09-17 17:26, Stuart Marsden wrote: >>>>> [ssl:info] [pid 1611] SSL Library Error: error:0D0C50A1:asn1 >>>>> encoding routines:ASN1_item_verify:unknown message digest algorithm >>>> >>>> So which message digest algorithm is the client trying to use? >>>> >>>> -- >>>> Wouter Verhelst >>>> -- >>>> openssl-users mailing list >>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>>> >>> >>> >>> -- >>> openssl-users mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Wed Sep 27 12:41:34 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 27 Sep 2017 12:41:34 +0000 Subject: [openssl-users] Storing private key on tokens In-Reply-To: References: Message-ID: <8811B155-4016-4B43-BB05-B55AC507DE36@ll.mit.edu> AFAIK, at this point pkcs11 engine doesn't support key generation. The only viable options AFAIK are OpenSC (pkcs11-tool) and vendor-specific applications like yubico-piv-tool. Regards, Uri Sent from my iPhone > On Sep 27, 2017, at 08:23, Dmitry Belyavsky wrote: > > Hello, > > What is the most natural way to generate private keys using openssl but store them on a specific hardware tokens? Reading/writing is implemented via engine mechanism. > > I suppose that it should be added support of -outform ENGINE to the genpkey command, but do not understatnd how to deal with it after that. > > Thank you! > > -- > SY, Dmitry Belyavsky > -- > 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: smime.p7s Type: application/pkcs7-signature Size: 5801 bytes Desc: not available URL: From jqian at tibco.com Wed Sep 27 12:59:35 2017 From: jqian at tibco.com (Jason Qian) Date: Wed, 27 Sep 2017 08:59:35 -0400 Subject: [openssl-users] DH_generate_key Hangs Message-ID: Hi, Need some help, one of our application that hangs when calling DH_generate_key (openssl-0.9.8y). This occurs randomly under loaded condition. Not sure, if anyone know this issue ? Thanks Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jochen.Bern at binect.de Wed Sep 27 12:50:35 2017 From: Jochen.Bern at binect.de (Jochen Bern) Date: Wed, 27 Sep 2017 14:50:35 +0200 Subject: [openssl-users] Hardware client certificates moving to Centos 7 In-Reply-To: References: Message-ID: <32130166-1678-ebae-d3d0-9904c9146229@binect.de> On 09/27/2017 02:07 PM, Stuart Marsden wrote: > Is there a way a can install a version of openssl on a dedicated standalone > Centos 7 server which will support these phones? > That would be preferable to me than having to leave Centos 6 servers just > for this I don't know offhand which OpenSSL versions did away with MD5, but you *can* install an 0.9.8e (+ RHEL/CentOS backported security patches) straight off CentOS 7 repos: https://centos.pkgs.org/7/centos-x86_64/openssl098e-0.9.8e-29.el7.centos.3.x86_64.rpm.html (There's a 32bit version of the RPM, too, of course, if you need it.) Kind regards, -- Jochen Bern Systemingenieur www.binect.de -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4278 bytes Desc: S/MIME Cryptographic Signature URL: From dirkx at webweaving.org Wed Sep 27 12:51:45 2017 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Wed, 27 Sep 2017 14:51:45 +0200 Subject: [openssl-users] Storing private key on tokens In-Reply-To: References: Message-ID: <0D0B66AD-465A-43F7-87E7-4CED3D6D931D@webweaving.org> On 27 Sep 2017, at 14:22, Dmitry Belyavsky wrote: > What is the most natural way to generate private keys using openssl but store them on a specific hardware tokens? Reading/writing is implemented via engine mechanism. > > I suppose that it should be added support of -outform ENGINE to the genpkey command, but do not understatnd how to deal with it after that. The OpenSC tools integrate nicely (and the yubico toools too with a bit more fiddling). You typically end up with constructs like: ${OPENSSL} << EOM || exit 1 engine dynamic -pre SO_PATH:/Library/OpenSC/lib/engines/engine_pkcs11.so \ -pre ID:pkcs11 \ -pre LIST_ADD:1 -pre LOAD \ -pre MODULE_PATH:opensc-pkcs11.so \ \ XXX -engine pkcs11 -key slot_$SLOT-id_$KID -keyform engine YYYYYY EOM where ?XX? and ?YYY? are the openssl command and arguments. The slot information of existing keys does usually need OpenSC or similar; as there is no easy syntaxtic sugar to get access for the engine (AFAIK): set `pkcs11-tool --module /Library/OpenSC/lib/opensc-pkcs11.so --list-slots | grep Slot | grep SCM` SLOT=$2 set `pkcs15-tool --list-keys | grep ID` AID=$4 KID=$7 Dw. From Michael.Wojcik at microfocus.com Wed Sep 27 18:02:24 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 27 Sep 2017 18:02:24 +0000 Subject: [openssl-users] Hardware client certificates moving to Centos 7 In-Reply-To: <32130166-1678-ebae-d3d0-9904c9146229@binect.de> References: <32130166-1678-ebae-d3d0-9904c9146229@binect.de> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Jochen Bern > Sent: Wednesday, September 27, 2017 06:51 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Hardware client certificates moving to Centos 7 > > I don't know offhand which OpenSSL versions did away with MD5, but you > *can* install an 0.9.8e (+ RHEL/CentOS backported security patches) > straight off CentOS 7 repos: Ugh. No need for 0.9.8e (which is from, what, the early Industrial Revolution?). MD5 is still available in OpenSSL 1.0.2, assuming it wasn't disabled in the build configuration. I think Stuart is dealing with an OpenSSL build that had MD5 disabled in the Configure step. Heck, MD4 and MDC2 are still available in 1.0.2 - even with the default configuration, I believe. I'm looking at 1.0.2j here and it has GOST, MD4, MD5, MDC2, RIPEMD-60, SHA, SHA1, SHA-2 (all standard lengths), and Whirlpool. That's just for digests, obviously; but the point is the MD5 support is still there. And yes, 1.0.2j can handle certificates with md5WithRsaEncryption signatures. -- Michael Wojcik Distinguished Engineer, Micro Focus From Michael.Wojcik at microfocus.com Wed Sep 27 18:02:24 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 27 Sep 2017 18:02:24 +0000 Subject: [openssl-users] DH_generate_key Hangs In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jason Qian via openssl-users > Sent: Wednesday, September 27, 2017 07:00 > To: openssl-users at openssl.org > Subject: [openssl-users] DH_generate_key Hangs > Need some help,? one of our application that hangs when calling > DH_generate_key (openssl-0.9.8y). This occurs randomly under loaded condition.?? > Not sure, if anyone know this issue ? The issue is running OpenSSL 0.9.8, which has not been supported since 2015. DH_generate_key can use an engine (at least in supported versions of OpenSSL - I no longer have any 0.9.8 code around to check), so we really can't say what it might be doing in your application. But if it's using the default OpenSSL implementation, then if your DH parameters don't already include a private key, you'll end up generating random numbers. That can hang, if OpenSSL is using a blocking CPRNG source such as /dev/random. But you haven't provided nearly enough information to do more than speculate. What you need to do: 1. Upgrade to OpenSSL 1.0.2 (or possibly 1.1.0, but that has API changes and isn't an LTS release). There's really no point in proceeding unless you do so. Your application is broken if it's using 0.9.8. 2. If the problem still occurs, debug a hanging instance and find out where *exactly* it's hung. -- Michael Wojcik Distinguished Engineer, Micro Focus From Michael.Wojcik at microfocus.com Wed Sep 27 18:02:23 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 27 Sep 2017 18:02:23 +0000 Subject: [openssl-users] Storing private key on tokens In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Dmitry Belyavsky > Sent: Wednesday, September 27, 2017 06:22 > To: openssl-users at openssl.org > Subject: [openssl-users] Storing private key on tokens > What is the most natural way to generate private keys using openssl but store them on a specific hardware tokens? > Reading/writing is implemented via engine mechanism. The tokens / HSMs I've used don't let you generate a key somewhere else and install it on the token. They insist on doing the key generation locally. That is, after all, part of the point of using a token - the key never leaves it. Some tokens and HSMs support key backup and restore, e.g. Nitrokey HSM's DKEK share mechanism, but that's deliberately not open to "restoring" some arbitrary private key onto the device. So this wouldn't make much sense for the pkcs11 engine, even if PKCS#11 provided an API for it. -- Michael Wojcik Distinguished Engineer, Micro Focus From dirkx at webweaving.org Wed Sep 27 18:19:05 2017 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Wed, 27 Sep 2017 20:19:05 +0200 Subject: [openssl-users] Storing private key on tokens In-Reply-To: References: Message-ID: <58054950-D246-4374-95D0-42423A74F948@webweaving.org> > On 27 Sep 2017, at 20:02, Michael Wojcik wrote: > >> What is the most natural way to generate private keys using openssl but store them on a specific hardware tokens? >> Reading/writing is implemented via engine mechanism. > > The tokens / HSMs I've used don't let you generate a key somewhere else and install it on the token. They insist on doing the key generation locally. That is, after all, part of the point of using a token - the key never leaves it. I've found that the Feitian ePass2000's and the Yubico keys allow for importing of the private key. They do usually want the 'extra' flags to specify use: pkcs15-init --store-private-key .ssh/id_rsa-foo --auth-id 01 --key-usage sign,decrypt --label "ssh key of me at mydomain.com" and some fail silently when you do not provide these. Dw. From freemonj at gmail.com Wed Sep 27 18:57:04 2017 From: freemonj at gmail.com (Freemon Johnson) Date: Wed, 27 Sep 2017 14:57:04 -0400 Subject: [openssl-users] Hardware client certificates moving to Centos 7 In-Reply-To: References: <32130166-1678-ebae-d3d0-9904c9146229@binect.de> Message-ID: Not sure if this helps but the native installation for CentOS7 by default installs OpenSSL with FIPS mode compiled in which means deprecated algorithms such as MD5 and the like will not work. If you tried to generate a certificate you should have received an error or not have seen that algorithm in your certificate etc. As others have suggested you will have to end building a version of OpenSSL with FIPS mode disabled in order to use MD5 unless you can get a version from the Centos repo mirrors without FIPS. The default output from "openssl version" in CentOS7 OpenSSL 1.0.1e-fips 11 Feb 2013 On Wed, Sep 27, 2017 at 2:02 PM, Michael Wojcik < Michael.Wojcik at microfocus.com> wrote: > > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > > Of Jochen Bern > > Sent: Wednesday, September 27, 2017 06:51 > > To: openssl-users at openssl.org > > Subject: Re: [openssl-users] Hardware client certificates moving to > Centos 7 > > > > I don't know offhand which OpenSSL versions did away with MD5, but you > > *can* install an 0.9.8e (+ RHEL/CentOS backported security patches) > > straight off CentOS 7 repos: > > Ugh. No need for 0.9.8e (which is from, what, the early Industrial > Revolution?). MD5 is still available in OpenSSL 1.0.2, assuming it wasn't > disabled in the build configuration. I think Stuart is dealing with an > OpenSSL build that had MD5 disabled in the Configure step. > > Heck, MD4 and MDC2 are still available in 1.0.2 - even with the default > configuration, I believe. I'm looking at 1.0.2j here and it has GOST, MD4, > MD5, MDC2, RIPEMD-60, SHA, SHA1, SHA-2 (all standard lengths), and > Whirlpool. > > That's just for digests, obviously; but the point is the MD5 support is > still there. And yes, 1.0.2j can handle certificates with > md5WithRsaEncryption signatures. > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > > > -- > 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 Wed Sep 27 19:15:19 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 27 Sep 2017 15:15:19 -0400 Subject: [openssl-users] Hardware client certificates moving to Centos 7 In-Reply-To: References: <32130166-1678-ebae-d3d0-9904c9146229@binect.de> Message-ID: >> I don't know offhand which OpenSSL versions did away with MD5, but you >> *can* install an 0.9.8e (+ RHEL/CentOS backported security patches) >> straight off CentOS 7 repos: > > Ugh. No need for 0.9.8e (which is from, what, the early Industrial Revolution?). MD5 is still available in OpenSSL 1.0.2, assuming it wasn't disabled in the build configuration. I think Stuart is dealing with an OpenSSL build that had MD5 disabled in the Configure step. > > Heck, MD4 and MDC2 are still available in 1.0.2 - even with the default configuration, I believe. I'm looking at 1.0.2j here and it has GOST, MD4, MD5, MDC2, RIPEMD-60, SHA, SHA1, SHA-2 (all standard lengths), and Whirlpool. Some of those algorithms may still needed for some use cases. For example, Apple still ships (or used to ship until recently) some certificates that use MD2. They were present in iOS 7 and 8. Also see http://seclists.org/fulldisclosure/2013/Sep/184. I think the best OpenSSL can for now is allow those who don't need antique algorithms to disable them at compile time. Otherwise, OpenSSL is making policy decisions that may not work well for some folks. Jeff From freemonj at gmail.com Wed Sep 27 20:10:22 2017 From: freemonj at gmail.com (Freemon Johnson) Date: Wed, 27 Sep 2017 16:10:22 -0400 Subject: [openssl-users] Hardware client certificates moving to Centos 7 In-Reply-To: References: <32130166-1678-ebae-d3d0-9904c9146229@binect.de> Message-ID: FIPS mode is a policy decision in my opinion also but since RedHat prides itself in security e.g. SELinux, etc. I believe that is a RedHat decision as opposed to the OpenSSL community. The alternative would be to use a different Linux distro like Ubuntu, etc. which does not compile their OpenSSL with FIPS enabled natively to support legacy algorithms. *FYI I am not speaking on behalf of RedHat or OpenSSL.* This is all conjecture and my 2 cents :-) On Wed, Sep 27, 2017 at 3:15 PM, Jeffrey Walton wrote: > >> I don't know offhand which OpenSSL versions did away with MD5, but you > >> *can* install an 0.9.8e (+ RHEL/CentOS backported security patches) > >> straight off CentOS 7 repos: > > > > Ugh. No need for 0.9.8e (which is from, what, the early Industrial > Revolution?). MD5 is still available in OpenSSL 1.0.2, assuming it wasn't > disabled in the build configuration. I think Stuart is dealing with an > OpenSSL build that had MD5 disabled in the Configure step. > > > > Heck, MD4 and MDC2 are still available in 1.0.2 - even with the default > configuration, I believe. I'm looking at 1.0.2j here and it has GOST, MD4, > MD5, MDC2, RIPEMD-60, SHA, SHA1, SHA-2 (all standard lengths), and > Whirlpool. > > Some of those algorithms may still needed for some use cases. For > example, Apple still ships (or used to ship until recently) some > certificates that use MD2. They were present in iOS 7 and 8. Also see > http://seclists.org/fulldisclosure/2013/Sep/184. > > I think the best OpenSSL can for now is allow those who don't need > antique algorithms to disable them at compile time. Otherwise, OpenSSL > is making policy decisions that may not work well for some folks. > > Jeff > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jochen.Bern at binect.de Wed Sep 27 20:47:14 2017 From: Jochen.Bern at binect.de (Jochen Bern) Date: Wed, 27 Sep 2017 22:47:14 +0200 Subject: [openssl-users] Hardware client certificates moving to Centos 7 In-Reply-To: References: Message-ID: On 09/27/2017 10:10 PM, Michael Wojcik wrote: > On Behalf Of Jochen Bern > Sent: Wednesday, September 27, 2017 06:51 >> I don't know offhand which OpenSSL versions did away with MD5, but you >> *can* install an 0.9.8e (+ RHEL/CentOS backported security patches) >> straight off CentOS 7 repos > > Ugh. No need for 0.9.8e (which is from, what, the early Industrial Revolution?). You and I would probably be willing to compile version $CURRENT_STABLE ourselves if needed, but then again, a dedicated CentOS 6 server would likely be fine with us as well. I presume that Stuart has an auditor breathing down his neck and itching to tick "current OS release of chosen standard distribs, only reputable / vendor repos configured, updates installed in regular intervals, no sources used or compilers installed, paid-support-request- and sue-for-damages forms prefilled in the drawer" checkboxes. Kind regards, -- Jochen Bern Systemingenieur www.binect.de -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4278 bytes Desc: S/MIME Cryptographic Signature URL: From Michael.Wojcik at microfocus.com Wed Sep 27 21:12:44 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 27 Sep 2017 21:12:44 +0000 Subject: [openssl-users] Hardware client certificates moving to Centos 7 In-Reply-To: References: <32130166-1678-ebae-d3d0-9904c9146229@binect.de> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Jeffrey Walton > Sent: Wednesday, September 27, 2017 13:15 > To: OpenSSL Users > Subject: Re: [openssl-users] Hardware client certificates moving to Centos 7 > > > > > Heck, MD4 and MDC2 are still available in 1.0.2 - even with the default > configuration, I believe. I'm looking at 1.0.2j here and it has GOST, MD4, MD5, > MDC2, RIPEMD-60, SHA, SHA1, SHA-2 (all standard lengths), and Whirlpool. > > Some of those algorithms may still needed for some use cases. For > example, Apple still ships (or used to ship until recently) some > certificates that use MD2. They were present in iOS 7 and 8. Also see > http://seclists.org/fulldisclosure/2013/Sep/184. > > I think the best OpenSSL can for now is allow those who don't need > antique algorithms to disable them at compile time. Otherwise, OpenSSL > is making policy decisions that may not work well for some folks. Oh, definitely. I wasn't suggesting we should get rid of them. Just wanted to point out that it wasn't necessary to go back to a stone-age release of OpenSSL to have them. Though, as subsequent people pointed out, I did not account for FIPS mode. Why anyone would install a FIPS build by default is beyond me (particularly since the FIPS validation is so picky about OS versions and the like). Though, of course, the application using OpenSSL need not enable FIPS mode... -- Michael Wojcik Distinguished Engineer, Micro Focus From kgoldman at us.ibm.com Wed Sep 27 21:13:10 2017 From: kgoldman at us.ibm.com (Ken Goldman) Date: Wed, 27 Sep 2017 17:13:10 -0400 Subject: [openssl-users] Storing private key on tokens In-Reply-To: <58054950-D246-4374-95D0-42423A74F948@webweaving.org> References: <58054950-D246-4374-95D0-42423A74F948@webweaving.org> Message-ID: On 9/27/2017 2:19 PM, Dirk-Willem van Gulik wrote: > >> On 27 Sep 2017, at 20:02, Michael Wojcik >> >> The tokens / HSMs I've used don't let you generate a key somewhere >> else and install it on the token. They insist on doing the key >> generation locally. That is, after all, part of the point of using >> a token - the key never leaves it. > > I've found that the Feitian ePass2000's and the Yubico keys allow for > importing of the private key. They do usually want the 'extra' flags > to specify use: FWIW, the TPM hardware also permits key import. It does validate attributes, so users will know that the key was not generated on chip. From ch at coderhacks.com Wed Sep 27 22:02:17 2017 From: ch at coderhacks.com (ch) Date: Thu, 28 Sep 2017 00:02:17 +0200 Subject: [openssl-users] PKCS7 and RSA_verify Message-ID: Hello! I am working on a tool for verifying SMIME-messages. Because cms and smime is only able to verify base64 pkcs7-signatures I try to do it "manually" and I now have a problem with the signing-timestamp. Lets do an example: openssl smime -sign -md sha1? -in plain.txt? -inkey mykey -signer mycert? -noattr? -outform der | openssl asn1parse -inform der If I put plain.txt and the 128 byte signature (from asn1parse out of the pkcs7) into RSA_verify it works perfectly. Every call would produce the same signature-hexdump. But if I remove the -noattr the signature-value will be different every second and then RSA_verify it not working anymore. How can I handle this? Thanks! Chris From steve at openssl.org Wed Sep 27 23:06:45 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 27 Sep 2017 23:06:45 +0000 Subject: [openssl-users] PKCS7 and RSA_verify In-Reply-To: References: Message-ID: <20170927230645.GA9633@openssl.org> On Thu, Sep 28, 2017, ch wrote: > Hello! > > I am working on a tool for verifying SMIME-messages. > Because cms and smime is only able to verify base64 pkcs7-signatures > I try to do it "manually" and I now have a problem with the > signing-timestamp. > I'm not sure what you mean by "only able to verify base64 pkcs7-signatures" it can handle PEM and DER forms too. > Lets do an example: > > openssl smime -sign -md sha1? -in plain.txt? -inkey mykey -signer > mycert? -noattr? -outform der | openssl asn1parse -inform der > > If I put plain.txt and the 128 byte signature (from asn1parse out of > the pkcs7) into RSA_verify it works perfectly. > Every call would produce the same signature-hexdump. > > But if I remove the -noattr the signature-value will be different > every second and then RSA_verify it not working anymore. > > How can I handle this? > When you don't use attributes the signature is over performed over the content. If you use attributes then the signature is over the encoding of a bunch of attributes including a signing time and the digest of the content. Because the signing time changes the data being signed in the attributes changes too. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From ch at coderhacks.com Wed Sep 27 23:19:30 2017 From: ch at coderhacks.com (ch) Date: Thu, 28 Sep 2017 01:19:30 +0200 Subject: [openssl-users] PKCS7 and RSA_verify In-Reply-To: <20170927230645.GA9633@openssl.org> References: <20170927230645.GA9633@openssl.org> Message-ID: Hello! Thanks for the support. On 2017-09-28 01:06, Dr. Stephen Henson wrote: > On Thu, Sep 28, 2017, ch wrote: > >> Hello! >> >> I am working on a tool for verifying SMIME-messages. >> Because cms and smime is only able to verify base64 pkcs7-signatures >> I try to do it "manually" and I now have a problem with the >> signing-timestamp. >> > I'm not sure what you mean by "only able to verify base64 pkcs7-signatures" > it can handle PEM and DER forms too. If the pkcs-signature is binary encoded it is not working for verifiying a SMIME-message in my experience with smime or cms-smime on the console. I tried to convert the binary ones to base64 but that does not everytime the trick. > >> Lets do an example: >> >> openssl smime -sign -md sha1? -in plain.txt? -inkey mykey -signer >> mycert? -noattr? -outform der | openssl asn1parse -inform der >> >> If I put plain.txt and the 128 byte signature (from asn1parse out of >> the pkcs7) into RSA_verify it works perfectly. >> Every call would produce the same signature-hexdump. >> >> But if I remove the -noattr the signature-value will be different >> every second and then RSA_verify it not working anymore. >> >> How can I handle this? >> > When you don't use attributes the signature is over performed over the > content. If you use attributes then the signature is over the encoding of a > bunch of attributes including a signing time and the digest of the content. > Because the signing time changes the data being signed in the attributes > changes too. Would PKCS7_verify (or something else) handle that for me or do I need to consider that different content with RSA_verify? > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org Again, thanks for the support! chris From wouter.verhelst at fedict.be Thu Sep 28 09:23:10 2017 From: wouter.verhelst at fedict.be (Wouter Verhelst) Date: Thu, 28 Sep 2017 11:23:10 +0200 Subject: [openssl-users] PKCS7 and RSA_verify In-Reply-To: References: <20170927230645.GA9633@openssl.org> Message-ID: <564601db-ad81-7e01-8812-4f829acde533@fedict.be> On 28-09-17 01:19, ch wrote> If the pkcs-signature is binary encoded it is not working for verifiying > a SMIME-message in my experience with > smime or cms-smime on the console. I tried to convert the binary ones to > base64 but that does not everytime the trick. What you call "base64" is commonly known as "PEM" :-) You can get it to parse binary, but to do so you need to specify "-inform der". -- Wouter Verhelst From ch at coderhacks.com Thu Sep 28 09:28:51 2017 From: ch at coderhacks.com (ch) Date: Thu, 28 Sep 2017 11:28:51 +0200 Subject: [openssl-users] PKCS7 and RSA_verify In-Reply-To: <564601db-ad81-7e01-8812-4f829acde533@fedict.be> References: <20170927230645.GA9633@openssl.org> <564601db-ad81-7e01-8812-4f829acde533@fedict.be> Message-ID: <20bfd0d4-78c7-97c8-59ca-83a5edd99b3b@coderhacks.com> Hi! I thought the difference between PEM and DER is NOT ONLY a different encoding of the string? base64 vs. binary So to understand that clear please let me ask: If I convert a PEM-signature from base64 to binary then it is DER? Thanks Chris On 2017-09-28 11:23, Wouter Verhelst wrote: > On 28-09-17 01:19, ch wrote> If the pkcs-signature is binary encoded it > is not working for verifiying >> a SMIME-message in my experience with >> smime or cms-smime on the console. I tried to convert the binary ones to >> base64 but that does not everytime the trick. > What you call "base64" is commonly known as "PEM" :-) > > You can get it to parse binary, but to do so you need to specify > "-inform der". > From Jose.DiazdeGrenu at digi.com Thu Sep 28 15:07:42 2017 From: Jose.DiazdeGrenu at digi.com (Diaz de Grenu, Jose) Date: Thu, 28 Sep 2017 15:07:42 +0000 Subject: [openssl-users] FIPS Object Module 2.0, fipsalgtest.pl fails Message-ID: <0B2EBCD48D33654381E736352034C70C01A20EC7@dor-sms-xch01.digi.com> I am trying to validate the FIPS Object Module. I have built the test tools as specified in [1] Appendix B.1 and I have downloaded and extract the test vectors from [2]. At that point I run the following: perl fipsalgtest.pl --dir=/run/media/sda1/fips_tv/OSF_JN2859_OE46.results (where /run/media/sda1/fips_tv/OSF_JN2859_OE46.results is the path I extracted the test vectors to). That produces the following output: Running DSA2 tests Running DSA tests Running ECDSA2 tests Running RSA tests FATAL parse error processing line 4 FATAL RSAVTEST file processing error WARNING: error executing verify test SigGen15 ../test/fips_rsavtest "/run/media/sda1/fips_tv/OSF_JN2859_OE46.results/OSF_2859_OE46/RSA2/resp/SigGen15_186-3.tst" "/run/m edia/sda1/fips_tv/OSF_JN2859_OE46.results/OSF_2859_OE46/RSA2/resp/SigGen15_186-3.ver" Running RSA tests FATAL parse error processing line 4 FATAL RSAVTEST file processing error WARNING: error executing verify test SigGenPSS(0) ../test/fips_rsavtest -saltlen 0 "/run/media/sda1/fips_tv/OSF_JN2859_OE46.results/OSF_2859_OE46/RSA2/resp/SigGenPSS_18 6-3.tst" "/run/media/sda1/fips_tv/OSF_JN2859_OE46.results/OSF_2859_OE46/RSA2/resp/SigGenPSS_186-3.ver" Running RSA tests FATAL parse error processing line 4 FATAL RSAVTEST file processing error WARNING: error executing verify test SigGenPSS(62) ../test/fips_rsavtest -saltlen 62 "/run/media/sda1/fips_tv/OSF_JN2859_OE46.results/OSF_2859_OE46_RSA62_PSS/RSA2/resp/ SigGenPSS_186-3.tst" "/run/media/sda1/fips_tv/OSF_JN2859_OE46.results/OSF_2859_OE46_RSA62_PSS/RSA2/resp/SigGenPSS_186-3.ver" Running SHA tests Running SP800-90 DRBG tests Running HMAC tests Running CMAC tests Running AES tests Running Triple DES tests Running AES CCM tests Running AES GCM tests Running AES XTS tests Running ECDH Ephemeral Primitives Only tests ALGORITHM TEST VERIFY SUMMARY REPORT: Tests skipped due to missing files: 0 Algorithm test program execution failures: 0 Test comparisons successful: 223 Test comparisons failed: 0 Test sanity checks successful: 6 Test sanity checks failed: 0 Sanity check program execution failures: 3 ***TEST FAILURE*** What could be causing those errors? Some more information: * OpenSSL 1.0.2j-fips 26 Sep 2016 * ARM7 platform. * The fips_test_suite binary runs successfully ("All tests completed with 0 errors"). Thanks [1] User Guide for the OpenSSL FIPS Objet Module 2.0: https://www.openssl.org/docs/fips/UserGuide-2.0.pdf [2] Test vector tarball: https://www.openssl.com/testing/validation-2.0/testvectors/tv.tar.gz From marquess at openssl.com Thu Sep 28 15:23:06 2017 From: marquess at openssl.com (Steve Marquess) Date: Thu, 28 Sep 2017 11:23:06 -0400 Subject: [openssl-users] FIPS Object Module 2.0, fipsalgtest.pl fails In-Reply-To: <0B2EBCD48D33654381E736352034C70C01A20EC7@dor-sms-xch01.digi.com> References: <0B2EBCD48D33654381E736352034C70C01A20EC7@dor-sms-xch01.digi.com> Message-ID: <239540b0-9fd7-181f-d102-67e551c1f6a5@openssl.com> On 09/28/2017 11:07 AM, Diaz de Grenu, Jose wrote: > I am trying to validate the FIPS Object Module. > > I have built the test tools as specified in [1] Appendix B.1 and I have downloaded and extract the test vectors from [2]. > > At that point I run the following: > > perl fipsalgtest.pl --dir=/run/media/sda1/fips_tv/OSF_JN2859_OE46.results > > (where /run/media/sda1/fips_tv/OSF_JN2859_OE46.results is the path I extracted the test vectors to). > > That produces the following output: > > Running DSA2 tests > Running DSA tests > Running ECDSA2 tests > Running RSA tests > FATAL parse error processing line 4 > ... The FIPS module and test suite software (fipsalgtest.pl) are designed to work with exactly those algorithm tests relevant to the associated validations (#1747/2398/2473). The test labs generate a unique set of test vectors for each platform validation; those test vectors must be of the expected format to be successfully processed. Often they are not, either because they we incorrectly specified or due to errors. Figuring out such discrepancies can be lots of fun (not!). You will want to compare your test vectors with a known good set from http://openssl.com/testing/validation-2.0/testvectors/. Pick a recent set, as the format of the test vectors changes over time. Note that as a result frequent adjustment of fipsalgtest.pl is often necessary. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 301 874 2571 marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From stuart at myphones.com Thu Sep 28 17:25:18 2017 From: stuart at myphones.com (Stuart Marsden) Date: Thu, 28 Sep 2017 18:25:18 +0100 Subject: [openssl-users] Hardware client certificates moving to Centos 7 In-Reply-To: References: <32130166-1678-ebae-d3d0-9904c9146229@binect.de> Message-ID: Hi thanks for all the comments and suggestions, especially the ones I could understand centos 7 yum upgrade openssl version gives: OpenSSL 1.0.2k-fips 26 Jan 2017 it looks like echo 'LegacySigningMDs md5' >> /etc/pki/tls/legacy-settings allows the reading of Md5 Client certificates (which are still being installed in "not released yet" phones) That is a week of my life I wont get back thanks again Stuart > On 27 Sep 2017, at 19:02, Michael Wojcik wrote: > >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Jochen Bern >> Sent: Wednesday, September 27, 2017 06:51 >> To: openssl-users at openssl.org >> Subject: Re: [openssl-users] Hardware client certificates moving to Centos 7 >> >> I don't know offhand which OpenSSL versions did away with MD5, but you >> *can* install an 0.9.8e (+ RHEL/CentOS backported security patches) >> straight off CentOS 7 repos: > > Ugh. No need for 0.9.8e (which is from, what, the early Industrial Revolution?). MD5 is still available in OpenSSL 1.0.2, assuming it wasn't disabled in the build configuration. I think Stuart is dealing with an OpenSSL build that had MD5 disabled in the Configure step. > > Heck, MD4 and MDC2 are still available in 1.0.2 - even with the default configuration, I believe. I'm looking at 1.0.2j here and it has GOST, MD4, MD5, MDC2, RIPEMD-60, SHA, SHA1, SHA-2 (all standard lengths), and Whirlpool. > > That's just for digests, obviously; but the point is the MD5 support is still there. And yes, 1.0.2j can handle certificates with md5WithRsaEncryption signatures. > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > Dr Stuart Marsden Tel: +44 (0)1494 414100 Email: stuart at myPhones.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahesh116 at gmail.com Thu Sep 28 18:36:30 2017 From: mahesh116 at gmail.com (mahesh gs) Date: Fri, 29 Sep 2017 00:06:30 +0530 Subject: [openssl-users] Query regarding the SCTP events for DTLS connections Message-ID: Hi, We have an application which has SCTP connections we have secured the SCTP connections using the openssl DTLS. DTLS is working as expected other than the SCTP events. We use the API "BIO_new_dgram_sctp" to create a BIO objects and we register a callback function to openssl using API "BIO_dgram_sctp_notification_cb" to populate the SCTP events. I observe that openssl enables only authentication related events, do not enable any other events like association, shutdown etc. Code snippet from the API "BIO_new_dgram_sctp": event.sctp_authentication_event = 1; ret = setsockopt(fd, IPPROTO_SCTP, SCTP_EVENTS, &event, sizeof(struct sctp_event_subscribe)); if (ret < 0) { BIO_vfree(bio); return (NULL); } Is there any specific reason for just enabling the authentication events ? If yes, is there any way applications register for other events like shutdown, association etc. We have a requirement where based on the SCTP events application executes certain business logic. Thanks, Mahesh G S -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgm at htt-consult.com Thu Sep 28 19:04:53 2017 From: rgm at htt-consult.com (Robert Moskowitz) Date: Thu, 28 Sep 2017 15:04:53 -0400 Subject: [openssl-users] Hardware client certificates moving to Centos 7 In-Reply-To: References: <32130166-1678-ebae-d3d0-9904c9146229@binect.de> Message-ID: <1e127442-30bd-bae1-79ea-25a71f76cc26@htt-consult.com> On 09/28/2017 01:25 PM, Stuart Marsden wrote: > Hi > > thanks for all the comments and suggestions, especially the ones I > could understand > > centos 7 > yum upgrade > > openssl version gives: > > OpenSSL 1.0.2k-fips 26 Jan 2017 > > > it looks like > > echo 'LegacySigningMDs md5' >> /etc/pki/tls/legacy-settings > > allows the reading of Md5 Client certificates (which are still being > installed in "not released yet" phones) I am almost concerned this is being done intentionally to meet some security downgrade requirement. I the more reason to only use this cert to bootstrap your own cert for the actual management. > > That is a week of my life I wont get back > > thanks again > > Stuart > > >> On 27 Sep 2017, at 19:02, Michael Wojcik >> > > wrote: >> >>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >>> Of Jochen Bern >>> Sent: Wednesday, September 27, 2017 06:51 >>> To: openssl-users at openssl.org >>> Subject: Re: [openssl-users] Hardware client certificates moving to >>> Centos 7 >>> >>> I don't know offhand which OpenSSL versions did away with MD5, but you >>> *can* install an 0.9.8e (+ RHEL/CentOS backported security patches) >>> straight off CentOS 7 repos: >> >> Ugh. No need for 0.9.8e (which is from, what, the early Industrial >> Revolution?). MD5 is still available in OpenSSL 1.0.2, assuming it >> wasn't disabled in the build configuration. I think Stuart is dealing >> with an OpenSSL build that had MD5 disabled in the Configure step. >> >> Heck, MD4 and MDC2 are still available in 1.0.2 - even with the >> default configuration, I believe. I'm looking at 1.0.2j here and it >> has GOST, MD4, MD5, MDC2, RIPEMD-60, SHA, SHA1, SHA-2 (all standard >> lengths), and Whirlpool. >> >> That's just for digests, obviously; but the point is the MD5 support >> is still there. And yes, 1.0.2j can handle certificates with >> md5WithRsaEncryption signatures. >> >> -- >> Michael Wojcik >> Distinguished Engineer, Micro Focus >> >> >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > > > Dr Stuart Marsden > *Tel:* +44 (0)1494 414100 > *Email:* stuart at myPhones.com > > Altos Banner > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Fri Sep 29 17:16:19 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 29 Sep 2017 17:16:19 +0000 Subject: [openssl-users] Missing EVP_PKEY method to set engine? Message-ID: <03112499-1646-4625-BC93-D90C7315DD10@ll.mit.edu> Apologies in advance for cross-posting ? but I?m not sure which of the two mailing lists this belongs to. A key (say, private key) is loaded from the pkcs11 engine via privkey = ENGINE_load_private_key(engine, ); and this operation succeeds. However the resulting key handle has its engine == NULL. I looked for a method or a macro to explicitly set that value to the pointer to the engine that this key is bound to, but couldn?t find any. I define new methods such as pkcs11_pkey_rsa_decrypt(), and ?try to make OpenSSL aware of them via: ?? ????????EVP_PKEY_METHOD *orig_pmeth = EVP_PKEY_meth_find(EVP_PKEY_RSA); ?? EVP_PKEY_METHOD *pmeth = EVP_PKEY_meth_new(EVP_PKEY_RSA, EVP_PKEY_FLAG_AUTOARGLEN); ?? EVP_PKEY_meth_copy(pmeth, orig_pmeth); ?? EVP_PKEY_meth_get_decrypt(orig_pmeth, &pdecr_init, &pdecr); ?? EVP_PKEY_meth_set_decrypt(pmeth, pdecr_init, pkcs11_pkey_rsa_decrypt); ? And then there?s a function PKCS11_pkey_meths(ENGINE *e, EVP_PKEY_METHOD **pmethods, const int **nids, int nid) that assigns the above pmeth to *pmethods.? Is the above correct/sufficient? Somehow it seems to never invoke pkcs11_pkey_rsa_decrypt()? when it should be used. How can one set the EVP_PKEY->engine field in 1.1+? In ENGINE_set_pkey_meths(engine, pkey_meths) what should pkey_meths() actually be? Is it documented? When does libcrypto use ENGINE->pkey_meths methods instead of ?ENGINE->rsa_meth?? Who/what entity is supposed to invoke ENGINE->pkey_meths to retrieve the RSA methods block? Is it normal if on a key (EVP_PKEY *) loaded by an engine, engine ptr is NULL? And if not ? who/how should set those pointers to the correct value? -- Regards, Uri Blumenthal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5211 bytes Desc: not available URL: From Michael.Tuexen at lurchi.franken.de Fri Sep 29 20:25:13 2017 From: Michael.Tuexen at lurchi.franken.de (Michael Tuexen) Date: Fri, 29 Sep 2017 22:25:13 +0200 Subject: [openssl-users] Query regarding the SCTP events for DTLS connections In-Reply-To: References: Message-ID: <7D3D8A42-DAB1-4812-8B42-5A1CCFBEFA5C@lurchi.franken.de> > On 28. Sep 2017, at 20:36, mahesh gs wrote: > > Hi, > > We have an application which has SCTP connections we have secured the SCTP connections using the openssl DTLS. DTLS is working as expected other than the SCTP events. > > We use the API "BIO_new_dgram_sctp" to create a BIO objects and we register a callback function to openssl using API "BIO_dgram_sctp_notification_cb" to populate the SCTP events. I observe that openssl enables only authentication related events, do not enable any other events like association, shutdown etc. > > Code snippet from the API "BIO_new_dgram_sctp": > > event.sctp_authentication_event = 1; > > ret = > setsockopt(fd, IPPROTO_SCTP, SCTP_EVENTS, &event, > sizeof(struct sctp_event_subscribe)); > if (ret < 0) { > BIO_vfree(bio); > return (NULL); > } > > Is there any specific reason for just enabling the authentication events ? The authentication events are needed by the DTLS implementation and are therefore enabled by it. Other events have to be subscribed by the application. See https://github.com/nplab/DTLS-Examples/blob/master/src/dtls_sctp_echo.c for an example. Best regards Michael > > If yes, is there any way applications register for other events like shutdown, association etc. We have a requirement where based on the SCTP events application executes certain business logic. > > Thanks, > Mahesh G S > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From vieuxtech at gmail.com Sat Sep 30 23:27:31 2017 From: vieuxtech at gmail.com (Sam Roberts) Date: Sat, 30 Sep 2017 16:27:31 -0700 Subject: [openssl-users] PKCS7 and RSA_verify In-Reply-To: <20bfd0d4-78c7-97c8-59ca-83a5edd99b3b@coderhacks.com> References: <20170927230645.GA9633@openssl.org> <564601db-ad81-7e01-8812-4f829acde533@fedict.be> <20bfd0d4-78c7-97c8-59ca-83a5edd99b3b@coderhacks.com> Message-ID: On Thu, Sep 28, 2017 at 2:28 AM, ch wrote: > Hi! > > I thought the difference between PEM and DER is NOT ONLY a different > encoding of the string? > base64 vs. binary > > So to understand that clear please let me ask: > If I convert a PEM-signature from base64 to binary then it is DER? Yes. Well, technically it could be BER as well, but the main point is PEM is just a wrapper to transport binary via email safe text, and you can unwrap it if you want. PEM also includes a header, so you know if the object is a cert, a key, an encrypted message, etc, meta-data which is not known if you just have the binary chunk. > > Thanks > Chris > > On 2017-09-28 11:23, Wouter Verhelst wrote: >> >> On 28-09-17 01:19, ch wrote> If the pkcs-signature is binary encoded it >> is not working for verifiying >>> >>> a SMIME-message in my experience with >>> smime or cms-smime on the console. I tried to convert the binary ones to >>> base64 but that does not everytime the trick. >> >> What you call "base64" is commonly known as "PEM" :-) >> >> You can get it to parse binary, but to do so you need to specify >> "-inform der". >> > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users