[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-users at dukhovni.org> wrote:
>
>
>> On Jan 22, 2018, at 9:39 PM, Jeffrey Walton <noloader at 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