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

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:openssl-users-bounces at openssl.org] Im Auftrag von
Viktor Dukhovni
Gesendet: Mittwoch, 24. Januar 2018 08:11
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 24, 2018, at 1:33 AM, Gladewitz, Robert via openssl-users
<openssl-users at openssl.org> 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
-------------- 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/23cfedac/attachment.bin>