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

[Jeffrey Walton]

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. Maybe
Dropbox is providing vendor patches.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

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
* 
https://software.intel.com/en-us/blogs/2014/10/03/changes-to-rdrand-integration-in-openssl
* https://trac.torproject.org/projects/tor/ticket/10402
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

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
> distinguished_name  = req_distinguished_name
> string_mask = utf8only
> req_extensions  = req_ext
>
> [ req_ext ]
> #subjectAltName = email:$ENV::adminemail
> #subjectAltName = email:ad...@htt-consult.com
> subjectAltName = IP:192.168.24.1
>
> I tried all three above alternatives for SAN.  No SAN in the root cert
> created with:
>
> openssl req -config openssl-root.cnf -key private/ca.key.pem \
>   -new -x509 -days 7300 -sha256 -extensions v3_ca -out certs/ca.cert.pem
>
> Thanks for any insight.
>
> This type of cnf worked for creating a CSR and with the copy option the SAN
> made it into the cert.

It looks a bit unusual for a Root CA.

As far as signing the CSR, you need

copy_extensions = copy

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

>> 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 aware of OpenSSL's behavior in the matter. But OpenSSL does not
understand issuing policies so its easy to confuse.

Forgive me if OpenSSL is now imbued with knowledge of issuing policies
and how matching should occur outside of the RFCs.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

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
>>>> 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.
>
> Such a certificate would be mis-issued and be revoked immediately. CN MUST be 
> an FQDN (or a wild carded FQDN, or an IP address), and a copy of the value in 
> CN MUST be present in the SAN extension.

Oh, you would have some fun watching how various user agents handle
that scenario. For your first stop, check out how OpenSSL handles it.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

> 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 'prompt = no' or -batch, if a DN object is
> empty (size 0), it should just be dropped.  This is not an error condition.

If this is a private PKI, then you can do things like that.

But I believe you need a distinguished name if you are following the
RFCs. Maybe you can modify your script to stuff the principal name
from the SAN in the DN somewhere.

> Next steps:
>
> complete basic setup for ecdsa pki and 802.1AR leaf.  Publish on my website.
> Write up 'lessons learned' and post it here.

I think there's a separate RFC or draft for 802.1AR, but I have not read it.

Maybe part of the pain point is, OpenSSL is not aware of it. Its just
using RFC 5280 (and to some extent, 6125).

Maybe you should stop using the command line tools and code something
up in C. Once you hit your stride using the C APIs, its easy to crank
out certificates the way you want them.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Dumb question about DES

[Jeffrey Walton]

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-
SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SH
A:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:DHE-D
SS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DS
S-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-S
HA:DHE-DSS-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM
-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA
:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA2
56-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GC
M-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128
-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA
:SRP-AES-128-CBC-SHA:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DH
E-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128
-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAME
LLIA128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RS
A-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES
128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:SEED-SHA:CAMELLIA128-SHA
:PSK-AES128-CBC-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:
ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:PSK-RC4-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE
-ECDSA-DES-CBC3-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:SRP-3
DES-EDE-CBC-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:ECDH-RSA-DES-CBC3
-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

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 imply that rpath is only
>> a setting
>> hiran.chaudhuri> for application (executables) but not for shared
>> libraries?
>> hiran.chaudhuri> In that case the test I tried would be totally
>> meaningless.
>>
>> Yes, that's correct.
>
> NO, it is not correct, shared libraries also have rpaths for their
> own dependencies. And when building OpenSSL for installation in
> non-default locations (not /usr/lib and the like) the libraries
> should have an rpath.
>
> It would sound logical. But how could I then enforce the runpath to be set
> in the libraries?

https://wiki.openssl.org/index.php/Compilation_and_Installation#Using_RPATHs.

I've never understood the use case - build a new/updated openssl,
compile time link against the new one, and then runtime link against
the old one.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

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 in libssl library. TLS
> hostname verification will not be available.
>
> Kindly help me out on this error.

When you build OpenSSL and your program, use an RPATH. Also see
https://wiki.openssl.org/index.php/Compilation_and_Installation#Using_RPATHs
.

We still don't know what use case is being represented by omitting the
RPATH in the OpenSSL build. Building OpenSSL with new library, but
runtime link to old library after installation makes no sense to most
users.

You can probably do it using LD_LIBRARY_PATH, but RPATHs are easier.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

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.
> https://wiki.openssl.org/index.php/Compilation_and_Installation#Using_RPATHs.
>
> With that, the libraries have run paths that show the correct target
> directories. Thanks to all for the hint.

Arg... I consider confusing text a documentation bug.

Is this better:
https://wiki.openssl.org/index.php/Compilation_and_Installation#Using_RPATHs
?

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

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 applications* that need to find 
> OpenSSL in a different place, does it?
>

Without RPATH's (or some other mechanism, like making openssl a script
that sets LD_LIBRARY_PATH), libssl.so will use the wrong libcrypto.so.
The openssl program will use the wrong libssl.so and libcrypto.so.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

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 those others.

OK, thanks.

So what are the problems here that need to be addressed? I think I
know some of them:

 1. Build OpenSSL with an RPATH if installed in non-system location
 2. Build user program with an RPATH if OpenSSL installed in non-system location
 3. Use another mechanism when Linux RATH not available (OS X, Solaris, friends)
 4. External build tools like Autotools and Cmake

Are there others?

OpenSSL build system should fix problem (1), like it does with BSDs.
The project should lead by example.

For (2) and (3), I think the best that can be done is (a) lead by
example as in (1); (b) ensure things like libcrypto.pc and libssl.pc
are up-to-date; and and (c) educate users. I realize the problems with
(c). If RTFM was going to work, then it would have happens in the last
50 years or so.

There's not much you can do with(4). They pick shitty flags, and they
are always going to be a problem. I advise *not* to build OpenSSL with
them, but Fan Boi's will still flock to them.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

> 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 
> library:fopen::crypto/bio/bss_file.c:74:fopen('root/database.attr','r')
> 140013244086016:error:2006D080:BIO routines:BIO_new_file:no such 
> file:crypto/bio/bss_file.c:81:

This usually indicates the OpenSSL conf file cannot be found. Its odd
that "Using configuration from /home/sec/newCA/openssl.cnf" is
reported.

Maybe you can try `OPENSSL_CONF=/home/sec/newCA/openssl.cnf `
to isolate the issue (or maybe rule out its not a conf file problem).

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

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.cnf
>>>  Can't open root/database.attr for reading, No such file or
>>> directory
>>>  140013244086016:error:02001002:system
>>> library:fopen::crypto/bio/bss_file.c:74:fopen('root/database.attr','r')
>>>  140013244086016:error:2006D080:BIO routines:BIO_new_file:no such
>>> file:crypto/bio/bss_file.c:81:
>>
>>
>> This usually indicates the OpenSSL conf file cannot be found. Its odd
>> that "Using configuration from /home/sec/newCA/openssl.cnf" is
>> reported.
>>
>> Maybe you can try `OPENSSL_CONF=/home/sec/newCA/openssl.cnf `
>> to isolate the issue (or maybe rule out its not a conf file problem).
>
>
> The message above doesn't indicate that openssl.cnf can't be found.  In fact
> it explcitly states that it IS found and IS using it
>
>>>  Using configuration from /home/sec/newCA/openssl.cnf
>
> It's the same openssl.cnf used in all the PRIOR steps, with not problem
> whatsoever.
>
> Rather it's
>
>>>  Can't open root/database.attr for reading, No such file or
>>> directory
>
> that's not found.
>
> I've found that if I simply
>
> touch root/database.attr
> touch intermediate/database.attr
>
> as already's been done with
>
> touch root/database
> touch intermediate/database

Oh, I was not aware you were skipping steps. I guess that explains the
unusual results.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

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 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
>>>> library:fopen::crypto/bio/bss_file.c:74:fopen('root/database.attr','r')
>>>>  140013244086016:error:2006D080:BIO routines:BIO_new_file:no such
>>>> file:crypto/bio/bss_file.c:81:
>>>
>>>
>>> This usually indicates the OpenSSL conf file cannot be found. Its odd
>>> that "Using configuration from /home/sec/newCA/openssl.cnf" is
>>> reported.
>>>
>>> Maybe you can try `OPENSSL_CONF=/home/sec/newCA/openssl.cnf `
>>> to isolate the issue (or maybe rule out its not a conf file problem).
>>
>>
>> The message above doesn't indicate that openssl.cnf can't be found.  In fact
>> it explcitly states that it IS found and IS using it
>>
>>>>  Using configuration from /home/sec/newCA/openssl.cnf
>>
>> It's the same openssl.cnf used in all the PRIOR steps, with not problem
>> whatsoever.
>>
>> Rather it's
>>
>>>>  Can't open root/database.attr for reading, No such file or
>>>> directory
>>
>> that's not found.
>>
>> I've found that if I simply
>>
>> touch root/database.attr
>> touch intermediate/database.attr
>>
>> as already's been done with
>>
>> touch root/database
>> touch intermediate/database
>
> Oh, I was not aware you were skipping steps. I guess that explains the
> unusual results.

BTW, I believe you are also supposed to add an initial serial number.
Something like:

echo "0" > serialno.txt

Check your conf file for the filename.

(The information is somewhere in the docs. It may be in the
Certificates HOWTO or the CA HOWTO).

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

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: -msg -debug -cipher
> ECDHE-ECDSA-AES256-GCM-SHA384"
>

GCM mode is a TLS 1.2 cipher. It looks like Java 8 enables it by
default; cf. 
https://blogs.oracle.com/java-platform-group/jdk-8-will-use-tls-12-as-default.

Maybe something like:

openssl s_client -connect www.example.com:443 -tls1_2 -servername
www.example.com

The command uses SNI and TLS 1.2, which is pretty much standard
practice nowadays.

If that does not do it, then maybe you can use SSLscan to identify the
protocols and cipher suites the server supports.
https://github.com/rbsec/sslscan

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

> 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 use. This is very confusing, and not something that an
> average developer will expect.
>
> There is usually no need to hardcode the location of the library in use,
> provided the SONAME is configured correctly. Surprise surprise, OpenSSL
> actually does that right:
>
> wouter@gangtai:~$ objdump -p /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
> |grep SONAME
>   SONAME   libssl.so.1.0.2
> wouter@gangtai:~$ objdump -p /usr/lib/x86_64-linux-gnu/libssl.so.1.1
> |grep SONAME
>   SONAME   libssl.so.1.1
>
> There is no way that ld.so will load libssl1.1 for an application that
> is compiled against libssl.so with an SONAME of libssl.1.0.2 -- unless,
> of course, you do things like muck about with RPATH and point it to the
> wrong version of the library. In that case, you broke it, you get to
> keep both pieces.

The OpenSSL I build from sources is located in /usr/local. The gear
from /usr/local is first on-path.

This is what happens on Ubuntu 16.10:

$ /usr/bin/openssl errstr 0x3208408D
/usr/bin/openssl: /usr/local/lib/libssl.so.1.0.0: no version
information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libssl.so.1.0.0: no version
information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libssl.so.1.0.0: no version
information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version
information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version
information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version
information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version
information available (required by /usr/bin/openssl)
/usr/bin/openssl: relocation error: /usr/bin/openssl: symbol
COMP_zlib_cleanup, version OPENSSL_1.0.0 not defined in file
libcrypto.so.1.0.0 with link time reference

This is what happens on Fedora release 25:

$ /usr/bin/openssl errstr 0x3208408D
error:3208408D:lib(50):func(132):reason(141)

It seems to me SONAME's just don't work as expected.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

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
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] ca md too weak

[Jeffrey Walton]

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 provided.

There's no need to download and build a new OpenSSL and OpenVPN.
However, if you to take that path, then see
https://stackoverflow.com/q/38985889/608639.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] ca md too weak

[Jeffrey Walton]

> 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 17:25:06 2017 Cannot load certificate file lcs/delentef.crt
> Fri Oct  6 17:25:06 2017 Exiting due to fatal error
>
> What solutions are there to this problem? Can I configure OpenSSL to
> accept this certificate after all?

https://fedoraproject.org/wiki/Changes/CryptoPolicy

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] DH_generate_key Hangs

[Jeffrey Walton]

>> 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 on-chip PRNG */
> OPENSSL_cpuid_setup();
> ENGINE_load_rdrand();
> rdrand = ENGINE_by_id("rdrand");
> if (rdrand) {
> int success = 0;
> if (ENGINE_init(rdrand)) {
> success = ENGINE_set_default(rdrand, ENGINE_METHOD_RAND);
> }
>
> /***
> Per OpenSSL wiki, call ENGINE_free here regardless of whether we're
> successfully using rdrand. The "functional reference" to rdrand will
> be released when we call ENGINE_finish.
> ***/
> ENGINE_free(rdrand);
> if (! success) ENGINE_finish(rdrand), rdrand = NULL;
> }
>
> if (!rdrand && !RAND_status()){
>   RAND_screen();   /* this isn't really emough entropy, but it's a start 
> */
>   if (!RAND_status()) {
>  RAND_poll();  /* try to gather additional entropy */
>   }
>}
> }
>
> void terminate_engines(void) {
>if (rdrand) ENGINE_finish(rdrand), rdrand = NULL;
>/* similarly for any other engines you use */
>ENGINE_cleanup();
> }
> -
>
> Call init_prng after your OpenSSL initialization code (e.g. after calling 
> OpenSSL_add_all_algorithms), and terminate_engines when you're done using 
> OpenSSL (e.g. just before process exit).
>
> Note that this code uses RAND_screen if RDRAND isn't available. RAND_screen 
> is really not a very good idea; it may be OK on workstations, but rarely 
> provides much entropy on servers because they typically aren't doing much 
> screen output. And if you still need entropy after the RAND_screen call, 
> you'll end up in RAND_poll anyway. The alternative is to write your own code 
> that harvests entropy from some source (or sources).
>
> Other people may have better suggestions.

Headless servers without hw entropy sources are tough. In this case I
use hedging. I've got some patches somewhere for 1.0.1, but they won't
apply to 0.9.8.

Also see:

* When Good Randomness Goes Bad: Virtual Machine Reset Vulnerabilities
and Hedging Deployed Cryptography,
http://pages.cs.wisc.edu/~rist/papers/sslhedge.pdf
* When Virtual is Harder than Real: Security Challenges in Virtual
Machine Based Computing Environments,
http://www.usenix.org/legacy/event/hotos05/final_papers/full_papers/garfinkel/garfinkel.pdf

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Hardware client certificates moving to Centos 7

[Jeffrey Walton]

>> 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

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

[Jeffrey Walton]

> 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
> 140492430772088:error:0906D06C:PEM routines:PEM_read_bio:no start
> line:pem_lib.c:707:Expecting: ANY PRIVATE KEY
>
> How do I tell it that the private key is DER?

-inform is used to specify the encoding. You can find the man pages at
https://www.openssl.org/docs/man1.0.2/apps/. You want the req.html.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] DH_generate_key Hangs

[Jeffrey Walton]

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 a patch ?
>
>
> It hangs on :
>
> libeay32.dll!RAND_poll() Line 523
>
> if (heap_first(,
>   hlist.th32ProcessID,
>   hlist.th32HeapID))

You should avoid calls to RAND_poll altogether on Windows. Do so by
explicitly seeding the random number generator yourself.

Also see https://wiki.openssl.org/index.php/Random_Numbers#Windows_Issues
on the OpenSSL wiki.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] DH_generate_key Hangs

[Jeffrey Walton]

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 Michael suggested, 0.9.8 is the biggest problem. You should
probably solve that problem first.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

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 unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Lattice Ciphers

[Jeffrey Walton]

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 would Thomas Paine, or Ben
> Franklin, or Patrick Henry say to this?

Off-topic, but... I was angry when I first read that, too.

Later I realized that was the best warning Google and Schmidt could
give. He basically told you government has infiltrated their systems,
and you should avoid their systems if security and privacy matters.

It is not just Google, but Google is the only one who has warned you.
Government has infiltrated other systems, including Apple, Amazon,
Microsoft, Saleforce, Rackspace and friends. You should be angry the
others have not warned you :)

Just avoid Google, Microsoft, Amazon and friends if your security and
privacy matters.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

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).

That's what Rich said: "X25519 is a key-exchange-only algorithm". The
shared secret that drops out of the x25519 key exchange is used to key
AES128/GCM (some hand waiving).

> Using openssl standard tools is it possible to generate a CSR through
> Ed25519 ?

This is a different application. ed25519 is signing, not key exchange.

I'm not sure how to do it because I've never needed it. But keep in
mind Rich said: "OpenSSL doesn’t fully support Ed25519".

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

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
> platform: debian-amd64
> options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
> compiler: cc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS
> -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack
> -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
> -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
> -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM
> -DGHASH_ASM -DECP_NISTZ256_ASM
> OPENSSLDIR: "/usr/lib/ssl"
>
> Since the putput above does not have OPENSSL_NO_HEARTBEATS, I assume
> heartbeats are not disabled in the build.
> So I am back to square one :( -> how do I make the server respond to a TLS
> heartbeat request ? Do I have to read the packet and write it back ?

You should also check  for OPENSSL_NO_HEARTBEATS.

$ cd openssl
$ grep -B 1 -A 1 HEART include/openssl/opensslconf.h
#endif
#ifndef OPENSSL_NO_HEARTBEATS
# define OPENSSL_NO_HEARTBEATS
#endif

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CMAC Authentication

[Jeffrey Walton]

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

CMAC is covered under EVP Signing and Verifying. See
https://wiki.openssl.org/index.php/EVP_Signing_and_Verifying .

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

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
>>> as a restriction on the allowed extended key usages of leaf certificates
>>> that can be issued by that CA.
>>>
>>> You should typically not specify extended key usage for CA certificates
>>> at all, unless you mean to restrict them to specific purposes.
>>
>> The behavior is inconsistent with RFC 5280:
>>
>> 4.2.1.12.  Extended Key Usage
>>
>>   This extension indicates one or more purposes for which the certified
>>   public key may be used, in addition to or in place of the basic
>>   purposes indicated in the key usage extension.  In general, this
>>   extension will appear only in end entity certificates.  This
>>   extension is defined as follows ...
>
> We're well aware of this, but this is the de-facto behaviour of
> multiple implementations.  This is an area in which RFC5280 fails
> to match the real world.

Apparently everyone did not get the memo :)

Maybe OpenSSL should allow users to choose between IETF issuing
policies and CA/Browser BR issuing policies.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

On Sun, Jan 21, 2018 at 1:31 PM, Viktor Dukhovni
 wrote:
>
> ...
> OpenSSL interprets the "extendedKeyUsage" extension in CA certificates
> as a restriction on the allowed extended key usages of leaf certificates
> that can be issued by that CA.
>
> You should typically not specify extended key usage for CA certificates
> at all, unless you mean to restrict them to specific purposes.

The behavior is inconsistent with RFC 5280:

4.2.1.12.  Extended Key Usage

   This extension indicates one or more purposes for which the certified
   public key may be used, in addition to or in place of the basic
   purposes indicated in the key usage extension.  In general, this
   extension will appear only in end entity certificates.  This
   extension is defined as follows ...

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

On Mon, Jan 22, 2018 at 1:44 AM, Gladewitz, Robert via openssl-users
 wrote:
>
> Thank you all for all the answers.
> The problem is that Cisco prescribes the attributes.
> ...
>
> Unfortunately, the Cisco CUCM telephone systems do not seem to accept 
> certificates without these attributes :-(.
>
> If I understand everything correctly, would the only (and unclean) workaround 
> be adding "TLS Web Client Authentication" to solve my problem?
>

I think you have a couple of choices.

First, you can downgrade to a version of OpenSSL that follows the RFC.
Second, you can patch OpenSSL to follow the RFC. Third, you can
implement the verify_callback and override the errant behavior.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

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/Browser BR issuing policies.
>
> The sensible thing at this point is to publish an update to RFC5280
> that accepts reality.

+1.

Add a Key-Interception usage while you're at it. Its a widespread practice too.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

On Mon, Jan 22, 2018 at 2:50 PM, Viktor Dukhovni
 wrote:
>
>
>> On Jan 22, 2018, at 12:07 PM, Gladewitz, Robert via openssl-users 
>>  wrote:
>>
>> the problem is, that i cant change the cisco implementation :-(.
>
> YOU DO NOT need to change the Cisco implementation.
>
>> Cisco tell me, the capf implemtation is following all rfc documents.
>
> Nothing Cisco is telling you requires your issuing CA to have an
> extended key usage listing just "TLS Web Server Authentication".
>
>> If you are right,
>> i cant use any freeradius implementation, because there are based on
>> openssl. There is no option in freeradius, to ignore some think like this.
>
> Your problem is a misconfigured CA certificate.  Make sure your *CA*
> certificate has no extended key usage specified, OR has *all* the key
> usages specified that are required by any leaf certificate it will issue.

This is wrong. The CA is not misconfigured.

>> For my understanding, CA certificate may have these exteded keys - it's just
>> something out of the ordinary.
>
> The extended key usages on the CA are interpreted to LIMIT the key usages
> of certificates it can issue.  You can certainly use this extension, but
> then expect the CA to be invalid for key usages you did not list.

This is wrong. The KU and EKU bits are not interpreted that way.

Here's the standards OpenSSL claims to implement:
https://www.openssl.org/docs/standards.html.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

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

My bad. Here's the corrected text:

This page is a partial list of the specifications that are
relevant to OpenSSL

I don't see CA/Browser Forums listed, but I do see RFC 3280 listed.

And there are no notes on issuing polices, which is the matter at
hand. No reasonable person would expect OpenSSL to cite 61 RFCs,
including the IETF's PKIX RFCs, and not use PKIX issuing policies.

I'm befuddled someone thought and others agreed it was OK to break a
worldwide standard. The purpose of the standard is to ensure
interoperability. The break is a throwback to the verify=false days
for folks who needs things to "just work".

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

On Mon, Jan 22, 2018 at 9:27 PM, Salz, Rich  wrote:
> ➢ I don't see CA/Browser Forums listed, but I do see RFC 3280 listed.
>
> The page also says it’s “casually maintained.”  Feel free to create a PR on 
> openssl/web repo. :)
>
> IETF RFC’s aren’t perfect; that’s why there are errata.  Dragging this all 
> the way to “we’re ignoring the words” is not nor accurate.  Someone who wants 
> to argue that OpenSSL is doing the wrong thing here, should go to the IETF 
> LAMPS WG and raise the issue.

If OpenSSL want to change the standard so that it aligns with the
project's implementation then the project should go to LAMP.
Otherwise, the project is acting without authority. OpenSSL cannot
arbitrarily decide to do something else on a suggestion or a whim.

You know, this issue could have been side stepped by providing both
behaviors, making one default, and allowing the user to make the
choice. Instead, the project wrapped its arms around the solution that
broke interop.

I can't help but wonder, doesn't anyone think these decisions through?

Thank god Andy has not broken AES interop by whitening AES keys
because some people think it is a good idea.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

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 implementation then the project should go to LAMP.
>> Otherwise, the project is acting without authority. OpenSSL cannot
>> arbitrarily decide to do something else on a suggestion or a whim.
>
> There is no "authority", nor is there an "Internet police".

"Authority" as in governance and policies and procedures.

>> You know, this issue could have been side stepped by providing both
>> behaviors, making one default, and allowing the user to make the
>> choice. Instead, the project wrapped its arms around the solution that
>> broke interop.
>
> Actually, IIRC Mozilla's NSS and Microsoft's CAPI do the same thing.
> So it is unclear where exactly we're breaking "interop".
>
>> I can't help but wonder, doesn't anyone think these decisions through?
>
> This was thought through and discussed.  I brought to the team's
> attention:
>
>
> http://www-archive.mozilla.org/projects/security/pki/nss/tech-notes/tn3.html

Apples and oranges. Browsers use the CA/B baseline requirements.

What does it have to do the the IETF, the RFCs and PKIX?

> I am sorry to hear that you're saddened by my lack of fealty to
> RFC5280, but I find real-world considerations more compelling.
> The OP in this thread has perfectly reasonable work-arounds,
> the main obstacle seems to be a language barrier more than
> anything else.

Yeah, the real world decision just decision just derailed the use of
crypto, not improve upon it.

I've seen this so many times in the past. It is the result of allowing
engineers drive requirements.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

On Tue, Jan 23, 2018 at 12:43 PM, Viktor Dukhovni
 wrote:
>
>
>> On Jan 23, 2018, at 7:31 AM, Gladewitz, Robert via openssl-users 
>>  wrote:
>>
>> Despite being wrong it is also absolutely irrelevant, because FreeRADIUS
>> retrieves the OpenSSL rejection of the cacert.capf.pem before any end-entity
>> certifcate is ever seen.
>
> This is almost certainly not the case.  Why would FreeRADIUS be validating
> a stand-alone CA certificate that is not part of a chain from a leaf
> certificate to a trust anchor?  The chain is validated for a particular
> purpose, presumably "TLS client" (the error message in the subject line of
> this thread is about the processing of a client certificate).
>
>> We now have a very plain cacert.capf.pem. It only shows the following
>> attributes:
>> X509v3 Key Usage: critical
>>Certificate Sign, CRL Sign
>> and things work.
>
> Great!  This confirms that the issue was the restricted EKU of the
> intermediate CA certificate.
>
>> So to sum up: there is a mistake, that we know of, but really it is not in
>> our hands to change it. And we do not need to change it, because it is of no
>> concern to the problem at hand.
>
> The previous CA certificate was explicitly not suitable for verifying TLS
> clients, based on the de facto interpretation of EKU in CA certificates in
> OpenSSL and various other TLS libraries.  So the issue was very much a
> "concern to the problem at hand".
>
>> Secondly the presented cacert.capf.pem is (by itself) a valid certificate.
>
> It is a valid intermediate CA certificate, that is (de facto) constrained
> to be used only for verifying for TLS server certificates, and NOT TLS
> client certificates.
>
>> It does not present a mistake. We should also not need to change it - but we
>> do. Why?
>
> You had to change it because you want to use this CA to issue TLS client
> certificates, and so its EKU needs to either be absent or to explicitly
> permit TLS client authentication.
>
>
>> Having read all the discussion i do not know why.
>
> Mostly because despite my best attempts to explain the above, perhaps
> a language barrier, and/or my inability to explain the issue sufficiently
> clearly, is preventing the reasons from being communicated effectively.
>
>> It is a CA certificate and Cisco somehow restricts this CA certificate to
>> a certain chosen purpose.
>
> Perhaps you mean that default software settings create such a certificate.
> If so, please raise this as a bug with the software vendor.  As you've
> already seen deploying a CA without an EKU works, so the previous EKU is
> not in fact a requirement.
>
>> OpenSSL should not interfere at this point.
>
> OpenSSL implements a widely practiced de facto CA certificate "purpose"
> policy based on the optional EKU extension in the CA certificate.  If
> you don't to restrict the purposes for which a CA can issue EE certificates
> (directly or indirectly), then DO NOT include an EKU in the CA certificate.
> If you do want to limit the CA to issue only certificates for particular
> purposes, then include all (and only) those purposes in the EKU.
>
> Good luck.  And thanks for reporting this, this discussion should
> help other users to quickly resolve similar issues in the future.

Your arguments are fallacious. How the browsers do things does not
constitute the "de facto" standard. Your just begging the claim.

The docs have _not_ changed: https://www.openssl.org/docs/standards.html.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

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

Related, the subject came up recently on the PKIX mailing list: "Next
edition of X.509",
https://www.ietf.org/mail-archive/web/pkix/current/msg33478.html .

https://www.ietf.org/mail-archive/web/pkix/current/msg33489.html was a
proposal to modify the text. The modifications appear to propose KU
and EKU cast a wider net to accommodate IoT gadgets.

https://www.ietf.org/mail-archive/web/pkix/current/msg33490.html was a
comment to avoid the modification. The objection stated to an OID for
the new usages to accommodate the use cases.

Another thread of interest from SAAG is "Considerations about the need
to resume PKIX work",
https://mailarchive.ietf.org/arch/msg/saag/BJWLw-XZvq_fgCYDldCDLVamNbg

There does not seem to be a lot of interest in revising PKIX. I
persoanlly find it disappointing because it seems like it is the wild,
wild west to me.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

On Tue, Jan 23, 2018 at 4:33 PM, Salz, Rich  wrote:
> On Tue, Jan 23, 2018 at 3:45 PM, Salz, Rich  wrote:
> > ➢ The docs have _not_ changed: 
> https://www.openssl.org/docs/standards.html.
> >
> > Nor is there any need for that page to change.  READ WHAT IT SAYS.
>
> ➢ I'm surprised you are arguing against clear documentation on behaviors.
>
> There is no need to be surprised, because I am not doing that.
>
> The webpage says “here’s a casually-maintained list of related standards or 
> other useful information.”  What on that webpage is wrong?
>
> You seem to be very very VERY upset by how OpenSSL implements one particular 
> part of RFC 5280.  Viktor has shown that it’s not just us, it’s other code as 
> well.  The original poster was able to live with OpenSSL’s implementation.  
> You don’t like that code.  So be it.

If that's your survey of the situation then it is wrong.

No wonder Henson and Marquess left the project. I would get tired of
the games, too.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

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

I'm surprised you are arguing against clear documentation on behaviors.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

What option is not recognized by OpenSSL 1.1.1d?

[Jeffrey Walton]

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 the
options are supported.

Which option is not recognized by OpenSSL 1.1.1d?

Thanks in advance.

bn_ops not being used in Android recipes

[Jeffrey Walton]

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 supplied with the library that leads to a failed
compile under NDK-r20.

 Android...
my %targets = (
"android" => {
inherit_from => [ "linux-generic32" ],
template => 1,
bin_cflags   => add("-fPIE"),
bin_lflags   => add("-pie"),
enable   => [ ],
},

"android-arm" => {
inherit_from => [ "android", asm("armv4_asm") ],
bn_ops   => add("BN_LLONG RC4_CHAR"),
},
"android-arm64" => {
inherit_from => [ "android", asm("aarch64_asm") ],
bn_ops   => add("SIXTY_FOUR_BIT_LONG RC4_CHAR"),
perlasm_scheme   => "linux64",
},

"android-x86" => {
inherit_from => [ "android", asm("x86_asm") ],
CFLAGS   => add(picker(release => "-fomit-frame-pointer")),
bn_ops   => add("BN_LLONG RC4_INT"),
perlasm_scheme   => "android",
},
"android-x86_64" => {
inherit_from => [ "android", asm("x86_64_asm") ],
bn_ops   => add("SIXTY_FOUR_BIT_LONG RC4_INT"),
perlasm_scheme   => "elf",
},
);

It looks like bn_ops are not being honored. For example, OpenSSL was
configured for android-x86_64, but SIXTY_FOUR_BIT_LONG and RC4_INT are
missing:

x86_64-linux-android23-clang -I. -Icrypto/include -Iinclude -fPIC
-pthread -march=x86-64 -msse4.2 -mpopcnt -mtune=intel -funwind-tables
-fexceptions 
--sysroot=/home/travis/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot
-DOPENSSL_USE_NODELETE -DOPENSSL_PIC
-DOPENSSLDIR="\"/home/travis/android23-x86_64\""
-DENGINESDIR="\"/home/travis/android23-x86_64/lib/engines-1.1\""
-DNDEBUG -D__ANDROID_API__=23 -MMD -MF crypto/bn/bn_add.d.tmp -MT
crypto/bn/bn_add.o -c -o crypto/bn/bn_add.o crypto/bn/bn_add.c

x86_64-linux-android23-clang  -I. -Icrypto/include -Iinclude -fPIC
-pthread -march=x86-64 -msse4.2 -mpopcnt -mtune=intel -funwind-tables
-fexceptions 
--sysroot=/home/travis/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot
-DOPENSSL_USE_NODELETE -DOPENSSL_PIC
-DOPENSSLDIR="\"/home/travis/android23-x86_64\""
-DENGINESDIR="\"/home/travis/android23-x86_64/lib/engines-1.1\""
-DNDEBUG -D__ANDROID_API__=23 -MMD -MF crypto/bn/bn_asm.d.tmp -MT
crypto/bn/bn_asm.o -c -o crypto/bn/bn_asm.o crypto/bn/bn_asm.c
crypto/bn/bn_asm.c:28:9: warning: shift count >= width of type
  [-Wshift-count-overflow]
mul_add(rp[0], ap[0], w, c1);
^~~~
crypto/bn/bn_lcl.h:475:14: note: expanded from macro 'mul_add'

(c)= Hw(t); \
 ^
crypto/bn/bn_lcl.h:469:36: note: expanded from macro 'Hw'
#  define Hw(t)(((BN_ULONG)((t)>>BN_BITS2))_MASK2)

The full build is available at
https://travis-ci.org/noloader/unbound/jobs/659771319.

How do I get the machinery to use bn_ops?

Jeff