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

classic Classic list List threaded Threaded
53 messages Options
123
Reply | Threaded
Open this post in threaded view
|

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

OpenSSL - User mailing list
Dear helpful people,

The problem is now solved by a workaround based on a new CAPF certificate.
That is that.

Concerning the discussion here, i (representing my supervisor) would like to
pinpoint 2 facts that arouse:

First and foremost the attached cacert.capf.pem is based on a Cisco __System
generated__ CSR and results in a certificate with the attributes:
X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
X509v3 Extended Key Usage: critical
                TLS Web Server Authentication
                                                               
This very certificate is than used by the Cisco __system__ to issue
telephone/end-entity certificates in the likes of the attached
SEPxxxxxxx-L1.pem. These end-entity certificates have the following
attributes:
X509v3 Key Usage
  Digital Signature, Key Encipherment
X509v3 Extended Key Usage
  TLS Web Server Authentication, TLS Web Client Authentication, IPSec End
System

This is just wrong and we know that. But the Cisco System does it anyway.
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.

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

Secondly the presented cacert.capf.pem is (by itself) a valid certificate.
It does not present a mistake. We should also not need to change it - but we
do. Why? Having read all the discussion i do not know why. It is a CA
certificate and Cisco somehow restricts this CA certificate to a certain
chosen purpose. It is also ok to issue an intermediate CA certificate with
pathlen=5 and then issue right beneath it a intermediate CA certificate with
pathlen=0 instead of 4 to further restrict.
Restriction is a tool to reach more secure environments. The keyUsage
attributes are a way to use the tool of restriction. OpenSSL should not
interfere at this point.
This is my take on this topic.

I do thank you very much for your help and effort. Even if some of you see
the topic different, i like the fact that we discussed this really vividly.

Robert

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

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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-3
In reply to this post by OpenSSL - User mailing list
On Sun, Jan 21, 2018 at 6:38 PM, Salz, Rich via openssl-users
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Viktor Dukhovni
In reply to this post by OpenSSL - User mailing list


> On Jan 23, 2018, at 7:31 AM, Gladewitz, Robert via openssl-users <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: 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-3
On Tue, Jan 23, 2018 at 12:43 PM, Viktor Dukhovni
<[hidden email]> wrote:

>
>
>> On Jan 23, 2018, at 7:31 AM, Gladewitz, Robert via openssl-users <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Viktor Dukhovni


> On Jan 23, 2018, at 3:07 PM, Jeffrey Walton <[hidden email]> wrote:
>
> Your arguments are fallacious. How the browsers do things does not
> constitute the "de facto" standard. Your just begging the claim.

You're trolling. I'm no longer playing along, better things to do...

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

OpenSSL - User mailing list
In reply to this post by Jeffrey Walton-3
➢     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.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 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-3
On Tue, Jan 23, 2018 at 3:45 PM, Salz, Rich <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

OpenSSL - User mailing list
On Tue, Jan 23, 2018 at 3:45 PM, Salz, Rich <[hidden email]> 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.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 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-3
On Tue, Jan 23, 2018 at 4:33 PM, Salz, Rich <[hidden email]> wrote:

> On Tue, Jan 23, 2018 at 3:45 PM, Salz, Rich <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

OpenSSL - User mailing list
>    > 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.
   
Okay, please post a correction.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

OpenSSL - User mailing list
In reply to this post by Viktor Dukhovni
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:[hidden email]] Im Auftrag von
Viktor Dukhovni
Gesendet: Dienstag, 23. Januar 2018 18:44
An: [hidden email]
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
<[hidden email]> 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

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

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Viktor Dukhovni


> On Jan 24, 2018, at 1:33 AM, Gladewitz, Robert via openssl-users <[hidden email]> wrote:
>
> 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.

Can you be a bit more explicit as to why these users cannot deploy a
certificate chain via an alternate CA that does not have a problem EKU
(just as you did)?  Is it not possible to replace the intermediate CA
certificate with one that either has no EKU or has a more complete
EKU that lists both "serverAuth" and "clientAuth" (shorter OpenSSL
names for the EKUs under discussion).

There are surely some Cisco Engineers reading this list.  Ideally
someone from Cisco will reach out to the OpenSSL team (say myself)
and we can help them update the product to avoid compatibility issues.
I've posted a feedback comment at:

  https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/212214-Tech-Note-on-CAPF-Certificate-Signed-by.html#anc7

Perhaps they'll reach out.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

OpenSSL - User mailing list

Hello Viktor,

By default, many users use the CAPF certificates that themselves issue the
CUCM devices. This means that the call managers will sign their own Reqest.
For the users only the download of the CAPF certificates remains - a change
of the iku is not possible any more.

Replacing the CAPF certificates is no small expense. There seem to be many
problems and dependencies. Our service provider needed more than two days to
implement this cleanly with us. In addition, there are the risks that
authentication at the infrastructure switches will fail and make phone calls
throughout the enterprise no longer possible.


Robert


-----Ursprüngliche Nachricht-----
Von: openssl-users [mailto:[hidden email]] Im Auftrag von
Viktor Dukhovni
Gesendet: Mittwoch, 24. Januar 2018 08:11
An: [hidden email]
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 24, 2018, at 1:33 AM, Gladewitz, Robert via openssl-users
<[hidden email]> wrote:
>
> 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.

Can you be a bit more explicit as to why these users cannot deploy a
certificate chain via an alternate CA that does not have a problem EKU (just
as you did)?  Is it not possible to replace the intermediate CA certificate
with one that either has no EKU or has a more complete EKU that lists both
"serverAuth" and "clientAuth" (shorter OpenSSL names for the EKUs under
discussion).

There are surely some Cisco Engineers reading this list.  Ideally someone
from Cisco will reach out to the OpenSSL team (say myself) and we can help
them update the product to avoid compatibility issues.
I've posted a feedback comment at:

 
https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-co
mmunications-manager-callmanager/212214-Tech-Note-on-CAPF-Certificate-Signed
-by.html#anc7

Perhaps they'll reach out.

--
        Viktor.

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

smime.p7s (8K) Download Attachment
123