[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

[Gladewitz, Robert]

Hallo Voktor,

I had contact with the Freeradius group in this regard. At first we also
assumed that something is wrong with the client certificate. But in TLS
Freeradius uses the OpenSSL standard functions to identify and verify the
client certificate. Exactly here only the CA certificate including the
certificate chain is checked - then only in the second step, whether the
certificate sent by the client belongs to the CA certificate.

Yes, the language barriers are problematic - thanks anyway for your help.

Nevertheless, a problem remains open for the Cisco CUCM users. If these use
the certificate internally signed by Cisco, the attributes are set as in the
discussion and can not be subsequently adapted in our case. This means that
for these users only the change to a non openssl based application remains -
really sad.

Robert


-----Ursprüngliche Nachricht-----
Von: openssl-users [mailto:openssl-users-bounces at openssl.org] Im Auftrag von
Viktor Dukhovni
Gesendet: Dienstag, 23. Januar 2018 18:44
An: openssl-users at openssl.org
Betreff: 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 Jan 23, 2018, at 7:31 AM, Gladewitz, Robert via openssl-users
<openssl-users at openssl.org> 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.

-- 
	Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6245 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180124/8ed1094a/attachment-0001.bin>