Re: [openssl-users] Is RDRAND the default engine in OpenSSL 1.1.0?

On Fri, Jul 28, 2017 at 3:53 PM, Salz, Rich wrote: >> I thought RDRAND was disabled as the default random engine since >> 1.0.1f. Has that changed in OpenSSL 1.1.0? > > No. Do "git grep ENGINE_set_default_RAND" Ack, thanks. I wonder where that's coming from for 1.1.0.

[openssl-users] Is RDRAND the default engine in OpenSSL 1.1.0?

I thought RDRAND was disabled as the default random engine since 1.0.1f. Has that changed in OpenSSL 1.1.0? Related, see: * https://stackoverflow.com/q/45370852/608639 * http://seclists.org/fulldisclosure/2013/Dec/99 *

Re: [openssl-users] Cant get the subjectALtName inot the root cert

On Thu, Aug 17, 2017 at 6:30 PM, Robert Moskowitz wrote: > I guess I am making progress. I am not getting SAN into the root cert. my > cnf has in it: > > [ req ] > # Options for the `req` tool (`man req`). > default_bits= 2048 > prompt = no >

Re: [openssl-users] Implementing deprecation of commonname and emailaddress

>> When you see a name like "example.com" in the CN, its usually a CA >> including a domain name and not a hostname. > > That's nonsense. If a certificate is issued under CA/B policies, and CN=example.com but it _lacks_ SAN=example.com, then its a not a hostname and it should not be matched. I'm

Re: [openssl-users] Implementing deprecation of commonname and emailaddress

On Thu, Aug 17, 2017 at 11:34 AM, Erwann Abalea <erwann.aba...@docusign.com> wrote: > >> Le 17 août 2017 à 17:26, Jeffrey Walton <noloa...@gmail.com> a écrit : >> >>>> When you see a name like "example.com" in the CN, its usually a CA >>>&g

Re: [openssl-users] Throwing in the towel on ENV for DN

> It is coming down that I would need a unique cnf for each cert type, rather > than one per signing CA. Things just don't work well without prompting or > very consistent DN content. So I am going to pull most of my. ENV. I am > leaving it in for dir and SAN. > > I feel it is a bug that if in

Re: [openssl-users] Dumb question about DES

On Thu, May 11, 2017 at 2:13 PM, Scott Neugroschl wrote: > OK. Are the 3DES CBC ciphers still part of DEFAULT? >From OpenSSL 1.0.1t: $ openssl ciphers "DEFAULT" ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-

Re: [openssl-users] Build from source; library not found?

On Sat, May 20, 2017 at 7:10 AM, Hiran Chaudhuri wrote: > Am 19-May-2017 00:36:18 +0200 schrieb openssl-us...@dukhovni.org: > >> hiran.chaudhuri> Now this is interesting. Yes, openssl can find both the >> libraries >> hiran.chaudhuri> libssl and libcrypto. Would that

Re: [openssl-users] Cannot find SSL_CTX_get0_param in libssl library

On Sun, May 28, 2017 at 2:59 AM, Mohit Batra wrote: > Hello All, > > I am trying to compile / install a utility from Source on CentOS that > utilizes OpenSSL 1.1.0 (latest version) . However, I get the following > error: > > configure: WARNING: Cannot find SSL_CTX_get0_param

Re: [openssl-users] Build from source; library not found?

On Sun, May 28, 2017 at 5:16 PM, Hiran Chaudhuri wrote: > It seems I misread the referenced documentation the first time. > > This stuff contains the answer, it just was not clear to me that also works > on Linux. >

Re: [openssl-users] Cannot find SSL_CTX_get0_param in libssl library

On Sun, May 28, 2017 at 5:25 PM, Salz, Rich wrote: >> We still don't know what use case is being represented by omitting the >> RPATH in the OpenSSL build. > > Because only one program, apps/openssl, presumably needs rpath. But that > doesn't solve the problem for *external

[openssl-users] OpenSSL and RPATH's (was: Cannot find SSL_CTX_get0_param in libssl library)

On Sun, May 28, 2017 at 5:31 PM, Salz, Rich wrote: >> The openssl program will use the wrong libssl.so and libcrypto.so. > > Yes, got it. > > But that's small potatoes compared to everyone else finding the wrong shared > library, and just saying "use rpath" doesn't help all

Re: [openssl-users] 1st time through, only -- "Can't open root/database.attr for reading, No such file or directory" ?

> but the process STARTS with an apparently non-fatal error ... > > Using configuration from /home/sec/newCA/openssl.cnf > Can't open root/database.attr for reading, No such file or directory > 140013244086016:error:02001002:system >

Re: [openssl-users] 1st time through, only -- "Can't open root/database.attr for reading, No such file or directory" ?

On Sun, Jun 4, 2017 at 7:56 PM, PGNet Dev <pgnet@gmail.com> wrote: > On 6/4/17 4:51 PM, Jeffrey Walton wrote: >>> >>> but the process STARTS with an apparently non-fatal error ... >>> >>> Using configuration from /home/sec/newCA/openssl.c

Re: [openssl-users] 1st time through, only -- "Can't open root/database.attr for reading, No such file or directory" ?

On Sun, Jun 4, 2017 at 8:57 PM, Jeffrey Walton <noloa...@gmail.com> wrote: > On Sun, Jun 4, 2017 at 7:56 PM, PGNet Dev <pgnet@gmail.com> wrote: >> On 6/4/17 4:51 PM, Jeffrey Walton wrote: >>>> >>>> but the process STARTS with an apparently

Re: [openssl-users] Problem in connecting to Java (Tomcat) server with ECDHE ciphers

On Sun, Jun 4, 2017 at 1:01 AM, Pravesh Rai wrote: > Hi, > > Even though I've disabled SSLvX protocols on both - client (openssl-1.0.2k) > & server (Java 1.8 with Tomcat), still getting following handshake error, > while executing: > > "openssl s_client -connect a.b.c.d:

Re: [openssl-users] OpenSSL and RPATH's (was: Cannot find SSL_CTX_get0_param in libssl library)

> RPATHs have advantages, but they have some major issues, too. For > instance, if for whatever reason you need to move files around so that > things are stored in a different location, suddenly you'll need to > recompile everything -- because the RPATH is a hardcoded location of the > library in

Re: [openssl-users] Trusting certificates with the same subject name and overlapping validity periods

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,

Re: [openssl-users] ca md too weak

On Fri, Oct 6, 2017 at 12:22 PM, Fabrice Delente wrote: > OK, I understand, thanks for your answer! I'll look into building > openvpn 2.4.3 from source. I believe you only have to set Fedora's security policy to allow MD5. That is covered in the Fedora wiki page you were

Re: [openssl-users] ca md too weak

> Until two days ago I used OpenVPN to connect to my workplace, on a > non-security sensitive tunnel (just for convenience). > > However, OpenSSL updated on my machine (Fedora 26), and now the > certificate is rejected: > > ... > routines:SSL_CTX_use_certificate:ca md too weak > Fri Oct 6

Re: [openssl-users] DH_generate_key Hangs

>> You should avoid calls to RAND_poll altogether on Windows. Do so by >> explicitly seeding the random number generator yourself. > > As a starting point, try something like this: > > - > static ENGINE *rdrand; > > void init_prng(void) { > /* Try to seed the PRNG with the Intel RDRAND

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

Re: [openssl-users] Problem with DER private key file into openssl ca

> openssl req -outform $format -config $cadir/openssl-root.cnf -set_serial > 0x$(openssl rand -hex $sn)\ > -inform $format -key private/ca.key.$format -subj "$DN"\ > -new -x509 -days 7300 -sha256 -extensions v3_ca -out > certs/ca.cert.$format > > unable to load Private Key >

Re: [openssl-users] DH_generate_key Hangs

On Thu, Oct 5, 2017 at 2:55 PM, Jason Qian via openssl-users wrote: > Thanks Michael, > > I saw a lot of discussion for this issue on, > >https://mta.openssl.org/pipermail/openssl-dev/2015-July/002210.html > > Not sure if openSSL has a workaround or

Re: [openssl-users] DH_generate_key Hangs

On Thu, Oct 5, 2017 at 3:27 PM, Jason Qian via openssl-users wrote: > Compared code of RAND_poll(void) between 1.0.1 and 1.0.2 and it seems no > change I believe it was fixed earlier than that. Also see https://rt.openssl.org/Ticket/Display.html?id=2100=guest=guest As

Re: [openssl-users] Generating CSR based on an x25519 public key

On Mon, Oct 23, 2017 at 6:47 PM, Kyle Hamilton wrote: > Out of curiosity, what are the algorithm identifiers for X25519 and Ed25519? > The ones I am aware of are available in http://tools.ietf.org/html/draft-josefsson-pkix-newcurves. Jeff -- openssl-users mailing list To

Re: [openssl-users] Lattice Ciphers

On Mon, Dec 18, 2017 at 1:38 AM, Colony.three via openssl-users wrote: > > G**gle's Eric Schmidt says, "If you have something that you don't want > anyone to know, maybe you shouldn't be doing it in the first place. This is > a profoundly undemocratic attitude. What

Re: [openssl-users] Generating CSR based on an x25519 public key

On Sat, Oct 21, 2017 at 9:38 AM, Codarren Velvindron wrote: > https://tls13.crypto.mozilla.org is using : The connection to this site is > encrypted and authenticated using a strong protocol (TLS 1.3), a strong key > exchange (X25519), and a strong cipher (AES_128_GCM).

Re: [openssl-users] How to respond to TLS heartbeat in openssl

On Fri, Dec 22, 2017 at 1:32 AM, Keshava Krishna Bhat K wrote: > Ok, I got to know that > openssl version -a gives out the flags used while building openssl. > so the output of this was > > OpenSSL 1.0.2g 1 Mar 2016 > built on: reproducible build, date unspecified >

Re: [openssl-users] CMAC Authentication

On Mon, Jan 15, 2018 at 8:22 AM, Rol Phil wrote: > Hello all, > > I have been using to tag data with an example I had found. > However when it comes to authenticate/decrypt a tag with given AES key I > could not find examples. > using cmac.h or evp.h. > Can anybody help me

Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

On Sun, Jan 21, 2018 at 5:59 PM, Viktor Dukhovni <openssl-us...@dukhovni.org> wrote: > > >> On Jan 21, 2018, at 2:40 PM, Jeffrey Walton <noloa...@gmail.com> wrote: >> >>> OpenSSL interprets the "extendedKeyUsage" extension in CA certificates >&g

Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

On Sun, Jan 21, 2018 at 1:31 PM, Viktor Dukhovni wrote: > > ... > OpenSSL interprets the "extendedKeyUsage" extension in CA certificates > as a restriction on the allowed extended key usages of leaf certificates > that can be issued by that CA. > > You should typically

Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

On Mon, Jan 22, 2018 at 1:44 AM, Gladewitz, Robert via openssl-users wrote: > > Thank you all for all the answers. > The problem is that Cisco prescribes the attributes. > ... > > Unfortunately, the Cisco CUCM telephone systems do not seem to accept > certificates

Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

On Sun, Jan 21, 2018 at 6:23 PM, Viktor Dukhovni <openssl-us...@dukhovni.org> wrote: > > >> On Jan 21, 2018, at 6:04 PM, Jeffrey Walton <noloa...@gmail.com> wrote: >> >> Maybe OpenSSL should allow users to choose between IETF issuing >> policies and CA/Bro

Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

On Mon, Jan 22, 2018 at 2:50 PM, Viktor Dukhovni wrote: > > >> On Jan 22, 2018, at 12:07 PM, Gladewitz, Robert via openssl-users >> wrote: >> >> the problem is, that i cant change the cisco implementation :-(. > > YOU DO NOT need to change

Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

On Mon, Jan 22, 2018 at 9:01 PM, Salz, Rich via openssl-users wrote: > > > Here's the standards OpenSSL claims to implement: > > Read the whole text. It doesn’t say anything like “claims to implement.” My bad. Here's the corrected text: This page is a partial

Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

On Mon, Jan 22, 2018 at 9:27 PM, Salz, Rich wrote: > ➢ I don't see CA/Browser Forums listed, but I do see RFC 3280 listed. > > The page also says it’s “casually maintained.” Feel free to create a PR on > openssl/web repo. :) > > IETF RFC’s aren’t perfect; that’s why there are

Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

On Mon, Jan 22, 2018 at 10:04 PM, Viktor Dukhovni <openssl-us...@dukhovni.org> wrote: > > >> On Jan 22, 2018, at 9:39 PM, Jeffrey Walton <noloa...@gmail.com> wrote: >> >> If OpenSSL want to change the standard so that it aligns with the >> project's

Re: [openssl-users] WG: TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

On Tue, Jan 23, 2018 at 12:43 PM, Viktor Dukhovni wrote: > > >> On Jan 23, 2018, at 7:31 AM, Gladewitz, Robert via openssl-users >> wrote: >> >> Despite being wrong it is also absolutely irrelevant, because FreeRADIUS >> retrieves the

Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

On Sun, Jan 21, 2018 at 6:38 PM, Salz, Rich via openssl-users wrote: > ➢ The sensible thing at this point is to publish an update to RFC5280 > that accepts reality. > > Yes, and there’s an IETF place to do that if anyone is interested; see the > LAMPS working

Re: [openssl-users] WG: TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

On Tue, Jan 23, 2018 at 4:33 PM, Salz, Rich wrote: > On Tue, Jan 23, 2018 at 3:45 PM, Salz, Rich wrote: > > ➢ The docs have _not_ changed: > https://www.openssl.org/docs/standards.html. > > > > Nor is there any need for that page to change.

Re: [openssl-users] WG: TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

On Tue, Jan 23, 2018 at 3:45 PM, Salz, Rich wrote: > ➢ The docs have _not_ changed: > https://www.openssl.org/docs/standards.html. > > Nor is there any need for that page to change. READ WHAT IT SAYS. I'm surprised you are arguing against clear documentation on behaviors.

What option is not recognized by OpenSSL 1.1.1d?

I'm trying to convert some scripts from OpenSSL 1.0.2 to OpenSSL 1.1.1d. Configure is dying: * Unsupported options: no-comp --prefix=/home/jwalton/tmp/build-test --libdir=/home/jwalton/tmp/build-test/lib According to INSTALL at https://github.com/openssl/openssl/blob/master/INSTALL, all

bn_ops not being used in Android recipes

Hi Everyone, I have a custom 15-android.conf that is used with a custom setenv-android.sh. setenv-android.sh sets the environment and exports the necessary variables for a cross-compile. 15-android.conf was copied from the OpenSSL library, and then modified to avoid some problems with the one

<    3   4   5   6   7   8