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:f...@frank4dd.com] Gesendet: Samstag, 20. Januar 2018 13:54 An: Gladewitz, Robert <robert.gladew...@dbfz.de> 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<mailto:robert.gladew...@dbfz.de> Saturday, January 20, 2018 8:29 PM Hello Frank, why it is wron for an ca cert? Robert Von: Frank Migge [mailto:f...@frank4dd.com] Gesendet: Samstag, 20. Januar 2018 04:10 An: openssl-users@openssl.org<mailto:openssl-users@openssl.org> Cc: Gladewitz, Robert <robert.gladew...@dbfz.de><mailto:robert.gladew...@dbfz.de> 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<mailto:f...@frank4dd.com> 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<mailto:f...@frank4dd.com> 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<mailto:openssl-users@openssl.org> 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=supp...@dbfz.de<mailto:ROOT/emailAddress=supp...@dbfz.de>" (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
