Re: 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 via openssl-users" <openssl-users@xxxxxxxxxxx>]

Hallo Frank,

 

this are bad news. The Cisco CAPF CA certifiace need TLS Web Server Authentification.

 

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

 

You mean, i sign the cert request new with adding anyExtendedKeyUsage will be work? Ir kann the root ca add the same extendedKeyUsage and resign byself?

 

Robert

 

 

 

Von: Frank Migge [mailto:fm@xxxxxxxxxxxx]
Gesendet: Samstag, 20. Januar 2018 13:54
An: Gladewitz, Robert <Robert.Gladewitz@xxxxxxx>
Betreff: Re: AW: [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

 

Hi Robert,

Lets see if I get it right. Please correct me if I am misinterpreting.

If an extended key usage extension such as "TLS Web Server Authentication" is set in the intermediate, its purpose conflicts with the signing purpose of an (intermediate) CA cert.

RFC8250 mentions that extended key usage extension (EKU) is only meant for end entity certificates (e.g. client or server certs). If both key key usage extensions (KU) and EKU extensions exist, both need to be checked for a consistent purpose. The EKU above could create a conflict of purpose with the KU before.  In that case, the RFC requires the cert not to be used at all.

In simpler words: CA certificates can't/shouldn't be also used as client or server certs, and vice versa. However, it seems that Cisco is doing exactly that, trying to achieve both functions in a single cert.

This RFC violation(?) may work in a closed Cisco-world, but could fail against other products, such as FreeRadius/OpenSSL.

That it used to work with an older Debian under OpenSSL 1.0.1 may have been luck. Victor mentioned that some changes to chain verification happened in versions 1.1.0 and beyond.

What could be done?

RFC 5280 mentions a "work-around". If the CAPF cert could be created outside of Cisco, replacing existing or adding the specific EKU called "anyExtendedKeyUsage", so it could act as a "wildcard"? Not sure if it would fix it (or breaks the Cisco side instead), and if indeed above problem is your issue, but it may be worth a try.

Frank

Gladewitz, Robert

Saturday, January 20, 2018 8:29 PM

Hello Frank,

 

why it is wron for an ca cert?

 

Robert

 

Von: Frank Migge [mailto:fm@xxxxxxxxxxxx]
Gesendet: Samstag, 20. Januar 2018 04:10
An: openssl-users@xxxxxxxxxxx
Cc: Gladewitz, Robert <Robert.Gladewitz@xxxxxxx>
Betreff: 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

 

I got it wrong. The failing cert from your log is actually the intermediate, which has five extensions:

>> Object 00: X509v3 Subject Key Identifier: 58:A4:EB:D9:DD:CE:A2:99:72:3B:E1:20:19:1D:40:C1:F9:D5:C2:28
>> Object 01: X509v3 Authority Key Identifier: keyid:E2:E9:20:42:29:83:C4:77:8C:87:AB:FA:4B:A1:A9:C4:CE:00:BD:39
>> Object 02: X509v3 Basic Constraints: CA:TRUE, pathlen:0
>> Object 03: X509v3 Key Usage: Digital Signature, Certificate Sign, CRL Sign
>> Object 04: X509v3 Extended Key Usage: TLS Web Server Authentication

This is were I would check first.

I am not fully sure, but believe that Extended Key Usage should *not* be there.

Frank

 

Frank Migge

Saturday, January 20, 2018 12:09 PM

I got it wrong. The failing cert from your log is actually the intermediate, which has five extensions:

>> Object 00: X509v3 Subject Key Identifier: 58:A4:EB:D9:DD:CE:A2:99:72:3B:E1:20:19:1D:40:C1:F9:D5:C2:28
>> Object 01: X509v3 Authority Key Identifier: keyid:E2:E9:20:42:29:83:C4:77:8C:87:AB:FA:4B:A1:A9:C4:CE:00:BD:39
>> Object 02: X509v3 Basic Constraints: CA:TRUE, pathlen:0
>> Object 03: X509v3 Key Usage: Digital Signature, Certificate Sign, CRL Sign
>> Object 04: X509v3 Extended Key Usage: TLS Web Server Authentication

This is were I would check first.

I am not fully sure, but believe that Extended Key Usage should *not* be there.

Frank

Frank Migge

Saturday, January 20, 2018 11:29 AM

Hi Robert,

error 26 : unsupported certificate purpose

It seems the cert gets declined because of a problem with cert

extensions. "keyUsage" or "extendedKeyUsage" are typical candidates. In

your case, the leaf certificate "CAPF-91d43ef6" has two extensions:

Object 00: X509v3 Key Usage

  Digital Signature, Key Encipherment

Object 01: X509v3 Extended Key Usage

  TLS Web Server Authentication, TLS Web Client Authentication, IPSec End System

I would check if an extension is now missing/newly required, or no

longer recognized. Try check for differences in the openssl.cnf and

freeradius config files between the old Debian system and the new one.

Some EAP TLS guides (incl. Cisco) also list extensions "nonRepudiation" and "dataEncipherment", but this is just a guess since you mentioned it works on the old system.

I have some problems with new Cisco CAPF certs

What is the authenticating device? Cisco IP phone?

Cheers,

Frank

Gladewitz, Robert via openssl-users

Friday, January 19, 2018 11:12 PM

Dear OpenSSL Team,

 

I have some problems with new Cisco CAPF certs and freeradius tls authentification. The point is, that freeradius users see the problem on openssl implemtiation.

 

<SNIP: DEBUG>

(69) eap_tls: Continuing EAP-TLS

(69) eap_tls: Peer indicated complete TLS record size will be 1432 bytes

(69) eap_tls: Got complete TLS record (1432 bytes)

(69) eap_tls: [eaptls verify] = length included

(69) eap_tls: TLS_accept: SSLv3/TLS write server done

(69) eap_tls: <<< recv TLS 1.0 Handshake [length 03c2], Certificate

(69) eap_tls: Creating attributes from certificate OIDs

(69) eap_tls:   TLS-Cert-Serial := "1009"

(69) eap_tls:   TLS-Cert-Expiration := "380111125719Z"

(69) eap_tls:   TLS-Cert-Subject := "/C=DE/ST=Sachsen/L=Leipzig/O=DBFZ Deutsches Biomasseforschungszentrum gGmbH/OU=IT/CN=CAPF-91d43ef6"

(69) eap_tls:   TLS-Cert-Issuer := "/C=DE/ST=Sachsen/L=Leipzig/O=DBFZ Deutsches Biomasseforschungszentrum gemeinnuetzige GmbH/OU=IT/CN=DBFZ CA INTERN ROOT/emailAddress=support@xxxxxxx"

(69) eap_tls:   TLS-Cert-Common-Name := "CAPF-91d43ef6"

(69) eap_tls:   ERROR: SSL says error 26 : unsupported certificate purpose

(69) eap_tls: >>> send TLS 1.0 Alert [length 0002], fatal unsupported_certificate

(69) eap_tls: ERROR: TLS Alert write:fatal:unsupported certificate

tls: TLS_accept: Error in error

(69) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

(69) eap_tls: ERROR: System call (I/O) error (-1)

(69) eap_tls: ERROR: TLS receive handshake failed during operation

(69) eap_tls: ERROR: [eaptls process] = fail </DEBUG>

</SNIP>

 

This means, that the check of ca certificate is failed. So, bu I do not see, why. If i check the certificate by command openssl –verify, all sems to be right.

# openssl verify -verbose -CAfile /etc/freeradius/3.0/certs.8021x.ciscophone/cacert.capf.pem SEP64A0E714844E-L1.pem

# SEP64A0E714844E-L1.pem: OK

 

 

The openssl version is Debian based 1.1.0g-2. But the same error is happening on 1.1.0f also.

 

Older freeradius version 2 on Debian 8/openssl 1.0.1t-1+deb8u7 working fine without this problem (by using the same certificates)

 

The ca certificate are signed by an intern ca. Can anyone see the error??

 

Robert

 

 

 

 

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